Case Study · 2026-09-04
744 DD6 vectors across four AI-native codebases, 307 of them assigned before the work began. Comparing the two populations shows a bias with a direction: hindsight makes intent look clearer and everything else look harder — and it distorts the shape of the vector rather than its total.
What we learned
A DD6 vector only measures something if it was assigned before the work. 307 of these were; 437 were written afterwards. Both populations sit in the same repositories, so they can be compared directly.
| Axis | At intake | After implementation | Delta |
|---|---|---|---|
| IIntent clarity | 1.87 | 1.42 | −0.45 |
| DDomain depth | 1.82 | 2.50 | +0.68 |
| SStakeholder convergence | 1.62 | 2.00 | +0.38 |
| BBoundary clarity | 1.68 | 2.00 | +0.31 |
| PPrecedent | 1.85 | 2.01 | +0.16 |
| TTestability | 1.71 | 1.84 | +0.13 |
The signature
Once the work is done you know what was wanted — so I falls.
You also know what it cost you — so everything else rises.
I moving against the other five is what makes this a signature rather than noise. If people simply rated old work as harder, intent clarity would rise with the rest. It does the opposite, in every repository.
Backfilled specs are older work, which might genuinely have been harder. Comparing within each repository removes that confound.
| Repository | n (intake / backfill) | I | D |
|---|---|---|---|
| core618 | 84 / 188 | 2.07 → 1.37 | 1.99 → 2.82 |
| orbit618 | 27 / 189 | 2.11 → 1.40 | 2.19 → 2.33 |
| myastralmap | 170 / 60 | 1.68 → 1.63 | 1.65 → 2.02 |
The composite sum. Backfilled vectors average 11.76 against 10.55 overall — but within orbit618 the sum falls (12.15 → 11.65), and the overall gap is driven by myastralmap, whose intake-scored specs describe genuinely smaller work (9.51). The bias is in the shape of the vector, not in its total — which is what the model already says, now measured.
Why it matters
A classification model is only as good as the data used to tune it. If nearly 60% of your historical vectors were written after delivery, and those vectors are systematically wrong in a consistent direction, then every calibration built on them inherits the distortion — confidently, and invisibly.
This matters more, not less, as agents do the implementation. The whole point of classifying an intake up front is to decide how much exploration it deserves before anyone starts. A vector written afterwards decided nothing; it only describes.
The dataset
Not four organisations adopting a standard — four environments inside one team, at four stages of maturity. Read the last column top to bottom and it is a timeline of when the discipline arrived, not a ranking of who is disciplined.
The product built to enforce this kind of discipline: intake classification, spec governance, agent execution policy.
Adopted DD6 last of the four. Shows what a codebase looks like when classification arrives after the work.
425 commits · 1 364 source files
Reusable Django apps and TypeScript packages consumed by every other product: multi-tenancy, plugin loader, workflow engine, messaging.
Mid-adoption. Roughly a third of its specs were classified before the work, the rest after.
773 commits · 2 171 source files
Generated long-form readings with narrated audio, live in the App Store. The only one with real users and real revenue.
Carries the volume. Highest commit count of the four and the highest rate of follow-up fixes.
2 548 commits · 958 source files
The first product started after DD6 was already standard practice. Every spec classified at intake, none backfilled.
The forward-looking cohort. Its value is not today’s 26 specs — it is that nothing in it will ever need backfilling.
implementation has not started
12% → 31% → 74% → 100%. The governance engine scores worst on the discipline it exists to enforce, because it predates it by six months. connectus scores perfectly because it began under it. That is a maturity curve, not a performance ranking — and connectus has 26 specs against four source files, so its rate reflects starting conditions rather than sustained practice.
Methodology
For each spec file, find the commit that created it, read the file as it existed in that commit, and check whether the DD6 vector was already present. Present at creation counts as classified at intake; added later counts as backfilled.
Files whose creation commit is unreachable under their current path — renamed specs — are excluded, which is why this totals 744 where a plain content scan of the same repositories finds 806. Band thresholds are computed from the score, never read from the text of the spec: hand-written band labels in these repositories are unreliable enough that a tool trusting them would produce a different distribution.
| Band | Domain | Count | |
|---|---|---|---|
| 6–8 | Clear | 122 | |
| 9–11 | Complicated | 293 | |
| 12–14 | Complex | 312 | |
| 15–17 | Deep | 77 | |
| 18 | Chaotic | 2 |
Two intakes at 18 out of 744. A band reserved for “stabilize first” should be nearly empty; if it held eighty, the scale would be broken.
Where this sits
DD6 is the first link. It classifies the problem; something downstream governs how the work is executed, and something after that measures what it cost.
The downstream half is CIRK’s companion case, which finds the same bias with one exception: integration risk does not move under hindsight. Structural risk can be estimated prospectively; experiential risk cannot.
Evidence status
fix: and revert: commits per spec — and the instrument turned out to have arrived alongside the practice it would measure. Older specs were fixed; those fixes carry no spec ID and are uncountable. No number is published.connectus is the cohort that can settle it: classified prospectively from day one, with no historical backfill to disentangle. As implementation proceeds, each spec carries:
Joined to the DD6 vector assigned before any of it happened, that is a matched prospective cohort — the only population that can support a claim about whether classification pays for itself. Until it has aged, the honest description of this page is operational evidence.
Data collected 2026-09-04 from four repositories at their dev HEAD. Method and
queries are reproducible from
the case file.