#A.6.P — U.RelationalPrecisionRestorationSuite — Relational Precision Restoration (RPR) — Kind‑Explicit Qualified Relation Discipline

Preface node heading:a-6-p-u-relationalprecisionrestorationsuite-relational-precision-restoration-rpr-kind-explicit-qualified-relation-discipline:10488

#Content

Type: Architectural (A) Status: Stable Normativity: Normative (Core)

Plain-name. Relational precision restoration suite.

Intent. Provide a family-level, reusable discipline for repairing a recurring defect in FPF texts: under‑specified relational language (often phrased as a seemingly binary verb) that actually hides (i) higher arity (missing participant positions), (ii) multiple semantic change classes, (iii) viewpoint/view asymmetry, (iv) boundary obligations (laws vs admissibility vs deontics vs evidence/work), and (v) endpoint referential compression (pronominal/metonymic stand‑ins and over‑broad kinds). RPR patterns turn “umbrella relations” into kind‑explicit, slot‑explicit, qualified relation records with an explicit change-class lexicon and lexical guardrails, while respecting the A.6 Signature Stack and A.6.B Boundary Norm Square separation.

Placement. Part A → cluster A.6 Signature Stack & Boundary Discipline → header pattern for the relation‑precision restoration family (A.6.5, A.6.6, A.6.8, A.6.9, A.6.H, and future A.6.x patterns).

Builds on.

• A.6 (stack layering + boundary discipline requirements).
• A.6.B U.BoundaryNormSquare (L/A/D/E routing; claim atomicity; cross‑quadrant references).
• A.6.S U.SignatureEngineeringPair (TargetSignature vs ConstructorSignature; canonical constructor verb mapping; effect‑free constructor ops).
• A.6.0 U.Signature (SlotSpec requirement for argument positions).
• A.6.5 U.RelationSlotDiscipline (SlotKind/ValueKind/RefKind stratification + canonical slot verbs; bind reserved for name binding).
• E.8 (pattern authoring discipline; Tell–Show–Show; SoTA echoing hygiene).
• F.18 (promise vs utterance vs commitment; avoids “interface‑as‑promiser” category errors).
• E.10 (LEX‑BUNDLE discipline; I/D/S vs Surface; L‑SURF token discipline; reserved primitives; Tech↔Plain pairing). (Referenced conceptually; no extra authoring apparatus implied.)

Coordinates with.

• A.2.4 U.EvidenceRole (witness semantics: role/timespan/freshness metadata for decision‑relevant witness sets).
• A.2.6 scope + Γ_time discipline (avoid implicit “current/latest”; make time selectors explicit when time matters).
• A.7 Strict Distinction (Object≠Description≠Carrier; avoid treating evidence/logs as properties of prose).
• A.6.2–A.6.4 (effect‑free episteme morphisms, epistemic viewing/retargeting as disciplined slot writes).
• A.10 evidence discipline (witnesses are carrier‑anchored; freshness is adjudicated in work/evidence lanes).
• C.2.1 U.EpistemeSlotGraph (slot read/write profiles for constructor operators, when declared).
• C.3.3 U.KindBridge + CL^k discipline (repairing endpoint kind mismatches; kind-level congruence + loss notes).
• E.17 MVPK / multi‑view publication (faces are views; “no new semantics”; viewpoint accountability).
• E.19 pattern quality gates (review/refresh discipline for guardrails and conformance lists).
• F.17 UTS (when ambiguity clusters become recurring vocabulary: publish stable RelationKind tokens and facet head phrases as UTS/LEX‑governed term assets, so rewrites don’t live only inside A‑patterns).
• F.9 Bridges + CL for cross‑Context/plane reuse (no silent sameness).
• C.2.2a / A.16 / A.16.1 / A.16.2 / B.4.1 / B.5.2.0 for the language-state seam: language-state chart positions, lawful moves, pre-threshold cue preservation, route publication, lawful retreat/reopen, and prompt-shaped continuations that are not yet stable relation publication; use A.16.0 only when lineage, branch, loss, or handoff history itself must be published as an explicit trajectory account.
• C.2.LS / C.2.4 / C.2.5 / C.2.6 / C.2.7 for language-state facet ownership: articulation explicitness, closure degree, language-state anchoring mode, and the language-state representation-factor bundle may be cited by RPR patterns but are not re-owned here.

Specialisations already in Core. These retained specialisations are current because they each carry one stable reusable burden family. Their mnemonic heads remain lawful entry points, but generic A.6.P does not treat token recurrence alone as sufficient to mint one new specialisation per overloaded trigger word.

• A.6.5: RPR for n‑ary relations and slot discipline (archetype: “putting something into a place”; explicit SlotKinds + ValueKind/RefKind + slot‑operation lexicon).
• A.6.6: RPR for “relative‑to / basedness” claims (explicit baseRelation token + scoped, witnessed base declarations + base‑change lexicon; lexical red‑flags for anchor*).
• A.6.8 (RPR‑SERV): RPR for the “service” cluster polysemy (facet‑explicit serviceSituation lens; canonical rewrites for service/server/service provider; routing tests for clause vs access point vs provider commitment vs work+evidence).
• A.6.9 (RPR‑XCTX): RPR for cross‑Context “same / equivalent / align / map” talk (explicit Bridges with direction, endpoint refinement, substitution licence, CL and loss notes; blocks silent inversion and “alignment” umbrella verbs).
• A.6.H (RPR‑WHOLE): RPR for “whole/part/integrity/complete” polysemy (WHOL triggers + Boundary–Parthood–Fold–Order/Time–Completeness lens; routes turnkey/end‑to‑end into A.15 coverage; includes artefact↔referent↔work level test).

#A.6.P:0 — TERM/LEX token guards (local-first)

This pattern reserves the following tokens on Tech (normative) surfaces:

• RPR — Relational Precision Restoration (the suite recipe; not a new U.Type).
• RelationKind — a Context-local vocabulary token (signature-level) that fixes polarity and SlotSpecs for participant/qualifier positions. It is a registry entry/token, not a relation instance.
• QualifiedRelationRecord — the slot-explicit relation instance record kind (Context-local episteme/record kind); instances carry a relationKind token reference plus explicit participant/qualifier slots.

Mint-or-reuse note (recipe-level). This pattern mints the suite label RPR, the role name RelationKind, and the generic shape name QualifiedRelationRecord as local-first terms for this family. It reuses existing FPF terms (U.Signature, SlotKind/ValueKind/RefKind, Bridges/CL, U.Scope, Γ_time, U.View/U.Viewpoint, evidence pins/carriers) without changing their meanings.

Definitions (recipe-level; non-deontic).

• RelationKind token — a declared vocabulary element (signature-level) whose public surface fixes polarity and SlotSpecs for participant/qualifier positions, and that is referenced by routed claims (L/A/D/E) that govern admissibility, duties/commitments, and evidence/work.
• QualifiedRelationRecord — a Context-local episteme/record kind whose relationKind field points (by id/ref) to a RelationKind token and whose instance records make all contract-required participant/qualifier slots explicit.

Rename-guards (common collisions):

• contract — Plain shorthand for “published boundary interface description”; a conforming text MUST NOT treat the term contract as itself establishing a promise/obligation. Promises, duties, and gates route via A.6.B.
• bind/binding — reserved for name binding (Identifier → SlotKind/slot-instance) and MUST NOT be used as a synonym for relation instance edits.
• same/synced/linked/connected/anchored/grounded — treated as umbrella tokens; allowed as Plain gloss only when immediately mapped to an explicit RelationKind token (Tech) via rewrite rules.

#A.6.P:1 — Problem frame

FPF repeatedly encounters a predictable precision failure mode:

Authors describe a situation with an apparently simple relational phrase:

• “X is the same as Y”, “X is linked to Y”, “X is synced with Y”
• “X depends on Y”, “X is grounded/anchored in Y”
• “X maps to Y”, “X aligns with Y”, “X is connected to Y”

…but the intended meaning is actually:

1. Hidden multiarity. The claim requires additional participant positions (scope, time selector, witness carriers, policy, direction/inverse, reference scheme, representation scheme, mediator artefact).
2. Kind elision. The umbrella verb stands in for an unstated family of relation kinds (different invariants; different admissibility; different evidence burdens).
3. Viewpoint fights. Different stakeholders describe “the same” relation from incompatible viewpoints, creating polarity flips and silent re‑typing.
4. Unnameable change semantics. Authors say “update/bind/anchor/sync”, but mean distinct semantic change classes (retarget vs revise vs rescope vs retime vs witness refresh).
5. Regression via prose. Even after ontology repairs, umbrella language re‑enters and collapses distinctions unless structural precision is coupled to lexical guardrails.
6. Pronominal/metonymic endpoints. Even when the relation verb is fixed, endpoints may be referred to via pronoun‑like or umbrella tokens (or metonymic pointers), so the relation cannot be typed or audited until endpoint facets/kinds are restored from context.

A.6.P defines a repeatable precision restoration recipe that makes this defect repairable and reusable across future A.6.x patterns.

#A.6.P:2 — Problem

How can FPF represent and evolve “relations in prose” that are structurally richer than they appear, so that:

• the relation kind is explicit and reviewable,
• missing positions can be made explicit without semantic drift,
• changes to the relation can be narrated with stable semantic change classes,
• multi‑view publication can exist without creating multiple incompatible contracts, and
• cross‑Context/plane reuse cannot silently assume “sameness by label”?

#A.6.P:3 — Forces

#A.6.P:4 — Solution — The RPR recipe (Lens → Slots → Change Lexicon → Guardrails), aligned to A.6 / A.6.B / A.6.S

A.6.P defines a suite recipe. A pattern is a RPR‑pattern (member of A.6.P) iff it provides the ingredients below.

#A.6.P:4.0 — Trigger rule (when A.6.P applies)

A relation mention or relation-bearing phrase is in-scope for A.6.P when any of the following holds:

