Verdict vocabulary
Every Trinitite-governed call — whether it routes through the Chat, Proxy, MCP Gateway, or CLI Firewall — returns exactly one of three outcomes. This is the contract your client code branches on.
The three outcomes
| Outcome | Meaning | What you receive |
|---|---|---|
passed | The output is fully compliant with the active policy. | The original output, unchanged, plus a receipt. |
corrected | A policy violation was detected and surgically repaired. | An RFC 6902 JSON Patch describing the fix, plus the patched output and a receipt. |
blocked | A critical violation that could not be safely corrected. | A 403-style refusal with a full forensic record. Do not use the original output. |
{
"verdict": "corrected",
"guardian": "pii-redactor",
"policy_hash": "sha256:7f3a…",
"correction_diff": [
{ "op": "replace", "path": "/choices/0/message/content", "value": "Customer SSN: [REDACTED]" }
],
"receipt": {
"ledger_id": "led_01J9X…",
"latency_ms": 187,
"determinism_mode": "batch_invariant",
"chain_hash": "e3b0c4…"
}
}
correction_diff
When verdict is corrected, the response carries correction_diff: an RFC 6902 JSON Patch array. Each operation is typed by op:
op | Effect |
|---|---|
add | Insert a value at the path. |
remove | Remove the value at the path. |
replace | Replace the value at the path. |
move | Move a value from one path to another. |
copy | Copy a value from one path to another. |
test | Assert a value before proceeding (used internally). |
Apply the patch with any RFC 6902 library (fast-json-patch, jsonpatch, etc.). Trinitite already applies the patch to the returned output — the correction_diff is provided so you can audit, log, or replay the exact transformation.
Receipt fields
Every verdict — passed, corrected, or blocked — is hashed, signed, and Merkle-chained into the Glass Box Ledger. The receipt travels with the response:
| Field | Description |
|---|---|
ledger_id | The ledger entry ID. Resolvable via the Logs and Public Verification endpoints. |
latency_ms | End-to-end governance latency for this call. |
policy_hash | Hash of the active policy at decision time. Proves which rules produced the verdict. |
determinism_mode | The kernel mode that produced the verdict — batch_invariant by default. |
chain_hash | The Merkle chain hash linking this verdict to the prior one. |
Determinism guarantee
Under batch_invariant determinism, the same (input, guardian_version, policy_hash) triple always produces the same verdict, the same correction_diff, and the same chain_hash — byte-for-byte, across batches, across nodes, across restarts. This is what makes Trinitite verdicts replayable and auditable: a past decision can be re-executed bit-exactly and the resulting receipt will match.
See Architecture for the geometric model behind corrected, and Observability for the production correction_diff telemetry.
→ Chat endpoint — submit a conversation and a Guardian; receive a verdict. → Errors, rate limits & conventions — the error envelope and shared headers. → Webhooks — receive verdict events as they happen.