Model Version Drift: The Record Must Pin What Actually Ran
An AI decision is only as trustworthy as your ability to prove which model, which weights, and which prompt produced it. Most systems cannot.
Ask most teams which model made a given decision last Tuesday and you will get a brand name. Ask which weights, which system prompt, which sampling settings, and which safety filter were live at that exact moment, and the answers thin out fast. Hosted models are updated continuously. A vendor ships a new checkpoint, retunes a guardrail, swaps a tokenizer, and the version string you logged points at something that no longer exists. This is model version drift, and it quietly dissolves accountability for every automated decision an organisation has made.
Why a model name is not an answer
A model name is a marketing label, not a fingerprint. Two responses can carry the same name and come from different weights, because the provider rolled the checkpoint forward between them. The prompt that shaped the output often lived in template code that has since been edited. The retrieval context was assembled from documents that have since changed. Reconstruct a decision six months later and you are not rebuilding what happened, you are guessing at a plausible version of it. In a regulated process, a guess is the same as having no record at all.
The cost lands when it matters most. A loan is declined, a claim is flagged, a clinical summary is escalated, and someone with standing asks you to show your working. If the model has drifted, you cannot reproduce the output, you cannot explain the reasoning, and you cannot prove the version under question is the version that ran. The decision stands in the world but its justification has evaporated.
Pinning, not logging
A changelog tells you a model was updated. It does not tell you which version touched a specific decision, and it can be edited after the fact. What governance actually requires is pinning: binding the exact model identity, the weight hash, the prompt, the retrieval context, and the configuration to each consequential action, then sealing that bundle so it cannot be altered later without detection. Pinning answers a sharper question than logging. Not what could have run, but what did run, provably, at this moment, for this output.
Two properties make pinning real. First, completeness: the record has to capture enough state to reproduce the decision, which means the weight hash and prompt, not just a friendly name. Second, integrity: the record has to be sealed at the moment of the action, so it cannot be quietly back-edited to match a later story. A log that can be rewritten proves nothing about the past. It only documents the present version of the past.
Why this is hard on someone else's infrastructure
On a hosted endpoint you do not hold the weights, so you cannot hash them. You do not control the rollout, so you cannot freeze a checkpoint while a case is open. You are handed a version string and asked to trust it. When the provider updates the model, your historical records still point at a name whose meaning has shifted underneath you. The drift is structural. It is a property of running intelligence you do not control, on hardware you cannot see.
Mickai treats this as a first-class problem rather than an operational footnote. Mickai is a Sovereign Intelligence Operating System, a SIOS, that runs fifty specialised brains (twenty-five domain and twenty-five operational) on the operator's own hardware, fully offline-capable. Because the weights live on the operator's machine, every model state is local, inspectable, and hashable. The operator decides when a checkpoint changes, so a version can be frozen for as long as a decision is open to challenge. Drift stops being something done to you by a remote vendor and becomes something you govern.
The Open Audit Record
Mickai's answer to drift is the Open Audit Record, the OAR. Every consequential action is captured with the model identity, the weight hash, the prompt, and the configuration that produced it, then sealed and signed with FIPS 204 ML-DSA-65, the published NIST post-quantum signature standard. Mickai did not invent that standard, it adopts it, which is the point: the signature scheme is open and verifiable by anyone, not a proprietary seal you are asked to trust. A signed OAR is a cryptographic claim that this exact model state produced this exact output at this moment, and that the record has not been altered since.
Signing fixes integrity. Permanence is a separate requirement, because a signed record still has to survive and stay anchored in time. Pantheon, Mickai's own sovereign Layer 1 (native token PAN, a fixed supply of five billion), anchors a hash commitment of the record to Bitcoin, giving the seal an independent timestamp that an operator cannot quietly rewind. Pantheon does not move Bitcoin and is not a Bitcoin Layer 2. It commits a hash for permanence. Anchoring is not spending. The result is a chain of proof that runs from the weights on the operator's disk, through a post-quantum signature, to a tamper-evident anchor in time.
What this changes when someone asks you to prove it
Reconstruct a decision under this model and you are not guessing. You hold the model identity and the weight hash, so you know exactly which version ran. You hold the prompt and configuration, so you can reproduce the conditions. You hold a post-quantum signature, so you can prove the record is the original. You hold an anchor, so you can prove when it was sealed. Version drift does not erase the past, because the past was pinned at the moment it happened, on hardware the operator controls.
This discipline is also where the patent portfolio sits as evidence rather than headline. Mickai's architecture is backed by 101 filed UK patent applications covering around 2,234 claims, owned by Mickai LTD, with Micky Irons named as inventor. The claims matter here only because they describe the machinery that makes a decision provable after the fact. The argument stands on the mechanism, the signed and anchored record, not on the count.
The standard to hold yourself to
Treat any AI decision you cannot reproduce as a decision you cannot defend. The test is simple to state and unforgiving to fail. Name the exact model, the exact weights, the exact prompt, and prove the record was sealed at the moment of the action and has not changed since. If your system can only return a model name, it cannot meet that test, and version drift will eventually turn a defensible decision into an unexplainable one. Pin what actually ran, seal it, anchor it. The record, not the changelog, is what stands up when someone asks you to prove it.