Where a Signed Record Fits the Standards

A standard is a promise about evidence

Pick up any modern governance standard for artificial intelligence (AI) and read it the way an auditor reads a contract, not the way a marketer reads a brochure. What you find, again and again, is a promise about evidence. The United States National Institute of Standards and Technology (NIST) AI Risk Management Framework (RMF) asks you to map, measure, manage, and govern risk, and to be able to show your working. The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) joint standard, ISO/IEC 42001, asks you to run a management system with documented controls, records, and continual improvement. The European Union (EU) Artificial Intelligence Act, whose high-risk obligations begin to bite from August 2026, asks for logging, traceability, and records you can hand to a regulator. None of these asks you to be perfect. All of them ask you to prove what happened.

That is the part most teams underweight. They treat a standard as a checklist of behaviours to adopt, and they adopt them sincerely. Then a year later, when an incident or an audit arrives, the question is not whether they had a policy. The question is whether they can produce a record that a sceptical outsider will believe. I have sat on the wrong side of that question. It is a bad place to be, and the badness has nothing to do with whether you did the right thing. It has to do with whether you can demonstrate it. A team can be honest, careful, and correct, and still lose the argument because the evidence it kept was never built to be challenged. That is the gap this essay is about, and it runs straight through every framework on the table.

What the frameworks actually require, read literally

Take the NIST AI RMF first, because it is the most widely cited and the most often misread. It is voluntary, it is outcome-oriented, and it is deliberately not prescriptive about tools. Its four functions, Govern, Map, Measure, and Manage, are a loop, not a ladder. Inside that loop, the recurring verb is document. You are asked to document context, document measurement methods, document decisions about acceptable risk, document the people accountable. The framework does not tell you how to store those documents or how to keep them honest. It assumes you will. That assumption is the gap, and it is the same gap that widens as you move from a voluntary framework toward a binding law.

ISO/IEC 42001 is more formal. It is a management-system standard, built in the same mould as the information-security standard ISO/IEC 27001, which means it lives and dies on records. Clause by clause it expects documented information: the scope of your AI management system, your risk assessments, your controls, your internal audit results, your management reviews, your corrective actions. A certification auditor will not take your word for any of it. They will ask for the record, they will ask when it was created and by whom, and they will look for the tell-tale signs of a record assembled the night before. The standard is, in effect, a discipline for producing trustworthy paperwork at scale, and trustworthy is the operative word, because paperwork that cannot withstand questioning is not an asset, it is a liability waiting for a date.

The EU AI Act is the one with teeth. For high-risk systems it requires technical documentation, automatic logging over the lifetime of the system, traceability of results, and the ability to provide all of it to competent authorities on request. From August 2026 those obligations stop being a roadmap and start being law for a defined set of uses. Read literally, the Act is asking for a logbook that survives contact with an investigation. Not a dashboard. Not a slide. A logbook, and one whose entries a regulator can trust were not curated after the complaint landed. The difference between those two things is the whole subject.

The quiet assumption all three share

Here is the thing the three regimes have in common, and it is rarely stated out loud. Each assumes that the record you produce is a faithful account of what your system did. NIST assumes your documentation reflects your real measurements. ISO assumes your logs reflect your real operations. The EU AI Act assumes your automatic logging captures the real behaviour of the model. The standards govern the shape of the evidence. They do not, by themselves, govern its integrity. They tell you what to keep. They are silent on how to make what you keep impossible to quietly rewrite.

In an ordinary information-technology environment, that assumption is usually fine, because logs are boring and nobody has a strong motive to forge them. In an AI environment it is more fragile, for a reason that is structural rather than cynical. The system generating the actions is also, very often, the system generating the logs about those actions. If a model misbehaves, the same pipeline that produced the misbehaviour produces the account of it. A log that is written after the fact, by the party with the most to lose, is exactly the kind of evidence a security realist learns to distrust. Not because people are dishonest, but because the design quietly invites the question and offers no answer. Good faith is not the issue. Verifiability is. A record that depends on the reader's faith in the author has already conceded the argument it most needs to win.

Where ordinary logging fails the test

