#U.BaseDeclarationDiscipline - Kind-explicit, scoped, witnessed base declaration discipline (with base-change lexicon)

Pattern A.6.6 · Stable Part A - Kernel Architecture Cluster

Plain-name. Scoped witnessed base declaration discipline.

Status. Normative (Core).

Placement. Part A, cluster A.IV “Signature Stack & Boundary Discipline”; adjacent to A.6.5 U.RelationSlotDiscipline.

Depends on. – A.6.0 U.Signature (universal signature carrier). – A.6.5 U.RelationSlotDiscipline (SlotKind/ValueKind/RefKind stratification + slot-operation lexicon). – A.2.6 (Scope discipline; explicit Γ_time; implicit “latest/current” is forbidden). – A.2.4 U.EvidenceRole (timespan + evidence-role discipline for decision-relevant witness sets). – A.7 (Strict Distinction; I/D/S vs Surface). – E.8 (pattern authoring order & SoTA discipline). – E.10 (LEX‑BUNDLE discipline; D.CTX lexical guardrails).

Coordinates with. – A.10 Evidence–Provenance DAG discipline (verifiedBy, validatedBy). – A.14 per-edge constructive grounding (tv:groundedBy) and validationMode discipline. – C.2.1 U.EpistemeSlotGraph grounding slots (GroundingHolonSlot, describedEntity). – A.6.3 U.EpistemicViewing (describedEntity-preserving view operators; base-relative “how” without retargeting). – A.6.4 U.EpistemicRetargeting (base-change along KindBridge; retargeting lexicon and continuity rules). – C.3.3 U.KindBridge & CL^k (explicit repair/translation when endpoint kinds or Contexts differ; no silent re-typing). – E.18 assurance-operations on U.Transfer (CalibrateTo, CiteEvidence, AttributeTo, ConstrainTo, …). – F.9 Bridges & CL (cross-context / cross-plane base declarations cite Bridge ids + CL policy). – F.15 F‑Suite validation harness (SCR/RSCR pins and refresh governance). – F.18 naming governance (surface rules for Tech/Plain twins).

Aliases (informative; discouraged for normative prose). – “anchoring / anchor” (legacy umbrella colloquial; a red‑flag token for under-described dependence). Prohibited in Tech register as a meaning‑surrogate; treat it as a defect to be rewritten into an explicit baseRelation(dependent, base) form. Allowed only when referring to a pattern-defined primitive that already reserves the word (e.g., E.10 MG‑DA Domain Anchoring; evidence/pin “anchors” where the term is explicitly reserved), or inside quoted legacy text that is immediately followed by a conformant rewrite. – “Qualified statement / attributed edge” (knowledge-graph colloquial). – “Pinning” (when witnesses are edition pins).

Mint‑or‑Reuse note (informative). This pattern mints the record shape name U.ScopedWitnessedBaseDeclaration (SWBD) and the base‑change lexicon operation class names (declareBase, rebase, retime, …) as canonical labels for semantic change classes. It reuses A.6.5 SlotSpec discipline (SlotKind/ValueKind/RefMode), A.2.6 Scope discipline (U.Scope, explicit Γ_time when time matters), and A.2.4 witness semantics (U.EvidenceRole) as the enforcement substrate.

FPF repeatedly needs to express a family of situations of the form:

#Keywords

• base declaration
• basedness
• baseRelation
• SWBD
• witnesses
• scope
• Γ_time
• anchoring
• rebase
• retime
• rescope.

#Relations

#Content

#Problem frame

FPF repeatedly needs to express a family of situations of the form:

A dependent content is admissible, usable, or interpretable only relative to an explicit base.

This family appears across disciplines:

• reference selection and identification (IDs, handles, pointers, registries),
• scale/datums/calibration (measurement traceability, baselines, normalisation),
• grounding of properties and abstractions to objects (attribution; “this property is about that thing”),
• admissibility/assurance (claims linked to evidence, checks, or proofs),
• publication discipline (what a statement is fit to be used for, where, and when).

In drafts, authors often reach for a single umbrella metaphor (frequently “anchor/anchoring”). That metaphor collapses different ontological situations and different operation classes, blocking precise invariants and making perspective-flips inevitable.

Deconfliction note (lexical). This pattern is about base-dependence in content (“X is usable relative to B”). It is not about E.10’s Domain Anchoring (MG‑DA), where “anchoring” is a lexical primitive meaning “object‑of‑talk anchoring” for token morphology. When you see anchor* in a basedness sentence, treat it as a defect unless an explicit baseRelation token is present.

