Every single enterprise AI maturity assessment I've seen shares the same five axes:

• Seats licensed,
• prompts per week
• Percentage of teams onboarded
• Executive sentiment
• A number somebody on the slide calls "adoption velocity."

Score high on all five and the "model" declares that you are advanced. Score low and you get a roadmap with more seats on it, brought to you by a model provider looking to sell more seats/tokens/licenses.

Not one of those axes asks whether the work is correct.

That omission isn't an oversight, it's the whole point of the model. A company can land in the top 10% for AI spending and the bottom 10% for AI maturity in the same fiscal year, and the adoption dashboard won't tell you which one you're looking at, because it was never built to ask the right question. Meanwhile the review queue is drowning, defect escape rates are climbing, and every chart on the transformation deck is green.

What CMMI got right that this generation forgot#

Software has graded organizational maturity before, and it did a better job of it than the current crop of AI radar charts.

The Capability Maturity Model, and later CMMI, spent the 1990s and 2000s scoring software organizations on a five-level scale. You had to produce artifacts, document processes, and provide historical defect data, not just an opinion or vibes.

Whether those artifacts reflected real behavior or became a target unto themselves is CMMI's own well-known second problem: appraisers were typically engaged and paid by the organization being assessed, and level-shopping became a real, documented criticism of the standard. But it set a floor that current AI maturity models don't even try to clear: an opinion is not evidence.

Today's AI maturity models threw that decision away. They ask a director to rate their organization's "AI readiness" on a scale of one to five and call the average an assessment. That is not a maturity model. That is a satisfaction survey wearing a rubric as a costume, and satisfaction surveys become gamified the moment they matter to anyone's bonus.

Maturity is where trust lives#

This Agentic Maturity Model is built on and around this core principle: maturity is not how much AI a company produces. It is what mechanism establishes that the work is correct, and whether that mechanism scales.

Everything else you would normally put on a maturity radar (tooling, knowledge architecture, observability, unit economics) is downstream of that one, key principle. It matures as a consequence of trust moving from human attention to a verified, compounding system. It does not mature on its own, no matter how many licenses you buy.

I call that principle "trust location". It is the actual axis of evaluation. Seats and tokens are a shadow it casts on the wall, a subsequent effect, and most enterprise AI strategy is currently spent measuring the shadow.

Three rules for a model that can't be gamed#

A maturity model that can be improved by enthusiasm will be improved by enthusiasm, and nothing else. So this one is built to three constraints, inherited from a lifecycle argument I made in the description of an Agentic Development Lifecycle and worth restating here because they are the whole reason this model is worth trusting:

1. Audit-checkable, not sentiment-checkable. Every level is defined by a structural fact you could verify in an afternoon: a log, an artifact, a query against production data. Not a survey answer. If the only evidence for your level is a director's confidence, you don't have a level yet.
2. Transitions are driven by pain, not aspiration. Nobody climbs a level because a slide said to. Each level ends because its trust mechanism hits a wall it cannot get past, and the organization is forced up or it stalls. Find the pain, and you've found the level.
3. Maturity is not monotone in AI usage. A team running four copilots and a chatbot can burn more tokens in a week than a team running a disciplined agent pipeline burns in a month, and the second team is the mature one. Mature organizations spend deliberately, concentrated where an error is expensive to catch late. They do not spend everywhere enthusiasm reaches.

That third rule is the one that breaks the adoption-curve story completely, because it means the leaderboard your vendor sends you every quarter, ranked by spend, is not just incomplete. It can be inverted. The company at the top of that leaderboard may be the one paying the most to generate the least trustworthy output at scale.

I wrote a series on the Agentic Development Lifecycle for the practitioner who has to actually build a system where the work is verified rather than merely produced. This series is for the person who signs off on that practitioner's budget, and who is currently being told by every dashboard in the building that Level 2 is the destination.

It isn't. The next two posts build the rest of the map. The five levels name where trust actually sits today, wall by wall. The diagonal law explains why almost every AI failure your board hears about, and a few that haven't reached the board yet, are the same misalignment wearing a different name.

Find your organization on the adoption curve if you want. It will tell you how much you spent. It will not tell you what you bought.

The last post made a claim: maturity is where trust lives, not how much AI you use. A claim like that is only useful if you can point at a map and find yourself on it.

Here is the map. Five levels. One axis. A wall at the end of each one that decides whether you climb or park.

The axis is trust, not tooling#

Every level below is defined by the same question, asked of a different mechanism: what establishes that this AI-produced work is correct, and does that mechanism scale?

Notice what moves as you climb, level to level, in the trust mechanism. It is never the tooling. It is always the answer to "who, or what, is allowed to say this is correct."

Level 0: Prohibition is zero visibility, not zero usage#

An organization at Level 0 has usually not achieved zero AI usage. It has achieved zero visibility into the AI usage that is happening anyway. Engineers paste code into personal accounts. They run local agents on side monitors. They expense a tool under a line item nobody scrutinizes closely enough to ask what it does. The policy did not prevent risk. It forfeited governance over risk that exists regardless, because the people doing the work found the policy slower than the deadline.

Almost every organization that believes it is at Level 0 is secretly at Level 1 with the lights off. The genuine exceptions are the rare environments where egress is physically controlled, air-gapped networks, classified systems, where prohibition is enforced by the network and not by a memo.

Audit check: run an anonymous survey and pull the egress logs. They will disagree with the policy, and the size of the disagreement is your actual Level 0 population.

Level 1: Experimentation, where nothing compounds#

Trust here is whatever each individual privately decides it is. Productivity claims are anecdotal, sincere, and unfalsifiable: someone found a workflow that saves them two hours a day, and there is no way to check, transfer, or scale that claim. The unit of AI work is the prompt: personal, ephemeral, unversioned, gone the day that person changes teams or leaves.

This is the level where a company can have real, individually impressive AI usage and zero organizational capability, because none of it is written down anywhere the organization can find it again.

Audit check: look for a single shared, versioned AI artifact anywhere in the organization, a prompt library, a skill, a template, that survives the departure of the person who wrote it. If none exists, you're at Level 1 regardless of how many people are quietly excellent at prompting.

