The SDD Pipeline
Four gates between intent and production. Each gate produces a specific artifact, invokes specialist AI agents for structured review, and requires a human operator’s written approval before work advances.
Four Gates, One Direction
A gate, in SDD, is a decision point with a written record. It is not a status column on a board. At each gate, a pipeline agent assembles a structured review from specialist agents, and the human operator documents an approval (or a rejection, or a scope reduction) with reasoning attached.
Work only advances when the gate has been cleared. A failed gate sends the spec back to the prior stage, not forward with a todo attached.
What Happens at Each Gate
PM-Spec — Spec Gate
Stage owner: the pipeline agent sdd/pm-spec. Gate owner:
the requester (product / engineering lead).
Produces the Feature Spec itself: business context, requirements,
acceptance criteria, scope boundaries, and — for Standard and
above — a Decision Rationale section that captures alternatives
considered and trade-offs accepted. For content-heavy specs,
marketing-copywriter is invoked to draft public-facing
copy.
The gate asks: are we solving the right problem, and have we named what we are deliberately leaving out?
Architect-Review — Arch Gate
Stage owner: sdd/architect-review. Gate owner: the
architecture lead (external reviewer required for Critical tier).
Validates the spec against existing architectural patterns. Invokes
architect-reviewer for system-design review and
penetration-tester for security-sensitive specs.
Evaluates whether the change has anchor impact —
whether an Anchor Spec update is required.
The gate asks: what alternatives did we consider, and what is the riskiest assumption in this approach?
Implementer-Tester — QA Gate
Stage owner: sdd/implementer-tester. Gate owner: the
engineer on the work.
Coordinates implementation and testing. Invokes
frontend-developer, ui-designer, and
graphic-artist for build-out;
test-automator and qa-expert for coverage;
code-reviewer for quality and security review; and
anchor-generator when the spec updates an Anchor.
The gate asks: what are we not testing, and are we okay with that? If this breaks in production, how will we know?
Deployment — Deploy Gate
Stage owner: sdd/deployment. Gate owner: the deploy
authorizer.
Prepares the release: merge readiness, rollback plan, known-gap disclosure, and post-deploy verification steps. For Anchor-impacting specs, the Anchor update must be in the same pull request as the code — atomic, never lagging.
The gate asks: what needs to happen after this goes live, and are we accepting any known gaps in this deploy?
The Learning Engine — Adjacent Feedback Loop
The Learning Engine is not a gate. It runs alongside the four gates, continuously, not per-spec — the feedback loop that keeps the other four gates from becoming rubber stamps.
Owned by the pipeline agent sdd/learning-engine, it
analyzes gate events across the pipeline to surface patterns: specs
that got stuck at a particular gate, escape events traced back to
their origin, process atrophy signals. It invokes
error-detective for root-cause analysis of production
escapes.
Where a gate asks should this spec advance?, the Learning Engine asks is the pipeline itself getting better, or is it drifting? The two questions live on different cadences and need different treatment.
What a Gate Actually Means
In most engineering processes, a "gate" is a status transition or a checklist. In SDD, a gate has three distinguishing properties:
- Specialist review is structured, not ad-hoc. Each gate names the specialist agents it invokes and the artifacts they evaluate against.
- Human approval is written. A gate approval includes reasoning — especially when the operator overrides an agent recommendation or chooses between viable alternatives. See Gate Annotations.
- Evidence scales with tier. Trivial changes require a one-line rationale in the commit message. Critical changes require full written responses to every agent concern, a 24-hour waiting period, and an external second reviewer. See Complexity Tiers.