• the predicate/verb phrase is lexically overloaded (umbrella tokens such as “same/sync/link/connect/anchor/ground/align/map/depends”), or
• one or more endpoints/qualifiers are expressed via pronominal / deictic / metonymic stand-ins or over-broad kind tokens (e.g., “it/this/that”, “the service”, “the system”, “at the table”), such that multiple referents/facets remain plausible, or
• a generic or over-broad head noun carries its load only through a qualifier, modifier, or surrounding phrase (e.g., “comparative note”, “safe guidance”, “interactive view”, “reliable output”), so the object kind is still ambiguous even though the qualifier sounds informative, or
• the statement implicitly relies on scope / Γ_time / viewpoint/view / schemes (reference, representation), or
• the relation is used for assurance / admissibility / gating / publication decisions, or
• the relation crosses Contexts or planes (requires Bridges + CL; no silent equivalence), or
• different stakeholders interpret endpoints differently (multi-view asymmetry and polarity fights).

Repair order note. When a load-bearing phrase is triggered because its head noun is too generic, first restore what kind of thing the head actually names (artifact, reading, process, lane, authority use, or another host-local kind) using local object-of-talk discipline (E.10, A.7, and nearby host law). A narrowing qualifier such as comparative, safe, interactive, or reliable may narrow the phrase, but it does not by itself restore the head kind. Then apply A.6.P to restore the remaining relation or comparison burden. Mixed-axis checks come after those two repairs, not before them.

Adoption test (review heuristic). If a reviewer can reasonably ask any of: “Which kind is this?”, “What exactly does this span refer to (which facet/kind, and in which lane: Object vs Description vs Carrier)?”, “What relation or comparison burden is hidden in this qualifier?”, “What else participates?”, “Under what scope/time/view?”, “What changed?”, or “What makes this admissible?”, then authors SHOULD treat the mention as in-scope and rewrite it into explicit kind+slots form before using it for cross-Context reuse or decision/publication claims.

Precision/relaxation note. A.6.P is not a blanket demand that every sentence stay maximally explicit forever. It is a trigger-based repair path for load-bearing prose. In design-time FPF texts and in run-time texts being prepared for admissible publication, review, gating, or reuse, the repair should be performed before any later didactic plain-language softening or lawful coarsening. Later relaxation is allowed only when the more precise upstream reading remains recoverable and authoritative.

Generic trigger-word governance rule (normative). Overloaded words are diagnostic entry points, not default future owners. Generic A.6.P therefore requires this order: restore head kind first, restore the remaining relation/comparison burden second, and only then judge whether one reusable burden family is strong enough to justify a new specialization. A new A.6.P specialization or broader trigger-word owner is owed only when one stable recurring burden, one reusable lens or rewrite kit, and one F.18 -> A.6.P-surviving head already exist by value across more than one worked case. Otherwise token-specific retained knowledge stays with an existing lawful specialization or in one cluster-local / owner-local note rather than expanding generic A.6.P into a token bucket store.

#Language-state entry note

RPR entry normally presupposes enough C.2.4 articulation explicitness that at least one relation-like skeleton can be named explicitly, and often enough C.2.5 closure that one candidate reading is worth publishing as a relation record rather than remaining mere cue pressure.

If the material is still best treated as a cue pack, routed cue, or unresolved route pressure, keep it in A.16.1 / B.4.1 rather than forcing relation publication prematurely. If the strongest lawful continuation is still an open explanatory question, route it through B.5.2.0. If a previously published relation must be reopened or backed off because the articulation/closure support collapses, route that retreat through A.16.2 rather than silently weakening the published relation in place.

#A.6.P:4.0a — Operational repair sequence (how repairs actually proceed)

The suite is presented as lens → slots → change lexicon → guardrails because the stable abstraction is what keeps repairs reusable. In actual editing, repairs often start from a triggering surface token and proceed through a context-reconstruction step.

Operationally, authors SHOULD follow this repair sequence when applying an RPR repair:

0. Restore the head kind if needed. If the triggering phrase uses a generic or over-broad head noun (note, view, guidance, output, artifact, and similar placeholders), first state what kind of thing it actually is in local host terms (publication artifact, reading, process, authority use, and so on). Do not let a qualifier do this job by implication alone.
1. Trigger on surface form. Detect umbrella relation predicates, pronominal/umbrella endpoint tokens or metonymic pointers, and generic-head-plus-load-bearing-qualifier combinations (including domain clusters such as service in A.6.8 and cross-Context “same/equivalent/align/map” in A.6.9).
2. Reconstruct the situation ontology from local context. Enumerate candidate referents/facets for endpoints (including A.7 lane: Object vs Description vs Carrier when it matters), candidate head kinds where the phrase is noun-led, and candidate RelationKind tokens or comparison burdens for the overloaded predicate/qualifier, plus implied participants (scope/time/view/scheme/mediator artefacts). Capture the result as a Candidate-Set Note (A.6.P:4.0b) so review has a checkable artifact: candidates → selected facet/kind → why. When metonymy is plausible, include both the literal and the intended candidates.
3. Choose a stable lens that can represent the reconstructed arity/polarity without ad-hoc role invention.
4. Refine the ontology under the lens. Turn implied roles into SlotSpecs; repair endpoint kind mismatches explicitly (narrowing / KindBridge / retargetParticipant); separate object kind, relation burden, and qualifier burden; make qualifiers explicit as slots or routed conditions.
5. Emit canonical rewrites + routing hooks. Produce Tech-form rewrites (relationKind(…) / arrow form) and state the A.6.B hooks: which parts are L vs A vs D vs E, and which witnesses/commitments/work claims are now demanded.
6. Only then allow later relaxation. If a Plain, didactic, or coarsened restatement is still wanted, derive it from the repaired form and keep the repaired form as the authoritative source for any stronger reading.

