The most dangerous state in codification as a practice is not absence. It is the standard that was accurate six months ago and hasn’t been touched since.
Teams that have done the work of codification (written down their criteria, extracted judgment from the experts who carry it, given their AI something real to check itself against) often arrive at a false confidence. The thing exists. People trust it. AI uses it. And nobody notices when it starts to drift from what the work actually requires.
Stale codification doesn’t fail visibly. It fails quietly: outputs that feel slightly off, reviewers who override the AI but can’t explain why, a growing sense that the standard doesn’t quite fit the cases that keep arriving. By the time the problem is obvious, the gap between the written standard and operational reality is large.
The advantage I described at the start of this series only compounds if the codification keeps pace with the work. That is the condition organisations may likely miss.
Why codification decays
Codification decays for structural reasons, not because people are careless.
The work changes. New edge cases arrive that weren’t anticipated when the criteria were written. The product shifts, the market shifts, the team’s understanding deepens. The standard that was accurate at a point in time becomes less accurate without anyone making a deliberate decision to abandon it. It just falls behind.
People move. The experts who held the tacit knowledge that informed the standard leave or shift roles. With them goes the ability to sense when the standard has drifted, because they were often the ones making quiet corrections, catching the cases where the written criteria produced the wrong result, without those corrections ever making it back into the document.
Delivery pressure wins. Updating codification is never urgent. It is always deferrable. There is always a more pressing thing. The standard sits in a Notion page that few people open each month, and the unwritten version (the version that actually governs what gets accepted and rejected) lives in the heads of whoever is still around and knows. IBM describes this pattern in AI code generation teams: rules become static artifacts the moment they stop being actively maintained. The same is true of any codified criteria, in any domain.
Three months ago I argued that codification is the prerequisite for AI that actually works. That argument is about sequencing: do the foundational work before you automate. This post is about what happens after the sequencing is right. The question is not whether to codify. It is how to keep it alive.
The update trigger already exists
The good news is that the signal for updating codification is the same signal as the signal for creating it.
In the last post I described how expert judgment surfaces at the edges: the override, the rejection, the correction made before the reason is clear. These moments are how you extract judgment that hasn’t been codified yet.
They are also how you detect codification that has gone stale.
Every time an expert says “no, that’s wrong” about an AI output or a colleague’s work, and the existing standard would have approved it, that is not just a correction. It is a gap in the codification. The standard missed something. The criterion that should have caught this doesn’t exist, or exists but no longer reflects how the work is actually judged.
The organisations that sustain the codification advantage have a habit: they treat corrections as update triggers. Not every correction requires a standard update: some are one-off edge cases, some are genuine judgment calls that should remain discretionary. But the pattern of corrections is always diagnostic. When the same type of error surfaces repeatedly, that is the codification telling you where it has fallen behind.
What a living standard looks like
The distinction is between codification as a project and codification as infrastructure.
A project has an end date. You do the extraction work, write the criteria, get sign-off, and move on. The document exists. The project is complete. Maintenance is someone else’s problem, or everyone’s problem, which is the same thing.
Infrastructure is different. It has owners. It has an update cadence tied to real events, not a calendar. It is referenced in the actual work: in the review process, in the AI prompt, in the definition of done. Not in a side document that people consult when they remember it exists.
In practice, a living standard needs three things most static documentation skips.
The first is ownership. Not a committee, not a team. A person who is responsible for the standard being current: who monitors the correction pattern, decides what gets incorporated, and is accountable when the codification drifts from operational reality. Without that, updates happen by consensus or not at all.
The second is an update trigger tied to real events, not a calendar. A class of error that keeps recurring. An expert override that reveals a gap. A significant change to the product or context that makes existing criteria less relevant. Quarterly reviews sound disciplined; event-driven updates are what actually keeps a standard current.
The third is integration with the work itself. The standard is consulted at the point of doing, not as a reference after the fact. It lives in the AI prompt, the code review checklist, the editorial brief: wherever the judgment is applied. A standard that exists outside the workflow is a standard that decays.
The compound condition
The argument across this series has been that codification is the AI-era competitive advantage because it compounds. Better criteria produce better outputs. Better outputs surface better corrections. Better corrections improve the criteria. The cycle runs in an organisation’s favour when it is running.
It stops running when the codification stops updating.
The organisations that will be operating at a different level in twelve months are not just the ones that did the codification work once. They are the ones that built a practice around it: turning corrections into updates, keeping the standard tied to the work, treating the gap between written criteria and operational reality as something to close rather than something to accept.
A codification project has an end date. A codification practice doesn’t.
This post is the third in The Codification Advantage series. Read the series opener for the full argument, or the second post on how to extract judgment rather than process from the experts who carry it.
Leave a Reply