The history of software is not a list of fads. It is one unbroken move: each time the cost of a wrong assumption arrived earlier and compounded harder, the discipline that survived was the one that *defined “correct” earlier*. The 1968 software crisis forced structure onto code. Test-Driven Development (2002–03) pinned correctness at implementation; Domain-Driven Design (2003) at the domain model; Behaviour-Driven Development (2006, built on DDD) at user behaviour.[1][2][3][4] Each felt like overhead until the teams that skipped it hit the wall. AI agents collapse the gap between “designed” and “in production” to near zero — so the next move upstream is governance, before the agent runs. That is GDD: not a new idea, but the latest instance of the oldest pattern in the field — and one already running in production.[5][6]
Read as a list of methodologies, TDD, DDD, BDD and GDD look like a stack of acronyms a generation of engineers argued about. Read structurally, they are one move repeated: each pushes the definition of “correct” one layer earlier in the lifecycle. The pattern is older than any of them. In 1968, at the NATO conference that named the “software crisis,” the field admitted software had outpaced the methods to build it; Dijkstra's structured programming was the first response — discipline the control flow before it becomes unmanageable.[1][7]
The early-2000s cluster moved correctness upstream again, three ways at once. Kent Beck's Test-Driven Development (book, 2002–03) said: prove behaviour at the unit before you write the code.[2] Eric Evans' Domain-Driven Design (2003) said: model the business and agree the language before you write a line.[3] Dan North's Behaviour-Driven Development (2006) — built directly on DDD's ubiquitous language — said: express what the system should do for the user in a shared, executable vocabulary.[4] Note the real order: DDD preceded and shaped BDD. These were not a relay but a cluster of responses to the same complexity pressure.
Each shift felt like overhead until the teams who skipped it hit the wall. A green unit test cannot catch a misunderstood requirement; a well-modelled domain cannot catch a misunderstood intent handed to a machine that executes before anyone reviews it. Every discipline solved the failure of the layer below it — and, in doing so, exposed a new class of assumption one layer up. The constant is the shape of the move, not a strict order: each pinned correctness earlier than the gap that had just burned someone.
There is a new layer now. AI agents execute on inferred intent — fast, autonomous, and wrong in ways that compound before the sprint closes. The gap between “designed” and “in production” has collapsed to near zero. The question none of the prior disciplines had to answer is now the expensive one: do we know what correct means here — before any agent runs — and can we prove it? That is Governance-Driven Design. Not a replacement for TDD, DDD or BDD, and not their equal in standing — their upstream completion, for the era where the machine no longer waits. The honest claim is modest and structural: GDD is the next instance of a 50-year pattern, earned by a working implementation rather than asserted.[5]
From the software crisis to governance before the agent runs — the same move, six times.
At the NATO Software Engineering Conference in Garmisch, the field admits software has outpaced the methods to build it. Dijkstra's “Go To Statement Considered Harmful” launches structured programming — the first move to discipline code before it becomes unmanageable.[1][7]
The CrisisBeck's “Test-Driven Development: By Example” makes test-first mainstream: prove the behaviour of a unit before you write the code that satisfies it. Correctness is pinned at the implementation layer.[2]
TDDEric Evans' “Domain-Driven Design” (Addison-Wesley, August 2003): model the business and agree a ubiquitous language before writing a line. Correctness is pinned at the domain layer — and predates BDD.[3]
DDDDan North's “Introducing BDD” (Better Software), built on DDD's ubiquitous language: express what the system should do for the user in a shared, executable vocabulary (Given/When/Then). Correctness is pinned at the behaviour layer.[4]
BDDGovernance-Driven Design moves the definition of correct before any artifact exists, before any agent runs — the upstream completion of the family for AI-first delivery. Not a replacement; the next instance of the pattern.[5]
GDDThe migration's newest layer is live: the CAL publishing pipeline is governed by GDD. After UC-236 shipped with errors that every prior check missed (“cited” ≠ “correct”), an explicit verification gate was built; the next four cases shipped with zero post-publish corrections.[6]
In ProductionThe discipline that survives is the one that defines 'correct' earlier — because that is exactly where the cost of being wrong keeps moving.
| Dimension | Evidence |
|---|---|
| Quality (D5) Origin · 90 | The migrating variable is the definition of “correct” itself — what counts, and when it is decided. The whole lineage is the relocation of that definition, earlier and earlier: implementation, domain, behaviour, governance.[1][2] D5 is the origin because every discipline in the family changes the same thing — not the code, but where and when correctness gets pinned down. It is the one dimension the entire fifty-year story is about.The Definition of Correct |
| Operational (D6) L1 · 84 | Test-Driven Development (Beck, 2002–03; roots in SUnit 1994 and XP 1999) pinned correctness at the implementation layer: prove the behaviour of a unit before writing the code that satisfies it.[2] D6 is the first modern instance of the upstream move — correctness defined operationally, at the point of construction, rather than discovered after the fact in QA.TDD — Implementation |
| Customer (D1) L1 · 82 | Behaviour-Driven Development (North, 2006), built on DDD's ubiquitous language, pinned correctness at the user-behaviour layer: express what the system should do for the user in a shared, executable vocabulary (Given/When/Then).[4] D1 is the move that connected correctness to the customer's intent — does it do the right thing, not merely run without error.BDD — Behaviour |
| Employee (D3) L2 · 84 | Domain-Driven Design (Evans, 2003) pinned correctness at the domain model and the ubiquitous language the team internalizes: agree what the business means before writing a line.[3] D3 sits with the people and the shared understanding — the discipline a team adopts so that code and conversation describe the same reality. It predated and shaped BDD.DDD — Domain & Shared Language |
| Revenue (D2) L2 · 80 | The engine of the whole migration is the cost of a wrong assumption — arriving earlier and compounding harder each decade. Every shift happened because the discipline that caught the error sooner was cheaper than the one that caught it later; the teams that skipped a shift paid at the wall.[1] D2 is the economic pressure that makes the upstream move inevitable rather than optional, and AI agents — fast and autonomous — sharpen it to a point. |
| Regulatory (D4) 86 | Governance-Driven Design pins correctness before any artifact exists, before any agent runs — the terminus of the fifty-year migration.[5] D4 is where the cascade arrives because, when a machine executes inferred intent, no check downstream of governance is early enough to catch a wrong assumption. The layer is not theoretical: the CAL publishing pipeline runs it in production, and the UC-236 incident (“cited” ≠ “correct”) is the documented case that built the gate.[6]GDD — Governance (the terminus) |
The cascade originates in D5 — Quality — because the migrating variable is the definition of “correct” itself: what counts, and when it is decided. From D5 the definition is pinned, in turn, at D6 (implementation — TDD) and D1 (user behaviour — BDD), then at D3 (the domain model and shared language the team internalizes — DDD), driven the whole way by D2 (the cost of a wrong assumption, arriving earlier and compounding harder each decade). The terminus is D4 — Governance — where GDD pins correctness before any artifact exists. The structural payoff is the route: across fifty years the definition of correct migrates from D6 (implementation) all the way to D4 (governance), and D4 is precisely where the AI era forces it, because a machine that executes inferred intent cannot be caught by any check downstream of governance. The cross-references are deliberate: [UC-235] traced a design philosophy propagating across decades — the same mould; [UC-241] and [UC-240] showed AI commoditizing the surface signal while the upstream layer survives — which is exactly GDD's bet; [UC-247] is the adjacent fight over who owns a foundational software layer.
-- UC-249: The Upstream Migration: 6D Amplifying Cascade
-- Correctness, defined earlier every time (connects UC-235/241/240/247)
FORAGE upstream_migration
WHERE definition_of_correct = migrating_upstream
AND cost_of_being_wrong = arriving_earlier
AND each_discipline_completes_the_last = true
ACROSS D5, D6, D1, D3, D2, D4
DEPTH 3
SURFACE upstream_migration
DIVE INTO correctness_locus
WHEN agent_executes_inferred_intent = true
AND surface_check_cannot_catch_it = true
TRACE crisis_to_governance_cascade
EMIT upstream_migration_signal
DRIFT upstream_migration
METHODOLOGY 90
PERFORMANCE 48
FETCH upstream_migration
THRESHOLD 1000
ON EXECUTE CHIRP high 'for 50 years software discipline has moved the definition of correct one layer earlier - TDD, DDD, BDD - and now GDD, governance before any AI agent runs; the latest instance of the oldest pattern in the field'
SURFACE analysis AS jsonRuntime: @stratiqx/cal-runtime · Spec: cal.semanticintent.dev · DOI: 10.5281/zenodo.18905193
Every shift pushed the definition of 'correct' one layer earlier, each time the cost of being wrong arrived sooner. TDD → DDD → BDD → GDD is not four ideas — it is one pattern, four instances. The history of software is a single migration upstream.[1][2]
DDD (2003) predates and shaped BDD (2006); these were contemporaneous responses to one complexity pressure, not a succession. The honest lineage is a family, not a line — and saying so is what makes the pattern credible rather than tidy.[3][4]
The failure mode that defines the AI era: an agent can cite a source accurately and still be wrong; the audit passes; the artifact compiles. The surface check survives; the truth does not. Governance is the only layer early enough to catch what the surface check cannot.[6]
GDD's claim is earned, not asserted: the pipeline that produced this very case is governed by it. After the UC-236 incident, an explicit verification gate was built; the next four cases shipped with zero post-publish corrections. A discipline describing itself, while running.[6]
Eight sources spanning the canonical software-engineering record — the 1968 NATO conference, Beck, Evans, North, Dijkstra, the Agile Manifesto — plus the GDD framework and its documented live implementation.
AI agents don't wait for the answer. So you decide it before they run.