Interactive demo - Project 3
Workflow Governance & Control
Three-layer governance for automated work: policy permissions before action, human intervention during high-value steps, and a hash-chained audit receipt after.
Routine paths continue under policy. Requests over $10,000 place an authorization hold, pause for operations manager intervention, and either execute or roll the hold back.
Control. Nothing above $10,000 executes without an explicit operations manager Approve or Reject. Reject releases the authorization hold and records a rolled-back receipt.
StackTypeScript, Next.js, SSE
System brief
- Challenge
- Teams often collapse permissions, live intervention, and audit into one layer - so high-value automation can move without a clear stop, and logs only explain harm after it happens.
- Solution
- A governed step runner that checks policy before action, pauses above $10,000 for operations manager intervention, and emits a hash-chained session receipt for who decided, when, on what amount, and under which policy.
- Business impact
- Routine work proceeds under policy bounds; high-risk spend cannot complete without an explicit human decision, and reject rolls back the reserved authorization hold instead of leaving a dangling intent.
Exception pathHold / review
- Policy before action
- Permissions and spend bounds are evaluated before the run attempts final execution - not only after a pause.
- Reject rolls back the hold
- Over-threshold runs reserve an authorization hold. Reject releases that hold (compensating rollback) and blocks downstream execution. This is an in-process demo hold, not a live ledger undo.
- Who reviews
- Operations manager decides in the governance console, with actor, timestamp, optional reject reason, policy id, and hold status on the session receipt.
- Audit receipt limit
- Entries are hash-chained for this session receipt. That proves reconstruction for the demo run - it is not a durable WORM store.
Architecture and trade-offs
- 01IntakeRequest packet
- 02PolicyPermissions before action
- 03ThresholdGate at $10,000
At or below threshold
Final execution + audit receipt
Routine path continues under policy without an intervention pause.
Above threshold
Hold - operations manager intervention
Approve releases the hold to execute. Reject rolls the hold back and records a rolled-back receipt.
Public runtime: TypeScript state machine with an in-memory checkpoint and hash-chained session receipt. LangGraph and Postgres checkpoint config in the repo is reference only for this hosted demo.
UI starts a scenario. /api/workflow runs a TypeScript in-process state machine: policy check, optional authorization hold, intervention checkpoint, then execute or rollback. Approve / Reject resumes or rolls back the hold and emits a governance receipt. LangGraph and Postgres checkpoint config in the repo is reference only for this hosted demo.
Trade-offs
- Deterministic TypeScript routing fits this fixed money gate - clearer than an open-ended planner for a single threshold interrupt.
- In-memory demo checkpoints and hash-chained receipts - fine for a portfolio run, not durable across deploys or multiple instances.
- A durable graph or checkpoint runtime (for example LangGraph with Postgres) can be added when approvals must survive restarts or span instances; that path is config/reference here, not the public runtime.
Interactive demo
1 Choose a scenario · 2 Run the system · 3 Inspect how it works
Governance control room
Layer 1: Policy
Permissions checked before action
Layer 2: Intervention
Idle until threshold gate trips
Layer 3: Audit
Hash-chained receipt after decision
Run status
- State
- idle
- Hold
- none
- Manager
- None
- Final
- idle
Governance path
Intake - Policy - Threshold - Final execution
Process steps
Default scenario is over $10,000. Start the run to watch policy, intervention, and audit layers fire.
Activity log
Policy checks, intervention events, and the hash-chained audit trail appear here while the workflow runs.