Element
What an assessor checks
Governance events
Agent ID, session ID, tool name, policy decision, timestamp, latency. No prompts, no completions, no PII.
Hash chain
Each entry is chained to the last, so a removed or altered entry does not verify. SHA-256 throughout. Each entry stores entry_hash = SHA-256(prev_hash + entry_json), where entry_json is the entry in a fixed field order with the two chain fields removed from their own input, and the first entry chains from an empty string. Every row also carries a sequence number; against Postgres the prior hash and the next sequence are read inside the appending transaction under a cross-replica advisory lock, so concurrent writers cannot fork the chain. Two hash layouts exist: the original does not cover account_id or sequence_number, the current one does, and a verification reports how many legacy rows it walked — a chain that passes over legacy rows says nothing about which tenant those rows belonged to. Note what this is: the platform audit chain. A separate per-tenant decision ledger with the same prev_hash / entry_hash shape exists as database schema only, with no write path behind it.
Merkle root
Two different constructions carry this name, and this page will not claim one of them for both. A gateway decision batch gets a real binary tree: each leaf is SHA-256 over one record’s canonical bytes, pairs are concatenated and hashed, an odd node is promoted unchanged to the next level rather than duplicated, and the process repeats to a single hex root. The window is one batch — 100 records or a 5-second flush, whichever comes first, per gateway — and the manifest’s from_ts and to_ts are the first and last record timestamps in it. A loop evidence bundle reuses the same manifest envelope but sets merkle_root to a flat SHA-256 content hash over the whole canonical bundle body. Same field, no tree.
Signature
Ed25519. There are two distinct signatures rather than one over everything. Each decision record is signed individually over its canonical JSON — fixed field order, sig omitted — covering decision_id, ts, org_id, gateway_id, bundle_hash, input_hash, decision, effect, stage, kid and seq. The batch manifest is signed separately over its own canonical bytes: batch_id, from_ts, to_ts, record_count, merkle_root, kid. So the manifest signature covers the root, and the root is what binds the records to it. A loop bundle signs that same envelope, where the root is the bundle’s content hash, so there the signature does cover the whole emitted body except the signing envelope itself. Distribution: every signature names a kid, and the public halves are served as a keyring — public material only, each key carrying ACTIVE, PREVIOUS or RETIRED status and a not-before / not-after window — from the control plane’s gateway-keys endpoint; a gateway that generates its own key registers the public half back. There is no JWKS endpoint and no out-of-band publication, which is precisely why third-party offline verification is not yet available.
Policy version
Every decision record carries bundle_hash: the SHA-256 over the canonical body of the policy bundle in force at that gateway when the decision was made — the org, kill switches, resolved bindings, active exceptions, OPA policies, the SLM contract and the behavioural thresholds, with every slice sorted before hashing so the value is order-independent. The bundle header alongside it carries a monotonic sequence and an epoch and is itself Ed25519-signed, and the same hash is what the drift check compares. Because bundle_hash sits inside the record’s canonical signing bytes, it cannot be changed after the fact without breaking that record’s signature. What it does not do is name the individual rule: it identifies the policy state by content, and resolving it back to readable policy needs the control plane that issued it.
Manifest
There is no archive and no directory layout — these are JSON documents, not a tarball, and the page should not imply otherwise. The batch manifest is a single object: batch_id, from_ts, to_ts, record_count, merkle_root, kid, sig. A loop evidence bundle is one document declaring schema_version: loops.evidence.v1, with a content-addressed bundle_id, generated_at, the account, the loop, an explicit machine-readable honesty verdict, then runs, events, stop_conditions and shadow_findings, a counts block and the signing envelope. counts.truncated is set when any collection hit its cap, so an omission is disclosed rather than silent. The compliance report export is a different artifact: one file in PDF, JSON, CSV or HTML, and it is unsigned — a report, not the sealed record.