Consider a concrete sequence. A high-risk AI system makes an automated decision that denies someone a service. Six months later a regulator asks why. Your team pulls the logs. The logs say the model scored the applicant below threshold at a certain time, with certain inputs. Good. Now the harder questions. Were those the inputs at the moment of the decision, or the inputs as reconstructed later? Has the log been edited since? Could it have been? Who had write access to the log store between the decision and the disclosure? Can you prove the log entry existed before the complaint, rather than being a tidy narrative written afterward? Each of those questions is reasonable, and a determined reviewer will ask all of them.

Most logging stacks cannot answer those questions in a way that a hostile reviewer accepts. They were built for debugging and observability, not for adversarial scrutiny. The records are mutable by design, because operators need to rotate, compress, and prune them. Access controls reduce the risk of tampering but do not eliminate the possibility, and crucially they do not let an outsider verify the absence of tampering without trusting your access controls in the first place. The standard asked you to keep a record. You kept one. It just cannot carry weight against a determined challenge, and the moment it matters most is precisely the moment someone challenges it.

This is the difference between a record and proof. A record is a statement about the past. Proof is a record that an adversary cannot plausibly dispute. The frameworks ask for records and hope they amount to proof. Closing that distance is an engineering problem, and it is one the standards leave to you on purpose, because standards bodies set outcomes and let the market supply mechanisms. They are right to do so. But it means the hardest part of compliance is the part no framework writes down for you.

The mechanism the standards leave open

So what would a record look like if it were engineered to survive the exact scrutiny the frameworks invite but do not enforce? Four properties, and they compound. None of them is exotic. Each addresses a specific doubt that ordinary logging cannot dispel, and together they convert a statement about the past into something a stranger can check.

First, the record must be written before the action, not after. If the account of a decision is signed and committed before the decision executes, there is no window in which the story can be edited to fit the outcome. This single inversion, signing before acting rather than logging after, eliminates the most common and most corrosive doubt about machine evidence. The accused can no longer be suspected of writing their account once they knew how things turned out, because the account predates the result.

Second, the records must be chained, each entry cryptographically bound to the one before it, so the sequence is append-only. You cannot quietly remove an inconvenient entry from the middle without breaking every link after it. Tampering stops being a discreet edit and becomes a visible fracture. An auditor no longer has to trust that nothing was deleted. The chain itself reveals any deletion, which means the integrity of the log no longer rests on the honesty of the people who hold it.

Third, the signatures must be built to outlast the cryptography of the present decade. A record that proves something today but can be forged by a quantum computer in the years ahead is not a durable record, and high-risk AI decisions can carry legal consequences far beyond the moment they are made. This is why the migration to post-quantum signature schemes matters here and not only in classified settings. The relevant United States standard, NIST Federal Information Processing Standard (FIPS) 204, defines the Module-Lattice-Based Digital Signature Algorithm (ML-DSA); the ML-DSA-65 parameter set is a sensible target for evidence meant to hold up across a regulatory lifetime, when the audit may arrive long after the cryptography of today has aged out.

Fourth, and this is the property almost nobody designs for, the record must be verifiable offline, by anyone, without trusting the vendor that produced it. If checking your audit trail requires calling your own application programming interface (API), then you are still asking the accused to confirm their own innocence. A record that can be verified in an ordinary web browser, with no live connection to the company that made it, is a record that has finally escaped the credibility problem at the heart of self-reported machine logs. The outsider does not have to believe you. They run the check themselves, and the mathematics answers, not your engineering team.

Mapping the mechanism back to the clauses

None of this conflicts with NIST, ISO, or the EU AI Act. It satisfies them more completely than they ask. The NIST AI RMF wants documented, traceable risk decisions; a signed, chained record is documentation that cannot be retroactively dressed up. ISO/IEC 42001 wants controlled documented information with provable integrity; an append-only, cryptographically verifiable log is the strongest form of documented information a management system can hold, and it makes the internal-audit and corrective-action clauses far easier to satisfy honestly. The EU AI Act wants automatic logging, traceability, and disclosure to authorities; a record signed before execution and verifiable offline is automatic logging that a regulator can check without taking your engineering team's word for anything.

There is a useful way to think about the relationship. Standards bodies define the obligations. They are, deliberately, silent on the substrate, the underlying layer that makes the obligations checkable rather than merely asserted. They have to be silent, because mandating a specific mechanism would freeze innovation and pick winners. But silence is not indifference. The frameworks are practically begging for a substrate that turns their documentation requirements into evidence that holds. The gap between record and proof is the substrate's job, and a framework that stopped to specify the substrate would stop being a framework and start being a product. So the work falls to whoever builds the layer underneath, and that is where the interesting engineering lives.

