A.6.6 - Base Declaration Discipline: Say Exactly What Something Depends On

Status: Stable Type: Definitional relation-discipline pattern

Plain-name. Saying exactly what something depends on.

Use this pattern when a sentence says that one thing is calibrated to, based on, attributable to, constrained by, or otherwise usable relative to another, and the actual relation is still hidden by words such as anchor, support, ground, or based on.

First useful move. Name the actual dependent and base, state the direct relation in an ordinary sentence, and apply that relation’s own predicate to the current facts. Stop when this readable assertion answers the receiving question.

What goes wrong if missed. An umbrella word hides the relation kind or reverses its participants. At the opposite extreme, a simple assertion is expanded into slots, witnesses, editions, and a new record even though no later use needs them.

What this buys. A direct, testable assertion first. Scope, time, evidence, a reusable RelationSignature, or a reviewable record is added only when the direct predicate or one named receiving use needs that distinction.

Not this pattern when. If the direct relation and its participants are already clear, use its direct pattern. If support means evidence use, assurance, ordinary help, work enablement, navigation, source description, or another non-basedness reading, use that reading’s direct pattern instead.

A.6.6:1 - Problem frame

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

The use, admissibility, or interpretation at issue depends on an explicit relation between the actual dependent and its base.

Examples occur across several 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 obscuring their direction and applicable rules.

Like A.6.5, this family can expose typing conflicts across viewpoints: an endpoint may be named by its self-kind while the selected direct relation expects another participant kind or reference mode. Make that mismatch explicit only when it is current; do not hide it by renaming ends or flipping direction. Use SlotSpecs only when a reusable relation declaration actually needs them.

Every ordinary basedness assertion first needs only:

1. the actual dependent;
2. the actual base; and
3. the direct relation and its obtaining test.

Scope, time, evidence, continuity, or a reusable declaration is added only when the direct predicate or one named receiving use depends on it. Until the direct relation is named, umbrella words such as anchor, ground, attach, support, or based on usually mean only:

“There is an under-described relation here.”

The repair is therefore progressive: recover and test the direct relation, stop if the assertion is enough, and materialize declaration or assertion machinery only for a concrete later use.

A.6.6:2 - 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 kind 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 its required basis. Declarations that gate work, publication, or assurance omit the basis required by that decision. A witness, pin, or time selector is required only when that use needs it; omitting the required basis prevents its audit.

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),
   • source-local meaning recovery and, when needed, an F.17 SchemeSenseCell and LocalSenseBasisRelation (not a base declaration).

8. Slot/basing conflation. A.6.5 distinguishes relation positions, their fillers, and stored references. Umbrella basing language can hide the direct relation at the next layer, while record-edit language can be mistaken for change in the relation itself.

9. Anchor relapse (source or meaning surrogate). “Anchor/anchoring” is used to mean “the source”, “the meaning”, “the global reference”, or “the thing that makes this true”. This hides the exact source, scheme, expression, local claim, and any obtaining basis relation behind a metaphor; the phrase alone does not let a reviewer recover them.

10. Support bucket relapse. “Support”, “support basis”, “support relation”, or “support record” is used as a generic container for unlike relations. Some cases are direct base-dependence; others are evidence use, assurance input, causal-use support basis, mathematical-lens use, work enablement, source description, publication companionship, or ordinary help. Treating them as one support relation recreates the under-described dependence that A.6.6 is meant to repair.

A.6.6:3 - Forces

A.6.6:4 - Solution - State the direct relation, then add only what the receiving use needs

A.6.6:4.0 - Ordinary direct path

Start with a readable sentence:

Thermocouple channel TC-17 is calibrated to standard ITS-90 for rig R3.

Identify TC-17 and ITS-90, then apply the direct calibratedTo predicate and its applicability rule to the current facts. If the task only asks whether that calibration relation obtains for this rig, the sentence and predicate result are complete. Do not create a declaration record, witness set, edition, or assurance package merely because those fields could be written down.

Add a qualifier only when it changes the direct assertion or a named receiving use:

• name scope when the relation is limited to a range, population, rig, publication, or other exact extent;
• name time when the predicate or the use is time-dependent;
• cite an evidence-use or provenance relation when a claim about the relation is relied on;
• open occurrence identity only when another claim must refer to the same occurrence, compare it, qualify it, or record its history; and
• open a reusable declaration only when the reuse test in A.6.6:4.3 is met.

