## Definition The **SDD spectrum** is the framing that places every task in one of three regimes — Spec-First, Spec-Anchored, or Spec-as-Source — depending on whether the spec leads the code, captures intent of existing code, or generates the code directly. ## The Three Points ### Spec-First You write the spec **before any implementation exists**. The agent reads it, asks clarifying questions, then proposes code. - Best for: new features, public APIs, schema changes, anything with low reversibility. - Trade-off: higher up-front cost; lower rework cost. ### Spec-Anchored Code already exists. You write a spec **alongside** it to capture *intended* behaviour, then run it against the implementation to find drift. - Best for: legacy code about to be modified, pre-refactor stabilisation. - Trade-off: spec must be *discovered*, not designed — slower to write but illuminates hidden assumptions. ### Spec-as-Source The spec **generates** the implementation. You edit the spec, regenerate, and the diff drives review. - Best for: highly structured artifacts — clients from OpenAPI, migrations from schema diffs, IaC from a declarative model. - Trade-off: powerful where it fits, brittle where the model can't express what you need. ## Decision Rule Default to **Spec-Anchored**. Move to Spec-First for new public surfaces and high-blast-radius changes; to Spec-as-Source only where a trustworthy generator exists. ## Related - [[Spec-Driven Development]] - [[Executable Acceptance Criterion]] - [[Spec-as-Prompt Pattern]]