Cycle step 6 · /sdd validate

Validation — four axes, one verdict

Code that compiles is not necessarily code that works, and code that works is not necessarily code that honours the intent. SDD validation covers four axes — technical, functional, business, governance — and the code is never finished until the SPEC is synchronized (Drift Lock).

Axis 1 — Technical validation

The objective baseline: the project's toolchain, run in full and reported as a table. No judgement, just facts.

Axis 2 — Functional validation

The functional axis confronts the code with the SPEC's test cases, criterion by criterion — against the code itself, not only against the tests. Specified inputs respected, processing steps followed, output format produced, every edge case covered by a test, every acceptance criterion checked off. On the team side, functional validation is carried by the QA Engineer, and usability — UX, accessibility, performance — by QA together with the PM.

Axis 3 — Business validation

Business validation, carried by the Product Manager, asks the question tests do not ask: is the intent honoured, and are the targeted outcomes achievable? The Drift Criterion of the parent Intent is re-read: is the observable signal of intent betrayal absent? This is the axis where fidelity to the intent is checked — a semantic defect that no toolchain detects.

Axis 4 — Governance validation

The four Tier 1 agents — AIAD-AI-ACT, AIAD-RGPD, AIAD-RGAA, AIAD-RGESN — are applied via the regulatory-veto skill. Each holds a right of veto: a VETO blocks, a WARN requires a remediation plan before merge. This validation is not optional for the projects concerned.

Verification is designed, not bought

Doctrine v1.9 makes a bet: the quality of verification depends first on the design of the process — what is checked, when and by whom — rather than on the power of the model doing the review. This is a position, not a demonstrated result: the evidence converges, but no single piece is sufficient on its own. It translates into four rules.

Review exemplars

An organisation's review knowledge — what a senior reviewer spots and why — can be extracted into annotated examples, versioned in dedicated files (for example .aiad/review-exemplars/) and loaded only in review sessions — not in the AGENT-GUIDE, which is injected into every session and reserved for permanent instructions. Roblox described this practice in 2026. An exemplar is built from real reviews, revised like an artifact, and retired when it no longer reflects the team's standards.

Verification Tax

A 2026 literature review uses this name for the gap between the productivity gain in writing code and the much smaller gain in delivering reliable software. The term describes what the upfront investment in SPEC and Gate seeks to reduce. The team-side corollary: efficiency is not quality — a faster review is not a better review (see the role of the QA Engineer).

A composition of skills, with no duplication

/sdd validate is the most composite command of the cycle: it implements no logic of its own but composes three reusable skills — ears-validator (coverage of §3's testable criteria), drift-detection (code ↔ SPEC gaps on the diff) and regulatory-veto (the 4 Tier 1 standards). Each skill is also invoked elsewhere in the cycle (/sdd gate, /sdd drift-check, /sdd security…): the logic lives in one place, and the commands orchestrate it.

The verdict

The Human Learning / Lesson Learned distinction is essential for continuous improvement: the former documents a gap between human intent and delivery (the SPEC was the problem), the latter a recurring agent error (the execution was the problem). Both feed the AGENT-GUIDE.

Verdict: JNSP — validation impossible without a human decision
What is validated: <PASS axes>
What blocks: <undecidable areas with § ref>
Question(s) for the human: <actionable rephrasing>

The complementary roles — /sdd security and /sdd audit

Two audit commands extend validation for high-stakes features, with reports persisted in .aiad/metrics/: