What Intent Driven Development is

The one-sentence difference

If you have done test-first development, this will feel familiar, and the familiarity needs a moment's care. Test-driven development proves that code does what you intend. Behaviour-driven development proves that a feature behaves as agreed; it points outward, from a requirement to the examples and tests that verify it. Intent Driven Development proves that a requirement deserves to exist; it points upward, from the requirement to the reason it is there.

They are not rivals. BDD guards the what; IDD guards the why. A mature project wants both, and they meet at the requirement: grounded upward to a reason, covered downward by a test.

In one minute

The idea is the test-first instinct, moved one level up:

• In TDD you do not write code without a failing test first.
• In BDD you do not build a feature without an agreed scenario first.
• In IDD you do not create a requirement without its justification first.

In throughline, the tool this estate is built with, that justification is a real, checkable thing. Every item in a graph is one small file with a permanent identifier. A few kinds of item are roots: an intent, a business need, a risk, a constraint, an assumption. Roots are the why and may exist on their own. Everything else must reach a root through a grounding link, and the links form a graph with no cycles, so nothing can justify itself. A command, tl check, validates the whole graph and fails the build if an item reaches no root, or if a root nobody serves is left dangling.

So a requirement that is grounded but not yet built is the method's version of a red test: specified and justified, not yet delivered. You move it on when the thing exists.

Where the person comes in

A machine can now write a hundred plausible requirements in an hour. The method's answer is not to forbid that but to bound it. An item that an AI wrote enters the graph as proposed and stays there until a named human ratifies it, which records their name against the exact wording they read. Until then it does not count as agreed, and the strict check treats it as an error. If the wording later changes, the signature no longer matches and the item asks to be read again. A signature can be withdrawn; an ambiguous item can be flagged and cannot be signed until someone clarifies it.

That is what signed by a named person means on the splash. It is not approval in the workflow sense. It is accountability: this person read this sentence and took responsibility for it, and the record says so.

What the record looks like

A graph is a directory in an ordinary git repository: a small configuration file and one YAML file per item, each named after its identifier. This is a requirement from the tool's own documentation, in full:

uid: FR-0022                 # permanent, never renumbered, never reused
type: requirement
status: approved
title: Guided setup wizard
text: The system shall walk new users through a 3-step setup.
normative: true
links:
  - target: BN-0003          # this requirement derives from a business need
    type: derives_from
  - target: ASM-0002         # …and depends on an assumption's validity
    type: assumes
    stamp: sha256:…          # the target's fingerprint when last confirmed

Because the files are the product and live beside the code, every change to a requirement is a commit with an author and a date, every decision is diffable, and a document can be rendered from the graph rather than written beside it and left to drift. The schema page goes through each part.

Why intent is invariant

The splash says intent is invariant; the output artefact is not. The six words that roll on the wordmark, discovery, definition, design, development, delivery and documentation, are the disciplines a piece of work passes through. In each the artefact is different: a conversation, a specification, a drawing, code, a release, a manual. The intent behind them is the same thing throughout, and the method keeps it as the one record that all of them are made from. When the artefact is regenerated, from a new model, a new framework or a new medium, the intent does not have to be rediscovered.

The worked examples show this on real work: a parking register whose legal paperwork and service were both generated from one signed record, an essay taken apart into claims and put back together, a product described in full only after it was already built.

Two meanings of the name

Nobody owns the phrase. It was a talk title by March 2025, and at least seven projects and talks have used it since, most of them meaning intent as the thing an agent builds from. Two pin it to a specific axis, and they are opposite ends of the same requirement. A widely used agent skill called intent-driven development turns one change request into acceptance criteria: the outward axis, what must be observably true when this change is done. throughline requires every requirement to trace upward to a reason before it counts: the inward axis, why this should exist at all.

They answer different questions and one change can use both: ground the requirement first and have a person ratify it, then write its acceptance criteria and record each as a verifying item in the graph. The axis, not the name, is what tells the two apart. This site means the upward one.

Where to go next

• The schema: roots, grounding links, statuses, what the check enforces, and how one graph composes another.
• Running one: install the tool, start a graph, watch the check fail and pass, bring an AI in, gate it in CI.
• Worked examples: seven accounts of real work on one record of decisions, with a technical page beneath each.
• The catalogue: standards such as WCAG and ASVS as graphs you compose into your own by reference.