FPF Reference

    A.6.P:7 — Conformance Checklist (CC‑A.6.P)

    Preface node heading:a-6-p-7-conformance-checklist-cc-a-6-p:12755

    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

    A pattern P conforms to A.6.P (i.e., is an RPR‑pattern) iff:

    Note. This checklist defines conformance for RPR specialisations (e.g., A.6.5, A.6.6, A.6.8, A.6.9, A.6.C, and additional admitted A.6.x patterns). A.6.P itself is the governing RPR pattern.

    1. CC‑A.6.P‑1 — Lens is explicit. P SHALL name the stable lens used to stabilise the ambiguity cluster and justify its fit.

    2. CC‑A.6.P‑2 — RelationKind is explicit and named through admissible mint-or-reuse. Every in‑scope relation claim SHALL name an explicit RelationKind token, and that token SHALL resolve to a vocabulary entry whose relation specification skeleton publishes (at minimum): polarity (and explicit inverses if needed), participant SlotSpecs ⟨SlotKind, ValueKind, refMode⟩, qualifier requirements, witness expectations for decision/publication lanes, admissible semantic change classes, and (when applicable) cross-Context or cross-plane policy (Bridge + CL + loss notes). Claims classified under A.6.B SHALL respect A.6.B. When a suitable token does not already exist, authors SHALL mint or document it through F.18 rather than inventing a one-off label by intuition: MintNew is the default, the seed candidate set and NQD-front SHALL be shown, and the final token SHALL be selected from that non-dominated front unless an explicit continuity exception is recorded. The relation specification skeleton SHALL also declare admissible repair options for endpoint kind mismatches (KindBridge / explicit narrowing / explicit retargeting) and enforce qualifier placement discipline (no adjective smuggling).

    3. CC‑A.6.P‑3 — Slot‑explicit instances. P SHALL ensure that every in‑scope relation instance is expressible as a Qualified Relation Record filling all relation-specification-required participant slots (no hidden arity; see WF‑A6P‑QR‑1).

    4. CC‑A.6.P‑4 — Qualifiers are explicit when required. If scope/time/viewpoint/reference-scheme assumptions matter (or the relation kind requires them), they SHALL be explicit; implicit “current/latest/in our context” SHALL NOT substitute. When witness freshness/decay matters, it SHALL be expressed explicitly (evidence-role timespans, qualification windows, explicit freshness predicates), not by treating Γ_time as a proxy.

    5. CC‑A.6.P‑5 — No silent polarity flips. If inverse wording is used, it SHALL use explicit inverse tokens or polarity‑preserving forms; implicit role flips are forbidden.

    6. CC‑A.6.P‑6 — Change semantics use a change‑class lexicon. Normative prose about relation evolution SHALL use named semantic change classes (declare/withdraw/retarget/revise/rescope/retime/refreshWitnesses/changeKind), not generic “update/modify/sync/bind/anchor”. Any mapping to more specific slot verbs MUST preserve the A.6.5 retarget vs by‑value edit distinction.

    7. CC‑A.6.P‑7 — “bind/binding” discipline. bind/rebind SHALL be reserved for name binding (Identifier → SlotKind/slot‑instance) and SHALL NOT be used as a synonym for relation edits.

    8. CC‑A.6.P‑8 — Lexical firewall is normative. P SHALL list red-flag umbrella tokens for the relation pattern and provide rewrite rules; umbrella tokens SHALL NOT function as meaning‑surrogates in Tech/normative prose. If retained Plain umbrella wording appears, it SHALL be immediately mapped to an explicit Tech form (relationKind(…) or --relationKind-->).

    9. CC‑A.6.P‑9 — A.6.B atomicity, classification, and explicit references are respected. Normative text SHALL be decomposed into atomic claims routable to exactly one quadrant (L/A/D/E). Dependencies SHALL be expressed by explicit references (IDs or canonical locations), not paraphrase. No‑upward‑dependency constraints SHALL be preserved.

    10. CC‑A.6.P‑10 — Evidence is carrier‑anchored (A.7 separation). Statements about witnesses/evidence/freshness SHALL be framed as properties/expectations of carriers and work, not as properties of prose.

    11. CC‑A.6.P‑11 — A.6.S compatibility when engineered. If the RPR specialisation is presented as engineered/evolving, it SHALL be compatible with A.6.S: distinguish TargetSignature vs ConstructorSignature; map constructor verbs to A.6.5/A.6.6 canonical verbs; keep constructor ops effect‑free; and (when a ConstructorSignature is present) declare the C.2.1 slot read/write profile and whether ops are A.6.2/A.6.3/A.6.4 species.

    12. CC‑A.6.P‑12 — Cross-Context or cross-plane reuse is explicit (no “sameness by label”). If a relation instance crosses Contexts/planes (or requires translation), the carrier SHALL cite Bridge ids + CL policy (and loss notes, when applicable). Label identity or “same anyway” prose SHALL NOT substitute.

    13. CC‑A.6.P‑13 — Disambiguation guide is actionable. P SHALL include an explicit rewrite/selection guide that maps each red-flag umbrella cluster or generic head phrase with FPF-governed use to candidate head kinds, candidate RelationKind tokens, and (when the ambiguity is endpoint-side) candidate endpoint facets/kinds, plus required qualifiers and canonical rewrite forms. The guide SHOULD follow the RPR‑Disambiguation format: trigger → candidates → discriminating questions/tests → canonical rewrite → L/A/D/E hooks.

      Where endpoint referential compression is a primary risk, the guide SHOULD also include (or point to) the Candidate‑Set Note template (A.6.P:4.0b) so instance‑level reviews have an auditable trail: candidates → selected facet/kind → why.

    14. CC‑A.6.P‑14 — Grounding spans System and Episteme. P SHALL include at least one Tell–Show–Show vignette in a System lane and at least one in an Episteme lane (per E.8), demonstrating a real ambiguity repair and a relation‑change narration using the change‑class lexicon.

    15. CC‑A.6.P‑15 — Trigger rule is explicit. P SHALL include an explicit trigger rule (or selection heuristic) stating when the repair case applies and what counts as “in-scope” umbrella relational prose.

    Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)