#A.6.B:5.2 — Quadrant A: Admissibility & Gates

Preface node heading:a-6-b-5-2-quadrant-a-admissibility-gates:7114

#Content

Intent. Specify when a mechanism application is permitted/admissible: runtime entry predicates, authorization gates, validity gates, applicability checks that require context or execution environment.

Common mistake #0 — Applicability ≠ Admissibility (informative). Signature Applicability scopes intended use/bounded context; it is not a runtime entry gate. Runtime entry checks and permission predicates belong in U.Mechanism.AdmissibilityConditions as A-*. If your prose reads like “clients must satisfy the applicability”, you almost certainly want a D-* duty + an A-* gate (linked by ID) instead.

Adjudication. In‑work: evaluated at mechanism entry (or operationally at the point the mechanism is applied).

Canonical form. Predicate style, e.g.:

• “A request is admissible iff …”
• admissible(x) iff P(x) (conceptual form; no particular syntax is required)

Prohibitions.

• An A-* statement MUST NOT be placed in U.Signature.Laws.
• An A-* statement MUST NOT use RFC deontic keywords as if it were an agent obligation. (It is a gate predicate, not a duty.)
• An A-* statement MUST NOT claim that evidence exists (that is E-*) or that someone must enforce the gate (that is D-*).

A.7 anchoring. A-* claims are Descriptions of a mechanism gate. They are not “what a client must do”; they are “what the mechanism admits”.

Required references (explicit). If an A-* predicate relies on defined terms or invariants, it SHOULD reference the relevant L-* IDs (or at minimum the signature that defines them).