A Right to Explanation Is a Right to a Record

The explanation nobody can produce

A regulator writes to you. A customer was refused credit, declined for a job, flagged as a risk, or quietly deprioritised by a model you run. The letter asks a simple question. Why. Tell us what the system did, on what basis, and show your working.

Most organisations cannot answer that question. Not because they are hiding something, though some are, but because the answer was never written down at the moment it mattered. The model ran. The decision shipped. The inputs moved on. By the time the letter arrives, the only honest reply is a reconstruction, and a reconstruction is a story you tell after the fact about a thing you can no longer see. That is not an explanation. It is a press release with a logo on it.

I have spent a long time around security, and the security mindset is useful here because it is allergic to trust. A security realist does not ask whether you intend to behave. They ask whether you can prove what happened when you have every incentive to shade it. Explanation rights are heading straight into that wall, and almost nobody building artificial intelligence (AI) systems has noticed.

The law assumes a record that was never kept

The legal machinery is already in place. Data protection regimes give data subjects rights around automated decisions and meaningful information about the logic involved. The European Union (EU) Artificial Intelligence Act layers high-risk obligations on top, with record-keeping, logging, and transparency duties that begin to bite from August 2026. Liability law is moving in the same direction, shifting the burden toward the operator who deployed the system rather than the person harmed by it.

Every one of these instruments shares a hidden assumption. They assume that somewhere, a faithful record of what the system did already exists, and that producing it is a matter of retrieval. The drafters imagined a filing cabinet. What they got, in most deployments, is an empty room with a confident spokesperson standing in it.

Read the obligations plainly and they are not really demands for transparency in the soft sense of a friendly summary. They are demands for evidence. Meaningful information about the logic of a decision is worthless if you cannot show that the logic you describe is the logic that actually ran. A right to explanation, taken seriously, is a right to a record. Without the record, the right is decorative.

Why after-the-fact explanation fails

There are three honest reasons reconstruction does not survive contact with a regulator, a court, or a determined adversary. None of them is exotic. They are the ordinary physics of running real systems at scale, and each one quietly defeats the after-the-fact story.

First, drift. Models are retrained, prompts are edited, retrieval corpora are refreshed, dependencies are bumped. The system that produced last quarter's decision no longer exists in the exact state that produced it. Re-running it today gives you an answer about today's system, not a record of the one that acted.

Second, post-hoc rationalisation. Modern explainability tooling is good at generating plausible accounts of why a model might have decided something. Plausible is the dangerous word. An explanation generated after the outcome, by a party with a stake in the outcome, optimises for defensibility, not truth. It tells you a story consistent with the result. It does not tell you what happened.

Third, and this is the one security people obsess over, the logs are mutable and the keeper is interested. An ordinary application log can be edited, truncated, back-dated, or selectively disclosed, and the organisation holding it is the same one that would face the penalty. Asking that organisation to be the sole custodian of the evidence against itself is not a governance model. It is a conflict of interest wearing a compliance badge.

What a real record requires

If you want an explanation that means something, the record has to satisfy properties that ordinary logging does not. I would set four, and I would treat all four as non-negotiable. Drop any one of them and a determined party can still rewrite history.

It has to be written before the act, not after. An account composed before a decision executes cannot be tuned to flatter the result, because the result does not exist yet. This single property kills post-hoc rationalisation at the root.

It has to be tamper-evident. Each entry should be cryptographically chained to the one before it, append-only, so that altering or removing any record breaks the chain in a way anyone can detect. You do not have to trust the keeper. You check the maths.

It has to be verifiable by an outsider with no special access and no trust in the vendor. If only the operator's own tooling can confirm the record, you have moved the conflict of interest, not removed it. The regulator, the data subject, and the auditor each need to verify the account independently.

And it has to outlast the cryptography it was born with. Records written today may be challenged in a decade, by which point the threat landscape will include adversaries with far more capable computers, including quantum ones. The signatures protecting today's evidence need to resist tomorrow's machines, because evidence that can be forged retroactively is not evidence at all.

The record we built

At Mickai, this is not a feature we are planning. It is the floor the whole system stands on. Mickai is a Sovereign Intelligence Operating System (SIOS), built and in production, and at its core sits the Open Audit Record (OAR). Every action the AI takes is signed before it executes, then hash-chained into an append-only ledger. The signature comes first. The act follows. The record cannot flatter an outcome it was written ahead of.

The signatures use post-quantum cryptography, the United States National Institute of Standards and Technology (NIST) standard Federal Information Processing Standard 204 (FIPS 204), ML-DSA-65, so the evidence does not rot when the cryptographic ground shifts. And the whole thing was designed for the property that matters most. Anyone can verify the record offline, in an ordinary web browser, with no trust placed in us. A regulator does not take our word. A data subject does not take our word. They open the record and check the chain themselves.

Mickai runs fifty brains, twenty-five domain and twenty-five operational, on the Poseidon silicon substrate, and we are actively training our own models now, fine-tuning and specialising open foundations and building a sealed corpus. None of that matters to the regulator's letter unless every one of those brains writes to the same signed ledger. They do. Above them, the Pantheon chain, a sovereign Layer 1 we are still building, anchors the audit root to Bitcoin, so the evidence is rooted in something no single party controls. The same discipline runs through the work behind the platform: a portfolio of 101 filed United Kingdom patent applications, about 2,234 claims, owned by Mickai LTD.

The uncomfortable conclusion

Here is the part most of the industry would rather not hear. If your AI system cannot produce a signed, replayable account of a specific past action, verifiable by someone who does not trust you, then you cannot meet a serious explanation request and you should stop pretending you can. The friendly dashboard, the feature-importance chart, the model card, these are useful, but they are commentary. They are not the record.

The rights are already written. The deadlines are already set. The liability is already shifting toward whoever deployed the model. The only question left is whether the evidence exists when the letter arrives. A right to explanation is a right to a record. Build the record first, or admit you never had one.