Level 2: Assistance is where maturity goes to feel finished#

This is where the typical enterprise sits, and it earns that position honestly, because Level 2 feels like maturity from the inside. Licenses procured. Policy written. Copilots deployed across engineering. A RAG-powered "chat with our docs" tool shipped to positive reviews. Giphy-filled fights over which harness is best play out across Slack channels. Usage dashboards, every one of them, green.

The trust mechanism underneath all of that activity is identical to the one the organization used before any of this AI infrastructure existed: a human reads everything before it counts. AI scaled production, but it did not scale verification. Those two things were supposed to move together and didn't, so review queues balloon, and the pressure has to go somewhere. Some of it goes to hiring reviewers, linearly, against output that scales with compute. Some of it goes to throttling the agents, which quietly caps the ROI the program was funded to deliver. And a great deal of it goes to the place that absorbs pressure without ever showing up on a chart: reviewers quietly stop reading in full and start approving blindly.

Your copilots made you feel mature. The review bottleneck says otherwise.

That is not a hypothetical for later. It's a live condition at most companies running this playbook right now, and the standard adoption metrics improve as it happens: acceptance rate climbs, cycle time drops, throughput per engineer looks fantastic. Every number the transformation program reports gets better while the mechanism that was supposed to catch mistakes quietly disappears.

Audit check: confirm that no AI-produced change reaches production without a human reading it in full, then measure whether that's still true. Pull last quarter's AI-assisted changes and plot review duration against diff size. A growing cluster of large diffs approved in under a minute is the review bottleneck showing up in the data before it shows up in an incident. The incident just hasn't been filed yet.

Level 3: Delegation is the structural break#

This is the level where trust actually relocates, and it's the only one on this list that requires the organization to build something rather than buy or staff something. Trust migrates from human attention to machine gates: executable tests frozen before implementation exists, contracts the builder is mechanically prevented from arguing with, and fresh contexts chartered to refute the work rather than assess it, what the ADLC calls prosecution when the work in question is code.

Humans don't disappear from this picture. They concentrate at the two places their judgment actually decides something: approving the spec before work starts and accepting the running behavior after it's built. Everything between those two moments is machine-gated, which is the entire point. Agents are delegated whole tasks here, not keystrokes, because the verification underneath them finally scales the way the capability does.

Audit check: find a change an agent produced that reached production with no human reading the diff, and name the specific gate(s) that made that safe. If you can't name the gate, you're not at Level 3 yet, whatever your capability or token spend suggests.

Level 4: Operationalization is the level that improves itself#

Level 4 is not "more Level 3." It's a different kind of system, one that gets cheaper and stricter at the same time, because the gates themselves are the object of continuous improvement. Recurring findings from review get converted into deterministic controls. Observed work gets mined into versioned organizational skills. Gates get calibrated with planted defects so "we have review" becomes "we know our review catches this percentage of this category of mistake." The unit economic that matters at this level is cost per merged, verified change, and it falls, quarter over quarter, because the system is designed to make it fall.

The closest concrete example I can point you to is the one I built for practitioners: the Agentic Development Lifecycle is the reference implementation of Level 4 for software development specifically. It is not the only way to get there. It's proof the destination exists.

Audit check: ask for the distillation log, the list of controls that exist today because a gate caught something last quarter, and the trendline of cost per verified change. If neither exists, the organization is somewhere south of Level 4, no matter what the capability roadmap says.

What dissolves each wall#

Every wall above has exactly one keystone unlock, the specific investment that dissolves it rather than merely postponing it.

There is no keystone unlock listed for what comes after Level 4, because there isn't a wall waiting there. The whole design of the level is that it keeps dissolving its own walls before they finish forming.

The spine is not the whole model#

Underneath these five levels sit five tracks, capability, verification, knowledge, observability, and economics, each climbing its own five-stage ladder in step with the level above. This post only covers the spine on purpose. The tracks are worth an article each, and they're coming.

Of those five tracks, one is holding up all the others: verification. Every capability rung on this ladder is only safe once the verification rung underneath it has actually been built, not purchased, built. That relationship between the two, and the precise shape of what goes wrong when an organization gets it backwards, is the subject of the next post.

Your AI program has two numbers, and you are probably tracking one of them.

The first number is capability: what you have deployed. The natural progression is prompts, then skills, then agents, then orchestrated fleets of agents. This number has a budget line, a vendor ecosystem, a slide in the board deck, and a conference circuit devoted entirely to increasing it. Everyone tracks this number. It's the one your dashboard is green about.

The second number is verification: what mechanism establishes that the work your AI produces is actually correct, and whether that mechanism scales. This number has no vendor category, rarely has a named owner, and almost never appears in the board deck. Most organizations could not tell you what theirs is if you asked in the meeting.

The Diagonal Law says the relationship between these two numbers is the whole agentic maturity game:

Capability above verification is risk; verification above capability is waste.

The law names resting states, not moves. Safe progress is diagonal, and the safe way to walk a diagonal is a staircase: build the verification step, then climb the capability step onto it. Time spent on one step above the diagonal is sequencing. Residence above it is waste. Time below it, in any amount, is risk.

I built this grid the same way I built the ADLC's flaw inventory: name the failure mode precisely enough and it stops being a vibe and starts being a checklist. For the ADLC, I named eight ways model-based builders fail that human developers don't. This one names seven ways enterprises misalign capability and verification, and, not by coincidence, the fix for the worst one turns out to be the same move both times: fresh contexts chartered to refute the work, not assess it.

Nearly every enterprise AI failure that makes the news, and, if you run agents under mandatory human review, at least one that is quietly developing inside your own organization right now, is an off-diagonal state on this grid. The exceptions are failures of raw model capability: a hallucinated fact inside a process that was correctly designed and verified belongs to a different axis entirely. Everything else lands here, and every off-diagonal state has a name.

The two ladders#

The previous article in this series defined maturity by where trust lives, named the trust location. This grid gives that definition coordinates.

The capability ladder is the visible one, the one every vendor sells as the whole story:

