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.