A regulator, an auditor, or your own legal team asks why the system approved something in 2024. By then the prompt has changed eleven times and the model's been deprecated. If the decision only lives in a system that keeps moving, you don't actually have an answer.
A run from March 2024, inspected today. The blueprint version that produced it has since been retired twice — but the run pinned its own version, its own evidence hashes, and its own reviewer sign-off, so it still explains itself exactly as it did the day it ran.
Someone edited the system prompt eleven times since that decision was made. Reconstructing what it actually saw means archaeology through commit history, if you're lucky enough to have any.
The vendor deprecated the model version. Even with the old prompt in hand, running it again today gives a different answer — so "just re-run it" isn't actually a defence.
The knowledge base has been updated dozens of times since. There's no way to know which version of which guideline was live when the decision was made two years ago.
A screenshot proves what was shown, not what was read or why. It has no chunk hashes, no model version, no reviewer — nothing a regulator can actually verify against.
A second system that records what the first system did will eventually disagree with it — a dropped log line, a timestamp mismatch — and that disagreement is exactly what an audit finds first.
Snapshotting an entire corpus every time anything changes is expensive and still doesn't tell you which chunks a specific decision actually used, only what existed nearby.
By the time the letter arrives, the prompt has changed, the model has been deprecated, and the person who built it has left. This is a decision made once, at build time, or not at all.
The blueprint version, the as_of date, and every instruction module applied are written onto the run itself — not referenced from a system that keeps moving.
Not a link to a document that might get edited or deleted — the exact hash of the exact chunk that was read, so the evidence itself can be verified byte-for-byte.
Approval, correction, and reviewer identity are fields on the run — not a separate sign-off system that can drift out of sync with what was actually decided.
The blueprint keeps shipping new releases and the knowledge base keeps syncing — old runs stay exactly as explainable as the day they ran.
Compare a two-year-old decision against what today's rules would produce with one click — a real diff, not a guess about what probably changed.
Bitemporal documents mean a run's evidence reflects the rules in force on the date that mattered — the application date, the incident date — not the day someone happened to run it.
The run viewer renders evidence, citations, and reviewer sign-off as a single readable trail — not a JSON blob someone has to translate for legal.
