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

Preface node heading:a-6-p-8-common-anti-patterns-and-how-to-avoid-them:13685

What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

Content

Anti-patternWhy it failsRepair
“Just define the umbrella word”Definitions do not separate arity, operation classes, or viewpoint asymmetry.Replace umbrella use with explicit RelationKind + qualified record + change lexicon.
Keep the umbrella verb, add adjectivesAdjectives are not relation specifications; invariants remain unstated.Mint or select distinct RelationKind tokens; enforce rewrite discipline.
Leave a FPF-governed generic head uninterpretedReaders cannot tell what kind of thing the phrase governs, so later qualifiers float without an ontology.Restore the head kind first in source-local terms; only then repair the remaining relation or comparison reading.
Let a qualifier smuggle the real claim kind or admissible-use boundaryA phrase like "comparative note", "safe guidance", or "reliable output" sounds precise while leaving the actual relation, comparison reference set, or authority-reference requirement implicit.Unpack the qualifier into explicit comparison reference set, relation kind, admissibility condition, or L, A, D, and E-classified claim before any claim requiring explicit relation, admissibility, authority-reference relation, or reliance.
Treat support as the recovered kind or relationSupportRecord, support source, support line, support relation, or supported use can sound precise while hiding whether the claim kind being made or admissible-use boundary is evidence path, source-use relation, admissible-use boundary, assurance claim, causal-use relation, decision help, publication help, C.29 lens-use result, characteristic construction, or ordinary orientation.Recover the governing claim kind named by value or admissible-use boundary and governing pattern first: evidence path, E.17:5.1b source relation or claim-admissibility vocabulary, relationClaimSlice, admissibleUse, projectSideFPFRef, assurance claim, causal evidence path or causal-use verdict, C.29 lens-use result, characteristic construction, bridge or comparison relation, or companion-only reader function. Use support-headed wording only when that local pattern named by value defines the field or record and states admissible and non-admissible use.
Leave pronominal and metonymic endpoints implicitEndpoint identity or facet remains guesswork; slot typing cannot stabilise.Reconstruct candidate referents and facets (capture as a Candidate‑Set Note); add explicit slots and references; then rewrite (A.6.8 is the archetype for “service” polysemy).
Ontology only, no lexical guardrailsProse re-collapses meaning.Add red-flag tokens + prohibited umbrella use in Tech or normative prose.
Lexicon only, no structural lensBecomes subjective policing.Introduce stable lens + slot schema; then attach guardrails.
Solve viewpoint mismatch by renaming endpointsSilent re-typing breaks cross-pattern reuse.Keep endpoint positions stable; use explicit kind selection + explicit repair options.
Using “bind” to mean “edit relation”Collapses name-binding vs slot-writing classes.Reserve bind and rebind for names; use change lexicon / slot verbs properly.
Implicit “current” or “latest”Violates explicit time discipline.Add explicit Γ_time where time matters.
Treat Γ_time as witness freshnessTime selection does not equal evidence freshness or decay; this conflates time discipline with evidence relations.Keep Γ_time for temporal scope; express freshness or decay via witness metadata and carrier-referenced E-claims.
Collapse search-space refs, declared-substrate interpretive views, and publication forms into one space or viewSearch-space refs, outcome-space refs, declared-substrate interpretive views, and source sets and set results become indistinguishable, so later claims lose their primary EntityOfConcern or relation named by value or claim record.Restore the declared CharacteristicSpace, any SearchSpaceRef and OutcomeSpaceRef, the active source set or active set result, the declared-substrate interpretive view or atlas view if any, and any OutcomeMapRef or BridgeDistortionNote before making the claim.
Compare across mixed kindsPublicationUnit, project record, process, authority-use claim, or source-use claim gets ranked on one comparison reference set before its kind and governing requirement are restored.First restore head kind, then qualifier-carried claim, then rewrite the sentence through the evidence path named by value, threshold, transfer condition, admissible-use boundary, or source-description claim wording so the comparison reference set is homogeneous.

Worked repair slice — NQD and OEE space, view, and publication stack.

Draft: “The archive projects into the outcome space through the atlas view.”

Repair sequence:

  • TraditionArchive = derived retention view over one declared palette.
  • OutcomeSpaceRef = guarded role reference to the declared CharacteristicSpace used for outcome-side judgment.
  • TraditionAtlasView = optional related interpretive view, not the default meaning of the archive.
  • OutcomeMapRef = explicit source-to-outcome map ref if the passage must show how the archive maps into one outcome-side or effect-side declared space or reference.

Canonical rewrite:

  • Keep TraditionArchive as the source set for the set publication.
  • Cite OutcomeSpaceRef only when the claim is about outcome-side evaluation against the declared CharacteristicSpace.
  • Cite OutcomeMapRef only when the source-to-outcome relation or named map ref itself matters.
  • Use TraditionAtlasView only if several declared views or qualifiers must stay visible together; otherwise leave the passage at archive-first or palette-first precision.

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