You have taken one ReviewRequest to a decision. These five questions explain what happened in each step, and what changes when a policy has more stages, a live source, or deadlines.
Who calls Casework, and on whose authority?
Section titled “Who calls Casework, and on whose authority?”Three parties authenticate independently. The producer is
the system that sends a ReviewRequest; your project trusts one, requester, under
trustedProducers, bound to an issuer, a subject, the source namespaces it may name, and the
policies it may ask for. The human reviewer is a person holding a staff or supervisor access
profile. The downstream executor is whatever system later acts on the answer, under its own
authority.
Each sends its own token and selects one access profile per request; Casework never combines two profiles, and a producer’s authority never supplies a reviewer’s. That is why the producer in your first review was refused the task: it may read its result, never the human work. An administrator maintains the directory and the holiday calendars, and an operator activates packages, but only a staff or supervisor profile can decide.
What does a ReviewRequest bind?
Section titled “What does a ReviewRequest bind?”A producer selects a ReviewPolicy by id, and may also
pin its version and digest. When Casework accepts the request it freezes the concrete binding,
so a later policy change never reinterprets work already admitted. A request that named only the
ID is bound to whatever is active at that moment; a request that pinned a version and digest is
refused with review.policy-mismatch if they are not the active ones.
The request also binds its subject by source, type, id, version, and a content digest.
That digest is the producer’s own fingerprint of the version it asks about. Casework does not
recompute it; it carries it into the task and the result, so the producer can tell which version
was reviewed. The acceptance returns a submissionDigest over the producer, its source namespace,
and the whole request. A retry with the same Idempotency-Key recovers that acceptance instead of
creating a second request.
Where does the reviewer’s context come from?
Section titled “Where does the reviewer’s context come from?”A policy chooses one of two custody models.
With context.mode: submitted, as in your project, the producer sends a snapshot that Casework
validates against the policy’s displaySchema and keeps. Casework needs no source service, and
the snapshot is review input, not current source data.
With context.mode: current-source, the policy names a
context provider, the source’s read-only review
interface. Casework keeps an exact reference and task metadata, never the source’s data. Each time
a reviewer opens a task, Casework asks the source again under that reviewer’s own credential.
When the source conceals the subject or its version moved, Casework refuses the read rather than
show stale data.
Either way the source keeps its data and its disclosure. Casework holds no write or apply authority over the source, so a review never becomes a change there by itself.
Who decides, and when does a request settle?
Section titled “Who decides, and when does a request settle?”A policy’s stages run in order. Each names its queue, the profiles that may decide, and how many independent reviewers must approve. When a stage becomes active, Casework creates a ReviewTask. A person reaches it only as a member of a team that serves the queue in the directory, holding a deciding profile, and not excluded as the initiator or an earlier stage’s reviewer. The policy declares which queues and teams exist; the directory, which an administrator keeps at runtime, says who is in each team.
A reviewer claims a task at the revision they read, and every
claim and decision is fenced by that revision, so a decision made on a stale read is refused.
Approvals that meet a stage’s threshold advance the request, or settle it as approved at the last
stage. A rejection, a request for changes, or an answer settles it at once. A request also leaves
reviewing without any reviewer when its producer cancels it, or supersedes it by sending a
replacement for the same subject and policy.
A clock measures a subject or a stage against a deadline, in elapsed hours or in working days on a calendar. It can mark work at risk, send a reminder, or move a due task to another queue. It never decides an outcome.
What comes back, and for how long?
Section titled “What comes back, and for how long?”The ReviewResult repeats the subject, the policy
binding, and the submissionDigest, so the producer can match it to its request, and adds a
terminal status, the outcome, any public reason, and any structured result the policy
requires. It never names the reviewer or carries the reviewer’s private reason, which stays in
Casework’s accountability record.
The policy’s terminalRetentionDays bounds how long the producer can read the result, which is
the availableUntil you saw. accountabilityRetentionDays, never shorter, bounds the record of
who decided. Maintenance erases each once it expires.