3.1
Does the constitution state, before any spec, what evidence an AI-infused feature must produce to ship, and who owns the verdict?
Spec Kit’s constitution governs how code is generated and leaves three articles empty. The AI QA Scoping Plan, regulatory anchoring, and the guardrail stance become seven assurance articles — probabilistic acceptance; coverage areas are spec sections; obligations trace to source; guardrails are assumptions, not evidence; evaluator provenance; monitoring-first; a named owner of the verdict — gated against at plan time.
3.2
Is “ready to generate from” a checklist passed, or a measured, intervalled claim?
DeFOSPAM, IEEE 830, and Planguage measure what SDD asserts; the recursive standard puts an interval on it. The spec gains a Spec Confidence block — lens counts, scores, open ambiguities and gaps, provenance of the analysis — recorded before planning. End reports show spec confidence beside output confidence.
3.3
Are the open markers a list to clear, or a risk register?
SDD contributes the discipline: marker syntax, a no-guessing rule, and a gate. The blueprints contribute the content: the scoping question set and the lenses that find what the author would not notice. Markers are classified by lens and by coverage area threatened. Blocking markers hold the baseline. Non-blocking ones travel as known unknowns.
3.4
Is this criterion a point the output must hit, or a distribution it must satisfy?
For AI-touched behaviour the measurable criterion is a distribution of judged outcomes: a named, versioned set; N; conditions (model, system prompt, decoding); rubric dimensions; a target; an interval. Binary only for deterministic flows and client-defined fixed prompts — as Design AI Testing already prescribes.
3.5
Is evaluation a component of the system being built, or something QA will do later?
The plan decides the architecture of the evidence as well as the system: evaluation hooks, provenance logging, baseline sets, rubric dimensions, HITL capacity, monitors. Spec Kit’s Phase −1 gates gain an assurance gate. A failed gate is justified in Complexity Tracking. The three test types map onto the plan directly.
3.6
Does the task list show where the evidence effort goes and why?
tasks.md carries [E] evidence tasks, traceable to a coverage area and a criterion, ordered by risk, sized by the estimation methodology. Evidence tasks that depend only on the spec start before generation. Evidence-budget allocation gets its first concrete home.
3.7
What evidence did not come from the generator or its relatives, and would it detect a bug they share?
The same context produces implementation and tests, and both may inherit AI-written spec analysis. Generated tests are scripted-level evidence for deterministic flows only. AI-touched behaviour needs Level 2 and Level 3 evidence with provenance distinct from the generator. AI judges get sampled human verification. Every AI call is logged.
3.8
Is Validate a gate passed once, or the moment the evidence stream starts?
“Confirm the output matches the spec” is the right obligation in the wrong tense: the output matches at a confidence level, under conditions, for now. Validate records distributions, promotes the highest-risk scenarios to monitors, and states a verdict. Converge re-reads the stream with regression deltas. Drift and incidents re-open Clarify and add evidence tasks.
3.9
What keeps intent legible across all four handoffs, at the level where boards and regulators ask the question?
Microsoft’s four handoffs are the Complexity Gap drawn as a process. The five evidence layers are the counter-measures drawn as a toolchain. Each handoff gets a carrier artifact and an arrival check. The spine is the thing that keeps intent legible across all four at once.