• C0 - None. No sanctioned AI capability. Whether any unsanctioned capability exists is a different question, and we'll get to it.
• C1 - Prompt. Personal, ephemeral, unversioned. Value dies with the author.
• C2 - Skill. The first organizational unit of AI capability: a versioned, shared, reviewable artifact bundling procedure, context, and constraints. The prompt is to the skill what the shell one-liner is to the committed script.
• C3 - Agent. Autonomy at task scale. An agent owns a ticket, not a keystroke.
• C4 - Orchestration. Multiple agents under deterministic control flow, fan-out, verification panels, pipelines, maturing into a lifecycle that improves itself.

The verification ladder is the one that holds all the rest up, the one nobody sells:

• V0 - Prevention. Policy as the only control. Nothing is verified because, officially, nothing exists.
• V1 - Individual judgment. Whoever ran the prompt decides if the output is good. Trust is a private matter.
• V2 - Human review. A person reads everything AI produces before it counts. The pre-AI trust mechanism, unchanged.
• V3 - Rails and adversarial review. Executable tests frozen before implementation, contracts the builder cannot argue with, fresh contexts chartered to refute the work rather than assess it.
• V4 - Calibrated prosecution. Planted defects measure what the gates actually catch. Review stops being a ritual and becomes an instrument with a known error rate.

Put capability on the horizontal axis and verification on the vertical, and every organization occupies a cell of a five-by-five grid. Realistically a region: large enterprises sit in different cells per team, and the outliers matter, because incidents start with your outlier teams, not your organization-wide average. The diagonal cells, where the ladders align, are the five maturity levels from the last post. Everything else is a trap.

Two measures govern how bad an off-diagonal cell is. The distance from the diagonal measures the size of the trust gap. The volume of work flowing through the capability measures your exposure to it. The same shallow gap is a smaller problem under a trickle of shadow prompts than under an agent fleet's full output, which is why the mildest trap and the defining one sit at the same distance from the diagonal, and volume, not geometry, separates them.

The Diagonal Law's jurisdiction#

Before walking the grid, let's discuss an honest boundary: the verification ladder ranks trust mechanisms for work whose acceptance criteria can be made executable, code, configuration, structured analysis, anything a frozen test or contract can adjudicate. That covers a far larger share of enterprise AI work than most leaders assume, and the whole ADLC argument is that teams under-invest in making criteria executable in the first place. But it doesn't cover everything.

Where correctness is irreducibly a judgment call, novel architecture, strategy, ethics, taste, expert human review is not a rung to transcend. It's the ceiling, and machine gates serve as filters that concentrate the human's attention, not replacements for it. The same is true where regulation makes a human decision-maker a legal floor: in medical devices, aviation software, credit decisions, and their neighbors, "no human reads the output" is a compliance violation, not Level 3. For that work, the diagonal tops out at a mandated lane, V2 - Human Review plus rails: human judgment as the final gate, machine verification underneath it, which the model treats as aligned, not immature. The lane is deliberately not a numbered level. It fails Level 3's audit check by design. (If your work lives in the mandated lane, read its C3 - Agent/V2 - Human Review cell as this carve-out, not as M2.)

One warning before reaching for this exemption: it has to be earned, not claimed. The boundary test is whether you can name the specific acceptance criterion that resists any executable expression. "We haven't written the tests yet" is not judgment work. It's M2 (defined below, The Review Bottleneck) with a vocabulary. The Diagonal Law governs everything on the other side of that boundary, which is where most enterprise AI output already lives.

The risk triangle: capability outruns verification#

Below and to the right of the diagonal, output is produced faster than anything establishes it's correct. Three named states live here. You'll meet M4, M5, and M7 in later articles in this series; the inventory is numbered across the whole model, and those three live on tracks this post sets aside.

M1 - Shadow Fleet (C1-2, V0)#

Policy says no. The egress logs say yes. Engineers are pasting code into personal accounts, running local agents, expensing tools under ambiguous line items, and because the official posture is prohibition, none of it is visible, none of it is governed, and none of it can even be measured. The Shadow Fleet is usually the mildest off-diagonal state, the volume flowing through it is a trickle, and the most common first trap: risk is small per incident, but the organization has forfeited the telemetry it would need to know that.

M2 - The Review Bottleneck (C3, V2)#

This is the defining trap of the era, so it earns the longest look.

An organization reaches M2 by doing everything right according to the adoption playbook. Licenses procured. Policy written. Copilots deployed, then agents. Usage climbs, the dashboard glows, the transformation program declares victory. And the trust mechanism throughout is the same one the organization used before AI existed: a human reads everything.

Here is the arithmetic that playbook never runs. Agents multiplied the volume of reviewable output; human review capacity did not multiply. Whatever the exact ratio in your shop, the direction isn't in doubt: production scaled and verification didn't. So the gap has to go somewhere, and there are only a few places it can go. You can hire reviewers, but you're hiring linearly against a capability that scales with compute. You can throttle the agents to review capacity, which quietly caps the ROI the program was sold on, and the throttle never survives the next quarter's targets. You can triage, routing only "high-risk" output to full review, which is real progress if the triage criteria are themselves verified, and a silent hole if they aren't. Every one of these postpones the wall. None dissolves it. And when the postponements run out, the remaining pressure lands in the one place that absorbs it invisibly: reviewers quietly stop reading.

Rubber-stamping is not a moral failure of your reviewers. It's the rational response to an impossible workload, and it arrives silently. The approval still happens. The checkbox still gets checked. The audit trail still shows a named human on every change. What disappeared is the thing the checkbox was supposed to certify, and no dashboard notices, because the dashboard measures approvals, not attention.

Worse: the standard adoption metrics improve as review integrity collapses. Acceptance rate climbs. Cycle time drops. Throughput per engineer soars. Every number your program reports gets better as the actual safety mechanism quietly dies. Acceptance rate is a sentiment metric in a lab coat.

If you want to know whether this has already started, don't ask your reviewers. Measure. Take last quarter's AI-assisted changes and plot review duration against diff size. The cluster to fear is large diffs with tiny review times, substantial changes approved in under a minute. Nearly every organization that runs agents under mandatory full review develops this cluster; its size is your distance from the trust mechanism you think you have. A sub-minute approval is a screening signal, not a conviction, some of those are pre-reviewed designs or mechanical refactors. The trend is the tell.