Deconfliction note (context/meaning). This pattern is also not a license to reintroduce “anchor” as a surrogate for Context, SenseCell, or “where meaning lives”. Any such use is an anchor‑relapse and SHALL be rewritten into explicit Context/SenseCell/ConceptSet lane constructs (E.10 D.CTX), not into SWBD.

Like A.6.5, this family also triggers typing conflicts across viewpoints: an endpoint may be spoken about in its self-kind while the baseRelation contract expects a different ValueKind (or a different refMode). If that mismatch is not made explicit (SlotSpec + contract), authors “solve” it by renaming ends or flipping direction, and the ontological obligation (bridge / narrowing / retargeting) is lost.

The structural reason for the collapse is consistent: what looks like “one anchoring” in prose is, in fact, a based declaration with at least five components:

1. Dependent — what is being made admissible/usable/meaningful,
2. Base — what it is relative to (reference frame / evidence carrier / standard / policy / object),
3. BaseRelation — the specific relation kind that states how dependent depends on base,
4. Scope/Time — where/when the declaration holds (scope plus explicit Γ_time when time matters),
5. Witnesses / pins — what justifies or enforces the declaration when it is used for decisions.

Until BaseRelation is named, umbrella words (“anchor”, “ground”, “attach”, “based on”) nearly always mean:

“There is an under-described type of dependence here.”

This pattern introduces a single stable lens — the based declaration — and couples it with a strict lexical discipline and an operation lexicon, so that base-dependence can be expressed precisely across domains without collapsing back into metaphor.

#Problem

Typical failure modes this pattern is designed to eliminate:

1. Relation-kind elision.
   One verb phrase is used to cover: ID-to-registry reference, claim-to-evidence admissibility, calibration-to-standard, property-to-object attribution, policy gating, etc. Rules and invariants cannot be stated because the relation family is unspecified.

2. Perspective flip (dependent-view vs base-view).
   The same situation is described alternately as “X is anchored/grounded” and “Y is an anchor/ground”, with incompatible naming, hidden directionality, and silent re-typing of the ends.

3. Base–witness confusion.
   Evidence, pins, certificates, or proofs are treated as “the base”, even when they are only witnesses for a base relation (or conversely: a true base is treated as a mere witness).

4. Scope/time collapse.
   Based declarations are treated as timeless truths; time dependence is smuggled in via “current/latest/recently”, violating explicit Γ_time discipline.

5. Γ_time used as a proxy for freshness.
   Authors treat Γ_time as “freshness” or “evidence decay”, collapsing TimePolicy with witness-timespan/freshness predicates.

6. Decision use without witnesses.
   Declarations that gate work, publication, or assurance are asserted without a witness/pin, breaking auditability and enabling folklore.

7. Grounding conflation.
   “Grounding” is used as if it were one relation, while FPF already distinguishes at least:

   • constructive grounding of a model-edge by a trace (tv:groundedBy),
   • situational/empirical grounding of an episteme via a grounding holon (C.2.1),
   • semantic meaning assignment (SenseCell/ConceptSet lane; not a base declaration).

8. Slot/basing conflation.
   A.6.5 disambiguates positions in n-ary relations (SlotKind) vs fillers (ValueKind) vs stored references (RefKind). Umbrella basing language reintroduces confusion at the next layer: “why this link exists” (BaseRelation) is missing, and slot-edit operations are conflated with base-declaration edits.

9. Anchor relapse (Context/meaning surrogate).
   “Anchor/anchoring” is used to mean “the context”, “the meaning”, “the global reference”, or “the thing that makes this true”. This collapses D.CTX + SenseCell/ConceptSet lanes into a metaphor and makes review/tooling impossible.

#Forces

#Solution — The U.ScopedWitnessedBaseDeclaration object and its lexicon

#Canonical object

Definition. A U.ScopedWitnessedBaseDeclaration (SWBD) is a first-class base-declaration record shape (a signature in the A.6.0/A.6.5 sense): it reifies “dependent is usable relative to base via baseRelation, under scope/time, witnessed by pins”.

U.ScopedWitnessedBaseDeclaration ::=
  〈 * DependentSlot     : SlotContent(VK_dep,  refMode_dep),
    * BaseSlot          : SlotContent(VK_base, refMode_base),
    * BaseRelationSlot  : SlotContent(U.NameToken, ByValue),     // contract-bearing token; not free text; not U.Surface*
    * ScopeSlot         : SlotContent(U.Scope, ByValue),         // concretely: ClaimScope | WorkScope | PublicationScope
    * GammaTimeSlot?    : SlotContent(U.GammaTimePolicy, ByValue)?,
    * WitnessSetSlot?   : SlotContent(VK_wit,  refMode_wit)? 〉

