Why AI audit replayability forces deterministic inference, versioned weights and frozen data snapshots
Reproducing an AI decision years later means freezing the model version, the data it saw and the decode path, then signing all three together.
Audit replayability forces three frozen artefacts: the model version, the exact data it saw, and the decode path, because dropping any one drifts the replay.
Why it matters now: regulated buyers in finance, health and government increasingly have to reconstruct an automated decision on demand. DORA has been in force since January 2025, NIS2 covers essential and important entities, and the EU AI Act's high-risk Annex III obligations, once due 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and Article 50 transparency largely unchanged. Meanwhile the US CLOUD Act can compel a US-based provider to hand over data regardless of where its servers physically sit, so where and how an audit trail is held is now a board-level question.
What must you freeze for an AI decision to replay years later?
A run replays only when the model version, its input data and the full decode path are frozen together and bound into one signed record.
Replayability is not a single control. It is a set of artefacts that must be captured at decision time and cryptographically linked, because any gap lets the reconstruction drift away from what actually happened. The table below sets out each requirement, what breaks it if skipped, and how we seal it into the audit ledger.
| Replay requirement | What must be frozen | What breaks it if skipped | How Mickai seals it |
|---|---|---|---|
| Versioned weights | The exact parameter set and model version id | An updated model returns different outputs | Content-hashed weight version pinned in the record |
| Frozen data snapshot | Every input and retrieved document at decision time | Live sources mutate and the answer changes | Immutable snapshot hashed and bound to the run |
| Deterministic decode (seed and temperature) | Fixed seed, temperature and sampling method | Stochastic sampling yields different tokens | Decode settings captured and replayed exactly |
| Kernel and hardware determinism | Compute kernels, precision and device profile | Floating-point order shifts the result | Attested hardware profile sealed with the run |
| The signed record that binds them | The cryptographic link across all four | Unbound artefacts drift apart over time | FIPS 204 or FIPS 205 signature over the whole entry |
Why do versioned weights matter?
Versioned weights pin the exact parameter set that produced a decision, because updated weights change outputs and make any later reconstruction unfaithful and legally weak.
A model is a fixed set of numbers, and any fine-tune, patch or silent update produces a different set that answers differently. If the weights that scored a loan or flagged a transaction have since been replaced, a replay run on the current model tells you what today's model would say, not what happened at the time. We treat each weight set as a content-hashed version and pin that hash into the record, so the reconstruction always loads the same parameters. Because our capability models run under sovereign aliases on operator hardware, the version you audited is the version you keep, not one a vendor rotated out from under you.
What is a frozen data snapshot, and why can't you skip it?
A frozen data snapshot captures every input the model saw at decision time, because live sources mutate and a moved record silently changes the answer.
Determinism in the model is worthless if the inputs shift. A retrieval step that pulls from a live index, a customer record that gets corrected next week, a document that is re-ranked differently: each of these quietly rewrites history. We hash the full set of inputs and retrieved context into an immutable snapshot bound to the run, held behind a zero-egress inbound perimeter so nothing about the decision leaves the operator boundary. The snapshot is what makes the replay honest, because it reconstructs the world the model actually saw rather than the world as it stands today.
How does deterministic inference pin seed, temperature and kernels?
Deterministic inference fixes the seed, temperature, sampling method and compute kernels, because floating-point order and stochastic sampling otherwise produce different tokens from identical inputs.
Two hidden sources of drift live in the decode path. The first is sampling: a non-zero temperature and an unfixed seed mean the model rolls dice, so the same prompt yields different text on each run. The second is arithmetic: the order in which floating-point operations execute on a given kernel and device can change the last bits of a result, and those small differences cascade. We capture the seed, temperature and sampling method with the run and seal an attested hardware profile alongside them, so the decode path is reproduced exactly rather than approximately. This is the part most teams underestimate, because it is invisible until a replay fails to match.
Is replayability a compliance checkbox or an infrastructure discipline?
Replayability is an infrastructure discipline, not a compliance tick, because the freezing must be engineered into storage, versioning and the decode path from day one.
Being candid: this is a real lift, and most teams underweight it. You cannot bolt replayability on after a decision has been made, because the artefacts you needed to freeze are already gone. Public cloud assistants such as ChatGPT, Copilot and Gemini are genuinely the right pick for general knowledge work and drafting, and they are excellent at it. The contrast is narrow and architectural: they are not designed to hand a regulated buyer a bit-for-bit reconstruction of a specific past decision on operator-owned hardware, which is exactly what an audit demands for the most sensitive data.
“Replayability is not a report you produce after the fact; it is a property you either engineered into the system before the decision or lost forever.”
How does Mickai bind all three into one signed record?
We seal weights, data snapshot and decode settings into one post-quantum signed record on operator hardware, so a run replays bit-for-bit years later offline.
Mickai is a Sovereign Intelligence Operating System, a SIOS, built and live and running offline on operator-owned hardware, with every action cryptographically sealed. Each ledger entry is signed with FIPS 204 ML-DSA or FIPS 205 SLH-DSA, both post-quantum digital signature standards, while FIPS 203 ML-KEM handles key encapsulation and never signs. Hardware-attested identity binds each signature to the machine that produced the run, and where a decision uses cross-model consensus across the 50 brains, 25 domain and 25 operational, every participating model version is pinned into the same record. The discipline is protected by an IP estate of 104 filed UK patent applications and 2,340 claims, owned by Mickai LTD, Companies House 17166618, filed and patent pending. The result is offline verifiability: a sealed run replays without depending on any external service staying online.
Frequently asked questions
How long does a Mickai run stay replayable?
For as long as the sealed record is retained. Because we freeze weights, data and decode settings and sign them on operator-owned hardware, a run replays bit-for-bit years later, offline, without depending on any external service remaining online. Retention policy is set by the operator, not by us.
Won't forcing determinism make my model weaker?
No. Fixing the seed, temperature and kernels constrains how a model samples, not what it knows. You trade a little output variety for exact reproducibility, and for audited decisions that is the correct trade. Non-audited, exploratory work can still run with sampling enabled.
What actually signs the audit record?
The ledger entry is signed with FIPS 204 ML-DSA or FIPS 205 SLH-DSA, both post-quantum digital signature standards. FIPS 203 ML-KEM performs key encapsulation and never signs. Hardware-attested identity binds each signature to the machine that produced the run.
Is full replayability overkill for my small team?
Most teams underweight it until a regulator or a court asks them to reproduce a decision, and then reconstruction is impossible. The lift is real, but it costs far less to freeze artefacts at decision time than to defend an answer that can no longer be reproduced. Cost scales with retention volume, not with headcount.
How does this map to the EU AI Act deadlines?
High-risk Annex III obligations, once due 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and Article 50 transparency largely unchanged. Replayable records position you ahead of whichever date applies, rather than scrambling near it.