A.6.B:0 — Conventions
Preface node
heading:a-6-b-0-conventions:7853
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
Keywords. The key words MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, and SHALL are to be interpreted as in RFC 2119/8174. Lower‑case “must/may/should” in explanatory prose is descriptive, not normative.
Quadrant labels. This pattern uses the routing labels L / A / D / E as statement quadrants:
- L — Laws & Definitions
- A — Admissibility & Gates
- D — Deontics & Commitments
- E — Work‑Effects & Evidence
These labels are claim-classification labels for statements, not MVPK face kinds and not pattern identifiers.
Statement identifiers (recommended). Routable statements SHOULD be given stable IDs with a quadrant prefix: L-*, A-*, D-*, E-*. Other sections and views SHOULD reference these IDs rather than restating the same constraint in new words.
Non-collision note (informative). The A-* prefix here is “Admissibility”, not Part‑A numbering and not MVPK’s AssuranceLane face kind. If this is a readability hazard in your program, prefer an explicit G-* (“Gate”) local convention while keeping the quadrant name “Admissibility”. Also avoid introducing single‑letter mnemonics for MVPK face kinds inside this cluster (MVPK has a legacy L,P,D,E mnemonic); spell face kinds in full to reduce collisions.
Atomic claim. An atomic claim is a sentence (or bullet) that performs exactly one logical role and is routable to exactly one quadrant. If a sentence mixes roles, it is not atomic and MUST be split before it can be routed.
Adjudication substrate (for routing). For the purposes of this square, an atomic claim is classified by the primary substrate that decides its satisfaction:
- In‑description / in‑theory: satisfaction is decided from the description alone (e.g., proof/type validation), or the claim is itself a governance utterance whose content is fully determined by the text.
- In-work or in-execution: deciding satisfaction requires observing executed work and/or inspecting carriers produced in work.
Note (important). D-* claims are authored and interpreted in the description; whether they are met is typically established indirectly via referenced E-* claims (or other governance procedures). This does not move D-* into quadrant E; it clarifies the routing distinction.
Modality family. A claim is either:
- Truth‑conditional: definitions, invariants, typing rules (“is”, “iff”, “∀”).
- Governance: governance conditions, obligations, commitments, and exclusions (“MUST/SHOULD/MAY”, “is admissible”, “is blocked”, “commits to”).
Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)