A complaints team at a mid-sized bank declined a claim in January. In October the supervisor asked why. The decision had passed through a model, a rule and two people. The model had been updated twice since. The rule had been rewritten once. One of the two people had left.
The team spent three weeks putting the story back together from emails, a ticket system and memory. The answer they sent was plausible. It was also, as everyone in the room knew, a reconstruction.
This is the normal case. It is what happens when automation is added to regulated work without deciding, on day one, what gets written down.
What a record is
A record is a short, complete account of one decision, written at the moment the decision is made. For a case that passes through Trace it holds five things:
- The data that was used, and where it came from.
- The model, with its version.
- The rule that applied, with its version.
- The person who approved, if a person was involved.
- The time of each step.
None of this is new. Banks have kept records of human decisions for a century. What changed is that part of the decision is now made by software that changes every week, and the record has to keep up with it.
A record is written while the decision happens. A reconstruction is written when someone asks, by people who were not there.
Why reconstruction fails
Three things drift between the decision and the question. The model changes, so running the same case again gives a different answer. The rule changes, so the policy the decision followed may no longer exist in the handbook. The people change, so the person who approved has moved on, and the one who replaced them has to guess.
A reconstruction is built from whatever survived that drift. Usually that is the emails. Emails record what people said about the decision, which is a different thing from the decision.
What it looks like in practice
Here is one case as Trace writes it. Six entries, each with its time, who acted and what happened. The people are illustrative; the shape is real.
When the supervisor asks about this case, the answer is the record itself, exported as a report. Nobody has to remember anything.
What it costs
Written as part of the workflow, the record costs nothing extra. The data, the model version and the rule are already in hand when the step runs; writing them down is one more line. Added later, the same record costs weeks, because every system that touched the case has to be asked what it did, and most of them cannot say.
So the decision is less about compliance than about when to pay. Teams that write the record from the first case pay once. Teams that wait pay every time a question arrives.
Where to start
Pick one operation: onboarding, claims, complaints, reconciliations. Map it the way it is actually done, exceptions included. Decide which steps a person must approve. Then run it with the record switched on from the first case, and read the record yourself after a week. If you can explain any decision from it in under a minute, the operation is ready to scale.