Where:

• DependentSlot is the dependent content whose admissibility/usability/interpretation is being constrained.
• BaseSlot is the base (reference frame / target / object / standard / policy / evidence-carrier) that the dependent is declared relative to.
• BaseRelationSlot is a declared relation/predicate/operator token (a vocabulary element with a signature/contract) that states the precise kind of dependence. It is not a prose metaphor and is not a U.Surface/publication carrier.
• ScopeSlot is an explicit USM scope object (U.Scope): Claim scope (G), Work scope, or Publication scope.
• GammaTimeSlot is an explicit time selector/policy when time-dependent assumptions exist.
• WitnessSetSlot is a set of witness references/pins establishing justification or enforcement when the declaration is used for decisions.

Notation. SlotContent(VK, refMode) is a compact shorthand for “a slot whose SlotSpec declares ValueKind=VK and refMode ∈ {ByValue | RefKind} (A.6.5)”.

SlotSpec note. VK_* / RK_* / refMode_* above are not “anything goes”: they are fixed by the chosen BaseRelationSlot contract and must be declared as SlotSpecs (A.6.5). In other words, SWBD is a reusable shape, but each Context’s baseRelation family makes it a concrete, typed signature.

Instance/prose notation note (convention). In the prose and examples below, the occupants are written as dependent, base, baseRelation, scope, Γ_time, witnesses (no *Slot suffix). The *Slot suffix is reserved for SlotKinds/positions only (A.6.5 / E.10).

Well-formedness constraints.

• WF‑BD‑1 (No kind-elision). A base declaration is well-formed only if BaseRelationSlot is present and points to a declared vocabulary element with a known signature.
• WF‑BD‑2 (No silent re-typing). DependentSlot and BaseSlot type-check against the baseRelation contract (ValueKinds + refMode). If the intended endpoint kinds do not match, the repair path is explicit (Bridge / narrowing / explicit retargeting), rather than a rename.
• WF‑BD‑3 (Time explicit when time matters). If the declaration’s interpretation depends on time, GammaTimeSlot is explicit; “latest/current” is not a substitute.
• WF‑BD‑4 (Decision use requires witnesses). If the declaration is used for assurance, gating, or admissibility decisions, WitnessSetSlot is non-empty and resolvable.
• WF‑BD‑5 (Edition fence for decision/publication). An SWBD that is cited by PublicationScope or used for decision is immutable per edition: any permitted change class is represented as a new declaration linked via explicit continuity/withdrawal, not as an in-place rewrite.
• WF‑BD‑6 (No silent cross-context reuse). An SWBD that relates dependent and base across Contexts/planes (or requires scope translation) is admissible only if it cites the Bridge ids + CL policy that make the reuse admissible (F.9). No “it’s the same thing anyway” prose is an admissible substitute.

This is the discipline-level analogue of A.6.5’s move: disambiguation is achieved by making the missing structural component explicit and non-optional in decision-relevant contexts.

#Underlying mathematical lens

SWBD reifies a kind-labelled dependence arrow over a base:

• a dependence edge (dependent → base),
• labelled by a declared relation token (baseRelation),
• qualified by explicit scope and (when time matters) explicit Γ_time,
• optionally supported by a witness set (mandatory for decision use).

This “object over a base” lens is stable across disciplines: calibration is “measurement over standard”, admissibility is “claim over evidence”, attribution is “property over object”, and constructive grounding is “edge over trace”.

#Slot discipline for SWBD

Any signature that introduces SWBD (or SWBD-like relations) SHALL define SlotSpecs per A.6.5: every position declares SlotKind / ValueKind / RefKind-or-ByValue.

Recommended canonical SlotKinds for SWBD:

• DependentSlot
• BaseSlot
• BaseRelationSlot
• ScopeSlot
• GammaTimeSlot
• WitnessSetSlot

Slot vs filler guard. *Slot names the position (SlotKind), not the occupant. In prose, say “fills BaseSlot with …” rather than calling the base itself “a BaseSlot”. (Slot suffix is structural; E.10.)

Slot-level invariants (derived from WF‑BD‑1..4; testable).

