Role changes
- PMs define scenarios and constraints.
- Architects shape the planning model.
- Engineers use AI to accelerate.
- Test shifts earlier, because acceptance criteria are explicit from the start.
Section 1
The three inputs
Spec-Driven Assurance does not replace the blueprints. It welds Microsoft’s spec-first lifecycle to the assurance obligation and the confidence question the blueprints already know how to ask.
Position paper · 21 October 2026
1.1 · Microsoft SDD
What Spec-Driven Development says.
Definition. Teams agree on guardrails, requirements, constraints, acceptance criteria, and edge cases before implementation. AI then generates code, tests, and supporting artifacts from that shared context. The spec is the shared source of truth for humans and AI.
The problem it names is translation loss at four handoffs: stakeholder needs to product requirements; requirements to architecture and design; design to implementation; implementation to validation and release. Prompt-first workflows break at scale. Requirements held only in prompts produce architectural drift, code drift, inconsistent implementations, harder reviews, and rework.
The bottleneck of AI-native engineering is not how fast code can be generated. It is how clearly intent can be captured, shared, and validated.
| Phase | Purpose | Artifact |
|---|---|---|
| 1 Constitution | Principles, standards, guardrails | constitution.md |
| 2 Specify | Requirements, scenarios, acceptance criteria | spec.md |
| 3 Clarify | Resolve ambiguity, dependencies, edge cases | [NEEDS CLARIFICATION] markers resolved |
| 4 Plan | Translate intent into architecture, flows, constraints | plan.md, plus research, data model, contracts |
| 5 Tasks | Implementation-ready units | tasks.md |
| 6 Implement | AI generates and refines code and tests | code + tests |
| 7 Validate | Confirm the output matches the spec | validation evidence |
Lessons and tooling
Alignment is a team habit, not a tool choice. Good specs capture intent, constraints, and acceptance criteria. Planning quality drives implementation quality. Not every change needs the full lifecycle. Specs are living documents. Adoption runs Pilot, Formalize, Iterate, Refine and scale. GitHub Spec Kit supplies the commands; the model must not guess past a [NEEDS CLARIFICATION] marker.
1.2 · The blueprints
What the blueprints already say.
AI Assurance — the what
Two pillars: AI feature logic and outputs, and the end-to-end experience. Three levels: model, system, and user. Lifecycle from scoping through monitoring. About twenty-two coverage areas, a 0–2 rubric, regulatory anchoring, and guardrails that are validated, never trusted.
Confidence Engineering — how we know
Twelve values, the Complexity Gap, the recursive standard, the Two Unknowns, and the Confidence Engineer. Five evidence layers — Intent, Verification Infrastructure, Exploration, NFR and performance, Runtime — and four anchors, with specification-by-example still an open thread.
The Crosswalk
Eleven notes pairing each AI Assurance artifact with its Confidence Engineering standard. Each note has an operating question, a worked translation, and what changes in practice. The extension keeps that form for nine SDD artifacts.
1.3 · Reference architecture
A specification spine.
The spine holds the definition: Define → Analyse → Trace & Verify → Hand over → Assure, with platform services for the audit trail and AI call log, metrics and reporting, a public API and agent integration, and control-tool integration.
It sits above suppliers and builders — software houses, AI-assisted teams, package vendors — hands them specification, scenarios, and measures, receives evidence back, and gives the board, auditors, and regulators a traceable position. It specifies and measures. It does not build. It is not a compliance management system.
In SDD terms the spine owns Constitution, Specify, Clarify, and Validate. Builders own Plan, Tasks, and Implement. The extension uses those stages as a neutral vocabulary and does not assume a product.