The assertion episteme, reusable declaration, world-side relation occurrence, evidence, and any Work remain different objects.

A.6.6:4.1 - Optional scoped assertion record

When replay, comparison, publication, or repeated review needs a stable representation, a project may show one C.2.1 assertion episteme in this local form:

scoped witnessed base declaration :=
  < dependent,
    base,
    directRelationKind,
    assertionPolarity,
    scope?,
    gammaTime?,
    evidenceUseRefs? >

This is a representation of claim content, not a public kind, RelationSignature, or world-side occurrence. directRelationKind resolves to an already governed relation kind; an affirmative assertion requires that relation’s predicate to obtain for the actual participants, while a negative assertion requires nonobtaining to be established under the applicable criterion or closure basis. Failure to establish the affirmative does not establish the negative. scope and gammaTime are present only when the direct relation or named use needs them. evidenceUseRefs, when present, resolve to exact A.2.4 evidence-use relations for this assertion. The evidence epistemes, producing Work, operation result, carrier, provenance, currentness, and later reliance remain separately identified under A.2.4 and A.10.

A.6.6 admits neither U.BaseDeclarationDiscipline nor U.ScopedWitnessedBaseDeclaration. The latter is a retired spelling and must not be used as a kind or as a world-side relation occurrence.

The record’s C.2.1 identity follows its complete ClaimGraph, exact EntityOfConcern, and effective ReferenceScheme. Changing an identity-bearing value identifies another episteme; a representation-only edit need not. Neither change by itself begins, ends, or alters the world-side relation it describes.

A.6.6:4.2 - Direct relation and optional assertion are different objects

The useful stable picture is a direct arrow in ordinary reading:

dependent stands in the named direct relation to base.

The arrow is not a generic mathematical constructor. Its participant meanings, predicate, applicability, and occurrence identity come from the selected direct relation pattern. A scoped assertion episteme may affirm or deny that this predicate holds, and evidence may support reliance on that assertion. Filling the optional record or merely asserting the claim establishes no occurrence. An episteme or publication may have a constitutive role under the direct relation’s own rule; evidential support remains independently governed.

Calibration, attribution, policy dependence, constructive grounding, and other cases therefore remain different relation kinds. A.6.6 supplies a recovery discipline, not one universal BaseRelation kind.

A.6.6:4.3 - Reusable declaration only for a named reuse

Use the direct relation’s A.6.0 RelationSignature only after the relation kind is already admitted and at least two named consumers need the same reusable declaration content. That signature states the participant meanings, predicate, applicability, and occurrence-identity rule. A.6.5 SlotSpecs belong inside that reusable declaration; they are not required in an ordinary one-case assertion.

If no direct pattern supplies the relation kind, participants, or predicate, keep the exact local claim or return the A.6.RCD missing-governor result. Do not repair the gap by minting a generic BaseRelation kind or token, SlotSpecs, or a scoped-record type.

A.6.6:4.4 - What a reusable direct-relation declaration must say

For a named receiving use that genuinely needs a RelationSignature, the direct relation definition states:

• the dependent and base participant meanings and direction or symmetry;
• the obtaining predicate and applicability;
• the occurrence-identity rule supplied by the direct pattern;
• admissible participant kinds and reference modes;
• any scope, time, evidence, or cross-local condition that changes this predicate or the named reuse; and
• the direct continuity or change rules, when that history is current.

Different exact local kinds, F.17 senses, scopes, or ReferencePlanes are handled by their applicable direct relations. Source difference alone creates no Bridge. A RelationSignature declares reusable content; the reusable form by itself neither asserts a current case nor establishes an occurrence.

A.6.6:4.4a - Claim-scoped non-kind predicate-base branch

When one identified derivation or criterion-selection claim uses exact claim content as its base, reuse A.6.6’s endpoint, scope, time, witness, Bridge/loss, change, and overread discipline without pretending that a new relation kind or special base-declaration occurrence has been admitted. Identify the exact dependent U.ClaimGraph, exact nonempty selected base subgraph by value, the derive or evaluate mode, exact derivation or evaluation-and-selection claim identity, bounded receiving use, and effective reference scheme. Add an exact A.2.6 ClaimScope, temporal policy/domain, source or witness qualification, or cross-scheme Bridge and loss account only when that independently varying fact changes the assertion.

