Cycle step 4 · /sdd gate

Execution Gate — SQS ≥ 4/5 or nothing

The Execution Gate is the checkpoint between a written SPEC and launching the agent. The rule is simple and admits no exception: no code before the Gate is open. The Spec Quality Score (SQS) must reach 4/5, and the Stranger Test must be documented.

Why a gate before the code

Handing a mediocre SPEC to an agent does not save time — it wastes it. Fixing a SPEC takes ten minutes; fixing code generated from a bad SPEC takes hours. The Gate embodies that economic trade-off: it forces the investment where the ROI is highest, before the first line is generated.

The Gate is run by the sqs-scoring skill, fed by ears-validator. Three possible outcomes: OPEN, CLOSED (with a remediation plan) — or UNKNOWN when the score is undecidable.

Doctrine v1.9 clarifies the Gate's place in verification: the critical conversation happens first at the Execution Gate. That is where you discuss what you want; code review then checks conformity with an intent already discussed. Review remains the place where you detect what was misunderstood, not where you discover what you wanted (see Validation). In the authority continuum, opening the Gate is the human act that validates the SPEC — it does not authorise deployment.

The five Spec Quality Score criteria

Each criterion is worth 0 or 1 point. Score ≥ 4/5: the Gate opens and the SPEC moves to ready status. Score < 4/5: back to revision with a remediation plan that is a deliverable in its own right — proposed replacement text and estimated effort, criterion by criterion. Two special routes: Atomicity at 0 → /sdd split; three consecutive failures → go back to /sdd intent, the problem is upstream.

Criterion 6 — the Stranger Test

A sixth, non-scorable criterion completes the checklist: "If I showed this SPEC to someone who doesn't know the project, would they understand why we are doing it?" It does not block the Gate if the answer is negative, but the question must be asked, and the answer — two sentences at most, written by a human — added to the SPEC before continuing:

## Context for an outside reader
[Two sentences. Written by a human. Before the Execution Gate.]

It is the Feynman principle applied to specifications: you only truly understand something when you can explain it simply. If the two sentences are impossible to write, the human context is insufficient — go back to the Intent Statement before continuing.

Strict EARS mode

When the SPEC declares Format : EARS in its header (see the EARS variant), the ears-validator linter switches to strict mode and mechanically affects criterion 2:

In prose format, the linter remains advisory: it flags ambiguities without altering the score.

UNKNOWN Gate — the SQS fail-closed

When one or more criteria are not scorable — testability impossible to judge without a known test stack, consistency unverifiable because a dependent SPEC is unreadable, atomicity undecidable because the parent Intent is unstated — the Gate exits neither OPEN nor CLOSED: it exits UNKNOWN, with a ?/5 score. This is a JNSP state (Je Ne Sais Pas — "I don't know") and it is fail-closed: no agent execution may start.

Gate: UNKNOWN (JNSP verdict)
SQS: ?/5
Non-scorable criteria:
  - Criterion 2 (Testability): reason = <what prevents scoring>
  - Criterion 4 (Consistency): reason = <what prevents scoring>
Question for the human: <actionable question>

Irreversible actions and credentials: what the Gate also checks

As soon as a SPEC involves an irreversible agent action, or an agent holding credentials or write access to a shared resource, the SQS is no longer enough. The Gate also checks, based on the "Agent execution scope" section of the SPEC and the Drift Criterion of the Intent Statement:

• the autonomy cap, documented and technically enforced — an instruction in a prompt is not a limit;
• the prior human authorisation of each irreversible action, by an identifiable person;
• the stop threshold: any observed overreach of autonomy halts the agent and triggers an immediate human review;
• the execution scope: isolation, network egress, credentials present, shared resources with write access.

No delegation of an irreversible effect without a documented cap and a rollback procedure: this is the "Agents with irreversible effects" profile of AIAD-AI-ACT. Details on the Agent autonomy page.

The deterministic gate-precheck — upcoming release, not yet published

The next release of the aiad-sdd package, not yet published, adds the npx aiad-sdd gate-precheck <SPEC> command, run by /sdd gate before any SQS scoring. It reads the "Agent execution scope" section and computes its verdict outside the model:

Only a structured declaration can close the Gate: keywords in prose only produce a warning, so that existing SPECs do not regress.

Preparing the Context Engineering Budget

If the Gate opens, it does more than rubber-stamp the SPEC: it prepares the Context Engineering Budget of the upcoming agent session — the list of files to inject, the estimated token total, and a check against a cap of about 50K tokens per session — an assumed sobriety heuristic, not sourced, not a technical limit; the documented operational threshold remains 60-70% of the available window. The budget is then re-verified at launch by /sdd exec.

Empirical validation

The Execution Gate is not a comfort ritual: it answers a measured bias. SOTA agents exhibit an action bias of 35 to 65% — the tendency to produce code rather than flag that a requirement is ambiguous or infeasible. The Gate imposes the human stopping point the agent does not impose on itself. The evidence synthesis is consolidated in docs/legitimation/execution-gate-evidence.md.