• Invariant (SlotSpec completeness). In any SWBD signature, the SlotSpec for DependentSlot and BaseSlot declares admissible ValueKind and refMode explicitly (A.6.5). If those types cannot be stated, the baseRelation contract is not yet defined.
• Invariant (Relation tokenness). BaseRelationSlot holds a declared U.NameToken that resolves to a vocabulary entry with a known signature/contract (A.6.0 + A.6.5). It is not free text and is not typed as a publication surface (U.Surface*).
• Invariant (Scope objectness). ScopeSlot holds a U.Scope object (ClaimScope/WorkScope/PublicationScope) and is not replaced by “where it applies” prose.
• Invariant (Time gating). If time-dependent assumptions exist, the SWBD includes GammaTimeSlot carrying a U.GammaTimePolicy (WF‑BD‑3).
• Invariant (Witness gating). If the declaration participates in assurance/gating/admissibility decisions, the SWBD includes a non-empty, resolvable WitnessSetSlot (WF‑BD‑4).

Field naming guard (implementation; informative). When materialising SWBD as a record/card, implementations SHOULD avoid naming data fields with the *Slot suffix. Prefer dependentRef, baseRef, baseRelationRef, scope, gammaTime, witnesses (or Context‑local equivalents). *Slot remains reserved for SlotKinds/SlotSpecs (A.6.5).

#BaseRelation contract

A baseRelation token is not “just a label”. For each baseRelation declared in a Context, its definition SHALL include:

• Role polarity. Which end is dependent and which end is base (or declare symmetry explicitly).
• Typing expectations. Admissible ValueKinds and refMode for DependentSlot and BaseSlot.
• Token discipline (LEX). The token SHALL satisfy E.10 token-class morphology for relations/verbs; it SHALL NOT use metaphor heads (Anchor*, Ground*, Attach*) as a meaning-surrogate. If a legacy synonym exists, record it as an alias but keep the contract-bearing token specific.
• Repair path for mismatches. If an endpoint’s self-kind does not match the expected ValueKind, the allowed repairs are declared (KindBridge, explicit narrowing, or explicit retargeting); “renaming the endpoint” is not a repair.
• Parameter placement. Any additional qualifiers required by the relation kind (ranges, metrics, reference planes, policies) SHALL be represented either inside scope (preferred) or as explicit additional slots in an extended base-declaration signature; they MUST NOT be smuggled as adjectives on the endpoints.
• Scope class. Whether the declaration is claim-scoped (G), work-scoped, or publication-scoped.
• Time discipline. Whether Γ_time is required, optional, or forbidden for this relation kind.
• Witness discipline. Whether witnesses are always required vs required only for decision use, and what witness classes are admissible (U.EvidenceRole, edition pins, calibration cert pins, proof artefacts, policy pins).
• Admissible change classes. Which base-change operations are permitted (below) and what continuity requirements apply.
• Cross-context / cross-plane policy. Whether this baseRelation family may cross Contexts/planes at all; if yes, what Bridge ids/CL thresholds must be cited and what loss notes are required (F.9 / C.3.3).

This mirrors A.6.5: a SlotKind without ValueKind/RefMode is underspecified; a baseRelation without its contract is equally underspecified.

#Perspective/voice discipline (dependent-view vs base-view)

Normative rule. In Tech / normative prose, authors SHALL express a based declaration in one of the following explicit forms:

• baseRelation(dependent, base) (functional notation), or
• dependent --baseRelation--> base (arrow notation).

Authors SHALL NOT use passive/umbrella voice (“X is anchored/grounded/attached”) as a substitute for an explicit baseRelation(dependent, base) form, because it invites direction flips and silent re-typing.

Base-view is allowed only if the polarity is preserved. If authors use base-view wording (“B validates X”), they SHALL either (i) keep both endpoints visible using the same polarity-preserving token (e.g., validatedBy(X,B)), or (ii) use an explicit inverse token that is declared in the baseRelation contract. Authors SHALL NOT flip roles implicitly in prose.

#Lexical discipline

Normative lexical rule. In Tech / normative prose and Tech register naming, authors MUST NOT use umbrella metaphors (“anchor/anchoring”, “attach/attachment”, “ground/grounding”) as substitutes for an explicit baseRelation token.

Red-flag rule (anchor* as dependence metaphor).

• In Tech / normative prose: authors MUST treat anchor* as prohibited as a meaning-surrogate for an unnamed dependence kind. Authors SHALL rewrite into explicit baseRelation(dependent, base) form (or move to the correct reserved primitive lane).
• In Plain / legacy commentary only: authors MAY quote anchor* as a legacy umbrella only if it is immediately paired with an explicit baseRelation token (e.g., “legacy ‘anchored’ ⇒ validatedBy(...)”) and does not introduce a new contract-bearing token.

