FPF Reference

    A.6.P:4.2 — Kind‑explicit relation tokens (no umbrella meaning‑surrogates)

    Preface node heading:a-6-p-4-2-kind-explicit-relation-tokens-no-umbrella-meaning-surrogates:12442

    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

    For every in‑scope relational claim, authors SHALL select (or mint) an explicit RelationKind token as a declared vocabulary element.

    A RelationKind token is authored as a U.Signature‑level vocabulary element with explicit SlotSpecs for its participant and qualifier positions (⟨SlotKind, ValueKind, refMode⟩). When no suitable token already exists, authors SHALL NOT improvise a one-off string by intuition. They SHALL use F.18 for mint-or-reuse: use MintNew by default, build a seed candidate set, show an honest NQD-front, run the sense-seed read-through, and record why the selected token is chosen from the non-dominated front. Use DocumentLegacy only when the label is externally fixed and that status is stated explicitly.

    RelationKind relation specification skeleton (minimum, recipe-level). For each RelationKind token, a conforming Context publication SHALL publish a vocabulary entry whose signature-level definition is paired with (or points to) an L, A, D, and E-classified claim bundle ("relation specification skeleton") that declares (at minimum):

    The leading (L)/(A)/(D)/(E) tags below indicate the intended A.6.B quadrant classification for each element of the skeleton.

    • (L) applicability (A.6.0): the Contexts or planes where the kind is defined (local meaning is first-class).
    • (L) polarity, and (if needed) explicit inverse tokens (no silent role flips in Tech prose).
    • (L) SlotSpecs for all participant positions (and any qualifier slots exposed by the relation pattern) (⟨SlotKind, ValueKind, refMode⟩, where refMode is either ByValue or a concrete RefKind token per A.6.5).
    • (A) admissible repair options for endpoint kind mismatches (normative): allowed repairs are (i) explicit narrowing, (ii) a KindBridge (+ CL^k + loss notes), (iii) explicit retargetParticipant, or a stated combination of these repairs when several mismatch conditions are live. Renaming endpoints is not a repair.
    • (L) qualifier expectations: which qualifiers are required, optional, or forbidden (scope, Γ_time, U.Viewpoint and U.View, reference scheme, representation scheme).
    • (D) qualifier placement discipline: extra parameters belong in scope or explicit qualifier slots, not as adjectives attached to endpoint names.
    • (A/E) witness discipline: when witnesses are required as an admissibility gate and what carrier-anchored witness sets look like in this relation pattern.
    • (L/A) admissible semantic change classes (see §4.4) and whether they require a new edition.
    • (A/E) cross-Context or cross-plane policy when applicable (Bridge ids + CL + loss notes policy).

    Important stack constraint (A.6, A.6.S, and A.6.B). Treat a relation specification as a classified set of claims, not a single magical object:

    • L‑claims (signature invariants; polarity; SlotSpec typing) live in the signature-level invariant/rule set.
    • A‑claims (admissibility gates) are authored as admissibility predicates (canonically placed in Mechanism.AdmissibilityConditions when an explicit mechanism exists) and may reference the RelationKind token by ID.
    • D‑claims (duties/commitments) name accountable roles/agents and may reference L-*/A-* by ID.
    • E‑claims (evidence/work effects) anchor to carriers and observation conditions and may reference L-*/A-* by ID.

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