FPF Reference

    A.6.B:5 — Quadrant specifications

    Preface node heading:a-6-b-5-quadrant-specifications:8840

    What this page is

    This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

    Methodology

    Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

    Content

    This section is the normative “API” of the square: what each quadrant is for, how it is written, and what it must not contain.

    A.6.B:5.1 — Quadrant L: Laws & Definitions

    Intent. State truth‑conditional content: definitions, invariants, typing and well-formedness constraints, equational laws.

    Adjudication. In‑description: can be checked by inspection, proof, type validation, or model reasoning.

    Canonical form. Definition: / Invariant: / predicate‑style constraints using “is / iff / for all”.

    Prohibitions.

    • An L-* statement MUST NOT contain RFC deontic keywords (MUST, SHALL, SHOULD, or MAY) as operators inside the law or definition itself.
    • An L-* statement MUST NOT encode runtime gate predicates (those are A-*).
    • An L-* statement MUST NOT assert evidence availability or measurement outcomes (those are E-*).

    A.7 EntityOfConcern binding. L-* claims are Descriptions: they specify semantics of the signature or mechanism description, not work.

    Typical dependence. A-* and E-* claims may reference L-* IDs for vocabulary, metric definitions, and invariants needed for interpretation.

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

    Intent. Specify when a mechanism application is 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 and bounded context; it is not a runtime entry gate. Runtime entry checks and admissibility 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 EntityOfConcern binding. 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).

    A.6.B:5.3 — Quadrant D: Deontics & Commitments

    Intent. State governance: obligations, governance conditions, exclusions, commitments, publication duties, operational duties, contractual commitments—always with accountable role assignments, role values, or admitted acting systems.

    Adjudication. In‑description (governance is stated in the spec); compliance may be audited via E-*.

    Canonical form. A deontic statement MUST have an accountable subject (role assignment, U.Role, or admitted acting system), e.g.:

    • “Client implementers MUST satisfy A-….”
    • “Operators SHALL retain carriers …”
    • “Provider SHALL meet E-… under exclusions …”

    Canonical payload (recommended; lintable). When a D-* claim is intended to be lintable and reusable, it SHOULD be representable as a U.Commitment record (A.2.8). Default fields to make explicit:

    • id (often the D-* claim ID),
    • subject (accountable role assignment or party; never an episteme),
    • modality (BCP‑14/RFC keyword family normalized),
    • scope + validityWindow,
    • referents (by ID; e.g., SVC-*, L-*, A-*, E-*, MethodDescriptionRef(...)),
    • optional adjudication.evidenceRefs when the commitment is meant to be auditable,
    • optional source when authority or provenance matters.

    Prohibitions.

    • A D-* statement MUST NOT use “the system, service, interface, or specification” as the grammatical subject unless the accountable role assignment or admitted acting system is explicitly named (so the statement is representable as a U.Commitment with an explicit subject, A.2.8). Use A.6.C when contract, promise, utterance, or agreement-like boundary language is live.
    • A D-* statement MUST NOT restate L-* or A-* predicates in new words when an ID exists; it SHOULD reference the ID.
    • A D-* statement MUST NOT pretend that commitments are laws. A commitment is an agent relation, not a truth‑conditional invariant.

    A.7 EntityOfConcern binding. D-* claims are primarily about Objects (accountable role assignments or admitted acting systems and their duties) or about Carriers (retention and exposure duties), but they are still written as Descriptions.

    Required references (explicit).

    • If a D-* statement imposes compliance with a gate, it MUST reference the relevant A-* ID(s).
    • If a D-* statement is meant to be auditable, it SHOULD reference the E-* claim(s) that provide evidence and the carrier classes involved.

    A.6.B:5.4 — Quadrant E: Work‑Effects & Evidence

    Intent. State what happens in work and how it can be evidenced: observed effects, emitted events, traces, logs, and metrics, produced reports, measurement outcomes.

    Adjudication. In‑work: checked by running or operating and inspecting carriers produced in work.

    Canonical form. An E-* statement SHOULD include the minimum fields needed for adjudication:

    1. Observation and measurement conditions (when, where, and how observed; workload, window, and triggers)
    2. Evidence carrier or record reference under A.7, A.10, or G.6 as applicable for the evidence relation or source basis
    3. Viewpoint and consumer (who uses this evidence and why; ties to viewpointRef discipline)

    Prohibitions.

    • E-* statements SHOULD NOT use RFC deontic keywords (they are not obligations; they describe adjudicable effects and evidence).
    • An E-* statement MUST NOT hide a gate predicate; gate predicates are A-*.
    • An E-* statement MUST NOT assign agency (“the interface guarantees …”); if enforceability or commitment is intended, express it as D-* referencing the E-*.

    A.7 EntityOfConcern binding. E-* claims are primarily carrier-referenced: they assert what carriers exist and how they relate to observed work.

    Required references (explicit).

    • If the effect or evidence claim is conditioned on a gate decision, the E-* statement SHOULD reference the relevant A-* ID(s).
    • If the evidence is interpreted using metric definitions or invariants, the E-* statement SHOULD reference relevant L-* ID(s).

    Last Updated: 2026-06-17 — upstream FPF commit 646b0b9b (github.com/ailev/FPF)