FPF Reference

    A.6.P:4.8 — Disambiguation guide (rewrite and selection)

    Preface node heading:a-6-p-4-8-disambiguation-guide-rewrite-and-selection:13433

    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 RPR‑pattern SHALL include an actionable guide:

    “If the draft says X, decide between relation kinds A/B/C, expand missing slots, and rewrite into explicit kind+slots notation.”

    For basedness repair, A.6.6 provides an existence proof of such a guide (select the baseRelation relation kind; add scope, time, and witnesses). A.6.P requires this move across RPR specialisations.

    Recommended format: RPR‑Disambiguation Guide (Winograd‑style, but ontology‑first). To keep disambiguation from collapsing into dictionary debates, present the guide as a compact decision scaffold:

    • trigger form → candidate RelationKinds and candidate facets or kinds → discriminating questions and tests → canonical rewrite(s) → L/A/D/E L/A/D/E hooks

    Rules for the guide:

    • Triggers may be relation umbrellas (“same, synced, linked, or anchored…”) or participant umbrellas (pronominal, metonymic, or over-broad kind tokens). The guide SHALL state which relation position(s) the trigger is standing in for (relation kind, endpoint kind, qualifier, mediator).
    • Candidate sets SHALL be stated as kinds, facets, and RelationKind tokens, not as synonym lists. “Service” ⇒ {promise content, access point, provider principal, commitment, performed work and evidence, …} is the archetype (A.6.8).
    • When endpoint‑side ambiguity is present, the guide SHOULD recommend producing a Candidate‑Set Note (A.6.P:4.0b) as part of the rewrite, so the chosen facet or kind is reviewable.
    • Discriminating questions SHOULD be phrased as small tests that map directly to slot requirements (e.g., “Can you call it?” ⇒ accessPointRef; “Is it deontic?” ⇒ commitmentRef + accountable principal; “Is it actuals?” ⇒ deliveryWorkRef + witnesses).
    • Canonical rewrites SHALL land in the A.6.P Tech forms (functional or arrow) and SHALL specify any newly required qualifiers (scope, Γ_time, U.Viewpoint and U.View, schemes, witnesses).
    • Quadrant hooks SHALL name which claim(s) are expected in each L/A/D/E quadrant so that “unpacking” reliably produces reviewable claim requirements rather than prose paraphrases.

    Mini-row (metonymy; endpoint-side trigger, illustrative).

    "at the table" → {PlaceRef(Table#7), MeetingRef(NegotiationSession#3), RoleRef(DecisionMakerSeat#2)} → tests {Is the claim about physical location? about participation? about accountable role? which carrier-referenced witnesses exist (badge or access log, calendar invite, minutes or recording)?} → rewrite {locatedAt(personRef=…, placeRef=…, Γ_time=…, witnesses=…) | participatesInMeetingUnder(personRef=…, meetingRef=…, roleRef?=…, Γ_time=…, witnesses=…)} → L/A/D/E hooks {L: publish RelationKind tokens + SlotSpecs + polarity and inverses; A: decision or publication use requires explicit Γ_time + witness set; D: forbid metonymic endpoint spans in Tech prose (require explicit refs); E: cite carrier-referenced witnesses and their observation conditions}.

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