The AI Decision Record: A Single Source of Truth for Every AI Decision
Updated: 1 day ago
Ask a financial institution to show you a decision its AI system made last year, and you will usually get a score.
Sometimes you will also get a log entry from the rules engine, a status in the core banking system and, with some effort, an analyst's note. What you will almost never get is the decision itself, assembled in one place: what was known, which rule applied, who had authority, what was done and what happened next.
The decision existed. It was simply never recorded as a whole.
That gap is the reason so many institutions struggle to explain, audit and measure their AI decisions. The fix is conceptually simple and architecturally demanding: every consequential decision needs a single record, under a single identifier, that connects everything the decision depended on and everything that followed from it. We call it the decision record.
Why scores and logs are not records
Scores and logs are byproducts of systems. A decision record is a deliberate artifact. The difference shows up in three ways.
Scores describe inputs to a decision, not the decision. A probability of default is one piece of evidence. It doesn't say what threshold it was compared to, what other evidence was considered, or what outcome was chosen.
Logs are organized by system, not by decision. Each system logs its own events. Reconstructing a decision means querying several systems, matching timestamps and hoping identifiers line up.
Neither captures what happened next. Whether a decision was accepted, executed, overridden or reversed, and what outcome it produced, usually lives somewhere else entirely, if it is recorded at all.
The anatomy of a decision record
A complete decision record is organized around one identifier, the Decision ID, and contains seven groups of information.
1. Identity and context
Decision ID, timestamp and decision type (for example, "SME credit-limit increase")
The subject: customer, account or transaction
The channel and the requesting party: customer, analyst, system or agent
2. Evidence
Every input used, captured as a snapshot at decision time
Source, date and lineage of each piece of evidence
The result of the sufficiency check: what was required, what was present, what was missing or outdated
3. Intelligence
Each model that contributed a signal, with its exact version
Each signal, with its uncertainty: the estimate and its range, not just a point value
4. Policy and decision
The exact policy version applied
The rules that determined the outcome
The typed outcome: allow, deny, condition or escalate
The explanation, in terms the affected party can understand
5. Authority
The accountable actor: a system operating under a mandate, an analyst, a committee
The authority under which the decision was made, and its limits
For agents, the mandate and the full chain of delegation
6. Lifecycle
Every subsequent state, appended over time: authorized, presented, accepted, executed, adopted
Every exception: rejected, expired, overridden, escalated, partially executed, reversed, failed, compensated
For each human intervention: who, when, under what authority, with what justification
7. Outcome and value
The observed result, when it becomes available
Where it can be estimated with confidence, the value attributable to the decision, with its method and confidence interval
Integrity information: the signature and hash chain that make the record tamper-evident
Design principles
A decision record is only useful if it is built according to a few strict principles.
One ID, end to end. The Decision ID is created when the decision is generated and travels with every downstream action. A payment, a limit change or a contract issued as a result of the decision carries its ID. Any action without one is, by definition, unauthorized.
Append-only. Records grow; they are never edited. A reversal doesn't erase the original decision. It adds a new event. History is preserved exactly as it happened.
Snapshot, not reference. The record stores what the system knew at the moment of the decision, not a pointer to data that may have changed since. Otherwise, reconstruction reads today's data and calls it yesterday's decision.
Facts separate from estimates. Whether a decision was executed is a fact. What it was worth is an estimate. The record keeps them in separate fields, each labeled for what it is.
Failures recorded with the same rigor as successes. A record that captures only approvals and completions produces flattering statistics and no learning. Blocked, escalated and reversed decisions are often the most informative.
Readable by people. A record that only engineers can interpret fails auditors, regulators and the customers who ask why. Each record should be presentable in a clear, structured form.
What the record makes possible
When every consequential decision has a complete record, capabilities that are otherwise expensive or impossible become routine.
Reconstruction. Any decision can be reproduced exactly as it was made: same evidence, same model versions, same policy, same outcome.
Explanation. The explanation of a decision can be generated from its record: the criteria applied, the evidence considered, what would have changed the outcome.
Audit and supervision. Auditors and supervisors can examine decisions directly, rather than reconstructing them from several systems.
Policy testing. New policy versions can be simulated against historical records to see which outcomes would change and why.
Measurement. Adoption, override and escalation rates, consistency across equivalent cases and attributable value can all be computed from records, rather than estimated from aggregates.
Dispute resolution. When a customer, counterparty or agent's principal contests a decision, the record settles what was known and decided.
The record as an institutional asset
Over time, decision records accumulate into something more valuable than any individual decision: an institutional memory of how the organization actually decides.
That memory reveals which policies work and which don't, where human judgment adds value and where it introduces inconsistency, which models earn trust and which don't, and which decisions create economic value. It is the raw material for improving every future decision.
It is also an asset that is very hard to replicate. Models can be retrained by anyone with data. A complete history of decisions, with their evidence, authority, execution, adoption and outcome, can only be built by recording them, one by one, from the start.
Where to start
Institutions don't need to record every decision at once. Start with one decision type that is high in volume and consequence. Define its record, field by field. Ensure the Decision ID travels to execution. Capture evidence as snapshots. Record exceptions and overrides. Then extend.
Within a few months, the institution will know more about that decision than it has ever known: how often it is made, how consistently, with what evidence, how often it is overridden, and what it produces.
A decision that isn't recorded as a whole can't be explained, audited or improved as a whole.
Want to see what a complete decision record looks like for your institution's decisions? Talk to our team →
Comments