M2 is where most "successful" enterprise AI programs are parked, and it's the reason this maturity model exists. The organizations in it feel mature. Their metrics say they're mature. They are one escaped defect away from a very different board conversation.

M3 - Cowboy Autonomy (C3-4, V1)#

Agents merging with neither human nor machine gates. Sometimes this is a startup that never built gates. More often, inside an enterprise, it's what M2 decays into: a team drowning in review debt that starts auto-approving "low-risk" categories without first building the rails that would make that safe. M3 is fast, and every week it survives gets cited as evidence it's fine. It is not fine. It's unpriced risk accumulating off the books, discovered by the incident rather than the dashboard.

The waste triangle: verification outruns capability#

Above and to the left of the diagonal sits the failure mode nobody writes post-mortems about, because its cost is invisible: opportunity.

The staircase distinction matters here. Verification running one step ahead of capability isn't waste. It's exactly the sequencing this model prescribes. Building the rails before deploying the agents is how you climb. The waste triangle names something else: verification as a residence. Infrastructure built, gates staffed, frameworks ratified, and a standing refusal to climb the capability step they were built for. The test that separates the two states is a single question: which capability step is this verification being built for, and when does it ship? Sequencing has an answer, a named step and a date. Residence has a standing committee.

M6 - Compliance Freeze (C1, V3-4)#

An AI governance council. A model risk framework adapted from banking regulation. A seventeen-step approval process for any AI-touched change. And underneath all of it: a handful of engineers using prompts, because nothing more capable can survive the gauntlet. Trust infrastructure with nothing to trust.

The frozen state isn't safe. It's slow-motion loss. The organization pays for governance designed for a capability level it refuses to reach, while its competitors climb the diagonal and its own engineers drift quietly into the Shadow Fleet, which means the actual risk posture of a Compliance Freeze organization is often M1 wearing M6's badge. Prohibition-grade oversight of the sanctioned tools, zero oversight of the real ones.

The truce#

Here's the political reading of the grid, because inside an enterprise the Diagonal Law isn't just an engineering claim. It's a negotiation.

Every vendor, and every enthusiast on your staff, pushes your organization rightward: more capability, now. Every CISO, auditor, and risk officer pushes upward: more control, first. Left to fight, these forces produce lurching, a sprint rightward into M2, an incident, a panicked slam upward into M6, a productivity revolt, another sprint rightward.

The diagonal is the truce. It gives the CTO and the CISO a shared map on which both of their instincts are correct, in alternation. The engineering side is right that the next capability rung must be climbed. The risk side is right that it must not be climbed before the verification rung below it exists. The Diagonal Law converts an ideological argument, move fast versus be safe, into a sequencing agreement: nobody argues about whether, only about what must be true first. In practice this is the model's highest-leverage use, not scoring maturity, but ending the meeting where the two halves of the company talk past each other.

Why you cannot leapfrog#

The seduction of the capability ladder is that every rung is for sale. A procurement order can put your organization at C4 by Friday: orchestration platforms, agent fleets, the works. The verification ladder's tooling is increasingly for sale too, eval platforms, guardrail products, red-team services. What isn't for sale is the thing the tooling instruments: the relocation of trust.

Trust relocations are organizational change. Rails have to be authored by people who learn to write executable specifications. Adversarial review, what the ADLC calls prosecution, has to be chartered, and then believed, which means calibrated, because no engineering leader will actually stop requiring human review until someone can show, with planted defects, what the machine gates catch. Observability has to exist before any of it, because you cannot calibrate what you don't record. You can buy every one of those capabilities at a vendor booth. You cannot buy your organization's willingness to route trust through them.

This asymmetry, capability is purchasable, trust relocation is not, is the entire explanation for the shape of the industry right now. It's why the risk triangle is crowded and the diagonal is not. Buying C3 while standing at V2 does not make you a Level 3 organization. It makes you M2 with better tooling.

Locate yourself in under a minute#

Three questions. Run them per workstream, not per company; a large organization lands in different cells for different teams, and the outliers are the point. Each answer is audit-checkable, which is also the point: a maturity model whose levels can be reached by enthusiasm will be gamed by its own audience.

1. Can AI-produced work reach production without a human reading it in full?

First, check whether agents actually flow through the gates that would make this true: rails with nothing riding on them is not Level 3, it's the staircase step just before it (C2 over V3), and the only question is when you climb.

• Yes, with calibration data: planted-defect catch rates, a log of gate findings converted into permanent controls. Level 4.
• Yes, gates exist but nobody has measured them: Level 3.
• Yes, but there's no gate, just precedent and luck: M3.
• No, verification is V2 or below: continue, and ask question two of every workstream that still routes through a human.

2. Do you run agents, AI owning whole tasks rather than keystrokes?

• No: capability sits at C2 or below. Continue to question three.
• Yes, outside the mandated lane: agents under mandatory full human review is C3 over V2, which is M2 by construction.
• Yes, inside the mandated lane: the same kind of measurement matters here too, but the target is rails under the human gate, never the removal of it.

For the outside-the-mandated-lane case, how far it's progressed is answered by the same measurement from the M2 section above: reviewers genuinely still reading everything means early M2, you're paying the full queue cost and the wall is ahead of you rather than behind you. A growing large-diff, tiny-duration cluster means the trust mechanism you're counting on has already partially dissolved. Either way the fix is the same, and it's not more reviewers.

3. Does your governance match your actual usage, not your sanctioned usage?

• Answering requires discovering what your actual usage is: you have M1 somewhere in the building.
• Governance is built for capabilities you prohibit: you're paying M6 prices for M1 risk.
• Verification is built out to V3-4 while capability idles at C1, gates with no dated plan to put anything through them: that's M6 itself.
• Policy, telemetry, and practice genuinely agree (including the rare organization whose egress controls make prohibition real): you're wherever questions one and two put you, and you have the receipts to prove it.

Most readers will land in M2, and most of the rest in M1 or M6. That's not an indictment. It's a map reference. The traps aren't failures of intelligence or diligence. They're the natural resting states of the two forces described above, which is exactly why escaping them requires a law and not just good intentions.

