gate-classification

name	gate-classification
description	Use when reasoning about which pipeline gates may run unattended and which need a human. Classifies every gate as verification (checks reality — always autonomous) or judgment (needs a human call — front-loaded or escalated per soe:soe-modes). Reference from the orchestrator and any skill that decides whether to ask the human or resolve-and-log.

gate-classification — verification vs. judgment gates (design §3.3)

Every gate in the soe pipeline is one of two kinds. Knowing which kind a gate is tells you whether it can run unattended. This is what lets soe run the execution loop autonomously without losing discipline: the disciplined checks (TDD, review, evaluators, verification-before-completion) never depend on a human being present, and only the genuinely-human calls are gated on the human.

The rule of thumb: ask "who is being asked for evidence?" If the gate asks the agent for evidence (tests, a diff, a review verdict), it is a verification gate. If it asks the human for a judgment (a direction, an approval, an ambiguity resolution), it is a judgment gate.

Verification gates — check reality (ALWAYS autonomous)

A verification gate checks a fact, not an opinion. It runs a test, inspects a diff, or renders a reviewer verdict against explicit criteria. There is nothing to ask a human, so these run autonomously in every mode — they ask the AGENT for evidence, never the human.

Members:

• TDD red/green — soe:test-driven-development (watch the test fail, then pass).
• Verification before completion — soe:verification-before-completion (run the commands, confirm the output, before any success claim).
• Code review — soe:requesting-code-review and soe:receiving-code-review (dispatch a reviewer; evaluate the verdict on technical merit).
• The evaluators — soe:eval-code-quality, soe:eval-integration, soe:eval-business-logic (score the work product against criteria).

If a "gate" is one of these, do not gate it on mode. It runs.

Judgment gates — need human judgment (front-load or escalate)

A judgment gate is a point where the engine could defer to a human: there is a real choice with no ground-truth to check. These are handled per soe:soe-modes — front-loaded into interactive setup where possible, and otherwise escalated or resolved-and-logged according to the active mode.

Members:

• Brainstorming — soe:brainstorming (explore intent and shape the design; needs the human's goals and approval).
• Spec / plan approval — soe:writing-plans (choosing and approving a plan direction).
• Adversarial review — the board's accept/reject conditions (soe:board-of-directors): accepting or overriding a board condition is a call, not a fact.
• Genuine ambiguity (clarify-first) — soe:intent-driven-development (when a requirement is genuinely ambiguous, clarify with the human before proceeding rather than silently guessing).

How this interacts with soe:soe-modes

soe:soe-modes selects how much the engine asks the human, and it changes behavior at judgment gates only:

• Verification gates run autonomously in all three modes (autonomous-guardrailed, interactive, fully-agentic). Mode is irrelevant to them — they verify facts.
• Judgment gates are mode-dependent. They are front-loaded into interactive setup (brainstorm / plan / review) so the execution loop can then run unattended; where a judgment call still arises mid-loop it is asked, escalated, or resolved-and-logged per the active mode.

The orchestrator (soe:soe-orchestrator) applies this by classifying each gate with this skill first — verification → run; judgment → hand to soe:soe-modes.

Red flags (stop and correct)

• Gating a verification gate (TDD, review, evaluators, verification-before-completion) on mode, or pausing it for a human.
• Treating a judgment gate (brainstorm, plan approval, board condition, genuine ambiguity) as if it were a fact the agent can just verify — silently guessing instead of front-loading or escalating.
• Classifying a gate ad-hoc instead of by the "who is asked for evidence?" test.