What an Auditable Decision Has to Prove

A credit application is refused. Six months later somebody asks why — that application, on that date, under the rules in force at the time. The answer has to survive the people who left, the model that was replaced twice since, and the fact that the log sits with whoever has an interest in what it says. Most systems that decide at scale cannot produce it, and the gap is not an ethical one: it is a missing data structure.

Finance settled this class of problem long ago, and it settled it procedurally. Balance sheets are verifiable, processes traceable, metrics reproducible, because double-entry bookkeeping, separation of duties and trails you can walk backwards make dishonesty expensive and visible.

Pointed at automated decisions, that discipline asks for something narrower than explainable AI and considerably more achievable: a decision that carries verifiable evidence of its own conduct — what was decided, on what input, under which constraints, and whether anyone touched the record afterwards.

The absence shows up in ordinary places. A credit model may issue opaque or discriminatory decisions with no demonstrable rationale; a risk-scoring engine may drift silently from approved parameters; trading algorithms may circumvent exposure limits by optimising against local objectives; generative systems used in compliance or reporting may produce untraceable output. All share the same flaw — no verifiable evidence of the decision process — and in finance that translates directly into operational and legal risk.

---

Auditing the Decision

Auditing a model runs into the artefact itself: it is large, opaque and replaced every few months, and by the time anyone asks about a decision the weights that produced it may no longer exist. Auditing a decision is tractable. Whatever produced it — a trained model, a hand-written scorecard, a person clicking approve — the record has the same shape, and that indifference to the source is what makes it durable: the trail does not have to be rebuilt every time the model is.

It is within this framing that I built a Decision Audit Toolkit: a dependency-free audit kernel, deliberately small enough to read in one sitting. Each decision produces a cryptographically linked record; each constraint is a pure function returning a pass or a fail with an identifier, a severity and a reason a human can read; sensitive values are coarsened to bands before they are written, with the names of the dropped fields kept on the record; the input distribution is watched for the one kind of shift the test can actually see. The objective is a system accountable in its failures.

---

What an Auditable System Has to Store

Strip away the abstraction and an auditable decision system needs four things on disk, each of which is either present or not.

A decision record. The outcome, the inputs it was given, an identifier for whatever produced it, and a timestamp. Sensitive fields are coarsened before they are written, a band rather than an exact figure, and the names of the fields dropped along the way are recorded alongside, so the omission is itself part of the record. This is deliberate data minimisation, not differential privacy: a banded income is still an attribute of the applicant, only a coarse one, and calling it anything stronger would claim a guarantee the code does not make.

A policy result. Constraints compile from declarative rules into pure functions — a loan-to-value ceiling is a ratio and a number — each returning a pass or a fail with an identifier, a severity and a readable reason. Policy can only ever override an approval: if the decision source says approve and a constraint fails, the recorded outcome becomes blocked by policy. A rejection stands on its own, because the layer exists to catch what was let through.

A chain that breaks when edited. Each block hashes its own content together with the previous block’s hash, so an edit invalidates the block that changed and every link after it. Storage is append-only JSON Lines, one signed block per line, each appended with fsync — adding a block is O(1) rather than a rewrite, and a crash mid-append leaves a detectably truncated final line instead of silent corruption.

A linear chain proves integrity to whoever holds all of it, which is usually the opposite of what anyone wants: showing a regulator that one decision is in the log would mean handing over every other decision in it. So a Merkle tree — the Certificate Transparency construction — is derived over the same block hashes, and it gives the two proofs the chain alone cannot. An inclusion proof shows that one record belongs to the log described by a signed tree head, disclosing nothing about what the others contain. A consistency proof shows that a later log still carries an earlier one as an unchanged prefix: that the history was appended to, not rewritten.

A signature anyone can check and nobody can forge. The block hash is signed with Ed25519. The asymmetry is what makes it useful to an outsider: verification needs only the public key, so a regulator or an auditor holding the chain file and the .pub can prove the log is intact without holding anything that would let them write to it. An HMAC cannot offer that — whoever can check one can also produce one.

Per-block signatures still cannot prove that nobody truncated the log or rewrote it wholesale, not if the signing key travelled with the file. That gap closes with a signed checkpoint: a short statement of the chain head — index, hash and tree root — pinned somewhere the log holder cannot reach. Checking it later proves the current chain still extends the history that was pinned. A shorter chain, or a different hash at that index, is evidence that survives even a key compromise, because the checkpoint predates it.

Drift sits alongside all of this. A decision system can be working exactly as specified while operating in a world it no longer fits, so the inputs are watched for that: a windowed mean-shift test, a per-feature two-sample z statistic against a reference window, aggregated and thresholded in sigma units. It catches shifts in the mean, and only those — changes in variance, or in the correlation between features, go straight past it. Richer distributional monitoring belongs on the list of things still to build.

The limit is worth naming plainly. What gets recorded is the decision; the reasoning inside a model stays where it is. Deterministic replay of an inference — pinning sampling state so that a generation can be re-executed bit for bit — is a coherent design target and a genuinely useful one, but a different system from this one. Being clear about which of the two you have is the kind of thing an audit is supposed to surface.

The Decision Audit Lab puts four of these records in front of you, chained and signed as the toolkit wrote them. Edit an amount, re-hash the block to cover the edit, carry the new hash into the one after it — the browser verifies the whole chain holding only the public key, and the seed that could re-sign it was destroyed after generation.

---

Where the Alarm Belongs

The public conversation about AI risk runs on the vivid end of the evidence. Anthropic’s Claude 4 System Card and its work on agentic misalignment, and Palisade Research’s experiments on shutdown resistance, document models that resist interruption or drift from the goal they were given under conflicting instructions. The findings are real and worth reading. What is worth borrowing is the method: thousands of adversarial probes, each deviation observable, classifiable and reproducible. That is an audit, run by the people with the most to lose from running it badly, and it maps the surface of risk, which is all an audit can do.

The failure that actually turns up in a regulated business is duller than any of that. A system performs correctly against its internal parameters while drifting from what the organisation meant, and nobody can say when that started, because nothing kept a record that would answer. The risk here is opacity, which is an administrative problem, and therefore one the tools of administration already reach: documenting, measuring, reviewing, on the schedule the rest of the business already runs on.

---

Operational Constraints and Epistemic Limits

Auditability introduces practical limits. Recording provenance, hashing every block and keeping the chain intact consume storage and time, which can grow quickly with model scale and usage. In large systems, full trace capture is rarely efficient; selective auditing at the level of decisions or subsystems is often the only sustainable approach.

Transparency also has side effects. The same mechanisms that make a decision reconstructible can expose parts of the input or of the internal state. Coarsening at the point of writing rather than at the point of reading limits that, and so does restricting who holds the log — but neither eliminates it. Stronger guarantees, formal privacy budgets or execution inside secure enclaves, are a different system with a different cost, and it would be dishonest to imply this one provides them.

Finally, auditability does not guarantee correctness. It can show how a decision was produced. Whether the underlying assumptions were valid is a separate question, and that is why human oversight remains necessary, as a check on whether the system’s logic still serves its intended purpose.

---

What Comes Next

What happens next is an institutional choice. Most large developers already possess the technical means to make their systems inspectable; what remains uncertain is whether they will accept the cost. Audit slows release cycles, exposes internal design choices and makes failure visible, and unlike accuracy it wins nothing in a demonstration.

Finance, aviation and pharmaceuticals each resisted regulation before treating it as the cost of staying in business. Technical accountability will travel the same road from research concern to compliance requirement, and the systems that arrive early will be the ones that had the evidence lying around anyway, because someone decided to write it down while it was still cheap.