# The **Assessment**

Published: 2026-07-08T16:59:08.000-0400
Tags: agents, llm, ai-development, amm, enterprise
Canonical: https://www.voodootikigod.com/amm-8-the-assessment

> Seven posts of theory collapse into one afternoon of audit checks: where you are, what dissolves the wall in front of you, and what to build next.

---

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](/amm-2-five-levels) 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](/amm-3-diagonal-law) 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](/amm-2-five-levels), 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.

| Transition | Wall being dissolved | Keystone unlock |
|---|---|---|
| 0 → 1 | Shadow usage | Amnesty plus visibility: acknowledge the usage, make it observable |
| 1 → 2 | Nothing compounds | Sanctioned tooling, the first shared skills, usage telemetry |
| 2 → 3 | The review bottleneck | Adversarial review plus frozen rails, trust migration from human attention to machine gates |
| 3 → 4 | Flat unit costs | Skill mining plus gate calibration, the distillation loop |

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](/amm-5-observability), 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](/adlc-6-lifecycle-gets-cheaper) 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](/amm-3-diagonal-law): 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](/series/adlc) 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:

| ADLC phase | Maps to |
|---|---|
| [Rail](/adlc-3-tests-are-the-spec) and [Prosecute](/adlc-4-prosecution-not-code-review) | Verification track, stages 3-4: rails, adversarial review, calibration via planted defects |
| [Triage](/adlc-2-two-human-gates#p0) (route by blast radius) | Economics track, stage 3: task-level routing |
| [Distill](/adlc-6-lifecycle-gets-cheaper) | Knowledge and observability tracks, stage 4: skill mining, learning telemetry |
| [Two Human Gates](/adlc-2-two-human-gates) | The Level 3 trust relocation itself |
| [Three Dials](/adlc-5-three-dials-parallel-agents) | Capability track, stage 4: orchestration |

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](/amm-1-adoption-curve-not-maturity), [the five levels](/amm-2-five-levels) and the walls between them, [the diagonal law](/amm-3-diagonal-law) and the seven traps it names, [RAG as runtime knowledge against skills as compiled knowledge](/amm-4-rag-runtime-skills-compiled), [why you cannot distill what you do not record](/amm-5-observability), [adversarial review as Level 3's entry fee, not Level 4's luxury](/amm-6-review-prosecution-calibration), and [the economics that make Level 4 cheaper and stricter at once](/amm-7-economics).

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.