Decision/publication fail-closed (normative). If an in-scope mention is used to justify an admissibility gate, publication claim, or cross-Context reuse, authors MUST resolve the candidate sets to a selected RelationKind, selected endpoint facets/kinds, and any required head-kind reconstruction and emit an explicit rewrite. If that cannot be done from available context and witnesses, keep the statement as Plain/informative gloss (or split into multiple explicit alternatives) and do not treat it as admissible input for the gate.

Informative: referential compression spectrum. Many triggers live on a spectrum from high to low referential precision: pronouns/deictics → overloaded polysemes → coarse domain kinds → facet head phrases → precise domain terms. Metonymy often shifts the denotation (e.g., a place phrase standing in for an object or a role). The repair sequence explicitly treats this as a candidate-set problem, not as “the dictionary meaning”.

Metonymy micro-example (informative; endpoint-side trigger beyond anaphora).

Draft: “Alice is at the table.”

at the table → candidates {place, meeting, artifact, role} → choose explicitly → rewrite into endpoint-refs + qualifiers:

CandidateSetNote(triggerSpan="at the table", role=endpointFacet(p₂)):
- candidates: {PlaceRef(Table#7), MeetingRef(NegotiationSession#3), ArtifactRef(AgendaDoc#12), RoleRef(DecisionMakerSeat#2)}
- selected:   MeetingRef(NegotiationSession#3) + RoleRef(DecisionMakerSeat#2)  // metonymy: place → meeting/role
- consequence: require explicit `meetingRef`, `roleRef`, `Γ_time`, `witnesses` (and route decision/admissibility separately via A.6.B)

participatesInMeetingUnder(
  personRef  = PersonRef(Alice),
  meetingRef = MeetingRef(NegotiationSession#3),
  roleRef    = RoleRef(DecisionMakerSeat#2),
  Γ_time     = snapshot(t),
  witnesses  = {attendanceLogPins}
)

If the literal location reading is intended, select PlaceRef(Table#7) and rewrite as locatedAt(…) with an explicit Γ_time qualifier.

This step is intentionally not lexicon-only. The lexical rewrite is the output of an ontology- and lens-constrained repair, not the starting point. If you cannot state the candidate referents/facets, the selected head kind where needed, and the selected RelationKind token, the repair is incomplete.

#A.6.P:4.0b — Candidate‑Set Note (informative; review artifact)

When endpoint identity (pronoun/deixis/metonymy/coarse kind) or relation-kind selection is ambiguous, reviews can collapse into “lexicon debates”. A.6.P treats this as an ontology reconstruction step with an explicit, checkable intermediate artifact.

Candidate‑Set Note template (informative).

Collision note. This “Candidate‑Set Note” is not the F.18 naming-process candidate set (NQD-front). It is a local disambiguation artifact for endpoint referents/facets and RelationKind selection during RPR repairs.

For each ambiguous role (relation kind, endpoint facet/kind, qualifier, mediator), record:

• Trigger span: the exact surface token(s) in the draft (copy/paste).
• Role being disambiguated: headKind | relationKind | endpointFacet(pᵢ) | endpointRef(pᵢ) | qualifier(qⱼ) | mediator.
• Lane (A.7) (when endpoint‑side): Object | Description | Carrier (state explicitly when live contenders span lanes; lane‑mixing is a common source of “contract” category errors).
• Candidate set: a short list of plausible head kinds, kinds/facets, and/or RelationKind tokens (not synonyms), each with the local cue(s) that made it plausible.
• Selected facet/kind (and selected RelationKind, if relevant): the chosen candidate(s).
• Why: the discriminating test(s) that were applied, plus pointers to the specific local evidence/witness cues used (carriers, claims, artefacts).
• Consequence: which SlotSpecs become required/forbidden and which A.6.B hooks are now triggered (L/A/D/E).

Minimal one‑screen representation:

Notes.

• For metonymy, list both the literal candidate and the intended target candidate (and make the shift explicit).
• Keep the candidate set small: include only live contenders, and state the elimination test for the others.
• This note is informative: it does not replace routed L/A/D/E claims. It exists to prevent “lexicon instead of ontology”.

#A.6.P:4.1 — Stable lens

A RPR‑pattern SHALL name a stable mathematical “lens” that prevents re‑inventing roles per domain. Examples of lenses (illustrative):

• Kind‑labelled qualified hyperedge / record (default A.6.P lens)
• n‑ary relation with distinguished positions (A.6.5 style)
• kind‑labelled dependence arrow over a base (A.6.6 style)
• span/cospan + declared loss/correspondence notes (Bridge‑like families)
• correspondence relation + repair operations (sync/consistency families)

The lens is a compression device: one stable abstraction that keeps the relation’s arity and polarity stable and makes invariants speakable.

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

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 route mint-or-reuse through F.18: use MintNew by default, build a seed candidate set, surface 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 contract 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) a routed claim bundle (“contract skeleton”) that declares (at minimum):

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

• (L) applicability (A.6.0): the Context/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 family) (⟨SlotKind, ValueKind, refMode⟩, where refMode is either ByValue or a concrete RefKind token per A.6.5).
• (A) repair path for endpoint kind mismatches (normative): allowed repairs are (i) explicit narrowing, (ii) a KindBridge (+ CL^k + loss notes), and/or (iii) explicit retargetParticipant. Renaming endpoints is not a repair.
• (L) qualifier expectations: which qualifiers are required/optional/forbidden (scope, Γ_time, viewpoint/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 family.
• (L/A) admissible semantic change classes (see §4.4) and whether they require a new edition.
• (A/E) cross‑Context/plane policy when applicable (Bridge ids + CL + loss notes policy).

Important stack constraint (A.6 / A.6.S / A.6.B). Treat “contract” as a routed set of claims, not a single magical object:

• L‑claims (laws/invariants; polarity; SlotSpec typing) live in Signature.Laws.
• 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.

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

A conforming text SHALL ensure that each in‑scope relation instance is representable as a Qualified Relation Record (a first‑class record/episteme in the relevant Context) that fills the relation’s slots.

Conceptual notation‑neutral shape:

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

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

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

  // qualifier kit (pattern-specific; contract selects subset)
  scope?       : SlotContent(U.Scope, ByValue | RefKind),
  Γ_time?      : SlotContent(U.GammaTimePolicy, ByValue), // time selector/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 occupants; prose SHOULD use occupant names (scope, witnesses, base, dependent, …) for fillers. This is the same guard used in A.6.6 and A.6.5.

Well‑formedness principle. The record is “typed by contract”: SlotSpecs are fixed by the selected RelationKind token, and missing slots are permitted only if the contract says they are optional. This mirrors A.6.6’s scoped/witnessed declaration move (SWBD): “shape + contract 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/edition boundary. If the kind changes, the result is represented as a distinct record/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/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/anchored …”) is permitted only as Plain gloss when immediately rewritten into one of the above forms.

Cross‑Context/plane note (recipe-level). If any participant/qualifier implies cross‑Context or cross‑plane reuse, the routed claim bundle MUST cite the relevant Bridge ids + CL policy (and loss notes, when applicable) in the appropriate routed claims (typically A-* and/or E-*). Label identity is not an admissible substitute.

#A.6.P:4.4 — Change‑class lexicon (operations are not adjectives)

A RPR‑pattern SHALL publish a relation‑change lexicon: a small set of semantic change classes used in normative prose to describe “what changed” without umbrella verbs.

Minimum semantic change classes (conceptual; specialisations may add more):

1. declareRelation — mint a new qualified relation record (slot‑explicit).
2. withdrawRelation — retire a relation instance (render it inactive for downstream use). If the intent is narrowing (still valid within a smaller scope/window), use rescope/retime rather than overloading withdrawal.
3. retargetParticipant(slotKind, newRef) — change a RefKind slot-content while preserving SlotKind and ValueKind (conceptually corresponds to slot‑level retarget).
4. reviseByValue(slotKind, newValue) — edit embedded by‑value content (conceptually corresponds to slot‑level assign/update or “by‑value edit”).
5. rescope(newScope) — change scope explicitly (no “in our context” prose).
6. retime(newΓ_time) — change Γ_time when time matters; not a substitute for witness freshness claims.
7. refreshWitnesses(newWitnessSet) — update witness bindings to point at appropriate carriers; generating evidence is Work, not a constructor op.
8. changeRelationKind(newRelationKindToken) — semantic change; MUST NOT be treated as an edit‑in‑place.

Edition fence rule (A.6.S / A.6.6 alignment). In decision/publication lanes, any semantic change that alters meaning SHALL be represented as a new edition and connected via explicit continuity/withdrawal, rather than mutating the old record in place.

Mapping note (informative, conceptual). These change classes are semantic; they may be realised by A.6.5 slot verbs (retarget vs by‑value edit) and, when the relation is a basedness family, by A.6.6 base‑change verbs. The semantic story must not collapse into “we edited something”.

#A.6.P:4.5 — Lexical guardrails (ban umbrella metaphors as meaning‑surrogates)

A RPR‑pattern SHALL define red‑flag umbrella tokens for its ambiguity cluster, and SHALL provide canonical rewrite forms.

Normative base rules (suite-level):

• In Tech / normative prose, umbrella predicates (e.g., “same”, “synced”, “linked”, “connected”, “anchored/grounded”) MUST NOT substitute for an unnamed RelationKind token.
• “bind/binding” is reserved for name binding (Identifier → SlotKind/slot‑instance) and MUST NOT be used as a synonym for declaring/changing a relation instance. Use the change‑class lexicon instead.
• Pattern-defined carve‑outs MAY exist (reserved primitives elsewhere), but they remain review triggers to ensure the reserved sense is intended (as in A.6.6’s anchor* carve‑out rule).

Recommended publication move (no extra authoring apparatus implied). For stable ambiguity clusters, publish the red‑flag token list and canonical rewrites as a LEX‑BUNDLE entry (PTG=Guarded) and, when the cluster introduces new RelationKind tokens or stable facet head phrases, include them in the relevant UTS rows (F.17). This keeps rewrite discipline shareable outside the A.6 cluster.

#A.6.P:4.6 — Progressive elaboration (the “precision dial” rule)

A.6.P supports a controlled escalation path that preserves meaning and prevents drift:

1. Start with a minimal explicit RelationKind token + principal endpoints (a binary projection is allowed only if every omitted participant/qualifier slot is contractually optional and irrelevant for the downstream lane(s)).

2. When ambiguity emerges, do one (or more) explicitly:

   • add missing participants as additional slots (turn the projection into n‑ary),
   • add explicit qualifiers (scope / Γ_time / viewpoint/view / schemes / witnesses),
   • refine the RelationKind token to a more specific one (new contract skeleton; changeRelationKind),
   • introduce Bridges + CL (and loss notes) when crossing Contexts/planes.

3. Authors MUST keep the transition monotone:

   • no silent re‑typing,
   • no implicit polarity flips,
   • no “edit‑in‑place” that changes meaning (use edition fences + explicit continuity/withdrawal links).

#A.6.P:4.7 — Two‑view / polarity discipline (no silent role flips)

A RPR‑pattern SHALL specify how the same relation is expressed from both “sides” without polarity flips:

• Either keep both endpoints visible with the same polarity-preserving token, or
• declare explicit inverse tokens and require them for inverse prose.

Implicit role flips (“B validates A” without explicit inverse) are prohibited in Tech/normative prose. This is already a core rule for basedness patterns and is generalised here.

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

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 families, A.6.6 provides an existence proof of such a guide (select baseRelation family; add scope/time/witnesses). A.6.P requires this move suite‑wide.

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 surface form → candidate RelationKinds / candidate facets (kinds) → discriminating questions/tests → canonical rewrite(s) → L/A/D/E routing hooks

Rules for the guide:

• Triggers may be relation umbrellas (“same/synced/linked/anchored…”) or participant umbrellas (pronominal/metonymic/over‑broad kind tokens). The guide SHALL state which role(s) the trigger is standing in for (relation kind, endpoint kind, qualifier, mediator).
• Candidate sets SHALL be stated as kinds/facets/RelationKind tokens, not as synonym lists. “Service” ⇒ {promise content, access point, provider principal, commitment, work+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/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/arrow) and SHALL specify any newly required qualifiers (scope, Γ_time, viewpoint/view, schemes, witnesses).
• Routing hooks SHALL name which claim(s) are expected in each quadrant (L/A/D/E) so that “unpacking” reliably produces reviewable obligations 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-anchored witnesses exist (badge/access log, calendar invite, minutes/recording)?} → rewrite {locatedAt(personRef=…, placeRef=…, Γ_time=…, witnesses=…) | participatesInMeetingUnder(personRef=…, meetingRef=…, roleRef?=…, Γ_time=…, witnesses=…)} → L/A/D/E hooks {L: publish RelationKind tokens + SlotSpecs + polarity/inverses; A: decision/publication use requires explicit Γ_time + witness set; D: forbid metonymic endpoint spans in Tech prose (require explicit refs); E: cite carrier-anchored witnesses and their observation conditions}.

#A.6.P:4.9 — A.6.B routing template for RPR relation families

Any RPR‑pattern that claims “contract-bearing” semantics SHALL route its normative content using A.6.B:

• L‑claims: signature‑level structure and laws (SlotSpecs, polarity, invariants).
• A‑claims: admissibility / “entry gate” rules for using relation instances in specified lanes (e.g., decision use requires witnesses; time dependence requires Γ_time; cross‑Context use requires Bridges/CL).
• D‑claims: deontic obligations on authors/agents (lexical firewall; prohibited umbrella use; rewrite obligations).
• E‑claims: work/evidence expectations and carrier anchoring (what counts as a witness; evidence freshness is a property of carriers, not prose).

A.6.P does not mandate a particular claim‑ID format; it mandates the separation and cross‑reference discipline.

Atomicity + explicit references (normative, recipe-level). Per A.6.B, mixed sentences MUST be decomposed into atomic claims so each claim routes to exactly one quadrant, and any dependencies MUST be expressed as explicit references (by claim ID or canonical location), not paraphrased duplicates.

No upward dependencies (normative, recipe-level). L-* claims MUST NOT reference A-*, D-*, or E-*; A-* and E-* claims MUST NOT reference D-*. Where cross‑quadrant coupling is needed, link by explicit IDs in the allowed directions.

#A.6.P:4.10 — A.6.S compatibility note (ConstructorSignature is optional but canonical for engineered families)

If a RPR‑pattern is used as an engineered family (created/evolved over time), it SHOULD be expressible as:

• a TargetSignature: declared relation kinds + SlotSpecs + laws, and
• a minimal ConstructorSignature: effect‑free operations that rewrite under‑specified prose into the explicit form and evolve relation records using the change‑class lexicon (mapped to A.6.5/A.6.6 canonical verbs).

If a ConstructorSignature is provided, it SHOULD (conceptually) declare, for each constructor operator family:

• whether it is a species of A.6.2 / A.6.3 / A.6.4, and
• which U.EpistemeSlotGraph slots (C.2.1) it may read and write (SlotKind/ValueKind/RefKind profile).

Publication note (recommended). If the TargetSignature / relation-kind registry is published via MVPK, treat every face as a view (no new semantics), keep viewpoint accountability explicit, and prefer stable claim IDs (Claim Register) so downstream carriers cite claims rather than paraphrasing.

#A.6.P:5 — Archetypal Grounding (System / Episteme)

A.6.P requires Tell–Show–Show grounding in both System and Episteme lanes.

#A.6.P:5.1 — System archetype: “same system across environments”

Tell. An operations note says: “Staging is the same service as Production.” Months later, incident metrics are aggregated “because it’s the same thing”, and evidence across environments is mixed, producing an incorrect causal story.

Show. Treat “same” as a red-flag umbrella token. Rewrite into an explicit cross-Context relation kind, typed to the facet the draft actually uses (service delivery system sameness for actuals/evidence aggregation; not about promise contents).

Show (candidate‑set note; endpoint facet restoration).

CandidateSetNote(triggerSpan="service" in "same service", role=endpointFacet(p₁)):
- candidates: {promiseContent, serviceAccessPoint, serviceProviderPrincipal, serviceDeliverySystem}
- selected:   serviceDeliverySystem
- why:        the claim is later used to justify mixing operational actuals/evidence (metrics + incident logs);
  local cues point to delivery artefacts (manifests/config/test runs), not clause carriers
- consequence: endpoints typecheck as `DeliverySystemRef` participants; clause/provider facets are explicitly out-of-scope

sameDeliverySystemUnder(
  leftDeliverySystemRef  = SystemRef(staging_delivery_system),
  rightDeliverySystemRef = SystemRef(prod_delivery_system),
  scope     = ClaimScope{SLO_family = X, signals = {latency, error_rate}},
  Γ_time    = interval[2025-12-01, 2026-01-31],
  viewpoint = OpsViewpoint,
  witnesses = {deploymentManifestPins, configPins, testRunPins}
)

aggregationAdmissibleIff(
  relationRef  = RelationRef(sameDeliverySystemUnder, SystemRef(staging_delivery_system), SystemRef(prod_delivery_system), ed=…),
  target       = deliveryWorkMetrics,                   // actuals
  Γ_time       = interval[2025-12-01, 2026-01-31],
  witnesses    = {metricCarrierPins, incidentLogPins}   // evidence carriers for the actuals
)

Show. Now the relation is auditable: aggregation is admissible only if the relation kind’s admissibility claims say it preserves the needed characteristics under the declared scope/time, and if witnesses exist. Cross-Context reuse is explicit and cannot piggyback on label identity.

#A.6.P:5.2 — Episteme archetype: “the models are synced”

Tell. A draft says: “The simulation model is synced with the physical twin.” Reviewers ask what “synced” means. The authors respond with examples, but downstream users still cannot tell whether the claim is about parameters, structure, calibration, evidence freshness, or mapping quality.

Show. Rewrite “synced” as an explicit correspondence relation kind + explicit qualifiers + witnesses:

entityMatchedBy(
  leftRef          = ModelRef(SimModel@ed=12),
  rightRef         = SystemRef(PhysicalTwin@ed=7),
  mappingArtifactRef = AlignmentModel_2025_11,
  scope            = ClaimScope{signals = S, metrics = M},
  Γ_time           = snapshot(t),
  referenceScheme  = RefScheme(CustomerIdRegistry#EU),
  viewpoint        = DataEngineeringViewpoint,
  witnesses        = {evalRunPins, calibrationPins, mappingArtifactPins}
)

Show (change narration). Two weeks later, the mapping artefact is replaced and the witness set is refreshed. In decision/publication lanes, represent this as a new edition and narrate the change via change classes (not via “re‑synced”):

withdrawRelation( relationRef = RelationRef(entityMatchedBy, leftRef, rightRef, ed=12) )

declareRelation(
  entityMatchedBy(
    leftRef           = ModelRef(SimModel@ed=12),
    rightRef          = SystemRef(PhysicalTwin@ed=7),
    mappingArtifactRef= AlignmentModel_2026_01,
    scope             = ClaimScope{signals = S, metrics = M},
    Γ_time           = snapshot(t₂),
    referenceScheme   = RefScheme(CustomerIdRegistry#EU),
    viewpoint         = DataEngineeringViewpoint,
    witnesses         = {evalRunPins_2026_01, calibrationPins_2026_01, mappingArtifactPins_2026_01}
  )
)

Show. Different “sync meanings” become different RelationKind tokens (e.g., entityMatchedBy, schemaAlignedUnder), not adjectives. Subsequent changes become narratable as retargetParticipant, rescope, retime, or refreshWitnesses, rather than “we updated the sync”.

#A.6.P:6 — Bias‑Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for RPR‑style precision restoration in the A.6 cluster.

• Gov bias: prefers explicit admissibility and evidence routing; increases auditability but raises authoring cost.
• Arch bias: favours reusable structural lenses (records/hyperedges) over narrative prose.
• Onto/Epist bias: pushes kind‑explicit relations and polarity discipline; discourages metaphor-first modeling.
• Prag bias: reduces rework and cross-team misinterpretation; may feel heavy in exploratory notes.
• Did bias: enforces teachable rewrite guides; can be perceived as prescriptive.

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

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 future A.6.x patterns). A.6.P itself is the suite recipe.

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 lawful mint-or-reuse. Every in‑scope relation claim SHALL name an explicit RelationKind token, and that token SHALL resolve to a vocabulary entry whose contract 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/plane policy (Bridge + CL + loss notes). Routed claims 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 surfaced, and the final token SHALL be selected from that non-dominated front unless an explicit legacy exception is recorded. The contract skeleton SHALL also declare admissible repair paths 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 contract‑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 lower-level 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 family and provide rewrite rules; umbrella tokens SHALL NOT function as meaning‑surrogates in Tech/normative prose. If legacy/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, routing, 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 pattern family 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/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 load-bearing head phrase 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 routing 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 family applies and what counts as “in-scope” umbrella relational prose.

#A.6.P:8 — Common Anti‑Patterns and How to Avoid Them

#A.6.P:9 — Consequences

Benefits

• Predictable precision upgrades. Umbrella relational prose becomes systematically expandable into explicit structure.
• Viewpoint conflict becomes repairable. Differences surface as explicit roles/kinds/qualifiers, not silent rewrites.
• Change becomes speakable. “What changed?” is a named semantic change class, reducing folklore.
• Cross‑Context safety improves. “Same/synced/linked” becomes contract‑bearing and auditable, not rhetorical.

Trade‑offs / mitigations

• Higher authoring overhead. Mitigated by progressive elaboration: expand only when invariants, reuse, or decisions require it.
• More explicit qualifiers. Mitigated by keeping the lens stable and reusing slot templates (A.6.5/A.6.6).
• Perceived prescriptiveness. Mitigated by allowing Plain-register glosses that are immediately mapped to Tech tokens (without creating new contracts).

#A.6.P:10 — Rationale

Upper/foundational ontologies optimise for broad applicability via sparse commitments. FPF’s recurring, high-cost failures are often elsewhere: under‑specified relations in prose, where ambiguity hides in arity, kind selection, viewpoint, and change semantics.

A.6.P is orthogonal to “add a global taxonomy”:

• It provides a repeatable method to restore relational precision without requiring any external formalism or auxiliary authoring apparatus.
• It operationalises A.6’s boundary discipline by ensuring relation talk can be cleanly separated into laws, admissibility, deontics, and evidence/work (A.6.B), rather than becoming “contract soup”.

#A.6.P:11 — SoTA‑Echoing (informative; post‑2015 alignment)

Evidence binding note. If your Context maintains a SoTA Synthesis Pack for relation/contract authoring or “qualified relations”, cite it here and keep this section consistent. Otherwise, treat the table below as a seed list (informative only).

A.6.P echoes contemporary practice across independent traditions, while remaining notation‑neutral and Context-local:

These echoes justify why A.6.P is structured as: stable lens → explicit slots → explicit change classes → lexical guardrails, rather than “just define the verb”.

#A.6.P:12 — Relations

Specialised by

• A.6.5 U.RelationSlotDiscipline — slot precision restoration for n‑ary relations.
• A.6.6 U.BaseDeclarationDiscipline — base‑dependence precision restoration (SWBD + base‑change lexicon + anchor* red‑flags).
• A.6.8 (RPR‑SERV) — service polysemy unpacking as a relation/facet precision restoration discipline (serviceSituation lens + canonical rewrites + service‑specific tests and change narration).
• A.6.9 (RPR‑XCTX) - U.CrossContextSamenessDisambiguation - Repairing cross-context “same / equivalent / align / map” via explicit Bridges
• A.6.H (RPR‑WHOLE) — wholeness language unpacking (“whole/part/integrity/complete”) into boundary, typed parthood, explicit Γ selection, order/time routing, and A.15 completeness/coverage claims.

Coordinates with

• A.6.S U.SignatureEngineeringPair — RPR rewrite operations can be packaged as a ConstructorSignature for engineered relation families; must preserve canonical verb mapping and effect‑free constructor semantics.
• C.2.2a / A.16 / A.16.1 / A.16.2 / B.4.1 / B.5.2.0 + C.2.LS / C.2.4 / C.2.5 / C.2.6 / C.2.7 - relation publication enters only after lawful language-state chart positioning, articulation, and closure support exist; earlier cue pressure stays on the language-state seam, prompt-shaped continuations stay with B.5.2.0, retreat/reopen moves remain owned by A.16.2, and A.16.0 is used only when lineage, branch, loss, or handoff history must itself be published.

Intended future A.6.x specialisations (illustrative)

• Cross‑Context equivalence / “sameness” discipline (Bridge + loss notes families)
• Correspondence/consistency + repair discipline (sync/alignment families)
• Transfer/hand‑off discipline (multi‑party “give/assign/ownership” families)

#A.6.P:End