I'm giving away the AIDLC scoring rubric. Here's what I'm keeping.

Last post ended on a cliffhanger I set up myself: your AI coding rollout is probably working, and you probably can't prove it — because the metrics you have were built for an era when the developer was the bottleneck. A few people asked, reasonably: prove it how, then?

Here's the instrument. In public, dated, and free to use.

The problem with "the developers seem happier"

Every measurement conversation I've had with a GCC engineering leader in the last year eventually collapses into a vibe check. Adoption dashboards tell you tool usage went up. Nobody's dashboard tells you whether the spec the AI was working from was any good — and a fast, confident implementation of a bad spec is the most expensive failure mode I've seen in twenty years of delivery, AI-assisted or not.

So before you can measure whether AI is helping, you need a falsifiable answer to a boring question: was this piece of work actually ready to hand to anything — human or model — in the first place?

That's what the Spec Readiness Index (SRI) is for.

The rubric

SRI scores a spec across six tests, each 0–2, for a maximum of 12:

1. The Ask Test (stated intent) — 0: the goal is inferred from a ticket title. 1: the goal is stated, but the outcome isn't distinguished from the output. 2: explicit success criteria, stated as an outcome.
2. The Proof Test (testable outcomes) — 0: none. 1: present but subjective — "should work well." 2: explicit and falsifiable.
3. The Handshake Test (interface specification) — 0: unstated. 1: named but unspecified. 2: explicit — what it calls, what it expects back, what breaks it.
4. The Guardrail Test (stated constraints) — 0: absent. 1: implied by convention. 2: explicit for this piece of work specifically.
5. The What-Breaks Test (failure coverage) — 0: happy path only. 1: some failure modes named. 2: known failure modes enumerated with expected behavior.
6. The Edge Test (boundary definition) — this one carries an asymmetric veto. Score a 0 here and the spec is Red regardless of what it scores everywhere else. A spec with no stated boundary isn't incomplete, it's unbounded — and an unbounded spec handed to a fast implementer (human or AI) doesn't fail slowly. It ships confidently, in the wrong direction.

Total score maps to a verdict:

• Green (9–12, boundary ≥1): ready to hand off, human or AI.
• Yellow (5–8): workable, but flag which tests are weak before you assign it.
• Red (0–4, or boundary = 0 regardless of total): stop. This spec will produce expensive, confident, wrong work.

That's the whole rubric — the Readiness Six. No proprietary weighting, no black box. Any team can start scoring specs against this tomorrow with a spreadsheet.

What I'm not giving away

The rubric tells you how to score a spec. It doesn't tell you, across a hundred epics and three delivery teams, which team's Yellow specs are quietly costing the most rework, or how spec quality correlates with your actual AI Code Modification Ratio, or where Prompt-Spec Thrashing is eating the sprint before anyone notices. That's the part I've built as software — a knowledge graph over your Jira/GitHub/Confluence history plus a rules engine that applies this rubric (and the metrics built on top of it) automatically, at scale, without a human re-scoring specs by hand every sprint.

The rubric is the instrument. The engine is what makes it usable at the size most GCC engineering orgs actually operate at.

Why publish the rubric at all, then

Two reasons, and I'd rather state them plainly than pretend this is pure generosity.

First: a scoring framework that governs whether work is "ready" is only trustworthy if people can see exactly how it works and argue with it. I'd rather have the six tests and the veto logic pressure-tested in public before any engineering org bets a governance program on them, than defend a black box later.

Second: this is dated, public, and citable now, which is the point of putting a stake in the ground before anyone else's dashboard product quietly reinvents the same idea under a different name.

This is licensed CC BY 4.0. Use it, adapt it, cite it. If you run it against a real backlog and it breaks somewhere, I want to hear about it — that's a more useful reply than "cool framework."

If you want the Readiness Six scored automatically across your actual delivery history instead of by hand — talk to me.