The SuperIntelligence Countdown: Surviving the Turbulence and Obsolescence

Look at your risk register. Find the line that says human review. Read it as if you had never seen it before, as if a regulator were reading it over your shoulder, and ask the one question that actually matters: which version of the thing does that review bind? Not which person signed. Not when they signed. Which artefact, down to the bytes, does their approval attach to, and what stops a later save from swapping that artefact for a different one before it ships? On most registers I have read, the honest answer is nothing. The box is ticked. The control binds air.

I. The Box That Binds Nothing

Human review is a promise about a person, not a promise about a version.

I want to be precise about what I am attacking, because it is easy to hear this as another complaint about lazy reviewers, and it is not. The reviewer can be diligent, senior, well rested and completely right about the document in front of them. My target is the wording of the control, not the character of the person executing it. Human review, as those two words sit on a register, is a claim that a qualified human directed attention at an artefact and formed a judgement. It is not a claim about a version. It does not say which bytes were judged, and it does not say the bytes judged are the bytes that shipped. The register records that a review happened. It does not record that the reviewed thing and the released thing are the same thing.

The collapse between those two is invisible right up until it is expensive. Approval is an event that attaches to an artefact at a moment in time. Shipping happens later, from a file that has been saved, merged, exported, regenerated, or copied since. Unless something in the control binds the reviewed object to the shipped object, the approval and the release are two facts about two possibly different objects, connected by nothing stronger than an assumption. The most careful review in the world protects nothing if a later save quietly replaces the file it approved. You did not buy a guarantee. You bought a memory of one.

This is not a hypothetical a pedant invents to sound rigorous. There is a court decision that turns on exactly this gap, and it is worth walking through slowly, because the facts are almost too clean.

II. The Lawyer Who Did the Work

He verified one draft, then filed the one he had not verified.

Consider the appeal reported as JMORR Properties, LLC v. Artist Alley Townhomes, LLC, 2026 WL 2328995 (Fla. 4th DCA, 12 Aug 2026). What makes it useful is not that a lawyer used an AI tool and got burned. We have a stack of those, and most reduce to somebody who never checked. This one is different, and the difference is the point.

By counsel’s own account, the process he ran was the responsible one on paper. The draft came from an AI system, and then a human was to verify it before anything was filed. That is the control everyone claims to run. Draft, then human review. The trouble is what happened between the review and the filing. What reached the court was the un-revised draft, still carrying citations to authority that did not support what they were cited for, some of which did not exist in the form given. He had, on the facts, done a verification. He filed the other document.

Here is the part I keep returning to. The court did not accept that the mix-up rescued him. It held, in substance, that the duty to verify attaches to the document actually filed, not to whichever draft was reviewed in private, and that submitting the wrong draft does not excuse the failure to verify the citations in the version the court received. I checked a different draft is not a defence, because the duty never attached to the draft you checked. It attached to the one you lodged. The court was blunt about what it was reading, and the matter carried consequences: a notice under Florida Rule of Appellate Procedure 9.210(c) and a referral to the Florida Bar, though the opinion itself imposed no monetary sanction.

Sit with the structure of that, stripped of the law. A human review occurred. It was competent. It corrected the errors. And it protected nobody, because the control had no mechanism binding the reviewed artefact to the shipped one. The approval was real. It was simply about a different file. That is the whole essay in one docket entry, and I did not have to reach for it. A court reached it first.

III. Approval Attaches to an Artefact

The gap under the lawyer is the same gap under your model, your config, and your prompt.

The reason JMORR is not a lawyer story is that the mechanism has nothing to do with law. Approval is a relation between a judgement and an object. It is true of the exact object judged and says nothing whatever about any other object, however similar. The instant a second object enters the flow, the approval either follows the bytes or it does not, and in most real systems there is no machinery that makes it follow. Law is only the most legible instance because filing is a discrete, timestamped act with a visible artefact. The same structure sits, less visibly, under three things that matter more to the readers of a register.

Models are the first. A validation function signs off a specific model as implemented: a set of weights, a feature pipeline, a threshold, a code path, all fixed at the moment of review. The Federal Reserve and OCC supervisory guidance on model risk management, the document the industry calls SR 11-7, is explicit that validation is an assessment of a model as it is actually built and used, and that a material change to the model can leave the existing validation no longer applicable, so that revalidation may be required. Read as a binding claim, that is exactly the artefact point. The approval is true of the validated version. Retrain the model, shift a feature, adjust a cut-off, promote a challenger, and the deployed object is no longer the object that was validated. The register still says validated. Unless deployment is bound to the validated artefact, that word now describes a version that no longer runs.

