Skip to content
Registry StackDocsv0.34.0
Search

Registry Casework overview

View as Markdown

Registry Casework gives an authorized human team one coordinated inbox: over work a source system owns, such as a governed change request a Base Registry Engine (BReg) holds, and over bounded decisions a calling service submits directly. Casework keeps the coordination: which queue a work item sits in, who holds it, what was drafted, and who decided; the source keeps eligibility, current visibility, and the record change itself.

If your team decides on registry change requests, or on decisions another service submits and waits for, Casework is where that work is held, routed, and recorded. Staff claim one item at a time and record an outcome, Supervisors assign work and cover absence, Administrators maintain the directory of teams and served queues, and a Requester service reads back only the items it created. The Registry App Kit is a separate project that provides a staff interface for BReg-backed work, and a standalone deployment calls the HTTP API from its own host.

sequenceDiagram
    participant R as Requester service
    participant C as Registry Casework
    participant S as Staff
    participant V as Supervisor

    R->>C: Create one request under an admitted review kind
    C->>C: Pin policy identity and submission digest
    S->>C: Claim the first review task
    S->>C: Record one declared outcome with a reason
    R->>C: Poll the result or result feed
    C-->>R: Return the terminal result without reviewer identity
    V->>C: Resolve one protected accountability event
    Note over C: Polling-only producers configure no completion destination

A submitted-context review request lives in Casework, and the policy pinned at acceptance fixes what it can become. Publishing a changed policy later shapes new requests and leaves the accepted request unchanged. The producer reads its own results from polling or the result feed; a Supervisor who leads a serving team resolves protected accountability through a separate audited route. A source-backed item follows the same path with the registry in the loop: every field a caller sees comes from a read made for that caller, and the decision reaches the registry as an attempt made with the person’s own token and selected source profile.

Make your first request

Section titled “Make your first request”

Put a local deployment on your machine:

Terminal window
curl -fsSL https://github.com/registrystack/registry-stack/releases/latest/download/casework-install.sh | bash
caseworkctl init tutorial-work/casework --template standalone-decision
caseworkctl dev tutorial-work/casework

The installer verifies the release SHA256SUMS before it installs casework and caseworkctl into ~/.local/bin. The standalone-decision template writes a project that declares one review kind and admitted producer and needs no registry behind it. caseworkctl dev starts PostgreSQL in a container, starts the maintained stock identity provider and casework, seeds the directory, and prints a report carrying a ready status, the service URL, the token endpoint, and one credential directory per local client.

Decide your first work item takes it from there: submit one review as a producer, claim and decide its task as Staff, and read the result back.

Choose your role

Section titled “Choose your role”
What you want to doWhere to start
Author a policy: review kinds, producers, sources, routing rules, and clocksAuthor a Casework policy
Run a deployment: database, runtime file, directory, and recoveryDeploy Registry Casework
Understand the model behind an itemHow Registry Casework works
Integrate a Requester serviceRegistry Stack client API reference and the Registry Casework API

Where the product stops

Section titled “Where the product stops”

Casework decides one item at a time, by one accountable person, against the policy pinned on that item. There are no bulk decisions and no automatic outcomes, and a second opinion is a delegation or an assignment, both recorded on the item. Clocks do act on a running item: when an authored reminder or due step falls due, Casework reads the source afresh, then records the reminder or moves the item to the queue the step names, under the actor system:clock. Those effects stay inside the item, because Casework delivers nothing outward and sends no message to a person or a system.

Casework serves an API and renders no interface of its own. A browser never calls it directly: a staff host calls Casework server to server on a private network, which is why the API enables no CORS. It issues no tokens and stores no users, so identity stays with your OpenID Connect provider.

Next

Section titled “Next”