Carve-outs (pattern-defined primitives). This red-flag rule does not ban uses where “anchoring” is already a pattern-defined primitive elsewhere in the spec (e.g., E.10 MG‑DA “object‑of‑talk anchoring”, or A.10 evidence “anchors”). It still acts as a review trigger: confirm you are using the reserved sense, not smuggling a basedness meaning.

Naming guard for baseRelation tokens. Do not mint new baseRelation tokens whose head noun is a metaphor (Anchor*, Ground*, Attach*). If you are tempted to do so, you either (i) have not named the relation kind yet, or (ii) are introducing a legacy alias that must map onto an existing, more specific relation family.

Instead:

1. Name the BaseRelation token (declared vocabulary element), and
2. Use a relation-specific verb phrase that corresponds to that token.

Lane guard for meaning. If the intent is “attach meaning to a term”, do not introduce a baseRelation named Anchor… or Ground…. Use SenseCell/ConceptSet discipline; semantic meaning assignment is not expressed by SWBD.

Grounding disambiguation rule. If the prose says “grounded”, it MUST be rewritten into one of:

• constructive grounding (tv:groundedBy, base is a trace),
• situational/empirical grounding (base is a grounding holon or experimental setup),
• meaning lane (SenseCell/ConceptSet; not SWBD).

Bind deconfliction note. Authors MUST NOT use the verb “bind/binding” as a synonym for declaring/refreshing/changing a base declaration. “bind/binding” is reserved for name binding (LEX discipline). For SWBD edits, authors SHALL use the base‑change lexicon (below) instead.

#Base-change operation lexicon

As A.6.5 distinguishes slot operations by whether they change a stored reference, resolve a reference, or replace a value, A.6.6 distinguishes base declaration changes by which component changes and what semantics are affected.

Operation classes (conceptual):

These names denote semantic change classes. In decision/publication lanes, implementations MUST represent these changes by minting a new SWBD (new id/edition) and linking it to the prior one via explicit continuity/withdrawal (WF‑BD‑5 / CC‑BD‑10), rather than mutating the old record.

1. declareBase — create a new base declaration with explicit dependent, base, baseRelation, scope, and, when applicable, Γ_time, plus witnesses when decision-relevant.
2. withdrawBaseDecl — retire a declaration (or render it inapplicable by scope narrowing or time restriction, depending on baseRelation contract).
3. rebase — change base while keeping the same dependent and baseRelation (legality depends on the baseRelation contract; often requires witness refresh).
4. repointDependent — change dependent while keeping the same base and baseRelation.
5. rescope — change scope (widen/narrow/translate) under the baseRelation’s scope contract; widening often triggers witness refresh.
6. retime — change Γ_time selector/policy when time matters; not a substitute for witness-timespan/freshness predicates.
7. refreshWitnesses — add/refresh witnesses/pins when decision use continues across time advances, scope widening, or evidence refresh.
8. changeBaseRelation — not an edit-in-place. Changing baseRelation changes meaning; mint a new declaration and relate them via an explicit continuity relation (F.13 discipline), rather than silently rewriting the kind.

Relation to A.6.5 slot operations (non-normative mapping). These are semantic change classes; an implementation may realise them using A.6.5 slot operations on the SWBD record fields. Example: a rebase may be implemented as a retarget of baseRef on a new SWBD edition. The point of A.6.6 is that “we retargeted a ref” is not the semantic story; “we rebased the declaration” is.

Relation to E.18 assurance ops (informative). On U.Transfer, the allowed ops (ConstrainTo/CalibrateTo/CiteEvidence/AttributeTo) can be viewed as Context-approved specialisations of declareBase/rescope/rebase/refreshWitnesses for specific baseRelation families, with stricter contracts and lintability.

#Disambiguation guide for selecting a baseRelation

When a draft uses an umbrella phrase (“anchored”, “attached”, “grounded”), replace it by selecting a baseRelation family:

This table is illustrative; the discipline requirement is that the chosen baseRelation be explicit, declared, and contract-bearing. The “Meaning lane” row is included only as a do-not-model-with-SWBD reminder.

Note. The viewedVia / retargetedAlong families are defined by the A.6.3/A.6.4 viewing/retargeting operators; this table only classifies them as “relative-to-base” cases.

#Archetypal Grounding

#System archetype: calibration to a standard

