Traceable AI: what a decision record actually contains

Fourteen months after a motor claim was settled, a letter arrives. The customer disputes the amount. The adjuster who handled it has moved to another team, the policy wording has been updated twice, and the repair shop’s estimate now exists in three versions across two systems.

Someone has to answer one question: why was this claim settled this way?

If an AI prepared that decision, “traceable” stops being a marketing word. Either there is a record that answers the question in minutes, or there is a week of reconstruction and a decision nobody can fully defend. Almost every enterprise AI product says its answers are traceable. Few say what that means. This is what it has to mean.

One decision, one record

Every time an agent makes or prepares a decision, it should write one complete record. Not logs scattered across five systems, but a single object that can be read on its own, by someone who was not there.

Field	What it holds	Why it matters
Input	What arrived: the case, documents and data, with a timestamp	Shows what the AI was asked, not what someone remembers
Evidence	The exact passages used: document, page, clause or record ID	Every statement can be checked against its source
Rules applied	Which policy or business rule was used, and its version	Rules change; the record keeps the version that applied that day
Model and configuration	Model version and the settings it ran with	The same case can be re-run and compared later
Steps taken	The tools the agent called and what each returned	Shows how the answer was reached, not just the answer
Recommendation	The proposed decision and the reason in plain words	What the reviewer actually approved or changed
Human review	Who reviewed it, what they looked at, what they did, when	Accountability stays with a named person
Outcome	The final result, and what happened next	Lets the system learn from real results

What one looks like

For the disputed motor claim, a shortened record might read like this:

	Record for claim 48213
Decision	Recommend settling at 3,180
Input	Claim form, 2 repair estimates, 6 photos · received 11 July, 09:42
Evidence	Estimate B, page 2: “rear bumper, replace” · Policy §4.2: “repair at an approved garage”
Rules applied	Claims guideline v12 (in force from 1 July) · excess 300
Model and configuration	Document reader v3.4 · reasoning v2.1 · configuration 7f3a…
Steps taken	Read 9 documents → matched 14 line items → estimate A set aside (garage not approved)
Human review	J. Park · opened 3 of 3 cited sources · 4 minutes · approved
Outcome	Paid 3,180 on 14 July · dispute opened 16 September the following year

Fourteen months later, the answer takes a few minutes: estimate A came from a garage outside the approved list, which clause 4.2 excludes; guideline version 12 was in force; a named adjuster checked every cited source before approving. The update to the guidelines since then does not matter. The record shows the one that applied.

Two technical details that make it trustworthy

Rules and models are pinned, not named. “Claims guideline” is not enough; guidelines change. The record stores the exact version, and ideally a fingerprint (a hash) of its content, so no one can later swap in a different text under the same name. The same goes for the model and its configuration. Because everything is pinned, a past decision can be re-run: feed the same input to the same versions and check that the same recommendation comes out. When a model is upgraded, re-running a sample of old cases shows exactly which decisions would now change, before the upgrade goes live.

Records are sealed as they are written. Each record carries a fingerprint of its own content and of the record before it, like links in a chain. Change one character in an old record and every link after it stops matching. Corrections are never edits: they are new entries that point to the old one, so the full history stays visible. This is the same idea that keeps a bank ledger honest.

The quiet risk: a click is not a review

A record that says “approved by J. Park” is not enough on its own. When an AI is right most of the time, people start approving without looking. The research term is automation bias; in practice, it is a tired reviewer at 6 pm.

A good record makes this visible. It stores what the reviewer actually opened and how long they spent, not just the final click. If an adjuster approves forty cases in ten minutes without opening a single source, that shows up, and the problem is a process to fix, not a person to blame later. Traceability is as much about the humans in the loop as about the model.

The same record, five domains

The structure stays the same across industries. What changes is the content of each field.

	Decision	Evidence	Rules applied	Human review
Finance	Approve a credit limit increase	Bank statements, income documents, repayment history	Credit policy, affordability thresholds	Credit analyst approves or adjusts the limit
Insurance	Settle a motor claim	Claim form, repair estimates, photos, policy wording	Coverage clauses, claims guidelines	Adjuster confirms or escalates
Healthcare	Code a hospital stay for billing	Discharge summary, procedure notes, lab results	Coding standards, payer rules	Clinical coder validates the codes
Airport operations	Clear a maintenance work order	Equipment logs, manuals, past fixes	Maintenance procedures, safety requirements	Supervisor signs off the work
Manufacturing	Release or hold a production batch	Sensor data, inspection results, deviation reports	Quality specifications, release criteria	Quality engineer releases or holds

In each case the record answers the questions that always come later: why was this paid, why was this batch held, which version of the procedure applied, and who agreed.

One more rule holds everywhere: the record points to data, it does not copy it. Evidence is stored as references (document, page, passage), not as fresh copies of patient files or bank statements. The personal data stays in the systems that already protect it, under their access rules and retention periods.

Why now

Regulators increasingly expect this. The EU AI Act, for example, requires high-risk AI systems to automatically log events over their lifetime so that their behavior can be traced. Internal audit, model risk teams and customers ask the same questions, usually before any regulator does.

There is also a reason that has nothing to do with compliance. A record that includes the outcome and every reviewer correction is the best training material an organization will ever have: real cases, from its own domain, with the right answers attached.

How NU Tech builds it

In AxP, the AI Transformation (AX) Platform, the decision record is not an add-on. N-Sight, the Agentic Decision Engine, writes it at every step of the agent loop, pins the rule and model versions, and seals each entry. Dudl, the Enterprise Knowledge Engine, supplies the evidence as source links with their versions. Because AxP runs on-premises, hybrid or air-gapped, the records stay inside the organization, next to the data they describe.

To see a decision record on real cases, request a demo.