The assertion is ordinary C.2.1 claim content under derivedUsingRuleContent or evaluatedAgainstRuleContent. The dependent and base are predicate parameters, not automatically A.6.5 SlotSpecs, participants of a reusable relation occurrence, or an intrinsic rule-bearing classification. Same-scheme use adds no Bridge. A source edition, designation, acceptance/currentness fact, trace, or witness qualifies the assertion but does not enter semantic-base identity. Equal graphs under the same scheme count as one semantic base with multiple qualifications; a changed graph is another base.

Change only the fact that changed: declare or withdraw a selected base, repoint the dependent, rescope, retime, refresh witnesses, or change the predicate relation. A changed subject, content, mode, bounded use, actual-use claim, scope extension, temporal policy, or interpreted endpoint identifies another C.2.1 assertion. A claimed edition succession additionally requires the continuity conditions of C.2.1:4.5. Do not infer a new relation kind, occurrence, evidence result, Work, authority, or reliance from that change.

A basis-family analysis is a separate, optional C.2.1 episteme opened only for a named comparison, replay, material-conflict, or reliance receiver. Its candidate universe, evaluations, pairwise compatibility, temporal partition, established family, and disposition neither edit this reusable predicate declaration nor become fields of each actual-use assertion.

A.6.6:4.4.1 - Perspective and voice

State the relation in the shortest ordinary sentence that keeps both participants and direction recoverable: TC-17 is calibrated to ITS-90 is valid. Functional or arrow notation may be added when it helps a formal receiver; it is not the default. Base-view wording is also valid when it preserves the same relation and direction. Do not turn B validates X into an inverse relation unless that inverse is independently defined.

A.6.6:4.5 - Lexical discipline

Normative lexical rule. In Tech or normative prose, do not use umbrella metaphors (anchor, attach, ground, or support) in place of the actual relation. Prefer an ordinary relation-specific sentence; add functional or arrow notation only when a named receiver benefits from it.

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

• In Tech or normative prose, rewrite anchor* as an ordinary relation-specific sentence, or move to the already reserved primitive that actually governs the claim.
• In Plain or source commentary, quoted umbrella wording may remain for traceability when the repaired sentence immediately names the actual relation. It must not be converted into a generic validatedBy, verifiedBy, SupportRelation, or metaphor-headed 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, such as E.10 MG-DA token-to-EntityOfConcern 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 relation vocabulary. Do not mint a new direct relation whose name merely preserves a metaphor such as Anchor*, Ground*, or Attach*. Name the actual relation kind and use the corresponding ordinary verb phrase. In an optional assertion record, the local directRelationKind field identifies that already admitted relation kind; the field is not another relation kind. Lane guard for meaning. If the intent is “say what this expression means in this source”, do not introduce an Anchor… or Ground… relation. Recover the source-local claim under F.0.1; use F.17 only when a durable SchemeSenseCell or obtaining LocalSenseBasisRelation is actually needed. Semantic meaning assignment is not a base-declaration record.

Grounding disambiguation rule. If the prose says “grounded”, its actual ordinary or governed meaning MUST be recovered. The following branches illustrate distinct meanings, not an exhaustive classification:

• constructive grounding (tv:groundedBy, base is a trace),
• situational/empirical grounding (base is a grounding holon or experimental setup),
• source-local meaning lane (exact source, scheme, expression, local claim, and optional F.17 cell or basis relation; no special base-declaration object).

Bind deconfliction note. Do not use “bind/binding” as a synonym for declaring, refreshing, or changing an assertion or reusable relation declaration. This local edit vocabulary does not rename name binding or other already governed binding relations, including A.6.1 application bindings. Use the local declaration-change label only when a named receiver needs that history.

A.6.6:4.6 - Base-change operation lexicon

The following local labels classify changes to an optional assertion episteme or reusable declaration when a named receiver needs that history. They do not describe the beginning, ending, or change of the world-side relation itself, and an ordinary direct assertion needs none of them. In decision or publication use, preserve the prior episteme when changing its ClaimGraph, exact EntityOfConcern, or effective ReferenceScheme; such a change identifies another episteme. A representation-only edit need not do so. Claim edition continuity only when the C.2.1:4.5 rule and case facts establish it.

Operation classes (conceptual):

