The discipline · v1.0
T2D2
Testing (and) Telemetry Driven Development
A discipline for keeping a checkable contract between what a human asked for and what a human-plus-agent pair actually built — from before the first line of code to whatever the system does in production, through however long it keeps running after that.
Language-agnostic · Free and open methodology · The tool is the reference implementation.
What T2D2 is
Test-driven, extended upward.
T2D2 extends Test-Driven Development's core move — write the check before the thing it checks — to the level of architecture and intent, not just function-level correctness.
The contract has three deliberately separate parts. A graph — a structural representation of the codebase, call shape and data shape — says what should exist. A test manifest — behavioral, Given/When/Then — says what should happen. An execution trace, once the system is live, says what actually did happen.
Graph and trace correlate by stable, deterministic node IDs. The test manifest is a separate, ordinary contract — not wired into that same ID scheme, on purpose: conflating structural and behavioral correctness into one check makes each less precise.
The graph does three jobs: proposed before code exists, for a human to review; regenerated after code is built, and diffed against the proposal; used as the map that production traces plot against once the system is live — which turns telemetry into something navigable rather than a firehose of logs.
The loop
Four phases. One loop. A check at every turn.
T2D2 follows Deming's Plan-Do-Check-Act cycle. Each phase has a specific ceremony and a specific artifact; nothing advances until the artifacts agree.
Brief → Survey → Calibration → Formalization
The agent proposes a structural edit to the graph. The human reviews it. Assumption corrections, a test manifest, and a formalization matrix are produced. Sign-off gates the next phase. No code is written before this closes.
Build against the plan
Implementation proceeds against the approved proposal. Standard practice — this is the phase that already looks familiar.
Fidelity Check & Test Manifest
The graph is regenerated from the real code and structurally diffed against the proposal. The test manifest is run against behavior. Both gates must pass. A mismatch returns work to Blueprint, not to another Build attempt.
Handover & In Service
Deploy. Stable node IDs are injected into the running system. The graph becomes the live map that execution traces plot onto — for debugging, refactoring, and onboarding, indefinitely.
Before code: a structured proposal that can be reviewed and disagreed with. After code: a deterministic check against that proposal — not a human reading a diff, not an LLM asking itself if the change "looks right." The check happens at both ends of Build, and the artifact is the same shape on both sides.
Two doors
Read from where you sit.
T2D2 sits at the intersection of a century-old quality tradition, a twenty-five-year software methodology tradition, and a two-year-old agentic-coding problem. There's a different path through the material depending on what you're evaluating.
For researchers and engineers
The research lens
The five mechanisms of compounding drift. The control-type vs. warning-type distinction. Direct engagement with Monperrus (2026). What's verified, what's contested, what's anecdotal.
Read the research →For business leaders
The business lens
Why removing inspection because it can't keep pace is not a recognized response in any safety-critical discipline. The cost that gets shifted forward, not eliminated. What design partnership would look like.
Read the business case →The rest of the discipline
Four more doors, if you want them.
Methodology
The ceremonies, values, guardrails
The full ceremony lifecycle, the six values that give it its spirit, and the six guardrails that make it enforceable — cleanly separated, no overlap.
Read the methodology →Problem classes
Where AI reasoning and coding fail
Seven distinct classes of failure that agent-driven development produces — and that T2D2 exists to catch, before it compounds.
Read the problem classes →Origins
Where it came from
Three lineages — quality/lean, software methodology, agentic coding — and the organic moment (a factory floor, a Heinlein story) that produced the discipline.
Read the origins →Research (again)
The evidence, graded
Every claim in this discipline carries an evidence tier. Strong, independently verified; contested; anecdotal. Each is named.
Read the research →Shop manual, not a sales brochure.
The methodology is free and stays free. The tool implements it. The discipline is versioned — future revisions belong in new files, not silent edits — so it can be disagreed with, cited, and improved. What gets built on top of the methodology later is a separate question.