What is Governance-Driven Design?
Governance applied after execution is remediation. Governance applied before execution is design.
Governance-Driven Design (GDD) is a pre-execution discipline for AI-first delivery lifecycles. Its central claim is simple: the most valuable and most fragile moment in AI-first delivery is not implementation but formalization — the act of making implicit expectations explicit, testable, and governed before any agent is invoked.
The Problem GDD Addresses
AI-first delivery is fast. Agents generate artifacts — code, schemas, analyses, decisions — at a pace that outstrips the organizational capacity to understand what was built, why it was built that way, and whether it is correct.
The instinctive response has been to add governance after the fact: compliance layers, audit trails, oversight dashboards applied once something has already been produced. This produces the governance gap — the distance between what an AI system was instructed to do and what it can be held accountable for doing.
The governance gap is not a tooling problem. It is a sequencing problem.
GDD is the discipline of applying governance before execution — of treating the formalization of intent, constraints, and expected outcomes as the first deliverable of any AI-first lifecycle, not the last.
The Lineage
GDD does not emerge from nowhere. It is the next step in a migration that has been underway for decades — the progressive movement of correctness earlier in the delivery lifecycle.
| Practice | Year | Correctness Defined At |
|---|---|---|
| TDD | 2003 | Implementation |
| BDD | 2006 | Observable behaviour |
| DDD | 2003 | Domain model |
| GDD | 2026 | Governance layer — before any artifact exists |
Each transition shared a common pattern: a prior practice was producing correct-looking output that failed in ways the practice could not detect. The failure was traced to assumptions made too late — after commitment, after cost. A new discipline moved the definition of correctness earlier.
AI-first delivery compresses the gap between "designed" and "in production" to near-zero. GDD is the logical response.
GDD is not a replacement for TDD, BDD, or DDD. It is their upstream completion.
On DDD's place in this lineage
Domain-Driven Design addressed design intent — making domain assumptions explicit through ubiquitous language and bounded contexts — rather than test or behaviour correctness. It belongs in this lineage because it moved formalization upstream. GDD extends it: where DDD formalized what the domain is, GDD formalizes what the governance layer requires. The analogy is structural, not identity.
What GDD Produces
GDD's primary output is a Governed Constraint Set — a formally structured definition of:
- What the system must hold true
- What it must not violate
- What remains unresolved and requires human judgment before execution proceeds
Every constraint carries a status:
| Status | Meaning |
|---|---|
[RESOLVED] | Confirmed — implement exactly as stated |
[ASSUMED] | Believed but unverified — flag and surface |
[UNKNOWN] | Cannot proceed without a decision |
[CONFLICT] | Two constraints contradict — neither side is safe to implement |
The unresolvable residue — every [UNKNOWN] and [CONFLICT] — is the most valuable output. It is the set of decisions that genuinely require human judgment. Surfacing these before implementation is the discipline. Resolving them before any agent runs is the governance act.
When GDD Applies
GDD is not a universal mandate. It is a discipline you reach for when the conditions warrant it.
Reach for GDD when:
- Stakes are high and visibility is low
- Regulatory or compliance constraints are material
- Multiple agents will operate on shared state
- The domain contains implicit assumptions never formally examined
- A legacy system holds business rules nobody has written down
GDD is not needed when:
- Rapid prototyping and exploratory work
- Low-stakes automation and internal tooling
- The domain is well-understood and constraints are already explicit
The practitioner's judgment about which context they are in is itself a governance act.
GDD and Related Practices
Event Storming (Brandolini, 2013) and Impact Mapping (Adzic, 2012) are established pre-build disciplines that surface domain assumptions before development begins. GDD does not replace them.
GDD is AI-first by design. Both Event Storming and Impact Mapping produce outputs for human consumers. GDD produces a machine-readable Governed Constraint Set that an AI agent can read, operate within, and surface violations of. The CLAUDE.md template makes this concrete: it converts the constraint set into a governance contract the model executes against.
GDD names the unresolvable as a primary deliverable. Event Storming and Impact Mapping aim to resolve ambiguity through collaborative discovery. GDD adds a formal category for what cannot be resolved in the room. A team that has already run Event Storming has a strong starting inventory for a GDD cycle — the domain events and assumptions from the storming session become the first pass at the FORMALIZE step.
The Human-as-Primitive Principle
A consistent property across the Semantic Intent ecosystem is human-as-primitive — human judgment as a first-class architectural element, not an optional approval step.
GDD operationalizes this at the earliest possible moment. The ICR cycle does not treat human input as an interrupt when something goes wrong. It treats the Synthesis Gate — the moment the machine hands the unresolvable residue to a human — as a designed-in architectural node.
This is the structural difference between governance-as-audit and governance-as-design.
The Philosophy
TDD, BDD, DDD were not arbitrary conventions. They were responses to real pain — hard-won understanding about where projects fail, where ambiguity compounds, where human judgment is irreplaceable. That knowledge does not expire because the tooling changed.
GDD is a reconnection: taking what those practices understood about discipline, formalization, and structured thinking, and asking what that looks like when AI is doing most of the execution.
It is also not the last word. The migration of correctness upstream will continue as delivery velocity increases. What matters is not the specific practice but the underlying discipline: define correctness before you build, not after you break.
Continue to The ICR Cycle →