1. declareBase - create a new optional assertion with explicit dependent, base, directRelationKind, and assertionPolarity, or a new reusable declaration for that same already governed direct relation kind; add only the scope, time, evidence-use, or other qualifications that its direct predicate or named receiver needs.
2. withdrawBaseDecl — retire an assertion or declaration (or render it inapplicable by scope narrowing or time restriction, depending on the direct relation’s declaration).
3. rebase — change base while keeping the same dependent and directRelationKind (legality depends on the direct relation’s declaration; often requires witness refresh).
4. repointDependent — change dependent while keeping the same base and directRelationKind.
5. rescope — change scope (widen/narrow/translate) under the direct relation’s scope rule; 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. changeDirectRelationKind — not an edit-in-place. Changing directRelationKind changes claim meaning; mint a new assertion or declaration rather than silently rewriting the kind. When edition history is needed, relate it to the prior episteme only if C.2.1:4.5’s continuity rule and case facts establish that relation. Use F.13 for a separately current lexical-continuity claim.

Relation to A.6.5 slot operations (non-normative mapping). A project may realize an edit to an optional assertion or declaration through A.6.5 slot operations. The semantic account must still say which episteme field changed. A separately claimed change to the actual relation uses the direct relation’s change rule and any current Work; it is never inferred from the record edit.

Relation to E.18 assurance ops (informative). On U.Transfer, ConstrainTo, CalibrateTo, CiteEvidence, and AttributeTo have their own declared meanings and constraints. A project may use the local declaration-change labels to describe changes in a represented assertion, but those labels neither subsume the E.18 operations nor create their relations.

A.6.6:4.7 - Disambiguation guide for selecting the direct relation

When a draft uses an umbrella phrase (“anchored”, “attached”, “grounded”), replace it with the direct relation that actually fits the claim:

This table is illustrative. Each row keeps its own direct relation and governor; it is not a list of species of one universal base relation or record. Grammatical subject and object expose a sentence’s direction but do not by themselves determine dependent/base allocation. Where the domain predicate or participant allocation is not supplied, recover it from the source or leave that local choice open; this guide does not define it. Ordinary aboutness and source-local meaning do not by themselves select a basedness or construction branch.

Note. A.6.3 defines the viewing arrow. A.6.4 keeps the retargeting arrow r, bounded-use assertion q, and current-case judgement separate: q’s ClaimGraph contains the invariant, visible loss, named receiving use, conditions, and affirmative or negative polarity; the judgement compares exact facts with q and returns exactly satisfies, fails, or cannot decide. A cannot decide judgement names the missing fact and reopen condition. This table directs those construction cases to their own patterns; it defines no second operator, arrow, assertion, judgement, application, or Work.

A.6.6:4.7a - Support wording selection test

When a draft uses support, supported by, supporting, support basis, support relation, or a support-headed compound, do not first choose a more formal synonym. Ask what assertion the next reader needs.

If the sentence is genuinely about basedness, write the smallest direct form:

dependent stands in <direct relation> to base

Identify the actual participants and apply that direct predicate. Stop there when it answers the use. Add scope, time, an assertion record, a reusable RelationSignature, occurrence identity, or evidence only when the predicate or one named receiver needs it.

If the sentence is not basedness, use the matching ontology:

Do not create SupportRelation, SupportBasis, SupportRecord, validatedBy, or verifiedBy as a fallback. Work, a result episteme, its carrier, provenance, evidence use, and later reliance remain separate.

A.6.6:5 - Archetypal Grounding

A.6.6:5.1 - 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. First state the direct assertion: TC-17 is calibrated to ITS-90 for rig R3 over 0–200 °C during the stated calibration interval. Apply the calibration predicate and stop there if this answers the use. When a later publication or comparison needs the exact assertion edition, show the same claim in an optional scoped record:

BD#Calib_TC17_v5 :=
〈 dependent    = ThermocoupleChannelRef(TC-17),
base         = StandardRef(ITS-90 / CalStd-2025-09),
directRelationKind = calibratedTo,
assertionPolarity  = affirmative,
scope        = WorkScope{rig=R3, range=[0..200]°C},
gammaTime          = interval[2025-09-01, 2026-03-01] 〉

When a later decision relies on this assertion, cite the exact A.2.4 evidence-use relation from the calibration-certificate episteme to the assertion. Use A.10 only if that decision also needs the producing Work, operation result, carrier, provenance, or currentness path. Then distinguish changes by what actually changed:

