Skip to main content

← JournalBlog

From archaeology to proof

By Sam Carter

Logs are archaeology. Decision proof is something else.

A core banking system can tell you what happened.

It can rarely prove why.

In place of proof, we have archaeology.


Fragments

Logs. Events. Traces. Dashboards.

Captured over time, written for the operations team answering "is the service up?" — never for the auditor who arrives a year later asking "why did this customer get this answer?"

Something goes wrong, and somebody starts digging.


Reconstruction

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%, declines.

Six months later the applicant's solicitor writes in: explain this decision.

A risk analyst pulls logs.

The inputs are there. The outcome is there.

But policy v3.1 was retired in May, and what's deployed now is v3.4.

Nowhere in Splunk, the case file, or the policy repo is there a record of which thresholds were live at 14:02 on that Tuesday in March.

The analyst is not observing the decision.

She is rebuilding a story.

Reconstructing the decision…

  • Pull v3.1 policy source from archive12 min
  • Diff against currently deployed v3.418 min
  • Locate DTI threshold live at 14:02no record
  • Confirm whether the operator overrodeunknown
  • Hash the inputs against what was scorednot possible

That's not proof. That's archaeology.


The problem

By the time anyone looks, the decision is gone.

Remaining:

Missing:

So the analyst infers, interprets, fills the gaps.

The answer that goes back to the solicitor is plausible, defensible — and partly invented.


Why this exists

Sanctions screening engines, underwriting rules engines, vendor approval workflows — none of these were designed to prove decisions.

They were designed to:

Audit trails came later, and recorded the cheap thing:

what happened.

Not why.

The decision lives briefly inside a function call.

Then it's gone, replaced by a row in a database.


Where it breaks

Day to day, this is fine.

Until it isn't.

A regulator asks for justification. A customer challenges an outcome. A risk team investigates a failure.

"Here are the logs" isn't enough.

Logs don't prove anything. They suggest.


The shift

Imagine if the decision itself were the artefact.

Not reconstructed later. Captured at the moment it was made.

Inputs. Policy. Context. Outcome.

Bound together — a single signed receipt an analyst can pull up six months later and read end to end.


The shape of proof

A provable decision has a shape.

It answers nine questions, captured at execution rather than inferred afterwards:

Not nine separate log entries stitched together later.

One bound artefact, retrievable by decision ID.

Asked

Why was this loan declined on 12 March at 14:02?

RCP-LOAN-43821 VerifiedResolved in 2.1 seconds

Archaeology vs proof

ArchaeologyProof
reconstructedcaptured
partialcomplete
interpretivedeterministic
after the factat execution

Closing

Logs tell you what happened.

Proof tells you why it happened.

A decision that needs to defend itself — in court, in front of a regulator, or in a risk committee — cannot be rebuilt from fragments.

And the analyst tasked with rebuilding it usually only discovers the gap when the solicitor's letter arrives.

Decision Assurance

If you can't prove a decision, you don't control it.

See how it works

More from the journal