The problem with self-signed logs#
Most audit logs are signed by the same vendor that produced them. That is enough to catch accidental corruption, but it does not answer the question a regulator or an enterprise auditor actually asks: how do I know this record was not written — or back-dated — after the fact? If the vendor holds the only key, the vendor could in principle re-issue the proof. The trust still rests entirely on the vendor.
What LumenFlow does differently#
LumenFlow keeps a tamper-evident evidence chain: receipts from supported governed action paths are folded into an append-only chain with a cryptographic root (a Merkle anchor) per workspace. The chain lets an auditor check the integrity of the receipts supplied for verification; it does not, by itself, prove that every action was captured. An anchor can have two verification layers:
- An operator seal — LumenFlow's own signature over the anchor, proving it came from your workspace and has not changed since it was sealed.
- An optional independent external witness — when configured and reachable, a trusted timestamping authority signs the anchor root using the RFC 3161 standard.
When an anchor has a valid witness token, the token is stored alongside it and can be re-verified offline against the authority's published certificates — no access to LumenFlow required. An anchor awaiting a token is not independently witnessed.
Why the external witness matters#
For a witnessed anchor, the third-party signature proves the evidence root existed by the witnessed time. A later change to that root would fail verification against the token. The proof stands on the witness's signature, not on trusting us. That is the difference between "we say this happened" and "an independent authority confirms this existed by then."
What it proves — and what it does not#
For a witnessed root, the token proves existence by a point in time; the receipt-chain verifier checks integrity and continuity of the receipts supplied to it. Neither check proves that all actions were captured or that the underlying work was correct or complete. The token also does not substitute for a formal conformity assessment.
How it fits compliance#
When present, the external witness adds an independent timestamp to the record used for EU AI Act Article 12 readiness. Check the anchor's witness status before describing an evidence bundle as independently anchored. See EU AI Act Article 12 readiness for the full obligation-to-primitive mapping.
The witness is additive. If the timestamping authority is ever unreachable, anchors are still sealed and recorded — they are simply marked as awaiting their independent timestamp rather than being blocked. An anchor is only ever shown as "independently verified" once a valid third-party token has been checked.
Per-receipt hash chain and signature#
The anchor above protects a periodic, batched root. Underneath it, every individual evidence receipt is also chained the moment it is written: each receipt's hash folds in the hash of the receipt immediately before it, so editing, deleting, reordering, or splicing a receipt breaks a link that is checkable without needing the periodic anchor at all. This hash-chaining happens for every receipt in every workspace, always — there is no configuration that turns it off.
On top of that unconditional hash chain, a deployment can optionally enable a cryptographic signature on each receipt using a dedicated signing key. When a signing key is configured, new receipts carry a signature that a third party can check with nothing but the matching public key. When no signing key is configured, receipts are still fully hash-chained — tampering, deletion, and reordering are still detectable — they simply are not individually signed. We say plainly which state a given workspace is in rather than implying every receipt is cryptographically signed by default.
How a customer or auditor checks this directly#
Two calls let anyone with API access verify the evidence chain themselves, without taking our word for it:
- Verify the whole chain confirms the sealed anchor history for a workspace is contiguous and unbroken — no gaps, no rewritten roots.
- Get a proof for one receipt returns a self-contained inclusion proof showing that a specific receipt is covered by a specific sealed root, which anyone can check independently against that root.
Both are available on the evidence API today and are the same mechanisms this article's guarantees are built on.