• New standard ⇒ rebase + refreshWitnesses.
• Wider applicability window ⇒ retime and likely refreshWitnesses.
• Relation-kind change (“not calibration, just normalisation”) ⇒ changeDirectRelationKind is not an edit; mint a new assertion or declaration. Claim continuity with the prior episteme only when that history is needed and C.2.1:4.5’s rule and case facts establish it.

A.6.6:5.2 - Episteme archetype: an evaluation result used as evidence

Tell. A report says that model M improved accuracy by 4%. The team points to EvalRun-2025-10-12, but that Work occurrence is neither the claim nor an evidence relation, and its log carrier does not become evidence merely by being attached.

Show. First recover the accuracy measure, reference condition or population, and percentage convention from the reported comparison. If those operands cannot be recovered, the exact 4% comparison claim remains unidentified; stop before relying on that numerical target. Once they are recovered, identify the result episteme that states the measured comparison and the target claim about the 4% improvement. State the exact A.2.4 evidence-use relation between that episteme and claim, including the relevant ClaimScope, polarity, window, and receiving use. If the decision also needs replayable source, carrier, provenance, currentness, or bounded-reliance information, use A.10 to cite the evaluation Work, its actual operation-result binding, the result episteme, the log carrier, and their independently obtaining direct relations.

Stop with the short evidence-use statement when it answers the question. No validatedBy(claim, Work) edge or scoped base-declaration record is required. If a project later needs a reusable evidence-relation declaration, that direct relation must first have its own participant meanings, predicate, applicability, and occurrence-identity rule.

A.6.6:5.3 - Structural archetype: constructive grounding of a model edge

Tell. Suppose a B.3.5 assurance requirement for this publication requires a recoverable constructor trace. A structural edge is published (“A componentOf B”) without that trace. It becomes treated as “obvious”, while the construction chain is not recoverable. Ordinary parthood does not require this trace; the failure here concerns the selected hypothetical assurance requirement.

Show. First state and test the direct tv:groundedBy assertion between the model edge and constructor trace. Stop when that assertion answers the use. If a publication needs a stable assertion edition with its current qualifiers, it may represent that C.2.1 episteme as:

BD#EdgeGrounding_ComponentOf_17 :=
〈 dependent    = WMEdgeRef(Edge:componentOf#17),
base         = TraceRef(Γ_m:ComposeCAL#c17),
directRelationKind = tv:groundedBy,
assertionPolarity  = affirmative,
scope        = PublicationScope{view=WMCardLite, system=S, line=L3},
gammaTime          = snapshot(2025-11-02) 〉

The printed trace reference names the intended constructor trace; its presence does not establish the trace or the grounding relation. If another use relies on the assertion that the grounding relation obtains, cite its exact evidence-use and provenance relations separately. 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”.

A.6.6:6 - Bias-Annotation

A.6.6:7 - Conformance Checklist

An A.6.6 use conforms when the checks for its selected branch pass:

1. CC-BD-1 - Direct assertion first. The actual dependent, base, direct relation, and readable affirmative or negative assertion are recoverable. The direct pattern supplies the predicate. Test affirmative obtaining or establish nonobtaining under its applicable criterion or closure basis; a record, label, or failure to establish the affirmative supplies no case result.
2. CC-BD-2 - Ordinary stop. If that assertion answers the receiving question, no SlotSpecs, declaration record, witnesses, edition, occurrence identity, or assurance package is required.
3. CC-BD-3 - Reusable declaration is demand-driven. A RelationSignature satisfies the reuse test in A.6.6:4.3 and applies only to an already admitted relation kind.
4. CC-BD-4 - Assertion and occurrence stay separate. A scoped witnessed record, when used, is a C.2.1 assertion or description episteme. It is not the world-side relation occurrence, and its form alone does not establish that occurrence; any constitutive contribution follows the direct relation’s rule.
5. CC-BD-5 - Qualifiers are local. Scope and time are explicit when the selected predicate or named receiving use depends on them; they are not a universal field kit. Gamma_time is not used as a proxy for evidence freshness.
6. CC-BD-6 - Evidence ontology is direct. Evidence use follows A.2.4 and A.10. Work, operation result, result episteme, carrier, provenance, evidence-use relation, and reliance remain separate; no generic verifiedBy or validatedBy edge is minted.
7. CC-BD-7 - Crossings are conditional. An actual relation between two exact F.17 cells uses F.9 only when its predicate obtains and keeps the bounded-use claim separate. A ReferencePlane crossing uses its applicable plane relation. One creates neither the other.
8. CC-BD-8 - No silent retyping or direction flip. Participant kinds and direction follow the direct relation. A mismatch is repaired by the applicable narrowing, Bridge, retargeting, or direct relation rule, not by renaming an endpoint.
9. CC-BD-9 - Plain language remains sufficient. Ordinary relation-specific prose is preferred. Functional or arrow notation is optional and may not replace the readable assertion.
10. CC-BD-10 - Metaphors do not become ontology. anchor, ground, attach, and support remain source-word triggers unless they name an already reserved primitive; no metaphor-headed fallback kind or relation is minted.
11. CC-BD-11 - Meaning lane stays separate. Source-local meaning starts with F.0.1 and uses F.17 only when a durable sense address or basis relation is needed; it is not a base-declaration record.
12. CC-BD-12 - Change claims name the changed object. Changing an assertion’s or reusable declaration’s ClaimGraph, exact EntityOfConcern, or effective ReferenceScheme identifies another episteme; representation-only editing need not. An actual relation change requires the direct relation’s own change predicate and any separately current Work.
13. CC-BD-13 - Optional history is proportional. declareBase, rebase, rescope, retime, or refreshWitnesses is used only when a named receiver needs that declaration history. The label establishes no world-side fact.

A.6.6:8 - Common Anti-Patterns and How to Avoid Them

A.6.6:9 - Consequences

Benefits

• A readable direct assertion can close an ordinary question without record-first work.
• Reusable declarations remain available when several consumers need the same participant meanings and laws.
• Scope, time, evidence, and continuity are explicit exactly where they change a predicate or receiving use.
• Evidence use, source-local meaning, semantic Bridges, plane crossings, and ordinary help keep their own ontologies.

Trade-offs and mitigation

• The author must identify the direct relation instead of hiding it behind support or anchor. The mitigation is one ordinary sentence and the direct predicate, not a universal form.
• A later replay or publication use may require more detail. Add only the missing declaration, qualifier, assertion, evidence, or occurrence identity at that point.

Adoption test (informative). A team has adopted A.6.6 when it can answer three questions in order: What are the actual participants and direct relation? Does its predicate hold for this case? Does a named later use require a reusable declaration, occurrence identity, scope, time, evidence, or history? A negative answer to the third question is a valid stop.

A.6.6:10 - Rationale

Why focus on base declaration rather than a metaphor. The recurring ambiguity is not “how to attach”, but which direct relation is being asserted between which participants. A readable relation-specific sentence exposes that answer; an optional declaration can then preserve it for a named reuse.

Why keep the direct relation, assertion, and evidence separate. The relation’s predicate determines whether the world-side fact obtains. A C.2.1 episteme may affirm or deny it under the applicable polarity test, and A.2.4/A.10 may support reliance on that assertion. Conflating these objects lets a record or carrier stand in for truth. A base is a participant in the selected direct relation. Evidence or other supporting material justifies an assertion only through its own direct relations. Conflating the two makes both reasoning and audit unreliable.

Why add scope and Gamma_time conditionally. They are required when the direct predicate or receiving use changes across extent or time. Adding them everywhere hides the ordinary relation behind a universal qualifier form. 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 retain a local declaration-change lexicon. When a named receiver tracks assertion or declaration history, the labels distinguish which episteme field changed. They are optional and do not describe actual relation change without the direct relation’s own predicate. When that history is needed, explicit change classes distinguish rebase, retime, rescope, and witness refresh; a generic edit label hides those differences and recreates the ambiguity A.6.5 removed at the slot layer.

A.6.6:11 - SoTA-Echoing

1. RDF-star and statement qualification. Adopt/Adapt. RDF-star/SPARQL-star explored attaching qualifiers/provenance to statements and edges. RDF 1.2’s Candidate Recommendation Snapshot of 7 April 2026 distinguishes representing a proposition from asserting that it holds. We adopt the “qualified statement” intuition, but adapt it by requiring an explicit relation kind and by making Γ_time and USM scopes explicit when the direct relation or receiving use needs them. Primary sources: Hartig and Thompson, Foundations of an Alternative Approach to Reification in RDF (first submitted 2014), retained as history and marked obsolete by its authors; RDF 1.2 Concepts and Abstract Data Model, Candidate Recommendation Snapshot, 7 April 2026.

2. Wikidata-style statements with qualifiers and references. Adopt/Adapt. Wikidata statements separate a core statement from optional qualifiers and references. We adopt that separation and adapt it by making decision-relevant basis requirements explicit through exact evidence-use relations, with slots only for a genuinely reused declaration, and explicit scope/time where the assertion or time-dependent use needs them. Primary source: Wikidata, Help:Statements.

3. Metrology traceability and calibration competence. Adopt/Adapt. Calibration is an operation relating a standard’s quantity values and uncertainties to indications, then using that information to obtain measurement results. Metrological traceability is a property of a measurement result related to a reference through a documented calibration chain. We retain the need for documented calibration evidence and adapt time-dependent applicability through explicit Γ_time and the witnesses or pinned calibration records required by the assertion or receiving use. Primary sources: JCGM VIM, calibration (2.39) and metrological traceability (2.41); ISO/IEC 17025:2017, edition confirmed in 2023.

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 source: OMG Structured Assurance Case Metamodel (SACM), version 2.3, October 2023.

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): the “object over a base” lens is the abstraction used to keep the pattern stable across domains (item 5).

A.6.6:12 - Relations

Specialises A.6.P Relational Precision Restoration. A.6.6 handles basedness wording by recovering the actual dependent, base, and direct relation, then stopping or opening only the additional object required by a named use.

Builds on A.6.REL and A.6.0. The direct pattern supplies relation obtaining and occurrence identity. A reusable RelationSignature is justified only for an already admitted relation kind and shared declaration content; the declaration form alone establishes no occurrence.

Builds on A.6.5 only when reusable declaration content is current. SlotKinds, ValueKinds, and reference modes type participant positions inside that RelationSignature; an ordinary one-case assertion needs no SlotSpec record.

Coordinates with A.2.4 and A.10. A.2.4 states the exact evidence-use relation. A.10 represents the independently established sources, Work, result epistemes, carriers, provenance, currentness, and later-use relations needed for bounded reliance. Neither pattern admits generic verifiedBy or validatedBy edges, and Work is not an evidence carrier.

Coordinates with A.14 and C.2.1. Constructive grounding and empirical grounding retain their exact direct predicates and participants. Their assertion epistemes and evidence remain separate from the world-side relations.

Coordinates with A.6.3 and A.6.4. A.6.3’s viewing construction keeps the source and receiving epistemes distinct with the same exact EntityOfConcern. A.6.4 retargets between different exact EntitiesOfConcern; its retargeting arrow r, bounded-use assertion q, current-case judgement, operation application, and Work remain distinct. Ordinary aboutness alone selects neither construction. A.6.6 adds no second arrow or universal relative-to object.

Coordinates with F.9 and ReferencePlane rules conditionally. F.9 applies only to an obtaining Bridge between two exact F.17 cells and keeps its bounded-use claim separate. A ReferencePlane crossing uses its applicable plane relation. If both are current, state both; if only one is current, introduce no object from the other branch.

Coordinates with A.2.6, A.7, and E.24.UK: A.2.6 governs scope and explicit Γ_time; implicit “latest/current” remains inadmissible. A.7 keeps EntityOfConcern, Description-episteme, specification use, and publication face, form, unit, carrier, and rendering distinct. E.24.UK supplies the kind-admission boundary applied in A.6.6:4.1.

Coordinates with C.3.3 and E.18. C.3.3 supplies U.KindBridge only for an independently established cross-local kind correspondence, with its exact kinds, direction, declared CL^k, and use/loss conditions; different participant kinds alone establish no KindBridge or silent re-typing. E.18 retains the meanings of its assurance operations on U.Transfer, including CalibrateTo, CiteEvidence, AttributeTo, and ConstrainTo; A.6.6’s declaration-change labels do not replace them.

Coordinates with E.8, F.0.1, F.15, and F.17: E.8 governs pattern-authoring order and SoTA discipline. F.0.1 recovers exact source-local meaning; F.17 supplies an optional durable sense address or basis relation. F.15 supplies the carrier/source-currentness, provenance, and refresh validation harness when that validation is current.

Feeds E.10, E.10.D1, and F.18 lexical governance. Umbrella words trigger recovery of the direct relation. Ordinary relation-specific prose remains valid; notation and durable public names are added only for a named use.

A.6.6:End