Governance · Guardrails · Lineage
We build the control plane between your models and your business: guardrails that enforce policy before side effects, a hash-chained ledger that records every decision, and idempotency and replay so any output can be reproduced and defended in front of an auditor.
Guardrail plane
Guardrails are a plane, not a prompt. Each check is a separately versioned component with its own tests, thresholds and ledger entry — so you can prove which policy was in force when a decision was made.
01 · Request
Authenticated actor, scoped tool permissions, request canonicalized and keyed.
02 · Pre-inference
Inputs are cleaned and classified before any model sees them.
03 · Inference
The model runs against a context bundle addressed by hash.
04 · Post-inference
Outputs are checked against sources and calibrated thresholds.
05 · Commit gates
Side effects above limits or below confidence route to a human.
06 · Ledger
Every verdict is written to the decision record before the action returns.
Pre-inference
Requests are matched against versioned policy-as-code (OPA/Rego or Cedar) keyed on actor, intent and data class. No matching allow rule, no inference — and the denial is ledgered with the policy version that produced it.
Post-inference
Outputs must parse against a JSON schema, every factual claim must resolve to a retrieved chunk ID, and domain rules run last — for example, adverse-action reason codes on any credit decline.
Data protection
Checksum-validated detectors (SSN, PAN, MRN) plus an NER model tokenize sensitive spans into a vault before inference. The model, the prompt cache and the logs only ever see tokens.
Adversarial
A fine-tuned classifier scores user prompts and retrieved documents for role-override and indirect-injection patterns. Above threshold, the input is quarantined; a red-team corpus runs as a regression suite on every classifier update.
Refusal logic
A refusal carries a reason code, a user-safe message and an escalation route, and is written to the ledger like any other decision — so refusal rates can be monitored and audited, not guessed at.
Calibration
Scores are temperature-calibrated on held-out data. Below the per-use-case floor (0.72 in the ledger sample) the decision escalates to a named reviewer instead of executing.
Side effects
Tool calls with monetary or irreversible effects check per-actor budgets and per-action limits at commit time. Over the limit, the action waits for a second approver whose attestation is ledgered.
Auditing
If evidence has to be reconstructed after the fact, it isn't evidence. We design systems so that the audit trail is written at decision time, sealed, and exportable without engineering help.
Storage
Ledger segments land in WORM object storage — S3 Object Lock in compliance mode, Azure immutable blob policies or GCS bucket lock — and the chain tip is periodically anchored to a separate account the application cannot write to.
Evidence
One call assembles a decision's record, its context bundle by hash, guardrail verdicts, reviewer attestation and replay transcript, sealed with a SHA-256 manifest.
Accountability
Reviewers sign the exact ledger hash they approved or overrode with a KMS-held key bound to their identity, so an approval can never be re-attached to a different record.
Export
JSON Lines for evidence tooling, CSV for auditors' workpapers, Parquet for your lakehouse. Every export states the chain tip it was verified against, so recipients can re-verify independently.
evidence/dcn_c08df8f4ac20/ ├── record.json # ledger entry, prevHash and ledgerHash ├── context.bundle.json # retrieved chunks, addressed by contextHash ├── guardrails.json # each verdict + pinned policy version ├── model.json # model id, prompt template hash, parameters ├── attestation.sig # reviewer signature over ledgerHash ├── replay.log # deterministic replay transcript └── manifest.sha256 # digest of every file above
Decision lineage & ledgering
At commit time each decision records what it saw, which checks it passed, who reviewed it and which decision it built on. Those parent links form a lineage graph you can walk in either direction: upstream to explain an output, downstream to find everything a bad input touched.
Chain intact240 recordstip 8,442,109
240 records
| Context hash | Ledger hash | Parent | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 2026-09-24 16:01:43Z#8,442,109 | foia-redaction-agentfederal | xgb-risk-v12 | 9597…855c | 2 · pass | executed | 0.924 | a.okafor | faae…9583 | ||
| 2026-09-24 16:00:55Z#8,442,108 | fraud-triage-agentfintech | bedrock/llama-4-70b-ft | d678…d1e4 | 3 · pass | escalated | 0.624 | j.lindqvist | 0f89…aa6c | root | |
| 2026-09-24 16:00:00Z#8,442,107 | meter-anomaly-agentenergy | claude-opus-5-5 | f3bb…8fd2 | 4 · blocked | rejected | 0.831 | m.reyes | d48f…e927 | root | |
| 2026-09-24 15:59:04Z#8,442,106 | credit-limit-agentfintech | claude-sonnet-5 | 2d7b…ac88 | 3 · pass | escalated | 0.616 | j.lindqvist | 4678…f567 | root | |
| 2026-09-24 15:58:02Z#8,442,105 | contract-clause-agentfederal | bedrock/llama-4-70b-ft | fd99…2d70 | 4 · blocked | rejected | 0.581 | m.reyes | a1b4…4502 | ||
| 2026-09-24 15:57:49Z#8,442,104 | foia-redaction-agenthealthcare | bedrock/llama-4-70b-ft | 81a3…b078 | 3 · pass | executed | 0.769 | — | d359…9677 | ||
| 2026-09-24 15:56:21Z#8,442,103 | dispatch-optimizerenergy | claude-sonnet-5 | baa8…f415 | 2 · pass | routed | 0.884 | — | 5fb7…f6ed | root | |
| 2026-09-24 15:55:56Z#8,442,102 | credit-limit-agentfintech | bedrock/llama-4-70b-ft | 34be…a4f3 | 4 · pass | escalated | 0.622 | r.haddad | 0c73…55ff |
Open any decision to walk its lineage graph and replay it. Full explorer and mechanism notes →
If you can't answer that question for a single decision today, start with a Systems Assessment. We map every decision path, score its evidence trail against your regime, and hand you a ranked remediation plan.
Idempotency
Agents retry. Gateways time out. Queues redeliver. Without an idempotency key, a retried “raise this credit limit” executes twice. We derive the key from the request itself — SHA-256 of the canonical {actor, intent, inputs} — so a duplicate resolves to the ledger entry that already exists and returns its recorded outcome.
Try it: submit the request, submit it again, then change the account or the amount. Same inputs, same key, one execution. Any change to the inputs produces a new key and a new entry. The store here is synthetic and lives only in this page.
Requests
0
Executions
0
Deduplicated
0
Empty. Submit the request to execute it once and append an entry.
No attempts yet.
Readiness mapping
A readiness mapping, not a certification. We map each mechanism to the control objectives it supports so assessors start from evidence rather than interviews. Your auditor determines applicability and sufficiency.
| Mechanism | SOC 2 (TSC) | ISO/IEC 42001 | NIST AI RMF | EU AI Act |
|---|---|---|---|---|
| Hash-chained decision ledgerAppend-only, tamper-evident record of every decision and its inputs | CC7.2, CC4.1 | 9.1; Annex A.6 (event logging) | GOVERN 1 · MEASURE 3 | Art. 12 record-keeping |
| Deterministic replayRe-derive any output from recorded, hash-addressed inputs | CC7.3, CC7.4, PI1.3 | 9.1, 10.2 | MEASURE 2 · MANAGE 4 | Art. 12; Art. 15 accuracy & robustness |
| Guardrail plane (pre-/post-inference)Policy checks, classifiers and thresholds enforced before side effects | CC3.2, CC7.2 | 6.1, 8.3 | MANAGE 1 · MANAGE 2 | Art. 9 risk management; Art. 15 |
| PII redaction & PHI minimum-necessarySensitive fields removed or tokenized before inference and logging | C1.1; Privacy criteria | Annex A.7 (data for AI systems) | MAP 4 · MEASURE 2 | Art. 10 data governance |
| Human review & reviewer attestationsNamed reviewer signs the ledger hash they approved or overrode | CC1.3, CC7.3 | 5.3; Annex A.3 (roles & responsibilities) | GOVERN 2 · MANAGE 2 | Art. 14 human oversight |
| Idempotency keysEach business intent executes exactly once, even under retries | PI1.2, PI1.3 | 8.1 | MANAGE 2 | Art. 15 robustness |
| Eval-gated model & prompt promotionGolden-set and guardrail regression suites block unsafe changes | CC8.1 | 8.1; Annex A.6 (verification & validation) | MEASURE 1 · MEASURE 2 | Art. 15; Art. 17 quality management |
| Evidence packs & audit exportPer-decision bundle with signed manifest; JSONL, CSV and Parquet export | CC2.1, CC4.1 | 7.5, 9.2 | GOVERN 1 · GOVERN 4 | Art. 11 technical documentation; Art. 12 |
| Risk tiering & impact assessmentEach use case classified, with controls scaled to its tier | CC3.2 | 6.1, 8.4 (AI system impact assessment) | MAP 1 · MAP 5 | Art. 9 |
| Drift & SPC monitoringControl charts on quality, refusal and guardrail-hit rates with alerting | CC7.2, CC4.1 | 9.1 | MEASURE 3 · MANAGE 4 | Art. 72 post-market monitoring; Art. 15 |
References are indicative: SOC 2 Trust Services Criteria (2017, revised points of focus), ISO/IEC 42001:2023 clauses and Annex A control areas, NIST AI RMF 1.0 functions and categories, and Regulation (EU) 2024/1689 articles for high-risk systems. Obligations under the EU AI Act depend on your role and your system's risk classification.
Two weeks, fixed scope. We map every model, prompt, data flow and decision path you run today, score them against your compliance regime, and hand you a ranked remediation plan with named mechanisms — not a slide deck.