Configuration is the second, and it is worse, because configuration changes do not feel like new artefacts. A limit is loosened, a flag is flipped, an environment variable is edited during an incident. Nobody experiences this as replacing an approved thing with an unapproved thing, yet that is exactly what has happened: the system in production is no longer the system that was reviewed, and no re-approval was sought, because nothing framed the edit as a new artefact needing one.

Prompts are the third, and in agentic systems they are the sharpest. A prompt is reviewed, tested, judged safe, and shipped. Then it is tuned, extended, concatenated with retrieved content at runtime, or rewritten by a downstream step. The approved prompt and the executed prompt share a lineage and diverge in substance. The review attached to a string that no longer exists in the form that was blessed.

In each case the register names a control called review or validation, and in each case the control, as written, binds a judgement to a category of thing rather than to a set of bytes. That is the defect. It is not that review is worthless. It is that approval attaches to an artefact, and almost nothing on a real register makes the shipped artefact prove it is that one.

IV. The One Review-Control You Can Actually Enforce

Most review-adjacent properties fail the enforceability test. This one passes it, cleanly.

Now the turn, because I do not want to leave you with only a complaint. I apply a single test to any control before I believe it. Can it refuse the wrong outcome at execution time, deterministically, in bounded time, independently of the system whose behaviour it governs? Most review-adjacent properties fail that test on contact. Whether a human paid real attention, whether a judgement was sound, whether a reviewer was competent on the day: none of these can be evaluated by a machine at the moment of release, and none of them fails closed on its own. They are properties of minds, recoverable only after the fact and only by inference. That is why I have been sceptical of review-as-a-control for a long time.

Version-binding is the exception, and it is the reason this piece is worth writing rather than just grumbling. The question this control has to answer is not whether a human understood the artefact. It is narrower, and it is mechanical: is the object about to ship byte-for-byte the object that was approved? That question has a deterministic answer. Take a cryptographic hash of the approved bytes at the moment of approval and record it as part of the approval. At release, hash the candidate bytes and compare. Equal, and the released artefact is provably the approved one. Unequal, and it provably is not, and the pipeline refuses to proceed. No judgement, no model, no interpretation sits on that path. It runs in bounded time and it fails closed on any mismatch, including the mismatch of a missing or unreadable artefact.

The legal system already codified this exact mechanism for signatures. Under the European Union’s eIDAS Regulation, an advanced electronic signature must be linked to the signed data in such a way that, in the words of Article 26(d), “any subsequent change in the data is detectable”. That is not a statement about the signer’s diligence. It is a statement about bytes: the signature is bound to the specific data signed, and any later alteration is detectable by construction. Detectable is the operative word, and detectable is exactly what human review, unaided, is not. Version-binding is version control written into law, and it is the property most registers gesture at with the word review and then fail to implement.

I should declare an interest here, plainly, because the conclusion favours what I do for a living. I build and sell deterministic enforcement of exactly this kind: an execution-time gate that binds an approval to specific bytes and refuses to ship an artefact whose hash does not match the one that was approved. So when I tell you version-binding is the rare review-property you can make binding, hear it with the discount that deserves. The test, though, is not mine to bend. Version-binding either satisfies deterministic, bounded, independent, fail-closed enforcement or it does not, and it plainly does, whether or not anyone buys it from me. What I am selling is an implementation of a property the eIDAS drafters and the SR 11-7 authors already treat as the real obligation.

V. Not the Placebo Argument

I am not saying review is theatre. I am saying unbound review is, and the distinction is load-bearing.

Here is where I have to hold myself back, because there is a stronger, more quotable version of this essay that is also wrong, and I watched myself drift towards it while writing. The overclaim is that human review is not a control at all. That is too strong, and if I let it stand it would sink the piece. A fully specified control can pass the enforceability test even with humans in it. Picture two independent reviewers, on separate systems, under a bounded response time, each approval cryptographically bound to the exact artefact, and release conditioned on both bindings matching the shipped bytes. That is a real control. It refuses, it is bounded, it is independent of the model, it fails closed. I am not against review. I am against a register that writes the word and supplies none of that specification, and above all against review that is not bound to the version that ships. That is the narrow, true claim, and it is narrow on purpose.

