Approved, But Not the Version That Shipped

An approval recorded beside a work product, rather than bound to a specific version of it, authorizes whatever ships next.

Ask the person who signs off on your AI workflow's output what exactly they signed. Most will name a document. Very few can name a version.

That gap is not a paperwork problem. An approval that names a document covers every future state of that document. It travels forward, silently, onto text nobody approved. The signature is real, the reviewer is competent, the process ran, and nothing in it can tell you which version the signature covers.

We hit this inside our own publishing pipeline this month. Independent reviewers read the piece before it went out, and two of the three sent it back for repairs. What nothing in the pipeline compared was the version they approved against the version that published.

Last week's edition was about an old result outliving a fix. This is its mirror: an old approval outliving the thing it approved. The difference matters, because the first is a data problem and the second is an authority problem, and they are fixed in different places.

What appeared to work

Our newsletter runs through a small governed pipeline. A draft is reviewed by several independent passes, the operator records an attestation that the piece is his work and his claims, and only then does a publish step lock the text into an immutable record. The gate that guards publication checks a list: the review record exists, it names this piece, it carries enough distinct reviewers, every verdict passes.

Every one of those checks answered a question about the approval. None of them asked the only question that matters to a reader: is the approved text the text about to be published?

Here is what our record shows, in order. September's edition went out to readers on a Monday. Later that day, we opened the change that would lock the published text into our permanent archive. Reviewers blocked it, because the archive requires a statement from the operator that the work and its sources are genuinely his, and no such statement existed. Twenty minutes later we added one, inside that same change.

A separate control then blocked the whole thing. Its rule is narrow: the approval has to be already locked in, on its own, before the change that ships under it. Ours had been written in the same breath. Nothing was archived, and the work was rebuilt as two steps.

Read the order again, because it is the part I would rather not print. The approval was recorded after the edition was already public, and it was written only because a reviewer demanded it.

Where ownership actually stopped

The approver believed he had approved a document. What he had actually approved was a moment, and in our case a moment that arrived after readers already had the text. Everything after that moment inherits the signature without asking him.

This is the part that is easy to miss in a workflow diagram. Draw the boxes and it looks airtight: draft, review, approve, publish. The arrows imply that what moves between boxes is the same object. In practice what moves is a filename, and a filename is not a version. The approver owns a decision about content. Nobody owned the question of whether the content still matched the decision.

When we traced it, the honest answer to "who is accountable if an edited draft ships under an old approval" was: whoever compares the final version against the approved one closely enough to notice. That is a hope, not an owner.

What was actually unbound

The mechanism is unglamorous. Our approval record sat next to the work as a separate file. It described the piece by name. It even carried a fingerprint of the approved text, because someone had the foresight to record one.

Nothing compared that fingerprint to anything.

The approval we eventually recorded named this weakness precisely. The gate, it noted, did not yet bind the approval to a fingerprint of the approved draft, and until it did, whoever ran the promotion had to confirm by hand that the draft's fingerprint matched the one stored on the approval.

Look at what that sentence proposes as the safeguard: a person, repeating that check by hand, every time, for as long as the gap stays open. That is an intention with a name attached rather than a control. It is also the most common answer you will get if you ask how an approval is enforced in a real operation, and it holds exactly as long as attention holds.

An approval that reaches toward the work without attaching to it.

What binding looks like

Three properties turn an approval into something that constrains reality.

The approval names the exact version. Not the document, not the folder, not the date. A fingerprint of the exact text the reviewer read. If the reviewer read something else, the fingerprint is different.

The publishing step recomputes the fingerprint and refuses on mismatch. Recording is not enforcement. The machine has to do the comparison at the moment of publishing, not a person afterwards. Ours now fails with a message aimed squarely at the tempting shortcut: "A draft edited after review needs a new review; do not re-record the digest alone".

The approval cannot be rewritten inside the change that ships. This one is less obvious and it is the one that bites. If the same change can edit both the work and its approval, then any edit can bring its own permission. Our pipeline refuses to publish when the approval record differs from the version already on the record, which forces two separate reviewed steps: land the approval, then publish under it.

That third property is what turned our one-step release into two, and it was live before we needed it. The replacement landed the approval on its own, and the publish followed three and a half hours later under an approval that could no longer move.

Bound: the approval names one version, and the gate refuses the rest.

How to tell whether your workflow has this

Two questions, and they are answerable today without a project.

Take the last thing your AI workflow shipped: a generated report, a customer reply, a pricing sheet, a summary that went into a board pack. Ask the person accountable for it: which version did you approve, and can you show me that version is the one that went out.

A good answer points at the exact copy the reviewer signed, and at a system record showing the published copy matches it.

If the answer comes back as a document name, a timestamp, an approval in a ticket, or an email thread, the approval is not bound. It is adjacent. Most approval trails in production AI workflows are adjacent, and they survive audit because nobody has asked the second question.

A stronger variant, for anyone who wants the uncomfortable version: ask whether an edit made after approval would have been visible at all, and to whom, and how.

What it cost us, precisely

The failure class is severe and our instance of it was not.

The cost was rework: one promotion change closed without ever merging, a rebuilt sequence, and a day of attention. No reader received the wrong text, and no revenue moved. What we did not have, at the moment readers had the edition, was an approval that covered it.

What makes it worth an edition is that the same structure, in a workflow with real throughput, produces an unreviewed artifact in front of a customer with a genuine signature attached to it. We found ours because a publishing pipeline is slow and visible enough for a human to notice. A pipeline that sends a thousand generated replies a day is neither.

And our fix is partial. The third property governs the change that publishes; it says nothing about the change that prepares the work. The fingerprint is still written by the author, and a reviewer reads a number they cannot easily recompute. Before publishing, an author could change the work and update the fingerprint together, and the gate would pass. Closing that means binding the fingerprint to each reviewer's own sign off, and we have not done it. The control we have stops accidents. It does not yet stop intent.

A control described as stronger than it is becomes the reason nobody checks it again.

The commercial version of this

If you are accountable for an AI workflow, three questions decide whether approval means anything in it.

What may the model decide on its own, and what must a person authorize? Where does that authorization attach, to a version or to a name? And who verifies, after launch, that the thing running is the thing that was authorized?

Most teams can answer the first. The second is where approval quietly stops being a control. The third is an owner with a standing job: someone who re-checks, on a named cadence, that what is running is what was authorized, and who reports when it is not. Not a line in a policy document.

The three questions above cost you ten minutes and tell you whether you have a problem. If the answers are uncomfortable, that is what the Readiness Scan my agency runs is for: one workflow, its failure modes mapped, and a plan for who owns it after launch. Work with OIA on one workflow.