Ask a vendor whether their system has an audit trail and the answer is always yes. The better question is: what does the trail record when things fail? On 2026-08-12 an independent evaluator - no insider context, working from a written script - spent an hour recording exactly that against the Flight Recorder, the append-only event ledger under our operations console.
The live circuit, timed
The cleanest moment in the recording is Scenario 1. The evaluator put the Flight Recorder on one browser tab in live mode, clicked a boot action on a second tab at 22:14:34, and watched the first tab. Eight seconds later, three new rows: GATE_ZERO_INGRESS, then two OPERATOR_DIALOGUE events, every one carrying the same fresh ingress id (1bacd06e) and each chained to the previous by a correction link. One click, one correlated three-event chain, visible across tabs in eight seconds, with the event ids in the transcript.
What failure looks like in the ledger
Here is the part that makes the ledger credible. Almost nothing in the run went right, and the recorder caught all of it:
- The boot failed. The local relay was down, so both boot attempts died with a 502. Each failed boot still wrote its full three-event chain under its own fresh ingress id (
ead1db6a, then 5adf1b8f). The boot never anchored; its telemetry was perfect.
- The approvals failed. A held dialogue message was approved twice; the endpoint crashed with a server error both times. Both failed approvals landed in the ledger (
a852e785, 187f092d), correction-chained back to the message they tried to release (416aae42, thread ca9d49a3).
- The validations blocked. Two geometric-hash rejections each wrote their own typed event (
GEO_HASH_BLOCKED).
The evaluator's own summary line is the one worth keeping: "failure is audited: failed boots, failed approvals, and blocked validations all produced correlated FR chains."
The inverse, kept in
The same recording contains the most damaging observation of the night, and it belongs in this story: one class of action - governance lifecycle transitions, the approve/activate/hold cycle on rule nodes - changed governed state three times and wrote no ledger events at all where the evaluator looked. That is the exact inverse of the ledger's promise, it was filed as a high-severity defect the same night, and this chapter will be updated when the fix is recorded. A second gap: the ledger rows would not expand in the UI, so the per-event integrity hash could not be inspected on screen this run.
An audit spine that hid those two findings would not deserve the name. The discipline here is the same one the ledger itself enforces: the record is append-only, including the parts that embarrass you.
Why this matters
Observability tells you what the system did. An audit spine tells you what everything and everyone did, in one place, in an order that cannot be quietly rewritten - which is why the interesting proofs are all negative ones: the failed boot that still reported, the crashed approval that still left a trace, the blocked validation with its own event type. Trust the ledger that records the bad days.
Captured from the TD-2 recorded run (OQS Phases 1-6 + Scenario 1, executed 2026-08-13 02:39-03:46 UTC by a naive evaluator). Event identifiers, timestamps and quoted lines are verbatim from the transcript; the governance-transition gap is tracked as a filed defect.
0 comments