The move is toward the diagonal#

One more thing the grid makes obvious that prose never did: when you find yourself off-diagonal, the corrective move is toward the diagonal, and which direction that is depends on which side you're on.

In the risk triangle, the move is vertical. Organizations here instinctively consider retreat: pull back the agents, move left. This feels responsible and accomplishes nothing, because the economic pressure that pushed you rightward hasn't gone anywhere. You'll be back in the same cell within two quarters, plus a demoralized engineering organization. The durable move is upward: keep the capability, build the verification underneath it. Freeze rails. Charter adversarial review. Instrument outcomes. In M3 the first vertical step is an emergency step, taken today: reinstate a gate, yes, a human one, yes, that lands you in M2, because rails take months to build and your exposure is daily. Then keep climbing.

In the waste triangle, the move is horizontal: keep the gates, they're genuinely valuable, and they were the hard half to build, and point them at real capability at last. An M6 organization is closer to Level 3 than it believes. It built the staircase's tall side first. What it never did was step onto it.

The law, restated#

The grid has two axes, but the model underneath it has more tracks, knowledge and observability among them, with their own traps (the RAG Plateau, Dashboard Theater, Skill Rot) that later articles in this series take up. The Diagonal Law is the case that matters most because capability and verification are the pair that produces incidents when misaligned in one direction and bleeds opportunity when misaligned in the other.

So: two numbers. The one you track, and the one that decides whether the first one is an asset or a liability.

Capability above verification is risk. Verification above capability is waste. Maturity is the discipline of climbing both ladders in step.

Somewhere in your company's AI strategy deck is a slide that says "We implemented RAG over our internal knowledge base," and it's presented as an arrival, a line item you can check off and move past.

It's not a destination. It's a rung, and a low one.

RAG enters at Level 2, not the finish line#

Mistaking it for the finish line is the single most over-claimed maturity signal in the enterprise. The previous posts in this series put trust location on two axes: capability and verification. There's a third track running underneath both, knowledge, and it has its own ladder. Retrieval-augmented generation shows up early on that ladder, at Level 2, right alongside the copilots and the review dashboards that make an organization feel mature while its actual verification stays exactly where it was before AI arrived.

The knowledge ladder, in full:

• None (L0). No sanctioned knowledge layer at all.
• Personal context-pasting (L1). Whatever an individual happens to paste into a chat window that session. Gone when the tab closes.
• RAG over the organizational corpus (L2). "Chat with our docs." Genuinely useful, genuinely necessary, and the point where most enterprise knowledge strategy stops.
• Agentic retrieval plus a curated skill library (L3). Retrieval becomes one tool among several an agent chooses to invoke, its quality measured rather than assumed, living alongside deliberate context engineering and a skill library someone actually curates.
• The distillation loop (L4). Stable knowledge migrates continuously out of retrieval and into skills, and RAG gets scoped down to what genuinely changes faster than that migration can keep up.

The organizing idea for the whole track fits in one line:

RAG is runtime knowledge. Skills are compiled knowledge. Distillation is the compiler.

Compiled doesn't mean deterministic#

Let us push on the compiler metaphor for a second, because it buys you less than it sounds like it does, and the gap matters.

Compiling knowledge into a skill gets you repeatable packaging: a versioned, shared, reviewable artifact that bundles procedure, context, and constraints, cheaper to invoke than a retrieval call and legible to a human who wants to audit what the agent was told. What it does not get you is deterministic execution. A skill still runs on a non-deterministic model. Two agents loading the identical skill file can still produce different output, because the compiler here compiles the instructions, not the interpreter that reads them.

That's why skills need version-pinned evaluation, the same discipline code needs tests, not a one-time authoring pass followed by faith. I built a whole package to track this for my own skill collection. A skill nobody re-verifies is a skill quietly voting against itself.

The maturity signal is migration, not corpus size#

Here's where a lot of enterprise knowledge strategy gets the measurement backwards. A growing retrieval corpus is not, by itself, evidence of anything. A legitimately growing business legitimately grows its corpus: new products, new regions, new tickets. Corpus size is not the tell.

The real signal is migration. Stable, procedural knowledge, the stuff that gets asked the same way every time, should be leaving retrieval and landing in the skill library, continuously. An organization whose retrieval corpus keeps absorbing procedures that never compile into anything is hoarding, not learning. It's the knowledge-track equivalent of a wiki nobody prunes: technically searchable, actually a landfill.

M4, the RAG Plateau (knowledge track stuck at stage 2, claimed as stage 4)#

"We implemented RAG" gets presented as an AI strategy on its own, full stop. It's runtime retrieval hoarding wearing the costume of a finished capability, with no compilation into skills happening underneath it. The organization can genuinely answer more questions than it could a year ago and still be exactly as immature as it was before, because nothing it learned got compiled into anything durable. Every answer is re-derived, at retrieval cost, forever.

The fix isn't ripping out RAG. It's the same discipline I described for an individual codebase's skill mining loop: survey what keeps getting asked and answered the same way, and migrate the stable patterns into versioned skills instead of leaving them to be re-fetched on every request. RAG doesn't disappear at Level 4. It gets scoped down to what actually deserves runtime lookup: today's document, this week's ticket, the state of a system right now. Everything with a stable answer moves out.

M7, Skill Rot (knowledge stage 3 without observability stage 4)#

The opposite failure looks more mature and is arguably worse, because it comes after an organization did the hard part. A skill library gets authored, once, in a burst of real enthusiasm. Nobody re-mines it. Nobody versions it against the products it describes. It quietly decays into misinformation delivered with the full authority of an approved, sanctioned artifact, which is exactly the property that made it valuable in the first place.

I've watched this happen to my own work at Vercel scale: twenty-two products, each shipping on its own cadence, fifty-seven skill files that don't update themselves. A skill that says npm install @vercel/workflow months after the package was renamed to workflow doesn't fail loudly. It fails quietly, sending a developer down a path that used to be right, and the fix is the same category of discipline code has had for a decade: a registry of what each skill claims to know, a checker that compares claims against what's actually shipping, and a product-version field that makes staleness visible instead of silent. The full shape of that fix is here, and the pattern generalizes past any one company's products.

