Chapter 15 — The Maturity Model

Most organisations have the one level that is not a prerequisite for anything.

15.1 What a maturity model must earn

Maturity models have a poor reputation and have earned it. They are typically unfalsifiable, linear about things that are not, self-assessed, aspirational at the top with no evidence anyone is there, and — most damningly — structured so that the answer to every level is to buy something.

So, as with Chapter 12's process model and Chapter 14's metrics, the standard first.

1. Observable from artefacts. If a level can only be established by asking someone how they work, it is a survey. Each level below has an artefact test — something you can look at.

2. Ordered by dependency, not ambition. Level n+1 must be genuinely difficult or impossible without level n. Otherwise the model is a list wearing a staircase.

3. An honest distribution. Where do organisations actually sit, with evidence? A model whose levels are all thinly populated at the top is describing an aspiration, and should say so.

4. A stated cost per level. The point of the model is deciding whether to climb. Without cost, it is exhortation.

5. A statement of what does not improve. The via negativa requirement, and the one that separates an honest model from a sales instrument. §15.8 is that section, and it is longer than one might hope.

Requirement 2 is where the conventional version of this model fails, and §15.5 is about that.

15.2 Maturity is which loops are closed

The first design decision: what is being measured?

The tempting answer is apparatus — how many controls, how many rules, how much configuration. It is tempting because it is countable, and it is wrong for two reasons already established.

Chapter 2 and Chapter 8 showed the apparatus should shrink. Harness mass measures what the model cannot yet do for itself; the optimal harness gets smaller as models improve, and Chapter 8 added the retirement arm to make that operational. An organisation with fewer controls than last year may be more mature, not less. Any model that counts apparatus punishes exactly the behaviour it should reward.

And counting apparatus is the definition of Harness Theatre. Chapter 14 §14.9 puts "count of rules, skills, or context-file entries" on the do-not-measure list for precisely this reason: it measures effort rather than effect.

The better criterion:

Maturity is which feedback loops are closed.

This works because a closed loop leaves evidence that cannot be faked. A control installed in response to a recurrence has a date, a named failure mode, and a prior incident it points back to. You can look at it. You cannot manufacture that record by writing more configuration, which is exactly the property requirement 1 demands.

Note the first two rows. On this criterion, L0 and L1 are the same level with respect to loops — neither closes one. That is not a rhetorical flourish; it is the observation §15.5 builds on.

15.3 The five levels

The artefact tests are the useful column. Each is a thing you can go and look for this afternoon, and each is hard to produce without genuinely being at that level.

Two are worth dwelling on.

L3's test requires a removal. A team that only ever adds controls has an install arm and no retirement arm, which Chapter 8 §8.2 showed terminates in theatre. The deleted control with a stated reason is the cheapest available evidence that the loop runs in both directions, and in my experience it is the single rarest artefact in this entire model.

L4's test requires someone else's template. A team that built a harness for its own service has done L3 work. A template is only a template when it has been consumed by people who did not write it, because that is where the versioning, drift, and contribution problems appear — the ones Chapter 8 §8.10 flagged as inherited wholesale from service templates.

15.4 Where teams actually are

Requirement 3, and this is where the model stops being aspirational and becomes a description.

From the 2,853-repository study [A]:

The authors' own summary is the one-line version: "Harness engineering in open source today is therefore mostly context engineering."

Two caveats that matter. This is open source, and the authors say plainly that enterprise practice may differ. And it is a point-in-time snapshot of a field whose conventions are still consolidating — their words. But the one enterprise case we have in detail points the same way: the organisation in Chapter 3 reached automated review under queue pressure, which is a partial L2 move, and did it without naming it, measuring it, or deciding how much to trust it [B] — which is L2 apparatus without an L3 loop.

So the honest statement: essentially the whole field is at L1, with a thin tail into L2 and almost nothing above. Levels 2–4 are aspirational, and a book that presented them as a normal progression would be describing a world that does not exist.

15.5 The ordering is wrong

Now the part that matters, and it starts with a question the conventional model does not ask.

Why is everyone at L1?

The comfortable answer is that L1 is the foundation — you must write your conventions down before you can enforce them, so of course adoption starts there. It is a satisfying story and I do not think it is true.

Test it against requirement 2. Is L2 genuinely difficult or impossible without L1?

Consider what an L2 move actually requires: a hook that runs your type checker on every agent edit and refuses the edit if it fails. What does that depend on? An agent loop with a lifecycle hook, and a type checker. It does not depend on a context file. Nothing about the sensor consults AGENTS.md. You could wire a blocking sensor into an agent's edit cycle in a repository with no context file at all, and it would work exactly as well.

L1 is not a prerequisite for L2. The dependency does not exist.

So why did the field converge on L1? Chapter 7 §7.7 already answered it, and the answer was a cost gradient, not a dependency:

Writing a paragraph in a markdown file takes minutes, requires no tooling, breaks nothing, and produces an artefact that looks like progress. Wiring a check into every edit requires deciding what to check, building it, integrating it, and living with its false positives forever.

Both are harness work. One costs an afternoon; the other costs a quarter and an owner. The field did the cheap one, universally, and then a maturity narrative formed around the observed sequence — mistaking what happened first for what must happen first.

This produces the chapter's most useful practical claim:

You can skip Level 1. Or more precisely: L1 and L2 are parallel, not sequential, and a team stuck at L1 improving its context file is polishing the only asset in the model that unlocks nothing. The higher-value move is sideways.

