Correlation replay
/audit/correlation/{uuid} reconstructs the request path in order: proxy, Brain signals, policy decision, HIL transition, upstream outcome.
Cryptographic audit trails for agent actions.
Inspect an illustrative chain locally, then review how a configured production ledger can connect a tool call, policy verdict, approval, and upstream outcome. Your audit and compliance teams decide whether that evidence meets their requirements.
Every entry in the ledger commits to its predecessor. Tamper a single byte and /verify tells you exactly which row broke the chain — and which downstream entries can no longer be trusted.
Genesis
→
64 × "0"
Row n
→
sha256(prev | json)
Row n+1
prev = row n hash
// hash chain genesis = 64 × "0" entry_hash[n] = sha256(prev_hash[n] || "|" || canonical_json(hashable[n])) // reconstructing a request GET /audit/correlation/{uuid} → [proxy, policy, HIL, upstream]
5
illustrative rows
256
bit hash function
0
backend calls to verify the sample
4
decision stages in the replay
Sample scope
The five rows are a committed illustrative fixture, not live customer traffic or an independent assurance artifact.
Hash primitive
Each fixture row uses SHA‑256 over the prior hash and the versioned canonical JSON shape.
Verification boundary
The sample verifier runs in WebCrypto. The separate live-demo endpoint exposes only aggregate chain health.
Production evidence
A pilot defines captured fields, redaction, access, retention, exports, and acceptance criteria for its own ledger.
Five sample rows. One chain. Verify in your browser.
These illustrative fixture rows use the ledger's canonical shape and hash‑link rule; they are not live customer events. Each entry_hash commits to its predecessor. Change one byte and the sample stops verifying locally.
Before
Rows 1–5 verify clean
Each row's prev_hash matches the prior row's entry_hash, and every recomputed digest matches storage.
After Forge a byte
Row #3 breaks; #4–#5 are untrusted
The verifier stops at the first mismatch and marks downstream rows as not trusted, even if their stored hashes still look well-formed.
- Loading receipts…
Or verify the aggregate live-demo chain with one curl
# Live aggregate only — no per-row data is public. $ curl -s https://demo.clavenar.com/verify | jq '{valid, entries_checked, first_invalid_seq}' { "valid": true, "entries_checked": <current count>, "first_invalid_seq": null } # Correlation replay requires the scoped console or an authorized # pilot export; the public edge deliberately exposes no ledger rows.
How the chain proves itself
- Genesis — the chain seeds
prev_hashwith 64 zeros. Row 1 commits to this seed. - Per‑row hash —
entry_hash[n] = sha256(prev_hash[n] || "|" || canonical_json(hashable[n])). The hashable shape and field order are the chain version — seeclavenar‑ledger/src/lib.rs:386. - Forward link — row N+1's
prev_hashequals row N'sentry_hash. Tampering any earlier row breaks every later hash. - Independent verification — your browser's
Verifybutton recomputes eachentry_hashwith WebCrypto SHA‑256, byte‑identical to whatverify_chaindoes on the server.
What a configured correlation replay can contain.
A hash anchors the recorded sequence; it does not establish that an omitted or inaccurate input was true. A pilot defines which request, decision, approval, and outcome fields are captured and who may replay them.
Policy decision
The ledger records verdict, rule, tier, and reason. A future policy edit does not rewrite the historical decision.
Approval evidence
Yellow-tier actions carry the approver identity, decision time, and final allow/deny transition before release.
Upstream outcome
Outcome rows link the recorded authorization to the later external-call result, so reviewers can inspect what the control plane allowed and what it observed afterward.
Chain verification
/verify returns the first invalid row and how many entries were checked; browser verification uses the same digest shape.
Retention export
Cold-tier exports keep signed manifests beside the ledger rows, giving compliance and incident response the same evidence object.
A refund that could not move until approval landed.
The sample chain includes a Yellow-tier stripe.refund. The illustrative replay shows why sequence matters: the request parks first, approval lands second, and the recorded upstream outcome follows.
-
01
Request received
stripe.refundarrives fromdemo-sentinel-botwith correlationdemo-sentinel-003. -
02
Policy parks the action
Rule
wire_transfer_requires_approvalreturnsReview; row #3 commits the Yellow-tier decision. -
03
HIL records the operator decision
finance-oncallapproves in row #4. The approval is chained to the parked request, not logged separately in a side channel. -
04
Upstream release is attributable
The side effect is allowed only after the chain shows authorization. A later audit can replay the exact decision path instead of trusting screenshots.
Map evidence fields to control questions.
These mappings are implementation aids, not certification, attestation, legal advice, or proof that a deployment complies.
- SOC 2 control mapping
- EU AI Act Art. 11/12 mapping
- NIST AI RMF mapping
- ISO/IEC 42001 mapping
Accountability
A configured ledger can record caller, tenant, method, verdict, reason, and operator identity for approvals.
Traceability
Correlation IDs link request, policy, HIL, and upstream rows without depending on scattered LLM logs.
Integrity
SHA-256 forward links expose row edits and downstream uncertainty immediately.
Retention
A pilot defines its retention period, storage tier, export destination, access roles, and deletion process.