Spec first, code second
Before a line of code, the AI turns the requirement into a structured spec. You sign off on the what before anyone spends effort on the how.
Spec-first · TDD enforced · Two-way traceability
AI writes code fast. SDD makes it correct — and provable.
Spec-driven development: every requirement clears a hard gate and traces to the exact code and test that implement it. No shortcuts, nothing lost on the way.
Spec-first
Structured requirements before code
TDD-enforced
Test first, then implementation
Two-way traceable
Spec ↔ code ↔ test, both directions
Tamper-evident
Hash-chain decision log
The core idea
What is SDD?
Think of SDD as a seasoned team's engineering process, packaged and wired straight into the AI. Instead of hoping the AI gets it right, you install mandatory checkpoints — an assembly line with a QA station at every step.
Hard gates between phases
A phase advances only when it clears a machine-checked bar. A miss stops the work and reports it honestly — never a "skip it to go faster".
Two-way traceability
From any requirement, trace to the exact code and test that implement it — and back again. No orphan features, no forgotten requirements.
Composable by stack and domain
One standard base, plus your technology layer (.NET, Django, Rails, Next.js, LLM apps…) and your domain layer (finance, ERP, e-commerce, SaaS). The right context from day one.
Controlled autonomy
The AI decides within allowed bounds, following an explicit heuristic chain. Every choice is logged for you to review later — bounded autonomy, not blind trust.
Tamper-evident audit log
Each automated decision is sealed into a hash chain, so any later change shows. Technical proof, not a promise.
#a4c
→
#1b7
→
#e2f
→
#9d0
The pipeline
The 7-phase process — one closed loop
A feature moves through 7 phases, with a machine-scored hard gate between each one. People set intent and judgment at the start of a phase, SDD and the AI do the heavy lifting, and the gate blocks defects before the work moves on.
1
PO / BA
Specify
Turn requirements into a structured spec with acceptance criteria.
2
Solution Architect
Plan
Fix architecture, NFRs and ADRs; the gate checks the module graph has no cycles.
3
Tech Lead
Tasks
Break 100% of the requirements into tasks, check the dependency DAG, split milestones.
4
Developer
Implement
Write the test first, then the code; small tasks, each traced to a requirement.
5
QA / SDET
Verify
Run the full test suite; check traceability and acceptance criteria.
6
QA + Tech Lead
Review
Three independent review rounds, each widening in scope; the AI never grades its own work.
7
Team Lead
Report
An honest summary: what passed, what failed, which decisions were logged.
When a gate FAILs — out of self-fix retries — the pipeline jumps straight to phase 7 REPORT with an honest report. It never stops in silence, and never pretends the work is done.
Roles at each phase (RACI)
| Phase | PO / BA | Sol. Architect | Tech Lead | Developer | QA / SDET | DevOps | Team Lead |
|---|---|---|---|---|---|---|---|
| Specify | A | C | C | I | C | I | I |
| Plan | C | A | R | C | C | C | I |
| Tasks | C | C | A | R | C | I | I |
| Implement | I | C | C | A | C | C | I |
| Verify | I | C | C | R | A | C | I |
| Review | C | C | A | C | R | I | I |
| Report | I | I | C | I | C | I | A |
R = responsible · A = accountable (exactly one per phase) · C = consulted · I = informed. SDD and the AI always execute under the accountable person.
SDD is a closed loop, not a one-way street: discover → specify → build under control (SPECIFY→TASKS via /autopilot, IMPLEMENT→REPORT via /pipeline) → release → operate and learn (tracked on the read-only /sdd-metrics dashboard) → next cycle.
Operational feedback returns to the spec through the /delta channel, and the spec lives with the codebase — so the next cycle starts from the spec, not a vibe-code from scratch.
Same AI, two outcomes
Problem ↔ Solution
Same AI, two very different outcomes. On the left is how most teams use AI today; on the right is the same work under SDD discipline.
AI coding on vibes
AI coding under SDD discipline
Drift from intent
Code quietly drifts from the original requirement; by acceptance, the divergence is already baked in.
A hard gate scores every phase and catches drift on the spot, before it carries forward.
Self-grading
The AI marks its own output — striker and referee at once.
Independent reviewers plus machine-scored gates; the AI never approves its own work.
Missing traceability
No one can say which code implements which requirement, and orphan features slip through.
Two-way traceability spec ↔ code ↔ test: every requirement links to the exact code and test.
Scattered decisions
Technical choices sit scattered around, and a later change goes unnoticed.
A hash-chain-sealed log where any later edit is detectable.
Structure, not a promise
Why you can trust it
Trust here comes from structure, not a promise: the six guarantees below fall straight out of how SDD runs, each anchored to one of the pillars above.
No shortcuts are possible
↳ Pillar · Hard gates between phasesA phase passes only when it clears a machine-scored bar; a miss stops it, with no "skip to go faster" exception.
verify-*.pyThe AI never grades itself
↳ Pillar · Controlled autonomyThe AI's autonomy is bounded and logged; grading is done by the gates and by reviewers that run read-only at task and milestone scope, and in a fresh context for the project round.
spec-compliance-reviewerThree widening review rounds
↳ Pillar · Hard gates between phasesEach round widens from narrow to broad — a gate, not a single glance.
task_lenses = 3Reviews both the business and the code
↳ Pillar · Spec first, code secondSign off on the what at the spec phase before spending effort on the how, then review the quality of the implementation.
spec-compliance → code-quality-reviewerTraceability is enforced
↳ Pillar · Two-way traceabilityEvery in-scope requirement must link to the code and test that implement it; a script blocks "done" until it does.
verify-traceability.py --auto-detectHonest reporting
↳ Pillar · Tamper-evident audit logGate results are written straight into a tamper-evident log — a later edit breaks the hash chain and the verifier flags it. No gloss, no hidden failures.
tasks/DECISIONS/ verify-decisions.py
Evidence, not a slogan
Discipline you can measure, not a promise
A handful of numbers pulled straight from this project — the site itself was built through SDD, so this is evidence, not a slogan.
27
specified functional requirements (FR)
specs/FUNCTIONAL.md
29
non-functional requirements (NFR)
specs/NON_FUNCTIONAL.md
7
phases with a hard control gate
SPECIFY → REPORT
3
independent review rounds per change
reviewers never grade their own work
Different worry per role
Control + speed
Audit-ready proof
Sign-off in business terms
Less rework, faster delivery
Who it fits
SDD answers a different worry for each role. If you see yourself in one of the four groups below, the rest of this page speaks to exactly what you care about.
CTO & Engineering Lead
Wants the AI's speed without giving up control, predictability, and one consistent quality bar across the team.
Compliance & Audit Team
Needs a hash-chained decision log and requirement-to-test coverage to prove compliance under scrutiny.
Non-technical Founder
Approves what the system will do in business language at the spec phase, with transparency at every control point.
Product Development Team
Less rework, fewer misread requirements, faster delivery — because drift is caught at commit time by a script instead of at acceptance by the client.
Book a consultation
Leave your details and we'll reach out to advise on applying SDD to your team.