decision provenance

Audit-ready evidence

An auditor asking whether a control operated is not asking for a dashboard screenshot. Every governance decision emits a signed receipt, batched into a Merkle tree, countersigned by an independent timestamp authority, and chained so alteration is detectable. Each layer has a stated limit, and you can verify a record without trusting us.

No. 01 · Audit-ready evidencedecision provenance

Why screenshots fail an audit

"Our database says the action was approved" is an assertion. Anyone with write access to that database could have made it true afterward. Ordinary logs answer what happened and when; they cannot show that nothing was edited, deleted, or backfilled between the event and the audit.

The stronger model is a receipt: a record whose integrity a skeptical third party can recompute without trusting the operator's word, or the operator's dashboard.

No. 02 · Audit-ready evidencedecision provenance

How a decision hardens into a receipt

Every material governance decision, a tool call permitted or denied, a document redacted, a human approval granted, emits a signed record. The canonical payload is hashed with SHA-256 and signed with Ed25519, and the receipt carries the signature together with the public key it verifies against.

Receipts are batched into an RFC 6962-style Merkle tree, each carrying its inclusion proof. Every batch root is countersigned by an independent RFC 3161 timestamp authority, so the time a batch was sealed is asserted by a third party rather than by our clocks. Batches form an append-only hash chain: deleting one leaves a gap, and reordering breaks the accumulator.

Signing runs off the decision hot path, so the evidence adds no latency to the agent.

No. 03 · Audit-ready evidencedecision provenance

External anchoring, stated honestly

A signature proves the integrity of a record you already hold. It says nothing about a record that was deleted, or a history re-signed wholesale by whoever controls the key. The chain makes those detectable, but only to a verifier holding an independently anchored copy of an earlier checkpoint.

That is the job of the external leg: chain checkpoints published to write-once (WORM) object storage that the operator cannot alter or delete before retention expires. This leg is implemented and configurable per deployment, and it is off by default.

Until an operator enables it, the guarantee is tamper-evidence against outside parties and against accident. A verifier who wants the stronger property should require the WORM leg on, or hold a checkpoint themselves.

No. 04 · Audit-ready evidencedecision provenance

Verification your auditor runs without us

One API call re-derives the full attestation chain for any record: payload hash, leaf signature, Merkle inclusion, root signature, timestamp. Every check reports its result explicitly, and a check that cannot complete reports failure with a reason rather than a silent pass.

The second path needs nothing from the vendor. A receipt verifies offline with standard cryptographic libraries and its own fields: recompute the payload hash, verify the Ed25519 signature against the carried key, check inclusion against the published checkpoint feed.

Human approvals sit in the same trail. A reviewer's yes or no is captured as a signed record in the chain, carrying the identifier of the action in question, so the package you hand an auditor is records with proofs attached, and the approval that released a wire transfer is itself evidence.