# Validation Gates
## Gate model
Each stage has a gate. A gate passes only when its checklist is complete. A failed gate routes work back to the smallest earlier artifact that caused the failure.
## G0 — Scope gate
Pass when:
- [ ] The RFC objective is stated.
- [ ] Public deliverables are named.
- [ ] Evidence artifact locations are named.
- [ ] Source corpus scope is known.
- [ ] Out-of-scope areas are listed.
Fail action: clarify scope before querying sources.
## G1 — Context gate
Pass when:
- [ ] Orientation context has been loaded or explicitly marked absent.
- [ ] Key concepts and vocabulary are listed.
- [ ] Known constraints are listed.
- [ ] Open questions are listed.
- [ ] Context-only claims are marked unconfirmed.
Fail action: repair the context packet before source scouting.
## G2 — Source authority mapping gate
Pass when:
- [ ] The mapping method matches the source profile for the run.
- [ ] Source-map queries are recorded when a map layer exists, or direct-source inventory and routing notes are recorded when it does not.
- [ ] Relevant source units and relationships are recorded.
- [ ] Source locators are available for every non-context-only claim path.
- [ ] Contradictions, stale results, and missing source areas are flagged.
- [ ] Missing source areas are assigned to scouts.
Fail action: refine the map or inventory, then dispatch narrower scouts where needed.
## G3 — Source scout gate
Pass when each scout report:
- [ ] Covers a bounded source area.
- [ ] Uses stable source IDs and locators.
- [ ] Separates direct evidence, inference, and uncertainty.
- [ ] Notes contradictions.
- [ ] Avoids drafting public RFC prose.
Fail action: request a narrower scout pass.
## G4 — Claim ledger gate
Pass when:
- [ ] Every candidate public claim has a ledger row.
- [ ] Each accepted row has source evidence or a design-decision ID.
- [ ] Public prose depends only on claims already present in the ledger.
- [ ] Inferred claims have reviewer approval.
- [ ] Open questions are not marked accepted.
- [ ] Rejected claims remain visible with reason.
- [ ] Claim rows map to planned RFC sections.
Fail action: repair evidence, reject the claim, or block drafting.
## G5 — Capability matrix gate
Pass when:
- [ ] Required behaviors, interfaces, concepts, and examples are represented.
- [ ] Each capability maps to accepted claims.
- [ ] Each required implementer capability names the public section, algorithm, state machine, or example that will deliver it.
- [ ] Gaps are marked scoped out, open, or blocking.
- [ ] Matrix rows identify affected RFC sections.
- [ ] No matrix row depends only on orientation context.
Fail action: fill the gap through source scouting or reduce scope explicitly.
## G6 — RFC skeleton gate
Pass when:
- [ ] Skeleton sections map to accepted claims.
- [ ] Normative sections have evidence coverage.
- [ ] Example slots point to example-lab tasks.
- [ ] Placeholder text is marked working-only.
- [ ] Public deliverable boundaries are clear.
Fail action: update the ledger or matrix before adding prose.
## G7 — Example lab gate
Pass when:
- [ ] Each public example has an example ID.
- [ ] Inputs and expected outputs are recorded.
- [ ] Validation method is recorded.
- [ ] The example is checked after rendering to public text, not only in source form.
- [ ] Actual result matches expected result or the failure is logged.
- [ ] Example behavior maps to accepted claims.
- [ ] Any byte-counted or binary payload example exercises a case that a naive line splitter would misread, so the counting rule is actually tested.
Fail action: correct the example, correct the claim, or remove the example from public text.
## G8 — Mechanical validation gate
Pass when checks find no unresolved failures for:
- [ ] Required sections.
- [ ] Unresolved placeholders.
- [ ] Unsupported normative keywords.
- [ ] Missing claim coverage.
- [ ] Broken section references.
- [ ] Terminology drift.
- [ ] Example/result mismatch.
- [ ] Public/evidence artifact separation.
- [ ] Literal grammar or operator characters that changed between source and rendered output.
- [ ] ABNF or other grammar inventories that no longer match the running text.
Fail action: log the failure and route to the earliest faulty artifact.
## G9 — Review gauntlet gate
Pass when all required reviews are complete:
- [ ] Source-grounding review.
- [ ] Capability completeness review.
- [ ] Example validation review.
- [ ] Security and IANA review.
- [ ] Spec-language review.
- [ ] Provenance-containment review.
- [ ] Adversarial ambiguity review.
A blocker finding fails the gate. A non-blocker finding must have a disposition.
Fail action: update the claim ledger, matrix, example set, or prose according to root cause.
## G9a — Reader on-ramp gate
Pass when:
- [ ] One reader report exists per target document.
- [ ] Each reader saw only that document's rendered public text.
- [ ] The report records first-loss point, unearned jargon, opening arc, abstract-standalone check, and verdict.
- [ ] No target document is `FAIL`.
- [ ] Every `SOFT-FAIL` has a fix-or-justify disposition.
Fail action: rewrite the opening, definition order, or teaching path in public prose, then re-run affected reader-facing gates.
## G9b — Prose-tell verification gate
Pass when:
- [ ] The current public draft has been audited as a heuristic de-tell pass, not as proof of authorship.
- [ ] The audit checks paired asides, antithesis frames, connective-stack prose, colon-then-elaboration rhythm, and rhetorical rule-of-three lists.
- [ ] Each flagged span records whether it is a wording defect or evidence that definitions, examples, or explanation are missing upstream.
- [ ] Legitimate spec punctuation, real contrasts, and structurally necessary lists are explicitly allowed and dispositioned.
- [ ] No unresolved high-density tell cluster remains in public prose.
Fail action: revise the public prose, or if tell-heavy wording is hiding a missing input, reopen the earliest faulty artifact.
## G10 — Recursive correction gate
Pass when each correction:
- [ ] Names the failed gate.
- [ ] Names the root artifact.
- [ ] Updates the earliest faulty artifact first.
- [ ] Propagates forward to dependent artifacts.
- [ ] Re-runs only the affected gates.
- [ ] Records final disposition.
Fail action: stop prose editing and repair the correction log.
## G11 — Clean-room proof gate
Pass when a fresh reviewer using only the permitted public packet can:
- [ ] State the document purpose.
- [ ] Identify normative requirements.
- [ ] Replay required implementer capabilities from the cited public sections, algorithms, or examples.
- [ ] Apply examples correctly.
- [ ] Explain edge cases.
- [ ] Avoid relying on hidden evidence artifacts.
- [ ] Identify no blocking ambiguity.
Fail action: revise the public RFC for clarity, then re-run affected validation and review gates.
## G12 — Final packaging gate
Pass when:
- [ ] Public RFC deliverables are complete.
- [ ] Evidence artifacts are complete.
- [ ] The public manifest excludes evidence-only files.
- [ ] The evidence manifest preserves the proof chain.
- [ ] Every required implementer capability still points to public text that actually delivers it.
- [ ] Open questions are excluded or explicitly scoped.
- [ ] No blocker findings remain.
- [ ] Any remaining human decision is captured in the escalation log or removed from the public dependency chain.
- [ ] The promotion target is explicit.
Fail action: do not promote. Return to the failed gate.
## Recursive correction rule
When a gate fails, do not patch only the visible symptom. Find the earliest artifact that introduced the bad claim, missing evidence, weak example, or ambiguous wording. Correct that artifact, then regenerate or update downstream artifacts in order.