The question arrives after the decision. A loan was declined, a transfer was flagged, a target was prioritised, a patient was triaged, and now a regulator, an auditor, a court or an angry customer wants to know why. In most AI systems the honest answer is that nobody knows precisely, and a team spends two weeks reconstructing it from application logs, model traces, database snapshots and vendor tickets, then produces a narrative that everyone hopes is right.
That reconstruction is the weakest link in every AI assurance programme, and it is weak for a structural reason: provenance was never stored, it was logged, and logs are a description of the system written by the system. This article is for the people who own that question: AI assurance and audit leads, model risk teams, compliance officers, and the engineers who will be asked to produce the evidence. It describes what it takes for "why" to be a query with a verifiable answer, and how 8DB delivers it.
What a real answer contains
A defensible answer to "why did the system conclude this" has five parts, and each one has to be a fact about the data rather than a claim by the operator.
- Which records the conclusion rested on, identified so they cannot be swapped afterwards.
- Where each record came from, and how much it should have been believed at the time.
- What the system was allowed to see when it acted, so nobody can later argue it used data it should not have had, or was denied data it should have had.
- That none of it has been altered since, provable to someone who does not run the system.
- A path to reverse the conclusion cleanly if it turns out to be wrong.
How 8DB stores each part
Records are content-addressed. Every atom in the store is identified by the hash of its content, so a source cited by a decision is the exact bytes that were cited, not a row that may have been updated since.
Provenance is a chain, not a log. Merges, derivations and decisions carry a provenance chain with a signed, reversible anchor recording the inputs, the confidence of each, and the governance state in effect. Asking why a set of records became one entity, or why a value was chosen, returns that structure. Reversing a bad decision is an atomic operation on the chain, not a restore from backup.1
Confidence travels with the fact. Each record carries a multi-axis confidence vector: sourced or assumed, number and independence of corroborating anchors, recency, method quality, authority agreement and domain authority. The answer to "why" includes how sure the system was entitled to be.
Governance state is recorded at the moment of use. Because clearance and policy epochs are inputs to key derivation, the store knows under which authority a read succeeded. What the system could see when it acted is a property of the data, not an inference from an access log.
Integrity is provable to an outsider. Datasets are authenticated with one ML-DSA-87 signature over a SHA-384 Merkle root, with a logarithmic inclusion proof per record. Hand a reviewer one record, its proof and the signed root, and they can verify it was part of the authenticated dataset and has not changed, with nothing else from the system and without trusting the operator. Tampered leaves and forged roots are rejected through an independent verifier path. This is a formal claim in our independent evaluation package, accepted only when both harnesses pass against frozen baselines on an evaluator's isolated host.
What this looks like in an audit
Instead of a two-week reconstruction, the audit is a session. The reviewer asks for the decision, receives the records it rested on with their content addresses, confidence vectors and provenance, receives the governance state under which the system read them, and receives the inclusion proofs and signed root. The reviewer verifies the proofs on their own machine. If the decision was wrong, the reversal is visible in the same chain. Nothing in that session depends on believing the operator, which is the property regulators are converging on and the property that ends most arguments before they start.2
What to bring us
- One decision you had to explain. The reconstruction you produced and how long it took. We will show what the same answer looks like as a query over an evidence-carrying store.
- Your assurance framework. The artefacts your auditors or regulators require. That becomes the shape of what the store returns.
- A reviewer. Give us someone who does not trust us. They can verify an inclusion proof against a signed root on their own machine before we have a second meeting.
Write to hello@8braid.com with the subject "Provenance as a query: assurance review". You will hear back from an engineer.
Sources and further reading
- NIST AI Risk Management Framework
- NIST FIPS 204: ML-DSA
- 8DB: The Database Is Part of the Model
- 8DB: What an Independent Evaluator Should Be Able to Run
Footnotes
-
The integrity proof is a formal claim in the evaluation package. The confidence, provenance and governance-attribution mechanisms described in this section are in the engine and are exercised in the evaluation package as supporting demonstrations rather than formal acceptance gates; we say so there and we say so here. ↩
-
Provenance of the data does not validate the reasoning of the model that used it; that remains the model owner's responsibility. Non-repudiation accreditation, timestamp authorities and long-term archival certification are separate credentials we have not claimed. ↩
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work