Governed Workflow State Graph

Where it fits

For a workflow where an organisation must later answer: what was decided, what evidence was in scope, which policy applied, who approved it, and whether a retry could repeat an effect.

Regulated approvals

Bind a reviewer’s approval to one policy version, one input, and one evidence set — so a later policy change or a revised document cannot silently inherit it.

Procurement

Require a bounded approval before an agent may prepare a purchase action, and make a lower-level exception incapable of widening what a tenant-level policy forbids.

Claims and policy review

Adjudicate against a named evidence set, with unresolved questions declared rather than absorbed into the decision.

Agentic actions

Record the intended effect, the receipt, the uncertainty, and the recovery path — so a retry after an interruption cannot quietly become a second effect.

What it guarantees

Each of these is enforced by the shape of the model rather than by convention, and each is covered by a test that attacks it.

• Approvals bind, or they do not apply. The approval is addressed by its content — instance, transition, policy version, input digest, evidence digest set. Change the evidence and the old approval is not found rather than silently reused.
• A repeat is not a re-run. The same idempotency key returns the original record and produces no second intent. A repeat with changed material inputs is rejected outright.
• Uncertainty is declared, not absorbed. A blocking or unresolved question routes to a human. A signed exception cannot override it.
• An escalation can be resolved — only by a human. Agents are refused. Terminal states are shut to everyone.
• Documents stay outside the record. The durable event shape has no field that can hold source text. What is retained is references, digests, bounded classifications, and caller-supplied labels.

A bounded evaluation walkthrough

1. Choose one decision. For example: approve a claim exception, approve a supplier change, or authorize an agent to prepare—not execute—an action.
2. Declare the boundary. Required evidence references, policy version, approval role, allowed operation, stop conditions, and retention constraints.
3. Run the workflow twice. The normal path, and one adverse path such as changed evidence, expired approval, denied policy, or an interrupted action.
4. Review the evidence. Hash-chained transitions, reason codes, approval binding, uncertainty state, and recovery classification.
5. Decide what would be required next. A production design needs the customer’s identity, storage, key-management, retention, integration, and control-owner decisions. This prototype does not supply them.

Discuss a bounded evaluation for a customer-shaped workflow. No source documents, provider credentials, payment authority, or live effects are needed for the initial review.

See it for yourself

• Ten worked scenarios — the normal approved path, denied policy, uncertainty, approval expiry, changed evidence, duplicate replay, interrupted recovery, attempted bypass, policy conflict, and the metadata-only audit guarantee. Rendered from engine output.
• Transition, evidence reference, and state graph schemas.
• API documentation — the demo surface is stateless and accepts metadata only.

What this is not, yet

No external audit, no certification, and no production deployment. The reference store is in-memory. Digests are accepted from the caller, so the engine cannot detect a caller that supplies a digest for bytes it does not hold. The event chain is tamper-evident but unsigned. Connecting a real disbursement is deliberately future work, not an omission.