Honest caveats, because a security realist owes you them

A signed, offline-verifiable record is not a cure for bad models, biased data, or poor decisions. It proves what happened. It does not make what happened right. If your system discriminates, a perfect audit trail will document the discrimination with crystalline precision, and that is the point; accountability requires that the bad outcome be undeniable, not hidden. Anyone selling cryptographic logging as a substitute for the harder governance work of measurement, testing, and human oversight is selling the wrong thing. The record is the floor of accountability, not the ceiling of good practice.

Second caveat. A record is only as good as what it captures. If you sign a hash of inputs you never actually fed the model, you have signed a lie, beautifully. Integrity of the chain does not guarantee fidelity of the content. The discipline of capturing the real inputs, the real model version, the real decision, at the real moment, is upstream of the cryptography and cannot be outsourced to it. Certification under ISO/IEC 42001 and conformity under the EU AI Act both exist partly to test that upstream discipline, and they should. Cryptography secures the chain. It does not absolve the people deciding what goes into each link.

Third caveat, and it is a matter of intellectual honesty about the field. Standards are still moving. The EU AI Act's harmonised standards and guidance are being finalised even as obligations approach. The NIST framework will see further profiles and companion resources. The ISO portfolio for AI is expanding. Anyone who tells you the rules are settled is guessing. What is not guessing is the direction of travel: more traceability, longer evidentiary horizons, less tolerance for unverifiable self-reporting, and a steady migration toward cryptography that survives the next decade. Building to that direction is prudent even before the last clause is ratified, because the cost of retrofitting integrity onto a logging stack after an audit is far higher than the cost of designing for it before one.

What I built, and why it sits where it sits

I run Mickai, a Sovereign Intelligence Operating System (SIOS). It is built and in production, not a roadmap. Inside it, fifty brains, twenty-five domain and twenty-five operational, run on a silicon substrate we call Poseidon. We are actively training our own models now, fine-tuning and specialising open foundations including Llama 3.2 and Qwen 2.5 while we build a sealed corpus, with funding scaling us toward fully native weights. We hold one hundred and one filed United Kingdom patent applications, roughly two thousand two hundred and thirty-four claims, owned by Mickai LTD with myself as named inventor. I tell you the architecture because the part that matters for this essay is the smallest part of it, and the part I would defend hardest if you put me in front of a regulator tomorrow.

Every action a Mickai brain takes is written to an Open Audit Record (OAR). The record is signed before the action executes, not after. It is hash-chained and append-only. The signatures use the post-quantum scheme ML-DSA-65 under NIST FIPS 204, so the proof outlasts the cryptography of this decade. And the whole chain is verifiable offline, in an ordinary browser, with no trust placed in Mickai. The audit root is anchored externally through Pantheon, our sovereign Layer 1, the one component still in build, which fixes the record to Bitcoin so even the substrate operator cannot rewrite history. The token is PAN, with a fixed supply of five billion. I built the OAR first and the cleverness second, because I have learned the order that actually matters. A clever model that cannot prove what it did is a liability dressed as an asset.

The record is where the standards land

Step back to the policy question that titles this piece. Where does a signed record fit the emerging standards? It fits exactly at the seam the standards leave open on purpose. NIST, ISO/IEC 42001, and the EU AI Act all converge on the same demand from different directions: produce evidence a stranger will believe. They specify the obligation and, wisely, leave the mechanism to the market. The mechanism that satisfies all three at once is a record written before the act, chained so it cannot be quietly altered, signed to outlast the decade, and checkable by anyone without trusting the maker. That is not an interpretation of the standards. It is the most literal reading of what they actually ask for.

I am not asking you to buy anything. I am asking you to apply one test to whatever governance stack you build, mine or anyone else's. When the audit comes, and for high-risk AI it is coming, can an outsider who distrusts you verify your record without your help? If the answer is yes, you have met the spirit of every standard on the table, and you will sleep through the audit. If the answer is no, you have a policy, you have paperwork, and you have a problem you have not met yet. The frameworks set the destination. The signed, offline-verifiable record is how you arrive with proof in your hand instead of a story in your mouth.