Skill Rot is a knowledge-track trap, not a capability or verification one, which is why it doesn't show up as a cell on the Diagonal Law's grid. It lives one layer under the grid, in whether the compiled knowledge that grid's Level 3 and Level 4 quietly assume is actually still true.

Knowledge needs a witness#

Neither of these traps are caught by asking "do we have RAG" or "do we have skills." Both answers can be yes while the organization is actively decaying. What catches them is the same thing that catches every trap in this model: a specific, checkable fact, not a survey answer. Whether stable knowledge is actually migrating out of retrieval. Whether skills are actually being re-verified against what they claim.

That fact doesn't produce itself. It's an observability question: what an organization can see about its own knowledge layer, and whether it's recording the kind of evidence that migration and rot both require to be caught early instead of discovered in production. That's the next track, and the next post.

Picture the AI transformation dashboard most executive teams are looking at right now: seats licensed, tokens consumed, acceptance rate, all trending the right direction, all green. Now ask the room a second question. What's your defect escape rate? What percentage of your gates actually catch a planted defect when you test them?

Watch how fast the room goes quiet.

Acceptance rate is a sentiment metric in a lab coat#

That line showed up once already in this series, describing the review bottleneck that most enterprise AI programs are currently living inside without knowing it. It belongs here too, because it's really a claim about observability: acceptance rate looks like a hard number. It has decimal places. It updates in real time on a dashboard. And it measures approvals, not attention, which means it can climb every single week that the thing it's supposed to be a proxy for, actual review integrity, quietly falls apart underneath it.

That gap is not a data problem you fix by adding another chart. It's a track this model treats as its own dimension, separate from where trust lives and separate from what capability an organization has deployed.

Why observability is a track and not a level#

It would be tempting to make observability Level 5, the reward for finishing everything else. That's exactly backwards, and the model is built to resist it on purpose. Making observability a level lets an organization defer it to the end, which means deferring the one thing every other transition actually depends on.

Every level transition in this model is an observability upgrade before it is a tooling upgrade:

• 0 → 1 requires seeing shadow usage: the gap between what the egress logs actually show and what the sanctioned tool list says should be there. You cannot govern what you deny exists, and an organization that hasn't built the visibility to see its own shadow fleet can't move past prohibition honestly, only on paper.
• 1 → 2 requires usage telemetry: which tools, which teams, what spend. Without it there's no way to know whether sanctioned tooling is actually being used, or just approved.
• 2 → 3 requires outcome telemetry, defect escape rates, an honest measurement of how deeply reviewers are actually reading. This is the one most dashboards skip, because the review bottleneck is invisible to usage telemetry by construction. Seats and acceptance rates look wonderful right up until you superimpose the escaped-defect curve on top of them, and the two lines tell completely different stories.
• 3 → 4 requires learning telemetry: which findings recur, which gates catch planted defects, which skills actually get hit in practice. Distillation and skill mining consume this telemetry as raw material. Without it, there's nothing to mine.

Put plainly:

You cannot verify what you cannot observe, and you cannot distill what you do not record.

Each transition is gated by the specific kind of evidence it consumes, not by telemetry in general. Outcome telemetry doesn't help you distill. Learning telemetry doesn't help you see shadow usage. Bringing the wrong instrument to a transition is its own kind of theater.

M5, Dashboard Theater (observability track stuck at stage 2)#

I've sat in too many meetings where the dashboard is all green and the one number that matters was never on it. This is the trap living directly underneath the pleasant-looking dashboard from the top of this post. Seats, tokens, and acceptance rate get reported as outcomes, full stop, with no defect-escape data, no gate-calibration data, and no accuracy analysis anywhere in the building. It's not usually dishonesty. It's an organization measuring what was easy to measure at the moment it started measuring, and then never asking whether that measurement still means what it used to.

The uncomfortable part of this trap is that it can coexist with real progress elsewhere. A company can build genuine rails, charter real adversarial review, and still report its AI program's health entirely in usage terms, because that's the telemetry the organization invested in first and nobody circled back. Dashboard Theater isn't the absence of data. It's the presence of the wrong kind, reported with the confidence of the right kind.

One caution the model is explicit about, because it would be easy to over-correct into a different mistake: telemetry is not virtuous by itself. An organization that instruments everything and acts on nothing has just built a more expensive version of the same theater. The point was never "collect more data." It's that each transition consumes a specific kind of evidence, and the discipline is matching the instrument to the boundary you're actually trying to cross.

What this buys the next two tracks#

Observability only earns its keep through what it feeds.

The verification track runs on outcome and learning telemetry: you cannot calibrate a gate's catch rate without recording what it caught and what it missed, and you cannot know a review process has degraded into rubber-stamping without measuring review depth directly rather than inferring it from approvals. The knowledge track runs on the same raw material from the other direction: skill mining needs to know which patterns recur before it can compile them, and skill-rot detection needs a record of what a skill claimed to be true so it can be checked against what's actually true now.

Neither of those loops closes without something recording, continuously, what actually happened. That's what makes observability a precondition rather than an option: it isn't a level you eventually reach. It's the thing every other level was quietly standing on the whole time.

A lot of leaders hear "Level 3" and picture more agents. Agents everywhere! More autonomy, wider deployment, the capability number going up again. That's half right and the less important half. Level 3 is defined by what happens underneath the agents, not by how many of them you're running.

Adversarial review is not a Level 4 luxury#

It's the entry requirement for Level 3. That ordering surprises people, because review, in most enterprise imaginations, is the mature, careful, later-stage thing you add once the exciting capability work is done. In this model it's the opposite: without it, you cannot safely delegate whole tasks to agents at all, because nothing established that the output is correct.

Adversarial review is what actually replaces the human review bottleneck described earlier in this series: fresh contexts, chartered specifically to refute the work rather than assess it, running until findings converge instead of stopping at whatever a single tired pass happens to catch. It's the same mechanism the ADLC calls prosecution when the work under review is code, and the underlying claim is domain-general: a reviewer that shares the builder's context will rubber-stamp the builder's blind spots, sincerely, every time. A reviewer that doesn't share that context is the only thing that can actually see them.

