← Back to the RFC register
WEKID-RFC-008 The core Open

Gate Class Taxonomy and the High-Stakes Judgment Gate

Cross-layer
Stage
 Public comment
Governance surface
The core
Type
Standards-track
Proposed by
Jim Judge
Target release
WEKID-STD-001 v1.2

Abstract

This RFC proposes two provisions. The first defines hard and soft gate classes in §9.1, assigns Data Integrity and Fabrication to the hard class and High-Stakes Judgment to the soft class, and permits a calibration profile to tighten a soft gate to hard but never the reverse. The second amends the five clauses, two headings and one conformance row in which the word “hard” was doing the work of “gate” because v1.1 had no second class — including the third core invariant of §2.2. The second provision is not tidying: without it the amended Standard would contradict itself, and the first provision should not be adopted alone.
The classification is not imported. §7.1 already qualifies the AL-0 consequence as applying to “hard-gated” outputs, and §4.2 already lists “constrain an Authority Level” as a gate effect distinct from blocking. The distinction is present in v1.1 in the two clauses that state what gating does; what is missing is the definition tying them to the §10.1 condition that invokes it. The RFC does change resolved outcomes in a defined class of case, which §5.3 discloses and §7 puts to comment.

WEKID-STD-001 v1.1 §9.1 states the High-Stakes Judgment Gate’s effect as “cap total score at 60/100 and require constrained/human review as applicable”. §10.1 resolves any triggered hard gate to AL-0 — reject or block. An output that is rejected is not one under constrained review, so the two cannot both be read literally. Separately, §10.1’s 50–69 row triggers on “Maturity Score 50–69 or soft gate”, and no soft-gate class is defined anywhere in the Standard.

Evidence base

The Standard should change because §9.2 makes determinism a conformance requirement — the same inputs under the same versioned profile SHALL produce the same Authority Level — and on this gate the text does not permit it. Two careful readers reach AL-0 and AL-1 respectively, and neither is being careless.
The change belongs to the Core surface. Gate classification governs how the two models interact at the Trust Bridge and how §9.2 precedence treats a triggered condition. It cannot be delegated to a calibration profile: a profile may tighten what the framework establishes, but it cannot supply a baseline classification the framework never set, and the protected core of STD-002 Provision 3 forbids a profile from relaxing a gate in any case.
Now, rather than later, because no ratified sector profile yet exists. A profile ratified against the current text would have to choose a reading and then be reopened when the Standard settles the question — reopening a profile means re-running the calibration lifecycle from Phase 2 under STD-002 Provision 10. Fixing the baseline before the first working group completes Phase 10 avoids that entirely.
Scope. This RFC addresses gate classification and the clauses that the classification makes ambiguous. The conservatism tie-break for competing precedence conditions is WK-CORE-RFC-003; the overseer-engagement decay outcome is WK-CORE-RFC-004; the verdict-contract fields recording which determinant bound are WK-CORE-RFC-006. Each is separable and none depends on this one. It is submitted third of the four because it is the only proposal in the set that changes a resolved outcome, and the Council should reach it having already settled the two questions that carry no such cost. Placing it third is a matter of the author’s sequencing rather than of dependency: it may be adopted, deferred or rejected without affecting the others.

The evidence is the text of WEKID-STD-001 v1.1. The contradiction is demonstrable by reading §9.1 and §10.1 together; the undefined class is demonstrable by searching the Standard for any definition of “soft gate” and finding the term only in the §10.1 row that invokes it.
Both were surfaced during a systematic build of the eighteen-module WEKID Training Programme against the ratified Standards. Writing examinable material exercises a specification differently from review reading: a clause two competent readers resolve differently cannot be taught, and the courseware must either choose a reading or present both and declare the Standard divided. Modules 6, 10 and 16 currently do the latter for this defect.
Two further clauses, identified in a clause-level audit of every normative use of the word “gate” in v1.1, show the distinction already present in the text. §7.1 qualifies the AL-0 consequence as applying to “hard-gated” outputs, a qualifier that is redundant unless a non-hard gated output exists. §4.2 lists “constrain an Authority Level” as a gate effect distinct from “block an output”. Neither clause was drafted as part of a taxonomy, and that is the point: the drafters reached for the distinction twice without naming it, in the two clauses where the consequence of gating is stated.
The same audit established the scope of provision 4.2. Every normative clause in v1.1 containing the word “gate” was examined against the proposed taxonomy; five narrow improperly once a second class exists, two headings become misnomers, one conformance row needs a sibling, and two clauses are correct as written. That enumeration is reproduced in §4.2 and is the material the working group should check first, since an error there is an error in the amended Standard rather than in this document.
Supporting material available to the working group:
• The findings register, items S2 and S3, with clause references and the modules that surfaced them.
• The cap-to-band mapping in §2.4, showing that three distinct caps produce two band outcomes.
• The clause-level audit underlying §2.6 and provision 4.2: every normative use of “gate” in v1.1, classified as widen, retitle, add, or leave.
• Module 6 of the training programme, which teaches both readings verbatim and names the divergence.

Where this proposal stands

  • Proposed · 2026-09-21 00:09:55
    Submitted by Jim Judge
  • Triaged · 2026-09-21 00:10:12
  • Working-group review · 2026-09-21 00:10:19
  • Public comment · 2026-09-21 00:10:43
  • Council decision
  • Versioned release

Public comment

Open until 2026-10-20 20:10:43. Comments are reviewed before they appear.

Every proposal moves through the same six-stage pipeline. See how the RFC process works.