Methodology / Pipeline

The SDD Pipeline

Six gates — four core (Spec, Architecture, QA, Deployment) and two conditional (Plan, once per multi-spec initiative; Baseline, for a spec that replaces or migrates existing behaviour). Each produces a specific artifact, invokes specialist AI agents for structured review, and requires a human operator’s written approval before work advances.

Staged Work, One Direction

Work moves through a staged pipeline — specification, architecture, implementation and test, deployment, and a learning stage that feeds what shipped back into how the next spec is written. Between the stages sit gates, and the gates are the point: work does not advance until a named human signs off, in writing, with the evidence the gate requires attached.

Six gates — four core (Spec, Architecture, QA, Deployment) and two conditional (Plan, once per multi-spec initiative; Baseline, for a spec that replaces or migrates existing behaviour). The two conditional gates differ in where they sit: the Plan Gate is at initiative altitude, above the per-spec journey entirely, while the Baseline Gate is at spec altitude — it inserts into a single spec’s flow, between the Architecture Gate and implementation. The gates below are numbered in the order work meets them.

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

These four run on every spec, in this order. The two conditional gates — Plan and Baseline — are described in the section below; neither is a stage that all work passes through.

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 Two Conditional Gates

The Plan Gate — once per multi-spec initiative

Stage owner: the requester, working from the approved spec. Gate owner: the product / engineering lead.

Between knowing what to build and deciding how it should be structured sits the question of shape: how large the work is, what it breaks into, and in what order those pieces land. When one objective is too big for a single spec, this gate approves that decomposition before any of it is built. A standalone feature never needs one.

It fires once per initiative — a group of specs under a single objective — rather than once per spec, and it sits at initiative altitude rather than in the per-spec sequence: one approval above, then each spec underneath runs its own journey through the gates below.

The gate asks: is this the right objective, broken into the right pieces, in the right order?

The Baseline Gate — only when existing behaviour is at risk

A spec declares whether it will replace or migrate something users already rely on. When it does, the Baseline Gate fires between Architecture and Implementation — capturing the before-state while the implementation that produces it still runs. Once the replacement lands, that evidence cannot be recovered.

The point is provable parity. With a baseline captured, the new behaviour can be checked element by element against what was actually there, rather than against what someone remembers being there.

The Three Journeys

Which gates apply is a property of the work. There are exactly three shapes.

A standalone feature

One spec of new work, nothing existing replaced. No Plan, no Baseline.

Spec → Architecture → QA → Deployment.

A migration or replacement

One spec that re-implements a surface users already have. Baseline, no Plan.

Spec → Architecture → Baseline → QA → Deployment.

A multi-spec initiative

One objective too large for a single spec, delivered as several in a deliberate order. One Plan Gate above; each spec underneath then runs one of the journeys above.

The Learning Engine — Adjacent Feedback Loop

The Learning Engine is not a gate. It runs alongside them, continuously, not per-spec — the feedback loop that keeps the 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.

No Unopposed Approvals

The most common failure mode of review — human or AI — is agreement. A single confirmatory reviewer reinforces the author’s priors; a reviewer who shares the author’s context finds the author’s conclusions. SDD’s answer is structural: at the two gates where judgment matters most, review is opposed by design.

At the Architecture Gate, two architects

One validates the design. A second — the adversary — hunts the riskiest assumption and the failure mode the validator did not look for. Neither sees the other’s output first. Where they diverge, the divergence is presented as the finding, never reconciled into one comfortable view. The disagreement is the signal.

At the Spec Gate, antagonistic review

For complex and critical work, two critics with different lenses and no coordination read the spec before it is approved — one attacking the substance, one reading it cold from the recipient’s chair. Verdicts are Pass, Pass with conditions, or Fail, and every finding is graded with the same proof vocabulary the rest of the methodology uses.

This is not process for its own sake. It is the cheapest known defense against the confident, fluent, wrong answer — from a model or from a person.

Apply This to a Portfolio Company.

The gates are how SDD turns AI-augmented engineering velocity into shipped product without losing the decisions that shape it. In a portfolio engagement, the pipeline is what the CEO and sponsor recognize as the operating model — concrete, decision-anchored, auditable. If you want to see what the pipeline looks like running on a real team, the conversation is the place to start.

Discuss a Growth Advisory Engagement