The verification ladder, walked as an organizational decision#

The Diagonal Law post already named these five stages as the vertical axis of the grid. Here they are again, this time as the sequence of decisions an organization actually has to make, not just a taxonomy:

• V0 - Prevention. The organization's only control is a policy document. Nothing gets verified because, officially, nothing exists.
• V1 - Individual judgment. Whoever ran the prompt decides whether the output is good enough. This is a private, unaccountable, unfalsifiable form of trust, and it's where most companies actually spend their "experimentation phase."
• V2 - Human review. A person reads everything before it counts. This is the trust mechanism the organization already had before AI arrived, kept in place unchanged, which is precisely why it becomes the review bottleneck the moment production volume multiplies and reviewer headcount doesn't.
• V3 - Rails and adversarial review. Executable tests frozen before implementation exists. Contracts the builder is mechanically prevented from arguing with. Fresh contexts chartered to refute. This is the stage where trust actually relocates from a person's attention to a mechanism, and it's the only stage on this ladder that requires the organization to build something rather than staff or buy something.
• V4 - Calibrated prosecution. The gates from V3, now measured rather than trusted on faith.

Notice the shape of that progression: every rung through V2 is a policy about who looks. V3 is the first rung that's a mechanism, and that's the transition this entire track hinges on. Every capability rung above it is only safe once the verification rung underneath has actually been built.

What calibration actually means, and why "we have review" isn't an answer#

V4 is where review stops being a ritual and becomes an instrument with a known error rate, and the mechanism is specific: planted defects, drawn from a held-out, severity-stratified bank the reviewed system cannot see, run through the gate the same way real work runs through it. What comes back is a number: what fraction of real, categorized defects did this gate actually catch.

That number matters more than most enterprises expect, because "we have review" and "we know our review catches sixty percent of the security-relevant category and eighty-five percent of the correctness category" are two entirely different claims dressed in the same sentence. The first is a policy. The second is engineering. I watched this distinction get proven the hard way, aiming prosecution at the review-calibration gate itself: the honesty meter that was supposed to measure review depth turned out to be gameable, and once that was found, the fix was frozen into a test so it couldn't quietly revert. That's not a hypothetical failure mode. It's what happens when nobody adversarially checks the thing that's supposed to be checking everything else.

An audit check that doesn't state the measured quantity and the specific gaming it resists isn't a real audit check. It's a sentiment metric with better production values, exactly the failure this whole model exists to catch elsewhere. "We have a calibration process" is not evidence. The catch rate, per category, with the plant bank held out from the system being measured, is.

Why this track can't be bought, only built#

Every other track in this model has tooling you can procure. Eval platforms, guardrail products, red-team services, all genuinely for sale and genuinely useful. What isn't for sale is the organizational decision this track actually requires: a leader who stops mandating human review of everything, on the basis of evidence rather than optimism, because someone showed them what the machine gates catch.

That's the reason you cannot leapfrog this ladder by buying agents and skipping straight to Level 3. Rails have to be authored by people who learn to write executable specifications. Adversarial review has to be chartered and then believed, which means calibrated. Nobody sells an organization's willingness to actually trust the number a calibration run produces instead of the number a survey produces. That willingness is the whole transition, and it's the reason V2 to V3 is where most enterprise AI programs stall out for months even after the tooling is sitting there, purchased and unused.

Get the verification track right and the economics move next, because a gate you trust is a gate you can stop paying a human to duplicate. That's where this series goes from here.

Ask a CFO how the AI budget is doing and you'll get a number about spend. Ask what that spend bought and, at most companies, the answer degrades quickly into a survey: people say they're more productive, the licenses are being used, the sentiment is positive. That's the entire economic case, fancying itself as a ROI slide.

The first post in this series named the problem this creates: a company can be a top 10% AI spender and a bottom 10% AI organization at the same time. This post is about why that's not a paradox. It's the predictable output of measuring the wrong variable.

The economic ladder#

Each level in this model has its own economic reality, not just its own trust mechanism, and the two move together.

• ROI by survey (Level 2). Per-seat licenses, usage dashboards, and a satisfaction question standing in for a measurement. This is the economics of the review bottleneck: spend scales with adoption, and nothing in the budget process asks whether the underlying work got any more trustworthy.
• Task-level routing (Level 3). Model tier gets chosen by the cost of an undetected error, not by task prestige. A low-stakes, fully-railed task routes to a cheap model because a mistake gets caught cheaply. A task where an error would escape gate detection routes to a stronger model, or to more verification, because that's where an undetected mistake actually costs something. This is the first level where spend is a decision rather than a default.
• Cost per merged, verified change (Level 4). The unit of account stops being tokens per developer per month and becomes the cost of one piece of work that's actually done and actually trustworthy, and that number trends down, quarter over quarter, because the system is built to make it fall.

That last point is the one worth sitting with, because it inverts the intuition most leaders bring into this conversation: that better verification necessarily costs more, forever.

The flywheel: cheaper and stricter at the same time#

It doesn't cost more forever, because verification at Level 4 isn't a standing expense. It's a ratchet. A finding that recurs, a category of mistake caught by review three sprints in a row, gets converted into its cheapest permanent defense: a deterministic lint rule if the pattern is mechanical, a versioned skill if it needs context, a new question in the spec-interrogation template if the bug existed because nobody asked. Each conversion moves that category of defect from probabilistic, dollars-per-catch detection to deterministic, free-forever detection.

I watched this compounding effect described in detail from the practitioner's side in the ADLC series: the diagnostic that matters is whether prosecution spend is trending down over time. If it's flat or rising, the organization is re-buying the same lessons every sprint, paying LLM-review prices for a mistake that should have been caught by a lint rule months ago. If it's declining, the system is doing exactly what Level 4 is supposed to do: getting stricter, because more categories of defect are now caught by something, and cheaper, because fewer of those catches require a model at all.

That's the flywheel in one sentence: the system gets cheaper and stricter simultaneously, and the mechanism is the same distillation loop that the knowledge track runs on. Capability migrates out of the model tier and into the artifact layer, where it compounds instead of getting re-billed per token, forever, for the same mistake.

