#A.6.P:4.3 — Slot‑explicit qualified relation records (recover hidden arity)

Preface node heading:a-6-p-4-3-slot-explicit-qualified-relation-records-recover-hidden-arity:13306

#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 conforming text SHALL ensure that each in‑scope relation instance is representable as a Qualified Relation Record (a first-class record or episteme in the relevant Context) that fills the relation’s slots.

Conceptual notation‑neutral shape:

Notation note (A.6.5 alignment). In this pattern refMode is a slot-content mode: either ByValue (inline value of the declared ValueKind) or a concrete RefKind token (slot holds a reference or pin of that RefKind).

QualifiedRelationRecord :=
⟨ relationKind : RelationKind, // vocabulary token / registry entry (signature-level)

  // participant positions (pattern-specific; relation specification fixes SlotSpecs)
  p₁ : SlotContent(VK₁, refMode₁),
  …,
  pₙ : SlotContent(VKₙ, refModeₙ),

  // qualifier kit (pattern-specific; relation specification selects subset)
  scope?       : SlotContent(U.Scope, ByValue | RefKind),
  Γ_time?      : SlotContent(U.GammaTimePolicy, ByValue), // time selector or policy; not an evidence freshness proxy
  viewpoint?   : SlotContent(U.Viewpoint, ByValue | RefKind),
  view?        : SlotContent(U.View, ByValue | RefKind),
  refScheme?   : SlotContent(U.ReferenceScheme, ByValue | RefKind),
  reprScheme?  : SlotContent(U.RepresentationScheme, ByValue | RefKind),

  witnesses?   : SlotContent(VK_wit, ByValue | RefKind)
⟩

Slot naming guard. *Slot suffix names positions (SlotKinds), not fillers; prose SHOULD use filler names (scope, witnesses, base, dependent, …) for slot contents. This is the same guard used in A.6.6 and A.6.5.

Well‑formedness principle. The record is typed by the relation specification: SlotSpecs are fixed by the selected RelationKind token, and missing slots are permitted only if the relation specification says they are optional. This mirrors A.6.6’s scoped and witnessed declaration move (SWBD): “shape + relation specification makes a concrete typed signature”.

Well‑formedness constraints (non‑deontic).

• WF‑A6P‑QR‑1 (Required slots are present). For any QualifiedRelationRecord r with r.relationKind = k, r provides values for every SlotSpec that k marks as required.
• WF‑A6P‑QR‑2 (No silent kind swap). relationKind is part of a record’s identity and edition boundary. If the kind changes, the result is represented as a distinct record or edition linked by an explicit changeRelationKind (or an explicit withdrawal + re‑declaration), not as an in-place mutation that preserves identity.

Normative prose forms (Tech). In Tech or normative prose, authors SHALL express an in‑scope relation instance in one of the following equivalent forms:

• Functional form: relationKind(p₁=…, …, pₙ=…, qualifiers…)
• Arrow form (binary projection only): p_left --relationKind{qualifiers}--> p_right

Passive umbrella voice (“X is synced, linked, or anchored …”) is permitted only as Plain gloss when immediately rewritten into one of the above forms.

Cross-Context or cross-plane note (recipe-level). If any participant or qualifier implies cross‑Context or cross‑plane reuse, the L/A/D/E-classified claim bundle MUST cite the relevant Bridge ids + CL policy (and loss notes, when applicable) in the appropriate L/A/D/E-classified claims: A-classified claims, E-classified claims, or both when both admissibility and evidence or disclosure consequences are live. Label identity is not an admissible substitute.

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