A human signs the scope. The workflow can only do what the mandate says

A Work Mandate is a document a person writes and signs before any agent touches it: which tools or workflows it authorizes (its scope), the conditions that let a case continue automatically, the triggers that instead route a case to a human, and a validity window. An unsigned mandate is a draft. It carries no authority until a real signature exists over the whole artifact, and that signature's target, the mandate's own hash, becomes the identifier every later stage points back to.

The loop is not four separate systems glued together. Every stage produces one hash-identified artifact the next stage reads: the mandate hash, then the run's own receipt, then, only on the escalation branch, a record hash and its closure. Each of the panels below walks one of those stages with a real, shipped example.

The Work Mandate Compiler reads the mandate's scope and turns it into an ordered list of workflow steps. It reads the mandate's conditions and escalation triggers, which must all point at the same one field of the run's output, and turns each into a routing rule on the one checkpoint step where they apply. Escalation triggers compile first, each routing to the reserved target escalate; passing conditions compile after, routing to the next step. Whatever value matches neither, by construction, still needs somewhere to go: the compiler sets that fallback to escalate as well, so an unrecognized case defaults to a person rather than to silent continuation.

That example is not illustrative shorthand: it is the compiler's own worked conformance fixture, proven under the suite's compute-integrity profile, so the diagram above is a real gate object, not a mockup of one. Mandates whose conditions and triggers disagree on which field they read are rejected outright at compile time, before a rule is ever generated, so a policy that cannot be expressed as one routing decision never silently becomes one anyway.

A run under a mandate folds the mandate's hash into every step's inputs and into the run's own summary, a conditional field present only when a mandate actually governed that run, so the finished receipt proves which policy was in force rather than merely claiming one existed. Each step is one deterministic computation with its own hash; a passing case runs every step in order and finishes with one combined hash over the steps that ran.

A case that trips an escalation trigger does not finish that way. The gate routes to the reserved target, and the run halts immediately: no further step executes. Every step that would have followed is marked with a distinct status showing it was skipped because of an escalation rather than skipped because of an ordinary routing decision, and an open record is emitted describing exactly which decision fired and exactly which steps never ran.

The open record's hash is computed only over the deterministic parts, the triggering decision and the list of halted steps, never over the moment the halt happened. That single choice is what lets a verifier confirm two escalations were caused by the exact same input, independent of when either one occurred.

An open record is where the loop hands control back to a person: the routine path never reaches a human at all, and the exception path never resolves without one. Closing a record means signing over its hash with a passkey, a WebAuthn assertion tied to one named device, and stating a decision of either approve or reject. That signed envelope is itself a receipted artifact, checkable the same offline way as anything else in the estate.

Each of those four checks is independent: the recomputed record hash has to match what the record actually contains, the signed envelope has to name that exact hash, the passkey signature has to verify, and the stated decision has to be one of the two allowed values. Mutating the halted-step list, the triggering decision, or the record hash itself in isolation fails the corresponding check every time, which is what makes the closure tamper-evident rather than merely signed.

Nothing in the loop above requires the party holding a mandate to be a person acting directly. It can be an agent that was itself delegated authority by someone else, and when that is the case, the delegation has its own verifiable chain, separate from the mandate's own signature.

Checking either chain never resolves a live document over the network and never operates the witness infrastructure that anchors the identifier in the first place; it verifies the log or the credential chain it is handed, structurally, the same offline discipline as every other check on this page. KERI, the identity model both formats build on, together with ACDC and its CESR encoding, was ratified by the Trust over IP Foundation in January 2026, the named precedent for delegated sponsorship this loop follows rather than invents.

The five panels above describe real, shipped mechanisms. None of them add up to more than what follows, and this panel is deliberately as prominent as the others rather than a footnote at the bottom of the page.