The cases discipline me too, and I have to be honest about which way they cut. There is a second recent matter, reported as Arbuckle v. Tanner (N.S.C.A., Gogan J.A., 12 Aug 2026), where a self-represented litigant filed transcripts presented as certified that had in fact been fabricated by an AI system, and the fabrication was caught. I could dress that up as support for my thesis. It is not, and pretending would be exactly the overreach the essay is warning against. The catch did not come from any producer-side review. It came from the adversary. Opposing counsel compared the filed transcripts against the genuine record and found the discrepancies, dozens of them, and the appeal was dismissed. That is a review-adjacent check that worked, and it worked because an interested opponent did it, not because a binding control existed. It cuts against me, and I would rather say so than launder it. Version-binding is what you install when you cannot rely on an opponent to audit you.

And I should say plainly what this essay is not, because I have argued nearby before. This is not a rerun of the reviewer-fatigue case I made in The Tired Human at the Gate. That piece ran the enforceability test on the reviewer, on the human at the desk, and asked whether attention could be made binding. This one is about the artefact, not the attention. The tired human and the fresh, expert, fully attentive human have the same problem here, and it is not tiredness. It is that neither of them is bound to the version that leaves the building. Different failure, different fix, and I wanted to build the artefact-binding point on its own rather than borrow the earlier one’s clothes.

VI. The Case Against This Essay

Concede the overreach out loud, or the thesis is just a longer advertisement.

Let me put the sharpest objections in one place, because a draft that cannot be attacked is not finished.

First, the overreach, which is the one that could actually kill the thesis. If ordinary human review, as actually written on real registers, routinely does deliver version-binding in practice, through change-control discipline, sign-off workflows, or release gates that already re-check the artefact, then my central claim collapses into a complaint about sloppy shops rather than a structural defect in the control. I have argued that the binding is almost never named, but almost never is an empirical wager, and a reader with a well-run change-management function is entitled to say the binding is present in theirs and I am generalising from the failures I happen to see. I think the binding is usually absent. I concede I have not counted, and that concession is the falsifier: show that plain registers routinely deliver version-binding, and the essay collapses.

Second, I lean on one clean case. JMORR is a genuine artefact-binding failure, but a single reported matter is a data point, not a distribution, and the other case to hand, Arbuckle, points the other way: it was caught, and caught by the adversary rather than by the box. If most AI-filing failures turn out to be opponent-caught rather than binding-failed, the gap may be narrower or less consequential than I claim. My defence is that SR 11-7 and eIDAS establish the mechanism independently of how many practitioners have tripped over it, but if JMORR is an isolated slip rather than an instance of a general gap, my anchor weakens, and I would rather flag that than have it found.

Third, the boundary between this argument and the reviewer-attention argument is one I drew myself, and a hostile reader can say I have split one idea into two essays to sell the same conclusion twice. I have tried to keep them genuinely distinct, attention in the earlier piece and the artefact here, but I concede the seam is mine to defend.

Fourth, the interest. I build and sell the deterministic binding I am recommending. A man who sells locks telling you your door is open should be read with suspicion. That does not make the enforceability test wrong, but it should make you read the prescription slowly, and check the citations rather than my incentives.

VII. Coda

Name the version on the register, or admit the box is empty.

So here is what I am actually asking, and it is smaller than the polemic might suggest. Go to the line on the register that says human review, and ask it one question: which version. If the control can answer, if it can point to the exact bytes it approved and prove the shipped artefact is those bytes, then it is a real control, it will refuse the wrong version at execution time, and it will survive a regulator’s stare. If it cannot, then it is not protecting the release. It is recording that a person once looked at something, and hoping that something and the thing that shipped were the same.

The lawyer in JMORR looked at a draft. He was diligent, by the account of his own process. Then a different draft went to the court, and the court held, correctly, that his diligence had attached to the wrong object. That is not a story about one careless practitioner. It is the shape of the gap sitting under model validation, configuration, and every prompt now shipping from an approval nobody bound to the bytes. A control that cannot name the version it approved is not a control. It is a hope with a signature. The one genuinely cheerful thing in this whole piece is that this is the rare governance gap with a deterministic floor already written into law. You can bind the bytes. The question is only whether your register has the nerve to say so.