Reference
Glossary — the vocabulary of SDD Mode
Every term of the framework, sorted alphabetically — from the founding vocabulary (Intent Statement, SPEC, Drift Lock) to the notions of the AIAD doctrine up to v1.9 (agent autonomy, verification, inherited context) and those introduced by the aiad-sdd software from version 1.7 to version 1.19 (routers, skills, JNSP, EARS, machine-verifiable traceability, Research Phase).
A
- Agent with irreversible effects (financial, operational, physical)
- Formerly "agent with financial and operational autonomy". An AI agent authorised to trigger effects that cannot be undone: payment, purchase, contractual commitment, deployment, permanent deletion, action on physical equipment. This profile requires the autonomy ceilings to be validated at the Execution Gate, a reversibility class and a stop threshold in the Drift Criterion, and falls under AIAD-AI-ACT (delegation, ceiling, evidential log, rollback, isolation). Not to be confused with a code-generation agent that has no irreversible external effect. See Agent autonomy.
- AGENT-GUIDE
- The agent's permanent context: absolute rules, project conventions, Lessons Learned, Human Learnings and governance cross-references. Injected in condensed form (max 500 tokens) into every session. Since
aiad-sdd1.12, it is the upstream source of the multi-runtime rules emitted byemit-rules. See the artifacts. - Anti-Drift Check
- End-of-iteration ritual verifying artifact / code synchronisation across the whole project — the periodic application of the Drift Lock. For each SPEC used, three questions: does the delivered behaviour match the SPEC exactly? Is the list of impacted files exhaustive? Does the Drift Criterion of the parent Intent flag a gap? Command:
/sdd drift-check. - ARCHITECTURE
- The technical-standards document: stack, patterns, structural decisions. Injected condensed (~500 tokens) into every agent session — never in full. Written with the
/sdd archassistant. - Art. 22 GDPR — automated decisions and agents
- An agent that alone decides an effect that significantly affects a person — access to a service, scoring, sanction, exclusion — falls within the scope of Article 22 of the GDPR. AIAD-RGPD (v1.9) only recognises human intervention that is real, not nominal: effective power to overturn, competence and authority, sufficient information, time-stamped trace. Precedent: a €824,990,000 fine imposed on Uber by the Dutch data protection authority on 21 August 2026 (Art. 22 and failure to inform) — Uber has appealed. See Governance — AIAD-RGPD.
- The application of the Human Authorship value (doctrine v1.9) as five levels — consultation, clarification, SPEC validation, write authorisation, deployment authorisation. Each step from one level to the next is a distinct human act that no other act can replace: "Answering is not consenting" — answering the agent's questions does not authorise any code to be written. See Agent autonomy.
C
- Cognitive debt
- Term (Fowler / Joshi, 2026): the accumulation of code whose implementation the team accepts without understanding the underlying conceptual model. SDD Mode prevents it through spec-first work and the Human Learnings. Not to be confused with technical debt (code quality): cognitive debt is about understanding.
- Context Engineering Budget
- The context-absorption capacity of an agent session, owned by the Product Engineer. Rules: one session = one objective, a single active SPEC, 60-70% of the window as the effective maximum, Intent and SPEC at the top of the context. Since doctrine v1.9: a delegation to a sub-agent that inherits the conversation costs the inherited context on top of its own work — delegate early — and every capacity or price assumption is dated. Audited by
/sdd context. See the Context Engineering Budget article. - Context Rot
- Quality degradation of an LLM before the theoretical limit of its context window: less precise answers, forgotten SPEC constraints, repetitive behaviour. Justifies the 60-70% operational threshold and the SPEC as a stable anchor point.
D
- Digital Omnibus on AI — Regulation (EU) 2026/1744
- Adopted regulation, published in the Official Journal on 24 July 2026 and in force since 27 July 2026, amending the AI Act (as well as Regulations 2018/1139 and 2023/1230). Timeline: transparency obligations (Art. 50) in force since 2 August 2026 (grace period until 2 December 2026 for Art. 50(2), only for systems placed on the market before 2 August 2026); new Art. 5 prohibitions (non-consensual intimate images, child sexual abuse material) applicable on 2 December 2026, with no grace period; Annex III high-risk systems on 2 December 2027 and Annex I on 2 August 2028. See Governance — AIAD-AI-ACT.
- Discovery
- Mandatory exploration of the real code during the Research Phase: the viability of an intent is verified in the repository, not in an abstract discussion. The
discovery-gate.jshook checks this prerequisite before/sdd specand/sdd exec. - DoOD — Definition of Output Done
- The completion criteria of a task, defined in the SPEC: code, tests, synchronised artifacts. Updating the SPEC is part of it — merged code with an out-of-sync SPEC is not done.
- DoOuD — Definition of Outcome Done
- The value-oriented counterpart of the DoOD: a feature is only truly "done" when the outcome targeted by the Intent is observed among users — not merely when the code ships.
- DORA Metrics
- The 4 delivery-performance indicators from the DORA programme: Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR. Computed organically by
/aiad dorawith an Elite / High / Medium / Low rating. See Metrics — DORA. - Drift Lock
- PR policy: the code and the corresponding SPEC are synchronised in the same PR. A PR without a synchronised SPEC does not meet the Definition of Done. Step 7 of the cycle, enforced by the pre-commit hook and by the traceability matrix in CI. See the Drift Lock article.
E
- EARS — Easy Approach to Requirements Syntax
- Optional SPEC-writing variant (
aiad-sdd1.11): SHALL requirements with WHEN / WHILE / IF / WHERE triggers. Enabled by/sdd spec --ears, strictly linted (rules R1-R7) at the Gate: 0 violations → guaranteed +1 on the SQS Testability criterion; ≥ 1 violation → criterion forced to 0. Reserve it for SPECs where ambiguity is expensive — security, payments, compliance, API contracts. - Execution Gate
- Checkpoint between the SPEC and the agent launch: no code before the Gate opens, that is SQS ≥ 4/5, the Stranger Test answered and the Context Engineering Budget prepared. As soon as an action is irreversible or the agent holds credentials, the Gate also checks the ceilings, the stop threshold and the execution perimeter. It is at the Gate that the critical conversation about what we want takes place first. Command:
/sdd gate; a deterministic pre-check before the SQS (aiad-sdd gate-precheck) is announced for the next release — upcoming. See the Execution Gate & SQS article. - Execution perimeter (agent)
- Conditional SPEC section "Agent execution perimeter" (doctrine v1.9), required as soon as the agent holds credentials or write access to a shared resource — "Not applicable" otherwise: isolation level, allowed network egress, credentials present, shared resources writable, including intended coordination spaces. Principle: containment is judged on the shared surface, not agent by agent. The package's SPEC template adds a "Stop threshold" line to it. See Agent autonomy.
F
- Fail-closed
- The governance uncertainty policy: when a Tier 1 agent cannot decide, the
UNKNOWNverdict counts as a VETO. Block by default rather than let things through — never any silent self-clearance. See Governance. - Flow Metrics
- The 5 value-stream health indicators: Cycle Time, Lead Time, Throughput, WIP, Flow Efficiency. Computed by
/aiad flow, with a Lead Time breakdown to locate the bottlenecks. See Metrics — Flow.
G
- GO / CONDITIONAL GO / DEFER / NO-GO
- The graduated verdict of the Research Phase on the viability of an intent: viable (GO), viable under explicit conditions (CONDITIONAL GO), to be postponed (DEFER), not viable (NO-GO). The verdict is decided by the human — the agent prepares the case, it does not rule. See Research Phase.
- Governance AGENT-GUIDEs
- The 4 Tier 1 regulatory guides holding veto power: AIAD-AI-ACT, AIAD-RGPD, AIAD-RGAA, AIAD-RGESN. The
aiad-sddpackage also ships, as a complement, an AIAD-CRA agent (Cyber Resilience Act) for software products. Details on the Governance page. - Governance gap
- The gap between the massive adoption of agentic harnesses — the 2026 Gartner Magic Quadrant projects 30 to 50% productivity gains by 2028 — and the absence of governance of human intent, which these proprietary harnesses do not address: they optimise "how to generate", not "who wanted what, and who validates". AIAD positions itself as the meta-framework that fills this gap. See Values & pillars.
H
- Harness Engineering
- The Agents Engineer's core practice: configuring, supervising and governing the agents under the minimal necessary permissions principle. Protection rests on isolation, not on the harness's permission mode. Audited by
/sdd security. - Value 7 of the framework: authorship of intent cannot be delegated. Every Intent Statement is written by an identifiable human — if an agent wrote it, the session is invalidated. Applied since v1.9 as the authority continuum. Checked by the
human-authorship-checkskill. See the Human Authorship article. - Human Learnings
- The AGENT-GUIDE section documenting failures of human intent — what the human expressed, calibrated or communicated poorly, independently of the agent's behaviour. Maintained by the PE and/or PM, reviewed at the Intent Workshop; entries can be categorised according to the 7 forms of misalignment of the Tang et al. (2026) taxonomy, and oversight failures form a category of their own. Not to be confused with Lessons Learned, which document the agent's errors.
I
- Inherited context
- The part of a sub-agent's context that comes from the parent conversation at the time of the fork, when the harness makes the sub-agent inherit the conversation (Claude Code's default behaviour since August 2026). The cost of a delegation is then parent context at the fork + own work: delegate early, while the parent context is still light. If inheritance is disabled, the sub-agent must be given the Intent Statement and the active SPEC explicitly. An "Inherited context (delegations)" line in the
/sdd contextaudit is announced for the next release of the software — upcoming. - Intent Statement
- First-order artifact capturing the human WHY in 5 fields: WHY NOW, FOR WHOM, OBJECTIVE, CONSTRAINTS, DRIFT CRITERION — the latter specifying, when agent actions have effects outside the code, their reversibility class and stop threshold. Human author mandatory, archived in
.aiad/intents/. See the Intent Statement article. - Intent Workshop
- Monthly ritual (60 min max) asking the question: "are we still building what we wanted?". A purely human space — AI agents play no role in it, not even an automatic summary. Prepared by
/aiad intention, never facilitated by it. See Loops & rituals. - Interrogatory LLM
- Pattern (Fowler, 2026) in which the agent builds the context by questioning the human with targeted questions, rather than passively receiving a prompt or guessing the intent. Implemented by
/sdd intent.
J
- JNSP — "Je Ne Sais Pas — I don't know"
- Uncertainty verdict (EN equivalent:
UNKNOWN): a valid signal, not a failure. The agent issues it when an area is undecidable — intent with no identifiable human, untestable criterion, ambiguous governance, missing@specannotation. In code:TODO-JNSP:, blocked by the pre-commit hook until resolved. CLI exit code:2. See the JNSP article.
L
- Lessons Learned
- The AGENT-GUIDE section documenting the agent's recurring errors (at least 2 occurrences on different tasks), collected at the retrospective. Not to be confused with Human Learnings.
O
- Oversight failures
- A separate category of Human Learnings (doctrine v1.9): the cases where human oversight was absent or had become nominal — an agent acting without approval, automated reviews stacked on top of one another with no human to decide. Question asked at the retrospective: at what point should a human have been consulted, and why were they not?
P
- Permission mode (is not a control)
- A harness setting — manual approval, automatic classifier, allow-lists — that reduces friction without constituting an enforceable guarantee. Doctrine v1.9 principle: a permission mode is not a control. Protection rests on isolation (container or virtual machine, restricted network egress, no superfluous credentials); the permission mode comes as a complement, never as a substitute. See Agent autonomy.
- PRD — Product Requirement Document
- The product source of truth: vision, users, outcomes. Injected only during the framing phase, never during development. Written with the
/sdd prdassistant. - Product Engineer (PE)
- Guardian of intent throughout the cycle: orchestrates AI agents to realise the intent without betraying it, and owns the Context Engineering Budget of every session. See The 5 responsibilities.
R
- R2Code
- arXiv study (April 2026) empirically validating the spec-first approach: −41.7% tokens consumed and +7.4% fidelity of the generated code for spec-anchored sessions compared with sessions without a specification. The empirical reference for the economic argument of the Context Engineering Budget.
- REASONS Canvas
- Optional SPDD tool (Kevlin Henney) for structuring the justification of a SPEC before the standard AIAD format — offered by
/sdd specwhen the Intent is complex or ambiguous. Associated skill:reasons-canvas. - Research Phase
- Step 2 of the cycle (
/sdd research), inserted between the Intent and the SPEC: it validates the viability of the intent grounded in the code (mandatory Discovery), not the quality of the SPEC. Graduated verdict GO / CONDITIONAL GO / DEFER / NO-GO. Proportionate: it can be explicitly short-circuited (and traced) for a trivial intent. See Research Phase. - Reversibility class
- Qualification of an agent action according to whether it can be undone: reversible (at no cost), costly to reverse (with a loss: money, time, restoration), irreversible (cannot be undone). Declared in the Drift Criterion of the Intent Statement as soon as an action has effects outside the code; the irreversible class requires a stop threshold (doctrine v1.9). See Agent autonomy.
- Review exemplars
- An organisation's review knowledge — what a senior reviewer spots, and why — extracted as annotated examples, versioned in dedicated files (for instance
.aiad/review-exemplars/) and loaded only in review sessions, never in the AGENT-GUIDE. Optional (doctrine v1.9); they are built from real reviews and retired when they no longer reflect the team's standards. - Router
- Command-namespacing mechanism introduced by
aiad-sdd1.7: the commands are grouped under 3 routers —/sdd <sub>,/aiad <sub>,/aiad-help— that is 33 commands today (17/sdd+ 16/aiad). Sub-command bodies are loaded on demand, cutting the cold-loaded frontmatter by 94%. See /sdd commands.
S
- /sdd audit
- Code-quality audit command: SPEC conformance, technical debt introduced, consistency with the AGENT-GUIDE. Reports persisted in
.aiad/metrics/audit/. - /sdd fact
- Command for capturing and qualifying a delivered/desired gap without a full Intent cycle — produces a Technical Fact in
.aiad/facts/. - /sdd security
- Security audit command: OWASP Top 10, secrets management, agent permissions (Harness Engineering), AI-ACT / RGPD compliance. Reports persisted in
.aiad/metrics/security/. - Skill
- Reusable, auto-triggered block of logic (introduced by
aiad-sdd1.9), stored in.claude/skills/. The package ships 9 of them:human-authorship-check,regulatory-veto,drift-detection,sqs-scoring,context-budget,reasons-canvas,ears-validator,traceability,grill-me(interactive gate). Complex commands compose several skills without duplicating their logic. - SPEC
- Detailed technical specification of an atomic task: scope, interface, behaviour, edge cases, tests, drift criterion. A single active SPEC per agent session. Prose or EARS format. Doctrine v1.9 adds two sections: "Agent stop points" (optional) and "Agent execution perimeter" (conditional). See the SPEC article.
- Spec-Anchored
- AIAD's positioning: the SPEC is maintained as a permanent anchor, synchronised with the code on every PR. Neither spec-first (spec discarded after the task), nor spec-as-source (spec that generates the code).
- Spec Drift
- Gap between the state of a SPEC and the actual state of the code. Treated as a process failure, not an agent error — detected by the
drift-detectionskill and the Drift Lock. - SQS — Spec Quality Score
- Quality score of a SPEC on 5 criteria (atomicity, precise interfaces, testability, non-ambiguity, defined scope) completed by the Stranger Test. Gate threshold: ≥ 4/5; an unscorable criterion produces
?/5and an UNKNOWN Gate. The SQS assesses the agent's input, not the code produced. See Metrics — SQS. - Stop points (agent)
- The moments when the agent must come back to the human, following a typology drawn from Ethan Mollick (2026): request an approval (before an action outside its mandate or an irreversible one), an expert opinion (when the decision goes beyond the SPEC), a plurality of viewpoints (when several interpretations of the intent are plausible), or make the human a witness to a notable decision. Optional SPEC section "Agent stop points". See Agent autonomy.
- Stop threshold
- Condition set in the Drift Criterion for any action of the irreversible class (doctrine v1.9): any observed overrun of autonomy — spending beyond the ceiling, action outside the delegated scope, an attempt to hide or alter its own traces — triggers the immediate stop of the agent and a human review, not an after-the-fact report. Providers' billing alerts do not fulfil this role: they can lag by up to 24 hours. See Agent autonomy.
- Stranger Test
- Criterion 6 of the SQS, non-scorable: "If I showed this SPEC to someone who does not know the project, would they know why we are doing it?". The answer, in two sentences at most written by a human, is documented in the SPEC (section "Context for an outside reader") before the Gate. A negative answer does not close the Gate, but signals insufficient human context: go back to the Intent Statement.
T
- Technical Fact
- Artifact of
/sdd fact: the capture of an observed gap between delivered and desired behaviour, with an impact qualification (functional / security / performance / compliance) and a corrective-action decision traced in.aiad/facts/FACT-NNN.md. - Tier 1
- The highest level in the governance-agent hierarchy — just below the AIAD Constitution. The 4 Tier 1 agents (AI-ACT, RGPD, RGAA, RGESN) hold a veto right over any non-compliant SPEC or implementation, with a fail-closed policy. See Governance.
- Traceability —
@intent,@spec,@verified-by,@governance - Machine-verifiable Intent ↔ SPEC ↔ Code ↔ Tests matrix (introduced by
aiad-sdd1.10), built from the annotations placed in the code:@intent INTENT-NNN(0..1),@spec SPEC-NNN-N-slug(1..n, mandatory on all application code),@verified-by(path to a test, 0..n),@governance(Tier 1 frameworks, 0..1). Generated by/sdd traceornpx aiad-sdd trace; thesdd-trace.ymlGitHub Action fails the PR on a blocking gap (--fail-on-gap). See the Traceability article.
V
- Verification Tax
- Term from a 2026 literature review: the gap between the productivity gain when writing code and the much smaller gain when delivering reliable software. It describes what the upstream investment in the SPEC and the Execution Gate seeks to reduce. See Validation.
- Vibe coding
- Term (Fowler, after Karpathy, 2026) for delegating code to the AI agent without human validation — the author accepts the implementation without examining it. This is what the Human Authorship value prevents; Fowler contrasts it with "serious agentic programming". Not to be confused with deliberate, throwaway rapid prototyping: vibe coding becomes a problem when unvalidated code reaches production.
Missing a term?
The glossary tracks the framework's evolutions. /aiad-help <keyword> finds the related command or concept directly from your agent; the reference source remains aiad.ovh.