Registry Casework overview

If people in your institution must answer or approve something before another system acts on it, Registry Casework gives them that review and returns their answer to the system that asked.

What a producer gets

A producer is the system that needs the answer. It sends a ReviewRequest naming the subject and the policy to review it under, and later reads one ReviewResult: the outcome, any public reason, and the exact subject and policy it answers. The result never names the reviewer. A retry under the same idempotency key returns the first request, not a second.

What you define

You write a ReviewPolicy in YAML: the stages a request passes through, which people decide each stage and how many must approve, the outcomes a Decision may record, what reviewers see, which producers may ask, and the deadlines that apply. caseworkctl checks the policy offline and pins it to a digest before any request uses it.

What runs

casework is an HTTP service that keeps review state in PostgreSQL and verifies tokens from your own OpenID Connect issuer. Reviewers claim and decide tasks through its API, so your application supplies their screens. A request stays reviewing until a decision settles it as approved, rejected, changes-requested or answered, or until its producer cancels it or supersedes it with a replacement.

What Casework refuses

Casework refuses an untrusted producer, a stale policy pin, an ineligible reviewer, and a decision against a changed task, and it never writes to the source; How Casework works explains each boundary.

When it is not the right product

Casework is for human judgment. A check a program can make from data belongs in the producer or in an Registry Evidence assertion, and a change to a registry stays with that registry, which decides whether to apply an approved review.

Where to start

Decide your first ReviewRequest runs Casework on your machine and takes one request to a decision in about 20 minutes.