I want to be careful not to overstate this. Chapter 6 defended context files properly: architecture is exactly what an agent cannot infer locally, and a markdown file is the cheapest available attack on the right problem. L1 has real value. The claim is narrower and sharper — L1 has value and no leverage. Nothing above it becomes possible because you did it, whereas both L2 components unlock everything above.

There is a Taleb-shaped observation here worth naming, because it generalises past this chapter. When a field's adoption pattern is explained by cost, the resulting sequence gets mistaken for a necessity, and a normative story grows over what was originally just an economic gradient. Chapter 5 made the same move about pull requests: they were checkpoints by cost, and everyone came to believe they were checkpoints by design. Cheapness leaves a residue of false necessity, and once it hardens into a maturity model it becomes advice.

15.6 The prerequisite nobody lists

Look again at Figure 15.2 and notice the node that appears in no conventional maturity model: trace capture.

Chapter 12 §12.8 established why it belongs there. The outer loop's only inputs are the inner loop's artefacts — retrieval traces, execution traces, sensor reports, escalations, recurrence counts. Without them:

A lifecycle without artefacts has no outer loop. Not a weak one — none.

Which means L3 is unreachable without trace capture, regardless of how many controls exist. A team with excellent sensors and no traces cannot detect recurrence, cannot tell a firing sensor from a silent one, and cannot compute a single one of Chapter 14's five starter metrics. It will fix instances forever, correctly, one at a time.

This is why L2 in §15.3 has two components rather than one, and why its artefact test requires both a hook configuration and a trace store. Sensors without traces gets you a better inner loop and a permanently closed door to L3. Traces without sensors gets you an observable inner loop with nothing to observe. They are a pair.

And the cost asymmetry is striking. Trace capture prevents no defect on its own — it is pure overhead by any local measure — and it is the precondition for every measurement and every control above it. It is the cheapest high-leverage investment in Part III and it will lose every prioritisation argument it is ever entered into, because its benefit accrues to a loop the organisation has not started running yet.

15.7 What each level costs

Requirement 4. Honest orders of magnitude rather than false precision.

The last row is the one people underestimate. L4 is not a tooling investment. Chapter 8 §8.3 established the Ashby constraint: a bounded regulator cannot govern an unbounded generator, so harness templates only work if the organisation has committed to a limited set of service topologies. That is a decision about architectural freedom, and it will be resisted by every team that wants to choose its own stack. A platform group that intends to let every team choose freely and also ship comprehensive harness templates is attempting something Ashby forbids, and no amount of L4 investment resolves it.

Two ongoing costs that do not appear in any maturity model and should:

False positives are permanent. A blocking sensor that fires wrongly costs attention every time, forever, and someone must own tuning it. Chapter 2's iterative-search result — a well-built capability scoring 12.0% against 15.7% for having no such capability — is the standing reminder that a control can be net negative and that only measurement reveals it.

Retirement is work. Chapter 8's retirement arm and Chapter 14's drills are not one-off. L3's cost is a rhythm, not a project, and organisations that fund it as a project reach L3 briefly and decay back to L2 with a larger pile of controls than they started with.

15.8 What does not improve

Requirement 5, and this is the section that decides whether the model is honest.

Behaviour verification does not improve. Chapter 8's behaviour harness is unsolved at every level. An L4 organisation still cannot mechanically verify that a feature does what was actually wanted, because generated tests prove consistency rather than correctness and a held-out acceptance set only checks the intent that was written down. Chapter 13 §13.6 drew the consequence: L4 does not license A3 or A4 for ordinary feature work.

Specification quality does not improve. Chapter 0's line stands unamended at every level: a harness cannot verify correctness against a requirement never articulated. An L4 organisation with poor specifications produces well-harnessed, thoroughly-tested, efficiently-delivered wrong software — faster than it used to. This is the most expensive failure available in this book and maturity accelerates it.

Blast radius does not improve. Chapter 13 §13.4 established that blast radius vetoes: a severe-blast-radius change does not become eligible for autonomy because the harness is excellent. Reaching L4 does not make it safe to let an agent run unattended against production credentials. You reduce blast radius by changing the system, not by maturing the process.

And judgment may degrade. Chapter 19 takes this up properly. The provisional statement: higher confidence in the tool is associated with less critical thinking, and a mature harness is precisely an apparatus designed to increase confidence in the tool. The mechanism that makes L4 valuable is the same one that erodes the faculty L4 cannot replace.

Which gives the model's honest summary, and I would rather it be the sentence people remember than any of the level definitions:

Maturity buys you the ability to catch mechanical failure faster and more cheaply. It buys you nothing against the failure modes that matter most, and it may quietly cost you the judgment that addresses them.

15.9 Placing yourself

The practical close. Walk down this list and stop at the first honest no.

Two closing observations about how to use this.

A level is per class of work, not per organisation — the same point Chapter 13 made about autonomy. A payments service may be at L3 while an internal tool is at L0, in the same company, which is entirely appropriate: L3 costs a standing role and the internal tool does not warrant one.

And the next step is almost never the next level. For the overwhelming majority of readers, who will stop at question 3, the useful move is not to improve the context file that got them past question 2. It is question 3 and question 4 — one blocking sensor and a trace store — which are, respectively, the highest-authority control in Chapter 7's quadrant and the thing without which nothing above it is reachable.

That is Chapter 26's ninety-day plan in one sentence, and Chapter 16 first has to answer the question that both of them depend on: who, in an organisation, owns any of this?