Why can't your logs explain the decision six months later?

A loan applicant submits at 14:02 on a Tuesday in March. The underwriting engine runs credit policy v3.1, hits a DTI threshold of 43% and declines.

Six months later, the applicant’s solicitor writes in and asks the firm to explain that decision.

At that point the practical questions are narrow. Which policy version was live at 14:02? Which threshold did it set? Was the outcome overridden, and by whom? Were the inputs on file the inputs that were actually scored?

A core banking system can usually say what happened. It can rarely show why. What it leaves behind is archaeology: fragments captured over time — logs, events, traces, dashboards — written for the operations team answering “is the service up?”, not for the auditor who arrives a year later asking “why did this customer get this answer?”

By the time anyone looks, the decision is gone

A risk analyst pulls the logs. The inputs and the outcome are there, but policy v3.1 was retired in May and what is deployed now is v3.4. Nowhere in Splunk, the case file or the policy repository is there a record of which thresholds were live at 14:02 on that Tuesday in March.

She is not observing the decision. She is rebuilding a story.

What survives is the outcome, partial context and whatever was recorded along the way. What is missing is the reasoning as it stood at the moment the decision was made. So the analyst infers, interprets and fills the gaps, and the answer that goes back to the solicitor is plausible, defensible — and partly invented.

None of this is an accident. Sanctions screening engines, underwriting rules engines and vendor approval workflows were designed to process inputs, produce outputs and move fast. Audit evidence came later and recorded the cheapest thing to capture: what happened. Not why. The decision exists for an instant inside the running system, then it is gone, replaced by a database entry.

Day to day, that is fine. It stops being fine when a regulator asks for a compliance defence, a customer challenges an outcome or a risk team investigates a failure. “Here are the logs” is not enough, because logs do not evidence a decision.

They suggest.

A provable decision has a shape

The alternative is to treat the decision itself as the artefact: not reconstructed later, but captured at the moment it was made. Inputs. Policy. Context. Outcome. Bound together as a single object the analyst can retrieve six months later and read end to end.

Such a record answers a fixed set of questions, captured at execution rather than inferred afterwards:

• who made it
• why
• what input was used
• which policy applied
• what evidence was considered
• what result was produced
• which version was in effect
• when it happened
• and that it hasn’t been altered since

Not nine separate log entries stitched together later.

One bound artefact, retrievable by decision ID.

Be precise about what such a record settles. It shows what was evaluated, which policy and version applied, and that the content has not changed since it was signed. Whether the policy was well designed, and whether the outcome was the right one, are still questions for the people reading it — but they are questions someone can now examine rather than reassemble.

Archaeology is reconstructed, partial and interpretive, after the fact. Proof is captured at execution, and the analyst tasked with rebuilding a decision usually only discovers the difference when the solicitor’s letter arrives.

The practical standard is that a decision another party may challenge should leave a record that party can read without trusting whoever assembled it. Take one such decision in your stack, and capture the policy, version, context and outcome at the moment it runs rather than the activity around it — a receipt is what that record looks like.