Skip to main content

Essay

From Archaeology to Proof

Sam Carter
Sam Carter25 Mar 2026 · 3 min read

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 decision proof, we have 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?"

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 repository 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.

What remains is incomplete:

  • the outcome
  • partial context
  • whatever was recorded along the way

What's missing is the reasoning as it existed at the moment the decision was made.

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 process inputs, produce outputs, and move fast.

Audit trails 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's gone, replaced by a database entry.


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.

They 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 as a single object — something the analyst can retrieve six months later and read end to end.


The shape of proof

A provable decision has a shape.

It 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.

Asked

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

RCP-LOAN-43821 VerifiedResolved in 2.1 seconds

Archaeology vs proof

Archaeology is reconstructed, partial, interpretive — after the fact.

Proof is captured, complete, deterministic — at 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.

Inspect a receipt

More from the Journal