Sealed before it runs beats logged after it happened

An audit record that is sealed before an action runs is stronger evidence than a log written after the action happened, because a pre sealed record cannot be shaped by the outcome, lost in the incident, or edited by whoever the record implicates. Conventional systems log after execution, which means the log depends on the system surviving the action intact and honest. Our Open Audit Record inverts that order. The action is described, authorised and cryptographically sealed first, and only then does it run.

This is not a new anxiety. NIST's Guide to Computer Security Log Management, Special Publication 800-92, published in September 2006, set out the problem two decades ago: logs must be protected because they can be altered or deleted, and the systems that generate them are often the very systems under attack. When an investigation matters most, the log is too often incomplete, editable, or simply absent for the window in question. Tamper evident, append only records are the emerging standard precisely because after the fact logging has failed so often.

Why do audit logs fail exactly when you need them?

Audit logs fail when they are needed most because they are written after the event, by the same infrastructure that performed the event, so anything that compromises the system compromises its memory too. An attacker with privileged access can clear or rewrite history. A misconfigured retention policy can rotate away the critical week. A failed disk or an unlogged administrative session produces the same result: a gap precisely where the questions are. None of this requires malice. It only requires that the record is created after, and stored beside, the thing it is supposed to witness.

What does sealed before it runs actually mean?

Sealed before it runs means the complete description of a consequential action is written, signed and committed to a tamper evident record before the system is permitted to execute it. Inside Mickai, that ordering is enforced by the operating system itself, not left to an application's good behaviour. If the seal cannot be written, the action does not run. Each sealed entry captures the following before execution:

• The proposed action in full, including the documents, data and studios involved
• The policy that permitted the action, referenced explicitly rather than assumed
• The person who cleared it, gated by voice biometrics, because consequential actions wait for a human's clearance
• The cryptographic signature and chain position binding the entry to everything sealed before it
• The timestamp and machine identity, anchored to a hardware held root of trust

Only once that entry is sealed does the action execute. The record is therefore a statement of what was permitted to happen, made at the moment of decision, not a reconstruction of what someone later believes happened.

How is the Open Audit Record protected against tampering?

The record is protected by cryptographic signing, chained entries and post quantum algorithms, so altering any entry breaks the chain visibly rather than silently. Each entry is signed and linked to its predecessors, which makes the record append only in practice: it can be added to, but it cannot be rewritten without the tampering being evident to anyone who verifies the chain. The signatures use post quantum schemes because audit evidence must outlive the cryptography that protects it. A record sealed today may be examined many years from now, and it must remain verifiable even after classical signature schemes have weakened.

“A log tells you what a system says happened. A sealed record tells you what was permitted to happen, before it did. That is the difference between evidence and recollection.”

Why does verifiable offline matter?

Offline verification matters because the organisations that most need trustworthy records are the ones least able to send them anywhere. Mickai runs on the customer's own hardware, on premise and air gapped, and the Open Audit Record is verifiable in the same room. An auditor, an investigator or a court appointed expert can check the chain without a network connection, without our involvement, and without trusting the operator whose conduct is in question. There is no phone home and no dependency on any external service still existing years from now. The evidence stands on its own.

What changes when AI systems start taking actions?

The stakes rise sharply, because agentic systems act at machine speed and in volume, so the gap between what a system did and what anyone can prove it did becomes the central governance problem. Our document review capability shows the pattern in practice. The system reads document packages, cross references certificates against the records behind them, drafts paperwork and holds anomalies for a person, and every one of those steps is sealed before it happens. The reviewer keeps disposition and sign off. When a regulator, a customer or a court later asks why a document was cleared or held, the answer is not a debrief assembled under pressure. It is a verifiable record sealed at the moment of decision.

We expect pre execution sealing to become the accepted shape of accountability for AI systems, just as append only ledgers did for financial records. Regulators are already asking who approved what, and on which policy basis, and after the fact logs answer those questions weakly. Organisations that adopt sealed before it runs architecture now will find that audits, investigations and customer assurance become queries against standing evidence rather than reconstruction exercises. That is the future we built the Open Audit Record for, and it is why sealing comes before execution in every one of our studios.

Frequently asked questions

What is the difference between an audit log and the Open Audit Record?

An audit log is written after an action by the system that performed it, and it can usually be edited, rotated or lost. The Open Audit Record is sealed before the action runs, cryptographically signed, chained to every prior entry and tamper evident, so it functions as standing evidence rather than a best effort diary.

Can a sealed entry be altered or deleted later?

Not without detection. Entries are signed and chained, so modifying or removing one breaks the cryptographic chain in a way that any verifier can see. The record can be appended to, but it can never be silently rewritten.

Does sealing before execution slow the system down?

Sealing places a deliberate pause only where one should exist. Reading, analysis and drafting proceed as normal, while consequential actions already wait for a person's clearance, and the seal is written within that clearance step. Our design principle is simple: no action worth auditing is worth running unsealed.

Why does the record use post quantum signatures?

Because audit evidence must remain trustworthy for its entire retention life. Records sealed today may be examined decades from now, when quantum computing may have weakened classical signature schemes. Post quantum signing means the chain remains verifiable for as long as the record must be kept.

Does the Open Audit Record replace a SIEM or log management system?

No. Operational logs remain useful for monitoring and troubleshooting, and the log management discipline described in NIST Special Publication 800-92 still applies to them. The Open Audit Record sits above that layer as the evidential record of consequential actions, decisions and clearances, sealed before execution rather than collected after it.

What is MICKAI?

MICKAI is a Sovereign Intelligence Operating System, a SIOS, that runs entirely on the customer's own hardware, on premise and air gapped. Every consequential action is sealed to the Open Audit Record, a cryptographically signed, post quantum, tamper evident record that is verifiable offline, before the action runs. Mickai comprises 87 studios, with ten production ready at launch and 77 in development, and the architecture is protected by 104 filed UK patent applications across 2,340 claims, filed rather than granted.