Evidence — Reference system
Governed Case Operations System
A complete operational system for resolving inbound cases: structured and unstructured intake, a deterministic workflow around governed AI, consequence-gated human authority, and a full audit trail. Read it through seven connected views.
Reference implementation
A reference implementation on a synthetic case scenario with synthetic data. It is not client work and describes no real organization.
The working interface
One case, three states — the same governed flow.
Switch between states to see how a case moves: model assessment recorded, a person holding authority over the consequential decision, and every step written to the audit trail. A reference implementation on synthetic data.
CASE CO-2480
Claim reassessment — policy 88-4471
- Owner
- Claims desk · SLA 2 days
- Model assessment
- Eligible · confidence 0.86 Eligible · confidence 0.86 Insufficient evidence · confidence 0.41
- Sources
- policy §4.2 · assessor report · 12 documents
- Authority
- High-impact decision — a person approves
- 14:02:11 model assessment recorded · sources attached
- 14:02:11 routed to human approval · high-impact
- 14:07:52 approved by A. Rivas · acted in ERP and CRM
- 14:09:03 returned to intake · missing form requested
- 13:51:02 exception EXC-04 · operator notified
View 01 · Executive
The whole operation works as one system.
A case is a single unit of work: a structured request accompanied by supporting documents or correspondence. Resolving it well means reading the documents, applying policy, deciding, acting in the systems of record, and being able to show — later — exactly what happened and why.
Done manually across separate tools, that work is slow, inconsistent, and hard to audit. The Governed Case Operations System makes it one deterministic operation: AI accelerates the routine reading and drafting, humans stay accountable for the consequential decisions, and every step is recorded.
-
Throughput with control
Routine steps run automatically within set bounds; people spend their attention on judgment, not clerical routing.
-
Consistency
The same policy, retrieval, and checks apply to every case, so outcomes do not depend on who happened to pick it up.
-
Provable
An append-only audit trail records every actor, action, citation, and approval — so a decision can be explained and defended.
-
Safe AI
The model assists inside a control boundary; consequential actions require human approval. Capability rises without authority outrunning consequence.
The outcomes above are design-level. This reference system does not report measured production throughput, accuracy, or cost — see the evaluation view.
View 02 · Operational
How a case moves.
Every case follows the same deterministic path. The workflow — not the model — decides what happens next; the AI does its work inside one state, and consequential cases stop for a human.
Case state machine
Text description of this diagram
A case runs through seven named states: received (a structured form plus supporting documents), triaged and routed, enriched with retrieved policy and context, assessed with an AI-generated draft and citations, a consequence-gated human approval, actioned in the systems of record, then closed and audited.
The workflow is deterministic; the AI assists only inside the "assessed" state. At the approval gate, a low-consequence case can be approved and actioned, while a case that fails a check is returned or escalated (the dashed exception path) and re-enters at "enriched". Every transition is recorded in the audit trail.
Roles and handoffs
- Intake and workflow services receive, triage, enrich, and route — no human effort spent on clerical steps.
- Case handlers review the AI draft and its citations, correct it, and decide medium-consequence cases.
- Senior approvers hold authority for high-consequence actions and sign off at the approval gate.
Exceptions and edges
- A failed policy check returns the case to enrichment, or escalates it, rather than proceeding.
- Missing or unreadable documents pause the case and request what is needed — they never produce a silent guess.
- Time in a state is tracked, so a case cannot stall unseen; overdue work surfaces to an owner.
View 03 · Architecture
Components, boundaries, and data.
A deterministic orchestrator is the spine. It owns the workflow and calls governed services for the work that needs them, but never hands them control. State lives inside a case data boundary.
System architecture
Text description of this diagram
A deterministic workflow orchestrator drives every case. It calls three governed services — retrieval (policy and prior context), a model gateway (the AI draft), and a policy-and-rules engine — but never hands control to them. Cases and documents, and an append-only audit log, live inside a case data boundary; the orchestrator reads and writes there under least privilege.
Actions reach the organization's systems of record only through integration adapters, so the boundary and the audit log always see every change first. Observability — logs, metrics, and traces — spans the whole system and is described in the evaluation view.
Components
- Orchestrator — the deterministic workflow engine; the only component that advances a case.
- Retrieval — fetches the policy and prior context a case needs, with provenance.
- Model gateway — the single, observable path to the AI model; enforces limits and logging.
- Policy & rules — deterministic checks the draft must pass.
- Integration adapters — the only way actions reach the systems of record.
Data boundaries
- Cases, documents, and an append-only audit log live inside one boundary; access is least-privilege.
- The model gateway sends only the minimum context needed, and records what was sent.
- Nothing reaches a system of record except through an adapter the boundary can see.
The consequential choices are recorded in the architecture decision record.
View 04 · Control & risk
Authority, permissions, and audit.
Control is designed in, not added afterward. Authority to act is granted in proportion to the consequence of the action, permissions are scoped by role, and every step is recorded.
Authority proportional to consequence
Text description of this diagram
Authority is granted in proportion to the consequence of the action. Low-consequence steps run automatically within explicit bounds. Medium-consequence work is decided by a case handler with AI assistance. High-consequence actions require a senior approver.
This is the human-authority model behind the approval gate in the state machine. Alongside it, data permissions are scoped by role: every actor — human or service — sees only the case data its role requires.
Permissions and boundaries
- Roles carry only the permissions they need; a case handler cannot approve a high-consequence action.
- Services run under least privilege — the model gateway cannot write to a system of record.
- Every actor sees only the case data its role requires.
The threats and mitigations are set out in the threat, evaluation, and acceptance specification.
Audit
The audit log is append-only and captures every actor, action, and citation. An excerpt for one case:
| Time | Actor | Role | Event |
|---|---|---|---|
| 09:02:11 | Intake | service | Case CASE-4837 received — request form + 2 documents |
| 09:02:12 | Workflow | service | Triaged: type=claim, priority=standard, queue=A |
| 09:03:04 | Retrieval | service | Policy sections P-12, P-19 retrieved |
| 09:03:05 | Model gateway | service | Draft assessment generated (3 citations) |
| 09:03:06 | Policy engine | service | Rule R-07 passed; R-11 flagged for review |
| 09:05:22 | u_214 | case handler | Edited draft; requested approval |
| 09:07:40 | u_038 | senior approver | Approved with condition |
| 09:07:41 | Integration | service | Action posted to system of record (SOR-99213) |
| 09:07:41 | Workflow | service | Case closed; audit entry sealed |
View 05 · Evaluation
How it is measured and accepted.
A system like this is only trustworthy if it can be measured and held to a standard. Evaluation is continuous: a build is measured, must clear an acceptance gate, then runs under monitoring while outcomes feed back.
Evaluation loop
Text description of this diagram
Evaluation is a loop, not a one-time sign-off. A build is measured against defined datasets and metrics, then must clear an acceptance gate whose thresholds are set in advance. Only then does it operate — under monitoring that watches quality, cost, latency, and human overrides.
Operational outcomes feed back into the next improvement, and the changed system is evaluated again before it is accepted. The datasets, metrics, and thresholds are set out in the threat, evaluation, and acceptance specification.
What is measured
- Extraction accuracy — does the system read the documents correctly?
- Groundedness — is every AI claim supported by a retrieved citation?
- Policy-check precision and recall — are the right cases flagged?
- Human-override rate — how often do handlers correct the draft?
- Escalation correctness — do consequential cases reach a human?
- Latency and cost per case — is it operable at volume?
Acceptance and recovery
- Thresholds for each metric are set before a build is accepted; a build that misses them is not deployed.
- Monitoring watches the same metrics in operation; drift triggers review.
- Failure handling is explicit: retries with backoff, dead-lettering for poison cases, and a documented recovery path.
Measured results are not published. This view defines the datasets, metrics, and thresholds by which the system would be evaluated and accepted — it does not assert production numbers, and independent senior review has not yet been performed (Gate 3 remains open).
View 06 · Failure & recovery
What happens when a step fails.
The operational view showed the happy path and its exceptions; the evaluation view named recovery as an acceptance requirement. This view is that requirement, drawn: a failed action is retried, then contained, then recovered — never silently lost, and never able to corrupt the case.
Failure and recovery
Text description of this diagram
Every action is attempted idempotently, so it either commits exactly once or it does not commit at all. A failed action does not stall the operation:
- It retries with backoff, up to a bounded number of attempts.
- If it still fails, it is dead-lettered — held safely, never silently dropped.
- An operator reviews the dead-letter, fixes the cause, and replays it.
- Because the action is idempotent, replay cannot double-apply the effect.
The whole path stays inside a containment boundary: a failure cannot corrupt case state, and every attempt, failure, and replay is written to the audit log.
Failure modes handled
- A transient downstream error retries with bounded backoff.
- A persistent failure is dead-lettered, not dropped, so no case disappears.
- A poison payload cannot loop forever; it lands in the dead-letter for a human.
- A duplicate submission resolves to one committed effect (idempotency).
Recovery guarantees
- Every attempt, failure, and replay is written to the append-only audit log.
- An operator can inspect a dead-letter, fix the cause, and replay it.
- Replay cannot double-apply, so recovery is safe to run.
View 07 · Deployment & ownership
Where it runs, and who owns it.
The control view established the boundary the system runs inside. This view answers whose boundary it is: yours. The system is deployed into an environment you control, and ownership is transferred rather than rented.
Deployment and ownership
Text description of this diagram
The system is deployed into an environment you control — your cloud account, on infrastructure you own or agree to — not a SageTensor-hosted black box.
Ownership is transferred, not rented. You receive the source and infrastructure-as-code, the runbooks and evaluation sets, and the append-only audit history. SageTensor builds the system and hands it over; it operates the system only for as long as you choose, and you can run, change, and audit it independently.
Where it runs
- In your cloud account, on infrastructure you own or agree to — not a hosted black box.
- Inside the control boundary of the control-and-risk view, under least privilege.
- Reproducibly, from infrastructure-as-code, so an environment can be rebuilt.
What you receive
- The source and infrastructure-as-code for the whole system.
- Runbooks and the evaluation sets, so you can operate and re-test it.
- The append-only audit history — it is your record, not ours.
How an engagement builds and transfers this is the subject of Delivery, and what you own is set out in Enterprise control.
What this does and does not prove
It shows
- That SageTensor designs the whole operation — intake, workflow, decision authority, controls, audit, recovery, and ownership — as one system.
- That AI is placed inside a deterministic workflow with explicit human authority, not left to act unsupervised.
- That control, evaluation, and failure handling are designed in from the start, not added afterward.
It does not show
- Any specific production performance, cost, or accuracy number.
- Suitability for a particular organization without its own mandate and evaluation.
- A client result — no real operation is represented.
How to inspect it
Read it through seven connected views — executive, operational, architecture, control and risk, evaluation, failure and recovery, and deployment and ownership — each available as semantic HTML. The architecture record and the threat/evaluation/acceptance specification are published as filled artifacts.
Engagement
Begin with what must change.
This is how SageTensor designs a whole operation. A Mandate Definition starts the same work for yours.
Or submit an RFP, or request an NDA first.