Why maturity is not monotone in usage#

Here's the line worth putting directly in front of whoever owns the AI budget: a Level 2 organization may consume more tokens than a Level 3 organization.

That's not a hypothetical edge case. It's close to the default comparison. A Level 2 organization is running every task through a human reviewer and through however many copilots and chat tools got procured along the way, with no routing discipline separating a low-stakes task from a high-stakes one. A Level 3 organization routes deliberately: cheap models on fully-railed work, verification concentrated exactly where an error would actually escape. The Level 3 organization can easily show a smaller token bill and be doing categorically more trustworthy work, because it stopped spending everywhere enthusiasm reached and started spending where an error was expensive to miss.

This is why a leaderboard ranked by AI spend is worse than useless as a maturity signal. It can be actively inverted. The company burning the most tokens may be the company that never built the routing discipline to spend less while catching more, and every dollar of that overspend is quietly financing the review bottleneck instead of dissolving it.

The number that actually tells you something#

If there's one number worth asking for instead of a spend total, it's cost per merged, verified change, and its trendline. A flat trendline is not a steady state. It's a failure signal: the distillation loop isn't running, and the organization is paying full price for the same lessons, on repeat, indefinitely.

A falling trendline is the only economic evidence that a maturity claim is real, because it's the one number that can't be improved by throwing more licenses at the problem. It only falls when trust is actually migrating from expensive, probabilistic human and model attention into cheap, permanent, deterministic controls. Everything else on the AI budget slide is a proxy. This is the measurement.

Pull every track in this series together, the levels, the diagonal, the knowledge ladder, the observability ladder, this economic ladder, and you get something an organization can actually run against itself: not a survey, an audit, with a level, a cell, and a keystone unlock at the end of it.

Seven posts in, you can probably already place your organization: a level, a cell on the diagonal grid, maybe a trap or two you recognized a little too well. That's not an accident. Every claim in this series was built to be audit-checkable, not sentiment-checkable, which means the assessment was never a separate document you'd commission later. It's been running the whole time. This post just collects it into something you can actually walk into a room and use.

The diagnostic, assembled#

Two tools from earlier in this series do the actual locating. Part two gave each level a one-afternoon audit check: an anonymous survey against egress logs for Level 0, a search for a single shared versioned artifact for Level 1, a plot of review duration against diff size for Level 2, a named gate for Level 3, a distillation log and a cost trendline for Level 4. Part three gave you three questions that place any workstream on the capability-by-verification grid in under a minute, and named the seven traps that show up when capability and verification drift apart.

Run both per workstream, not per company. A large organization occupies a region, not a point, and the outliers are the ones that produce incidents. The assessment isn't a survey you administer once a year. It's a set of facts you could, in principle, check on any given Tuesday.

What dissolves each wall, in order#

Every boundary in this model has exactly one keystone unlock, the specific investment that dissolves the wall rather than just absorbing the pressure it creates for another quarter.

You've seen this table once already, in part two, back when it was a reference you checked your position against. Having walked the knowledge, observability, and economic tracks since, read it again as a sequence you execute, not a lookup you consult.

Two things about this table are easy to miss on a first read, and both matter more than the table itself.

The first is that observability shows up as a prerequisite at every single row, not as its own transition. You can't dissolve 0→1 without seeing shadow usage first. You can't dissolve 2→3 without outcome telemetry making the bottleneck visible at all, because it's invisible to the usage dashboards an organization already has. The unlock in the right column is never just a tool purchase; it's a tool purchase that only works because the observability underneath it was built first.

The second is that these unlocks are sequenced, not optional add-ons you can reorder to taste. Skill mining is precisely located as the mechanism of the 3→4 transition, the enterprise generalization of the ADLC's distill phase applied to every recurring procedure the organization runs through AI, not code specifically. That mechanism does not work as a 1→2 move. An organization that tries to skill-mine its way past the review bottleneck before it has adversarial review and frozen rails in place is not climbing the ladder. It's buying a capability rung and standing on it with nothing underneath, which the diagonal law already named: capability above verification is risk, no matter how sophisticated the capability is.

The ADLC is the reference implementation, not the definition#

This series and the nine-part Agentic Development Lifecycle series answer different questions on purpose. The AMM tells an organization where it is. The ADLC shows what Level 4 actually looks like running, for software development specifically.

That specificity matters, because the verification stages in this model are defined by outcomes, not by any one methodology. V3 means acceptance criteria frozen before implementation begins, plus review chartered to refute rather than assess. V4 means gates with measured catch rates, and findings that get converted into permanent controls instead of re-discovered next sprint. Any process that demonstrably achieves those outcomes qualifies as Level 3 or Level 4 verification. The ADLC is one such process, thoroughly documented and battle-tested, not the only possible one.

Where the ADLC's phases land on this model's tracks:

Every row in that table is a place where a practitioner-level post in the other series shows the machinery this series describes from the leader's chair. If your organization is trying to build its way to Level 3 or Level 4 in software specifically, that series is the how. This one has been the where, and the why it matters enough to fund.

Two audiences, one system#

I wrote the ADLC for the practitioner who has to actually build Level 4: the person authoring the rails, chartering the adversarial review, writing the distillation loop that converts this quarter's findings into next quarter's lint rules. I wrote this series for the person who signs off on that practitioner's budget, headcount, and timeline, and who is currently being told by every dashboard in the building that Level 2, the one with the green usage charts and the human reading every diff, is the destination.

It isn't. It's the level that feels the most like maturity while doing the least to earn the name, because it's the level where the adoption metrics and the actual trust mechanism can point in completely opposite directions without anyone noticing for a very long time.

The whole series, in order: the adoption curve isn't a maturity model, the five levels and the walls between them, the diagonal law and the seven traps it names, RAG as runtime knowledge against skills as compiled knowledge, why you cannot distill what you do not record, adversarial review as Level 3's entry fee, not Level 4's luxury, and the economics that make Level 4 cheaper and stricter at once.

Find your organization on the grid. Name the wall in front of it. Build the one unlock that actually dissolves that wall, not the one that just buys another quarter of looking mature. That's the whole assessment, and you already had everything you needed to run it before you finished this sentence.