AI writes code fast. SDD makes it correct — and provable.

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.

• 📋Spec first, code second (spec-first)

  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.

• 🚦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.

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. 1

   SPECIFY

   PO/BA

   Turn requirements into a structured spec with acceptance criteria.

2. Hard gate

   2

   PLAN

   Solution Architect

   Fix architecture, NFRs and ADRs; the gate checks the module graph has no cycles.

3. Hard gate

   3

   TASKS

   Tech Lead

   Break 100% of the requirements into tasks, check the dependency DAG, split milestones.

4. Hard gate

   4

   IMPLEMENT

   Developer

   Write the test first, then the code; small tasks, each traced to a requirement.

5. Hard gate

   5

   VERIFY

   QA/SDET

   Run the full test suite; check traceability and acceptance criteria.

6. Hard gate

   6

   REVIEW

   QA + Tech Lead

   Three independent review rounds, each widening in scope; the AI never grades its own work.

7. Hard gate

   7

   REPORT

   Team Lead

   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 per phase (RACI)

R = responsible · A = accountable (exactly one per phase) · C = consulted · I = informed. SDD and the AI always execute under the accountable person.

The product lifecycle under SDD

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.

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.

• Drift from intent

  Problem · AI coding on vibes

  Code quietly drifts from the original requirement; by acceptance, the divergence is already baked in.

  Solution · AI coding under SDD discipline

  A hard gate scores every phase and catches drift on the spot, before it carries forward.

• Self-grading

  Problem · AI coding on vibes

  The AI marks its own output — striker and referee at once.

  Solution · AI coding under SDD discipline

  Independent reviewers plus machine-scored gates; the AI never approves its own work.

• Missing traceability

  Problem · AI coding on vibes

  No one can say which code implements which requirement, and orphan features slip through.

  Solution · AI coding under SDD discipline

  Two-way traceability spec ↔ code ↔ test: every requirement links to the exact code and test.

• Scattered decisions

  Problem · AI coding on vibes

  Technical choices sit scattered around, and a later change goes unnoticed.

  Solution · AI coding under SDD discipline

  A hash-chain-sealed log where any later edit is detectable.

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

  A phase passes only when it clears a machine-scored bar; a miss stops it, with no “skip to go faster” exception.

  ↳ Pillar: Hard gates between phases

  machine-scored gates: verify-*.py

• The AI never grades itself

  The 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.

  ↳ Pillar: Controlled autonomy

  spec-compliance-reviewer (independent agent)

• Three widening review rounds

  Each round widens from narrow to broad — a gate, not a single glance.

  ↳ Pillar: Hard gates between phases

  task_lenses = 3 (SDD default)

• Reviews both the business and the code

  Sign off on the what at the spec phase before spending effort on the how, then review the quality of the implementation.

  ↳ Pillar: Spec first, code second (spec-first)

  spec-compliance → code-quality-reviewer

• Traceability is enforced

  Every in-scope requirement must link to the code and test that implement it; a script blocks “done” until it does.

  ↳ Pillar: Two-way traceability

  verify-traceability.py --auto-detect

• Honest reporting

  Gate 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.

  ↳ Pillar: Tamper-evident audit log

  tasks/DECISIONS/ hash-chain + verify-decisions.py

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)

  counted in specs/FUNCTIONAL.md

• 29

  non-functional requirements (NFR)

  counted in 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

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

  Control + speed

  Wants the AI’s speed without giving up control, predictability, and one consistent quality bar across the team.

• Compliance & Audit Team

  Audit-ready proof

  Needs a hash-chained decision log and requirement-to-test coverage to prove compliance under scrutiny.

• Non-technical Founder

  Sign-off in business terms

  Approves what the system will do in business language at the spec phase, with transparency at every control point.

• Product Development Team

  Less rework, faster delivery

  Less rework, fewer misread requirements, faster delivery — because drift is caught at commit time by a script instead of at acceptance by the client.