Tell. A lab instrument channel TC‑17 is described as “anchored to ITS‑90”. Later, the reference standard is swapped, the phrase “still anchored” is kept, and the applicability window silently expands. Downstream work disagrees and nobody can reconstruct what changed.

Show. Express it as a base declaration:

BD#Calib_TC17_v5 :=
〈 dependent    = ThermocoupleChannelRef(TC-17),
base         = StandardRef(ITS-90 / CalStd-2025-09),
baseRelation = calibratedTo,
scope        = WorkScope{rig=R3, range=[0..200]°C},
Γ_time       = interval[2025-09-01, 2026-03-01],
witnesses    = { WorkRef(CalibrationRun#8841), CertRef(CalCert@edition=5) } 〉

Show. Disambiguate edits by operation class:

• New standard ⇒ rebase + refreshWitnesses.
• Wider applicability window ⇒ retime and likely refreshWitnesses.
• Relation-kind change (“not calibration, just normalisation”) ⇒ changeBaseRelation is not an edit; mint a new declaration and relate via continuity.

#Episteme archetype: claim admissibility via evidence relations

Tell. A report asserts: “Model M improves accuracy by 4%.” The team says the claim is “anchored in an experiment”, but dataset version, evaluation harness, and time selector are unclear, and no resolvable evidence is linked.

Show.

BD#AccGainClaim_2025Q4 :=
〈 dependent    = ClaimRef(CG:Claim#acc_gain_4pct),
base         = EvidenceCarrierRef(Work:EvalRun#2025-10-12),
baseRelation = validatedBy,
scope        = ClaimScope{dataset=BenchX@v3, metric=Top1, hardware=A100},
Γ_time       = snapshot(2025-10-12),
witnesses    = { SCRRef(EvalLog@edition=12), ComparatorSetRef@edition=7 } 〉

What becomes explicit is not “anchoring”, but:

• the relation kind (validatedBy),
• the scope slice,
• the time selector,
• the witness carriers that make the declaration admissible for decision use.

#Structural archetype: constructive grounding of a model edge

Tell. A structural edge is published (“A componentOf B”) without a constructor trace. It becomes treated as “obvious”, while the construction chain is not recoverable.

Show.

BD#EdgeGrounding_ComponentOf_17 :=
〈 dependent    = WMEdgeRef(Edge:componentOf#17),
base         = TraceRef(Γ_m:ComposeCAL#c17),
baseRelation = tv:groundedBy,
scope        = PublicationScope{view=WMCardLite, system=S, line=L3},
Γ_time       = snapshot(2025-11-02),
witnesses    = { WorkRef(AssemblyRun#7712), EditionPin(Γ_m:ComposeCAL@edition=4) } 〉

This example shows why “grounding” must be disambiguated: here it is a declared constructive relation with an explicit base (trace), not a vague claim of “stability”.

#Bias-Annotation

#Conformance Checklist

A carrier (pattern, spec, schema, code artefact, or publication) conforms to A.6.6 iff:

1. CC‑BD‑1 — Base relation kind is explicit.
   Every base-declaration-like statement SHALL name an explicit baseRelation token (a declared vocabulary element). No umbrella metaphor SHALL substitute for a relation kind.

2. CC‑BD‑2 — Dependent and base are explicit and typed.
   Every based declaration SHALL make both dependent and base explicit, and SHALL be SlotKind/ValueKind/RefMode disciplined per A.6.5.

3. CC‑BD‑3 — Scope is explicit.
   Every based declaration SHALL include an explicit scope (Claim scope (G) / Work scope / Publication scope).

4. CC‑BD‑4 — Γ_time is explicit when time matters.
   If any time-dependent assumption exists, the based declaration SHALL include an explicit Γ_time; implicit “latest/current” SHALL NOT be used as a substitute.

5. CC‑BD‑5 — Decision use is witnessed.
   If a base declaration participates in assurance, gating, or admissibility decisions, it SHALL include a non-empty, resolvable witnesses set (pins).

6. CC‑BD‑6 — No silent kind edits.
   Changing baseRelation SHALL be treated as a semantic change: it SHALL be represented as a new declaration plus explicit continuity, not as an edit-in-place.

7. CC‑BD‑7 — Grounding is disambiguated.
   Any use of “grounding/grounded” SHALL be disambiguated to a specific declared relation kind or moved to the meaning lane (SenseCell/ConceptSet).

8. CC‑BD‑8 — Cross-context use is explicit.
   If dependent and base reside in different Contexts (or scope translation is required), the declaration’s reuse SHALL cite Bridge ids plus CL policy (no silent reuse across Contexts/planes).

9. CC‑BD‑9 — Γ_time is not treated as freshness.
   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.

10. CC‑BD‑10 — Edition fence for decision/publication.
    If a base declaration is used for decision or cited in PublicationScope, it SHALL be immutable per edition: updates SHALL mint a new declaration and connect it via explicit continuity/withdrawal.

11. CC‑BD‑11 — Slot suffix discipline is respected.
    The *Slot suffix SHALL be used only for SlotKinds/positions, never for endpoint values or references.

12. CC‑BD‑12 — No “anchor” relapse.
    anchor* / ground* / attach* SHALL NOT be used as surrogates for Context/SenseCell/ConceptSet or for an unnamed dependence kind. Authors SHALL either use the reserved primitive sense (where explicitly defined elsewhere) or rewrite into explicit baseRelation(dependent, base) form. Metaphor-head tokens SHALL NOT be minted as new contract-bearing baseRelation vocabulary entries (record them only as legacy aliases that map onto a specific, non-metaphor token).

13. CC‑BD‑13 — BaseRelation contracts are explicit.
    Every baseRelation token used in an SWBD SHALL resolve to a vocabulary entry whose contract declares (at minimum): polarity; typing expectations (ValueKind + refMode) for DependentSlot/BaseSlot; admissible repair paths (KindBridge / narrowing / explicit retargeting); scope class; time discipline (Γ_time required/optional/forbidden); witness discipline; admissible change classes; and cross-context / cross-plane policy (Bridge ids + CL threshold + loss notes where applicable).

14. CC‑BD‑14 — Authoring voice is explicit.
    In Tech / normative prose, based declarations SHALL be written as baseRelation(dependent, base) or dependent --baseRelation--> base. Base-view prose SHALL be used only if polarity is preserved via explicit inverse-token use; implicit role flips SHALL NOT be used.

15. CC‑BD‑15 — Meaning lane separation.
    Semantic meaning assignment SHALL be modeled via SenseCell/ConceptSet lane constructs (E.10 D.CTX), not via SWBD. SWBD SHALL be used only for non-semantic base-dependence (admissibility, calibration, attribution, policy gating, constructive grounding, viewing/retargeting specialisations).

16. CC‑BD‑16 — Reserved “bind” discipline.
    bind/binding SHALL be reserved for name binding (LEX discipline) and SHALL NOT be used as a synonym for declaring/refreshing/changing a base declaration. Authors SHALL use the base‑change lexicon (declareBase, rebase, rescope, retime, refreshWitnesses, …) and explicit continuity/withdrawal relations instead.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits

• Disambiguation by construction: base-dependence becomes explicit via baseRelation.
• Cross-domain reuse: one stable record shape works for calibration, evidence admissibility, attribution, policy gating, and constructive grounding.
• Determinism where required: explicit scope and Γ_time prevent silent “latest/current” assumptions.
• Reduced “grounding” confusion: multiple grounding senses become distinguishable relation kinds.

Trade-offs / mitigations

• More explicit metadata and vocabulary: mitigated by defining baseRelation families once per Context and reusing them.
• Authoring overhead for witnesses in decision contexts: mitigated by pointing to already-existing artefacts (Work refs, pins) instead of creating new documents.

Adoption test (informative). A team has adopted A.6.6 if, for any decision-relevant “relative-to” statement, it can produce a resolvable tuple 〈dependent, base, baseRelation, scope, Γ_time?, witnesses?〉 and can classify any update as one of: declareBase / withdrawBaseDecl / rebase / repointDependent / rescope / retime / refreshWitnesses / changeBaseRelation.

#Rationale

Why focus on base declaration rather than a metaphor.
The recurring ambiguity is not “how to attach”, but “what is the declared base, and what kind of dependence is being asserted”. Naming the baseRelation token makes the dependence explicit and reviewable.

Why separate base from witnesses.
Bases are semantic reference frames; witnesses are justifiers/enforcers for decision use. Conflating them makes both reasoning and audit impossible.

Why include scope and Γ_time.
A declaration is never “everywhere forever” by default in FPF. Scope makes applicability explicit; Γ_time prevents hidden time dependence (“recent”, “current”, “latest”).

Why prohibit kind edits.
Changing the relation kind changes meaning; treating it as an update erases history and breaks continuity discipline.

Why the base-change lexicon.
Without explicit change classes, prose collapses distinct edits (rebase vs retime vs rescope vs witness refresh) and recreates the same ambiguity A.6.5 removed at the slot layer.

#SoTA-Echoing

1. RDF-star and statement qualification.
   Adopt/Adapt. RDF-star/SPARQL-star continues the semantic-web tradition of attaching qualifiers/provenance to statements and edges. We adopt the “qualified statement” intuition, but adapt it by requiring an explicit relation kind token and by tying time and scope discipline to FPF’s explicit Γ_time and USM scopes rather than leaving them implicit or purely notational.
   Primary source: Hartig et al., “Foundations of RDF* and SPARQL*” (2017+).

2. Wikidata-style statements with qualifiers and references.
   Adopt/Adapt. The Wikidata model popularised practical “statement + qualifiers + references” structures at scale. We adopt the separation of the core statement from its qualifiers/references, and adapt it by making decision-relevant witness requirements explicit via U.EvidenceRole and by requiring explicit scope/time where time-dependent assumptions exist.
   Primary sources: Wikidata statement model documentation and design lineage (post‑2015 practice).

3. Metrology traceability and calibration competence.
   Adopt/Adapt. Laboratory competence standards treat calibration as traceability to standards with documented evidence and bounded validity. We adopt the expectation that calibration-to-standard is not timeless, and adapt it by representing the validity window via explicit Γ_time plus witnesses as pinned calibration artefacts.
   Primary source: ISO/IEC 17025:2017.

4. Assurance case metamodels for claim–evidence structure.
   Adopt/Adapt. SACM formalises claim/evidence structures and emphasises structured support relations. We adopt the idea that decision-relevant admissibility links should be explicit, and adapt it by using FPF’s scope/time discipline and by treating relation-kind elision as a first-order defect.
   Primary sources: OMG Structured Assurance Case Metamodel (SACM), 2018+.

5. Objects over a base as a stable mathematical lens.
   Adopt/Adapt. Modern category-theory texts make “objects over a base” (slice categories) a reusable pattern for “X relative to B”. We adopt that lens as the stable abstraction behind base declarations, and adapt it with explicit scope/time and witness semantics needed for engineering governance.
   Primary source: Riehl, Category Theory in Context (2016).

SoTA binding note (informative). This pattern’s “qualified statement + explicit relation kind + references” move aligns with RDF*/Wikidata practice (items 1–2); the explicit time-window + witness semantics in decision use align with metrology traceability and assurance-case structures (items 3–4); the “object over a base” lens is the abstraction used to keep the pattern stable across domains (item 5).

#Relations

Specialises A.6.P U.RelationalPrecisionRestorationSuite. A.6.6 is the RPR specialisation for “basedness / relative‑to” claims: it makes the relation kind explicit via baseRelation, qualifies it with scope/Γ_time/witnesses, and standardises evolution via a base‑change lexicon plus lexical red‑flags (anchor*).

Builds on A.6.5 U.RelationSlotDiscipline.
SWBD introduces a structured record with slots; those slots must be SlotKind/ValueKind/RefKind disciplined, and its change classes must not be confused with slot-edit operations (A.6.5) or name-binding terminology (E.10 / L‑BIND).

Constrains A.10 evidence admissibility links.
verifiedBy and validatedBy are treated as baseRelation tokens; their scope/time and witnesses become explicit when used for decisions.

Aligns with A.2.4 U.EvidenceRole.
Decision-relevant witness sets should be representable as EvidenceRoles with explicit timespans and provenance discipline, not as ad‑hoc prose references.

Aligns with A.14 constructive grounding (tv:groundedBy).
Constructive grounding is one specific baseRelation family: dependent is a model edge, base is a constructor trace; witnesses pin the trace and work artefacts.

Coordinates with C.2.1 grounding holons.
Situational/empirical grounding via GroundingHolonSlot is treated as a distinct baseRelation family; it must not be collapsed with tv:groundedBy or with semantic meaning assignment.

Coordinates with A.6.3–A.6.4 viewing/retargeting.
Viewing and retargeting are specialised “relative-to-base” moves (preserve describedEntity vs change it along a declared bridge). They should reuse SWBD vocabulary where an explicit base declaration is required (scope/time/witness), without collapsing into generic “anchoring” prose.

Coordinates with A.2.6 and Γ_time.
Base declarations inherit the rule that time-dependent assumptions require explicit Γ_time; “current/latest” is not admissible.

Feeds E.10 / F.18 lexical governance.
Umbrella metaphors are disallowed as substitutes for baseRelation tokens; prose must name explicit relation kinds and keep the meaning lane separate (SenseCell/ConceptSet).

#A.6.6:End