Intentions, Requirements & AI📋

Stop tracking what you promised. Type it — then let the AI read the map instead of guessing the territory.

An agent can write a thousand lines before lunch. That stopped being the bottleneck. The bottleneck is month six, when nobody — human or model — can answer the only questions that matter: What were we supposed to build? Does the code still do it? How do we know?

The code is the territory. A prose spec in Jira, in Confluence, in a REQUIREMENTS.md that nobody has opened since the second sprint — that is a tourist brochure for a territory that has since been bulldozed by forty agent runs. It does not compile, so nothing ever tells you it has gone stale. Every new prompt re-guesses the terrain from scratch. That is where drift, hallucination, and unverifiable promises come from. Not from the model being weak — from the model having no map.

This series makes one argument, in two folds. First, requirements-as-code is Domain-Driven Design applied to the why — you model the justification of the software as a domain in its own right, and you refuse to call the model finished until it touches the proof. Second, because that map is typed, git-tracked, forkable, and compiler-gated, it is exactly what lets you point an AI fleet at one codebase without losing the plot — today, and eighteen months from now.

The Thesis📋

The map has its own language, a typed legend every artifact snaps onto:

REQ  ↔  FEAT  ↔  AC  ↔  TEST  ↔  IMPL  ↔  EVIDENCE

The relationship between a requirement and its acceptance criteria is deliberately loose — governed not by a hard-wired schema but by a Style, shipped with a sensible default. This is not aspiration; it is already built. We will read the real types.

How to Read This Series📋

Part 01: The Territory Has No Map📋

Why AI multiplies output but not understanding, and why prose specs rot silently. The problem this whole series answers.

Part 02: DDD on the Why, Down to the Proof📋

The centerpiece. We are not modelling the business domain; we are modelling the domain of justification. And unlike classic DDD, the model does not stop at the concept — it descends until it touches evidence in CI.

Part 03: The Map's Own Language📋

The legend REQ ↔ FEAT ↔ AC ↔ TEST ↔ IMPL ↔ EVIDENCE as an imposed ubiquitous language — and why typing it (not writing it in prose) is what makes the map machine-traversable.

Part 04: The Loose Link Is a Style📋

The requirement-to-AC link is intentionally distended: ACs live on the Feature, not the Requirement, and the vocabulary is parameterised by a RequirementStyle. We read the real generic Requirement<S> and its compile-time narrowing.

Part 05: Scaling AI on the Map📋

The payoff, both halves with equal weight: the sub-second compiler feedback loop that makes agents finish, and the .md / git / forkable / compliance-gated substrate that keeps the framing durable past month six.