#Local-First Unification Naming Protocol

F.18 · Stable · Part F - The Unification Suite (U-Suite): Concept-Sets, SenseCells & Contextual Role Assignment

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Status: Stable Pattern state: stable pattern. Audience: engineer-managers, lead architects, ontology editors, and authors who must make one name reusable without turning that name into a hidden ontology.

Use F.18 when a name must become stable, public, Core-facing, reusable across contexts, or durable enough that later work can cite it without guessing. Typical cases:

#Relations

#Content

#Use This When

Use F.18 when a name must become stable, public, Core-facing, reusable across contexts, or durable enough that later work can cite it without guessing. Typical cases:

• a local expression becomes a durable name for a role, relation, slot, method, work, characteristic, status value, architecture element, or other already governed value;
• two teams use different words for the same candidate sense and need one reusable term plus preserved local wording;
• one tempting head word is useful in one context but misleading in another;
• a role-derived, method-derived, status-like, evidence-like, interface-like, or slot-like name risks creating a second ontology by wording alone.

First useful move: recover the exact governed object or governed value before choosing the name. When relation-facing wording is current, distinguish a predicate-definition episteme, an admitted relation kind, an obtaining relation occurrence, a representation element, and a designator or reference; for a residual relation claim, cite the A.6.RCD settlement before naming. Other candidates—such as a role, method, work, characteristic, status value, architecture element, or claim-bearing episteme—stay under their direct owners rather than being forced into that relation-facing list. Then ask: under which effective by-value U.ReferenceScheme, by which governing pattern, for which use, and with which exact local sense is this object named? Only then decide whether a local expression is enough or a NameCard is needed. A public row is a later step: create one only when public, Core-facing, durable-across-context, or cross-context reuse is current and the F.17 entry/result gate in section 4 passes.

Do not use F.18 for one-off wording repair. If the phrase is local and not becoming a reusable name, use E.10, E.10.ARCH, A.6.P, A.6.RSIR, C.2.P, or the governing pattern for the object being named. In particular, say in ordinary words whether one exact Bridge is suitable for one named use; do not create a NameCard, public claim kind, or durable CamelCase head merely to abbreviate that C.2.1 claim. Reopen F.18 for that claim only when an independent later use actually needs a reusable name beyond the local statement.

#Context

Names are handles for use, not creators of ontology. A good name lets people talk about a governed value without smuggling in extra role, capability, method, work, status, evidence, interface, or cross-context claims.

FPFCoreReferenceScheme is the by-value U.ReferenceScheme used to interpret current FPF Core Tech labels and relation names. A NameCard that uses it carries that reference-scheme value by value, consistent with C.2.1; F.18 does not introduce U.ReferenceSchemeRef. A name interpreted under another reference scheme carries that scheme by value. When a naming use must align two exact local senses, compare their <ReferenceScheme, LocalSenseClaim> projections. The same projection plus another expression is a designation question and gets no Bridge. Different projections—including the same scheme with different LocalSenseClaim values—open the F.9 question; a different scheme is only one such case and proves no Bridge. Test the exact F.17 cells and cite a Bridge only when its predicate actually obtains. State the proposed naming use separately in an exact current C.2.1 claim with that Bridge as EntityOfConcern and affirmative polarity; name the direction, correspondence rule, and tolerated loss. For ordinary bounded reliance below B.3's threshold and with no assurance claim, require the exact A.10 evidence-provenance graph relation plus RelianceDisposition=pass for that use. When an assurance claim is made or the threshold is met, follow B.3's first-claim decision and require either a current positive claim carrying that use with its sufficient record or an exact disposition that stops or narrows it; the threshold alone creates no positive claim. The named use is still claim content. Neither reliance route authorizes it or proves that it occurred. If it did occur, recover the actual Work under A.15.1, assertion episteme under C.2.1, publication occurrence under E.17, direct relation under its domain pattern, operation application under A.6.1, or another receiving object under its current owner. Name a BoundedModelUseStructure only when that selected structure changes the sense or naming use. Until the Bridge, separate claim, and required reliance are current, keep the names local or record the unresolved alignment. When no semantic-correspondence use is current, create no Bridge or use claim regardless of scheme count. A reference-scheme or model-use-structure difference alone supplies neither premise, governed-value identity, nor U.BoundedContext.

F.18 supplies the naming discipline for Part F and for any FPF pattern that needs a durable public term. It coordinates with:

• F.5 for type-name and role-description label form;
• F.8 for the prior decision that an expression should become a durable name rather than remain local, reused, or aliased;
• F.9 for an actual sense Bridge between different <ReferenceScheme, LocalSenseClaim> projections;
• F.13 for renames, aliases, splits, and merges;
• F.14 for anti-explosion control;
• F.17 only as a later public-row consumer whose current entry and result must accept the exact F.18 objects named below;
• A.6.5 and A.6.RSIR when relation, signature, interface, slot, or role wording hides the governed object; A.6.P.WMR when work/method-boundary wording still hides the exact relation; and A.15.1 when a candidate performed-work name still lacks occurrence grounding.

The central subject is one F.18 naming settlement for one exact already-governed value. F.18 governs the candidate comparison, selected Tech and Plain designations, declared naming use, and reopen conditions. The value's direct pattern still governs its kind, identity, obtaining, and other subject semantics.

Its complete claim graph records the selected designation expressions, exact local sense, covered and rejected alternatives, rationale, lineage, and reopen condition.

#Problem

FPF texts fail when names are treated as if they carried ontology by themselves.

1. A short label appears in another context and gets treated as the same value although no obtaining Bridge establishes the exact sense relation, no separate claim says that Bridge suits this reuse, and no current reliance supports that claim.
2. A role-looking name quietly bundles role value, holder assignment, capability, method fit, work evidence, or authorization.
3. A status-like or evidence-like phrase becomes a fake role or fake type because the row says "evidence role", "status role", or similar wording.
4. A relation, declaration-local slot, interface, port, or signature name hides the exact governed object, relation-participant meaning, or direct pattern that should own the claim.
5. A term chosen for convenience becomes a permanent Core-facing name without candidate comparison, rejected alternatives, or lineage.
6. Local names proliferate until the corpus has several almost-synonyms and no recoverable reason for choosing one.

The repair is not to choose prettier words. Recover the governed value, then record a naming settlement whose kind, effective reference scheme, exact local sense, intended use, and selected designations remain visible. Publication is a separate later relation.

#Forces

#Solution

Use a local-first naming protocol:

1. Recover the governed value, its kind, and its direct governing pattern.
2. Decide whether the expression should remain local or the current use needs a durable reusable name; apply F.14 before adding a card, cell, or row.
3. For a durable name, constitute one NameCard episteme under C.2.1; keep the value, its kind, the card, selected designations, exact local sense, and any basis or Bridge relation distinct.
4. Choose the Tech and Plain labels from the smallest candidate set that covers the live head-term families and plausible neighbouring objects.
5. Record the covered alternatives, rejected candidates, selection reason, lineage, and the smallest condition that reopens the settlement.
6. Only for public, Core-facing, durable-across-context, or cross-context reuse, test the then-current F.17 entry. It must accept the exact governed value and kind, NameCard episteme, by-value scheme, local sense, and any actual Bridge. Public or durable reuse alone creates no Bridge. When the named use relates different <ReferenceScheme, LocalSenseClaim> projections, F.17 must also accept the separate affirmative C.2.1 claim and current A.10 or B.3 reliance through the row rationale or notes rather than treating either as NameCard content. Its result must supply the required public row. If any required input or result is absent, retain the durable name and NameCard locally, mark the public row pending, and stop.
7. Keep the Bridge, the separate claim about its named use, A.10 or B.3 reliance, authorization, and any actual Work, assertion episteme, publication occurrence, direct relation, operation application, status, evidence, slot, role, method, or interface object under their own governing patterns. F.18 decides only the naming settlement.

#Naming Invariants

Every durable name must satisfy these invariants.

#NameCard Fields

A NameCard is complete when its exact C.2.1 identity-bearing U.ClaimGraph is recoverable; completeness is not a field count. The accepted D11 progressive-minimum cards NC-U-RELATION, NC-CROSS-CONTEXT-RELATION-STRUCTURE, NC-PROBLEM-CRITERION-APPLICABILITY-RELATION, and NC-PROBLEMATIC-FOR-RELATION remain conforming. Each already states the governed value and direct owner, effective scheme and local-sense claim, one selected Tech/Plain pair, candidate set, rejections, rationale, lineage, and reopen condition. Its direct owner makes the governed kind unambiguous. These filled claims together constitute the card's complete claim graph; an omitted expanded field contributes no hidden claim. Section 4.2a carries the four current expanded bounded-model-use cards.

Use the expanded form only when the current naming use needs the additional position:

NameCard:
  NameCardId:
  GovernedValueRef:
  GovernedValueKindRef: [add when the kind is not unambiguous from the value and direct owner, or a consumer needs the exact kind reference]
  GoverningPatternRef:
  ReferenceScheme:
  ClaimContent: [reference to the complete U.ClaimGraph constituted by all identity-bearing naming-settlement claims]
  LocalSenseCellRef: [add when a separately recoverable F.17 scheme-based SenseCell is current; otherwise LocalSenseRef carries the direct local-sense claim]
  LocalSenseBasisRelationRef: [add only for an actual separately governed basis relation]
  TechLabel:
  PlainLabel:
  CandidateSet:
  CandidateCoverage: [add when family coverage, an open alternative, or a forced exception must be explicit]
  RejectedCandidates:
  SelectionRationale:
  BridgeRefs: [add only for actual F.9 Bridge occurrences used to align exact local senses; no use direction, rule, tolerance, polarity, or reliance lives here]
  PublicRowStatus: [add when public-row use is current]
  UnifiedTermRowRef: [add only for a current row returned by section 4.4]
  LineageEntries:
  RefreshCondition:

Field discipline:

• The card is a [C.2.1](/generated/patterns/C.2.1) episteme. GovernedValueRef is its exact EntityOfConcern; the complete U.ClaimGraph constituted by all identity-bearing naming-settlement claims is its ClaimContent; and ReferenceScheme is the effective by-value U.ReferenceScheme under which that graph is interpreted. Changing any of those three identifies another card episteme. Changing only a graph designator, card designator, carrier, field order, or layout does not.
• In the expanded form, the ClaimContent field resolves to that complete graph; it is never a scalar summary beside other identity-bearing claims. The readable sibling fields designate graph nodes, edges, or projections. Changing a selected designation, declared use, local-sense claim, coverage, rejection, rationale, lineage, or reopen claim changes the graph and therefore the card episteme even if the displayed ClaimContent reference string stays the same.
• NameCardId designates the card episteme. It is not another identity discriminator and does not create a card kind.
• GovernedValueRef resolves to the exact already-governed object or value being named. GovernedValueKindRef is added when the kind is not already unambiguous from that value and its direct owner, or when a receiving use needs the exact kind reference. For relation-facing wording the value reference resolves to exactly one of the objects distinguished in section 5.6; a field label, card, table row, or local phrase is not a proxy for that object.
• GoverningPatternRef names the direct pattern that decides the value. [F.18](/generated/patterns/F.18) governs only the naming settlement recorded in the card; a pattern that merely presents or teaches the name governs neither the value nor this settlement.
• LocalSenseRef in a progressive-minimum card states the exact local-sense claim directly under the card's by-value scheme. LocalSenseCellRef in an expanded card resolves to the current F.17 coordinate <ReferenceScheme by value, LocalExpression, LocalSenseClaim> and does not require a context holon. LocalSenseBasisRelationRef is present only when a separately governed relation to a basis episteme is current; a source title, card field, or publication is not that relation.
• CandidateSet records the plausible labels considered by head-term family. When family coverage or an exception is not already recoverable from the set, rejections, and rationale, add CandidateCoverage to state which live families and neighbouring-object readings were tested and whether any plausible alternative remains open.
• RejectedCandidates records why tempting names were not selected. A usable alias is recorded in lineage as an alias, not left as a second selected Plain label.
• BridgeRefs contains only actual F.9 Bridge occurrences whose relation-semantic profiles obtain for the exact endpoint senses. It carries no naming-use direction, use-specific rule, tolerated loss, polarity, reliance, or permission. When naming across different semantic-context projections relies on a Bridge, recover the separate C.2.1 claim and its current A.10 or B.3 reliance outside the NameCard; omit BridgeRefs when the settlement makes no Bridge claim.
• PublicRowStatus is exactly one of localOnly, pending, or current when public-row use is current. UnifiedTermRowRef separately resolves to the exact row and is present only when status is current after the section 4.4 [F.17](/generated/patterns/F.17) entry/result gate passes. Omission in an accepted progressive-minimum card claims no row. A pending public use does not imply that a row already exists.
• RefreshCondition names the smallest value, kind, scheme, local-sense, Bridge, governing-pattern, use, or repeated-reader-error change that reopens this exact settlement.

Names such as "foundational principle pattern set", "FPF Core", "domain principle framework", and "local practice framework" require ordinary NameCard work before public stabilization under an effective reference scheme. Source aliases such as ZPF, SPF, TPF, or broad xPF labels remain intake aliases until [F.18](/generated/patterns/F.18) has settled the governed value and kind, by-value reference scheme, exact local sense, rejected candidates, and admissible short form.

#Current Bounded-Model-Use NameCards

The four expanded cards below are the current FPFCoreReferenceScheme naming settlements consumed by F.17:12.4d-12.4e. Each resolves to one exact current scheme-based F.17 cell and its separately governed local-sense basis relation. They publish designations for already governed values; they create no kind, structure, relation occurrence, assertion, Work, Bridge, use, reliance, row-availability occurrence, or other receiving action.

NameCard:
  NameCardId: NC-BOUNDED-MODEL-USE-STRUCTURE
  GovernedValueRef: BoundedModelUseStructure
  GovernedValueKindRef: U.Kind
  GoverningPatternRef: A.1.1
  ReferenceScheme: FPFCoreReferenceScheme
  ClaimContent: NC-BOUNDED-MODEL-USE-STRUCTURE.ClaimGraph — complete C.2.1 U.ClaimGraph constituted by all identity-bearing naming-settlement claims designated below
  LocalSenseCellRef: SenseCell.BoundedModelUseStructure.FPFCore.2026-07-25
  LocalSenseBasisRelationRef: LocalSenseBasisRelation.BoundedModelUseStructure.FPFCore.2026-07-25
  TechLabel: BoundedModelUseStructure
  PlainLabel: bounded context
  CandidateSet: BoundedModelUseStructure; ModelApplicabilityStructure; ModelUseRelationStructure; BoundedContextStructure; U.BoundedContext
  CandidateCoverage: exact dependent-structure head; applicability-only neighbour; use-only neighbour; DDD retrieval head; false holon-kind neighbour; no plausible live head family remains untested
  RejectedCandidates: ModelApplicabilityStructure omits actual use and fixed-content expression coherence; ModelUseRelationStructure collapses the wider organization into one relation family; BoundedContextStructure hides what is bounded and invites a container reading; U.BoundedContext falsely claims another holon kind
  SelectionRationale: the Tech label names the A.1.1 dependent U.Structure specialization selected from one exact model edition, admitted model-use holons, obtaining applicability, actual-use, and fixed-content expression-coherence occurrences, exact applied constraint claims, and one named frame; the Plain label retains DDD retrieval without adding a context bearer or any crossing to that identity
  PublicRowStatus: current
  UnifiedTermRowRef: UTS.BoundedModelUseStructure.FPFCore.2026-07-25
  LineageEntries: DDD bounded-context wording retained as the Plain retrieval label; U.BoundedContext holon, boundary-container, semantic-frame-bundle, and crossing-bearing readings retired; any crossing belongs only to a distinct A.22 structure over already identified bounded model-use structures
  RefreshCondition: reopen when the A.1.1/A.22 membership or continuity rule, one of the three direct relation kinds, the exact constituent, selected-occurrence, applied-constraint, or frame discriminator, FPFCoreReferenceScheme, the current F.17 cell or row, or repeated container or crossing overreading changes

NameCard:
  NameCardId: NC-MODEL-APPLICABILITY-RELATION
  GovernedValueRef: ModelApplicabilityRelation
  GovernedValueKindRef: U.Kind
  GoverningPatternRef: A.1.1
  ReferenceScheme: FPFCoreReferenceScheme
  ClaimContent: NC-MODEL-APPLICABILITY-RELATION.ClaimGraph — complete C.2.1 U.ClaimGraph constituted by all identity-bearing naming-settlement claims designated below
  LocalSenseCellRef: SenseCell.ModelApplicabilityRelation.FPFCore.2026-07-25
  LocalSenseBasisRelationRef: LocalSenseBasisRelation.ModelApplicabilityRelation.FPFCore.2026-07-25
  TechLabel: ModelApplicabilityRelation
  PlainLabel: this model applies to this holon within this claim scope
  CandidateSet: relation-kind heads {ModelApplicabilityRelation, ModelAppliesToRelation, ModelScopeRelation}; claim-or-predicate heads {ModelApplicabilityClaim, ModelApplicabilityPredicate}; temporal head {ModelApplicabilityInterval}
  CandidateCoverage: direct ternary relation kind; readable predicate direction; claim or predicate neighbour; scope-membership neighbour; derived temporal-extent neighbour; no plausible live head family remains untested
  RejectedCandidates: ModelAppliesToRelation suggests a binary relation and hides the participating claim scope; ModelScopeRelation mistakes A.2.6 scope membership for model applicability; ModelApplicabilityClaim and ModelApplicabilityPredicate name epistemic or semantic content; ModelApplicabilityInterval names the derived maximal continuous extent
  SelectionRationale: the Tech label names the direct relation kind over one model episteme, exact holon, and participating claim scope; the Plain sentence exposes the predicate while A.1.1 alone decides whether its applicability condition holds and reidentifies the maximal continuous occurrence, leaving scope membership, assertion, interval, and structure separate
  PublicRowStatus: current
  UnifiedTermRowRef: UTS.ModelApplicabilityRelation.FPFCore.2026-07-25
  LineageEntries: retains the A.1.1 relation-kind label; earlier broad applicable-model and context-boundary wording is not an alias; ModelApplicabilityInterval remains a local derived extent
  RefreshCondition: reopen when A.1.1 changes the participant kinds, applicability predicate, scope-alignment or model-scheme interpretation rule, temporal occurrence identity, FPFCoreReferenceScheme, the current F.17 cell or row, or the public receiving use

NameCard:
  NameCardId: NC-MODEL-USE-RELATION
  GovernedValueRef: ModelUseRelation
  GovernedValueKindRef: U.Kind
  GoverningPatternRef: A.1.1
  ReferenceScheme: FPFCoreReferenceScheme
  ClaimContent: NC-MODEL-USE-RELATION.ClaimGraph — complete C.2.1 U.ClaimGraph constituted by all identity-bearing naming-settlement claims designated below
  LocalSenseCellRef: SenseCell.ModelUseRelation.FPFCore.2026-07-25
  LocalSenseBasisRelationRef: LocalSenseBasisRelation.ModelUseRelation.FPFCore.2026-07-25
  TechLabel: ModelUseRelation
  PlainLabel: this assignment's holder uses this model during this work concerning this holon
  CandidateSet: relation-kind heads {ModelUseRelation, ModelUsageRelation, ModelApplicationRelation}; work-or-assignment heads {ModelUseWork, ModelUserRoleAssignment}; claim-or-record heads {ModelUseClaim, ModelUseRecord}
  CandidateCoverage: direct actual-use relation; availability-or-usage neighbour; applicability neighbour; Work neighbour; assignment neighbour; claim or record neighbour; no plausible live head family remains untested
  RejectedCandidates: ModelUsageRelation invites availability, access-count, or generic usage readings; ModelApplicationRelation collides with applicability and can suggest applying a method; ModelUseWork and ModelUserRoleAssignment name participants; ModelUseClaim and ModelUseRecord name epistemes about use
  SelectionRationale: the Tech label names the direct relation kind over one role-assignment occurrence, model episteme, performed Work occurrence, and use-locus holon; the Plain sentence exposes actual use by the derived assignment holder without adding that system as a fifth participant, while A.1.1 keeps applicability, assignment, Work, method application, claim, and record distinct
  PublicRowStatus: current
  UnifiedTermRowRef: UTS.ModelUseRelation.FPFCore.2026-07-25
  LineageEntries: retains the A.1.1 relation-kind label; availability, mention, method application, performed Work, role assignment, and use-claim readings remain separate and are not aliases
  RefreshCondition: reopen when A.1.1 changes the participant kinds, F.6 performed-under-assignment prerequisite, actual-use predicate, actor derivation, maximal-continuous-use identity, FPFCoreReferenceScheme, the current F.17 cell or row, or the public receiving use

NameCard:
  NameCardId: NC-MODEL-EXPRESSION-COHERENCE-RELATION
  GovernedValueRef: ModelExpressionCoherenceRelation
  GovernedValueKindRef: U.Kind
  GoverningPatternRef: A.1.1
  ReferenceScheme: FPFCoreReferenceScheme
  ClaimContent: NC-MODEL-EXPRESSION-COHERENCE-RELATION.ClaimGraph — complete C.2.1 U.ClaimGraph constituted by all identity-bearing naming-settlement claims designated below
  LocalSenseCellRef: SenseCell.ModelExpressionCoherenceRelation.FPFCore.2026-07-25
  LocalSenseBasisRelationRef: LocalSenseBasisRelation.ModelExpressionCoherenceRelation.FPFCore.2026-07-25
  TechLabel: ModelExpressionCoherenceRelation
  PlainLabel: this model content and this expression content satisfy this declared coherence criterion under this comparison scheme
  CandidateSet: relation-kind heads {ModelExpressionCoherenceRelation, ModelConformanceRelation, ModelImplementationRelation, ModelExpressionAlignmentRelation}; predicate-or-assessment heads {ModelExpressionCoherencePredicate, ModelExpressionCoherenceAssessment}
  CandidateCoverage: direct fixed-content relation; conformance neighbour; implementation or realization neighbour; weaker alignment neighbour; local predicate-value neighbour; evaluation or result neighbour; no plausible live head family remains untested
  RejectedCandidates: ModelConformanceRelation invites compliance or status readings and hides the declared criterion and permitted loss; ModelImplementationRelation suggests realization, production, or causation; ModelExpressionAlignmentRelation is weaker than the declared Boolean condition; ModelExpressionCoherencePredicate names the five-part criterion participant; ModelExpressionCoherenceAssessment names evaluation Work or a result episteme
  SelectionRationale: the Tech label names the participant-determined direct relation over one model episteme, expression episteme, admitted five-part predicate value, and comparison scheme; the Plain sentence exposes the truth test after either the same-scheme branch or the predicate-declared bridged branch is established, while maintenance, transformation, evaluation, result, evidence, and assertion remain separate
  PublicRowStatus: current
  UnifiedTermRowRef: UTS.ModelExpressionCoherenceRelation.FPFCore.2026-07-25
  LineageEntries: retains the A.1.1 relation-kind label; earlier maintenance-alignment and implementation wording is narrowed to separate Work, transformation, evaluation, result, evidence, and assertion objects
  RefreshCondition: reopen when A.1.1 changes the participant kinds, five-part predicate-value membership, same-scheme or bridged-comparison branch, permitted-loss rule, participant-determined identity, FPFCoreReferenceScheme, the current F.17 cell or row, or the public receiving use

All four current cards use one FPFCoreReferenceScheme cell apiece and therefore add no Bridge or use claim. If a named current use relates different <ReferenceScheme, LocalSenseClaim> projections, F.9 separately governs the obtaining Bridge, C.2.1 separately identifies the affirmative bounded-use claim, and A.10 or B.3 separately governs reliance; without that use, no Bridge or use claim is added. For ModelExpressionCoherenceRelation, an A.1.1 predicate may name an obtaining Bridge as a prerequisite of its bridged interpretation branch; a receiving assertion or structure selection that relies on that occurrence still needs its own bounded-use claim and reliance path. None of those objects becomes part of a NameCard or public row.

#Candidate Selection

Do not pick a durable label in one stroke or work toward a fixed candidate count. Build the smallest set that covers at least two live head-term families and every plausible neighbouring-object reading that could change the decision. Stop when each live family has a representative and no untested plausible alternative could overturn the selection. If a deadline forces closure while a plausible family or alternative remains untested, record that exception in CandidateCoverage and make it part of RefreshCondition.

Judge candidates on:

• semantic fidelity: does the label preserve the governed value without adding or losing required conditions?
• reader ergonomics: can the intended reader recognize, say, and remember it in the current situation?
• morphology fit: does the word shape fit the kind being named, for example role value, method, work, description, relation, slot, characteristic, or status value?
• alias risk: will a careful reader import a wrong sense from nearby FPF patterns or external practice?

Use these as ordinal comparisons. Do not average them into one score. If a Pareto-front or quality-diversity method is used, the dimensions and dominance rule must be visible on the card.

One candidate can win even when it is not perfect, but the SelectionRationale must say what it buys, what risk remains, and why the covered set is sufficient for this use.

#Public Term Rows

A durable local name needs no row. When public, Core-facing, durable-across-context, or cross-context reuse is current, test the then-current F.17 entry with the exact objects already recovered here. Public or durable reuse alone creates no Bridge. The entry must accept separate references to the governed value and its kind, direct pattern, NameCard episteme, selected Tech and Plain designations, effective by-value reference scheme, exact F.17 scheme-based SenseCell, any separate local-sense basis relation, and any actual F.9 Bridge. When the row use relates different <ReferenceScheme, LocalSenseClaim> projections, its rationale or notes must separately cite the affirmative C.2.1 claim for the row's exact action, direction, rule, and tolerance and that claim's current A.10 or B.3 reliance. Its result must return one row for one naming decision with the supported and blocked citation uses visible. If it cannot, keep the durable name and NameCard local and mark the public row pending. Do not repair or emulate the missing row inside F.18.

When that gate passes, keep these positions distinct:

• GovernedValueRef: the exact already-governed value;
• GovernedValueKindRef: its exact kind, never an alternative to the value reference;
• direct governing pattern;
• NameCard episteme and selected designation expressions;
• exact local-sense and basis-relation references;
• any actual Bridge occurrence;
• for reuse between different semantic-context projections, the separate affirmative C.2.1 claim about that Bridge and its current A.10 or B.3 reliance, cited in the row rationale or notes rather than absorbed into the NameCard;
• the row or row episteme, its edition, supported citation use, blocked use, and currentness condition.

The row is neither the governed value nor an agent of publication. When availability is needed, an E.24.PUB EpistemePublicationRelation occurrence makes the exact row-episteme edition available to a declared audience for a bounded use through a distinct publication form and presentation carrier. The form does not publish itself, and the row's currentness claim or relation remains separate from the availability occurrence.

A row for ReviewerRole points to the role value and its selected names; it neither creates the role nor makes an assignment obtain. A row for EvidenceUseRelation points to the admitted relation kind or other exact governed object; it does not make an episteme into a role or make the relation obtain. A row for SlotKind or EndpointSlot carries or designates selected vocabulary only after the exact slot object is governed; it neither makes that row edition available nor creates a generic interface ontology.

#Role, Assignment, Slot, and Status Naming Settlement

This settlement makes several naming boundaries explicit.

#Role Names

A durable role name names one governed U.Role value interpreted through one named role-taxonomy episteme under its effective by-value U.ReferenceScheme. If one selected model-use structure, role-relation structure, claim scope, or project-work relation changes the naming use, cite that object separately; the name does not create it. Good role names normally use role morphology, for example ReviewerRole, ShipbuilderRole, or ServiceProviderRole.

A role name must not include:

• the holder that fills a role assignment;
• capability evidence or skill level;
• method or method-family selection;
• performed work;
• status value or gate result;
• source, evidence, publication, or assurance use.

If a phrase such as SeniorReviewer, NightOperator, or source wording like evidence role appears, recover the governed values first. The result may be a role value, a holder assignment, a status assertion, an evidence-use relation, a work admission condition, or a local source phrase. Do not force all of them into one role name.

#Holder Assignment Names

A holder-assignment name denotes one already recoverable obtaining U.RoleAssignment occurrence governed by A.2.1; the role name itself does not identify that occurrence. Before naming it, recover its four actual participants: the admitted holder system, role value, role-taxonomy episteme, and effective reference scheme. Also recover the uninterrupted assignment episode. The currently known AssignmentInterval remains assertion- or occurrence-description content, not a fifth participant. A durable name uses a NameCard whose GovernedValueRef resolves to that occurrence. If public or cross-context reuse is needed, apply the section 4.4 gate; until it passes, retain the card locally and mark the row pending. Neither a name, card, row, nor publication occurrence makes the assignment obtain.

Holder#Role:Context@Window is source notation only. Recover the exact referent behind Context, its kind, and the direct relation that makes it relevant. A selected BoundedModelUseStructure stays in the receiving assertion or use and appears only when it changes interpretation. The token is neither a role name nor proof of assignment, capability, or performed work.

#Capability, Method, and Work Names

Keep these separate:

• ShipbuilderRole names a role value;
• ShipbuildingCapability names a capability of an admitted U.System, including an acting holon admitted as a system for that capability claim;
• ShipbuildingMethod names a method or method family;
• HullAssemblyWork names a work family or planning-level work label until an exact performed occurrence is current.

A role-derived or role-method-coupled expression is only a naming cue. First recover the exact value it refers to. If that value is an exact method or method family under A.3.1, choose a method name. If it is an exact U.MethodDescription, U.WorkPlan, or dated U.Work occurrence, name that description episteme, plan episteme, or occurrence separately under A.3.2, A.15.2, or A.15.1; those names are not method names. If the expression refers to another value, use that value's direct owner. F.18 chooses a durable name only after this recovery. A role relation may constrain who may use the method or perform the work; it neither creates nor names the method, description, plan, or work occurrence.

Treat an action nominal such as testing, assembly, maintenance, evaluation, or inspection as a morphology cue, not a governed kind. Placement in function- or flow-structure prose identifies no U.Function. If the function-like use remains claim-bearing while its exact object or relation is hidden, apply A.6.F; if it is already recoverable, name the exact method, method description, required-transformation or required-effect claim, actual U.Transformation, TransformationFlowStructure locus, functional-view record, plan content, performed-work occurrence, or other governed value under its direct pattern before F.18 selects a durable name. A WBS element, activity, or Work Package remains plan- or assignment-episteme content about intended work; none of these uses identifies a performed Work occurrence admitted under U.Work.

A durable name for exact performed work names one occurrence already grounded under A.15.1, not the action nominal or plan row. The current naming use must be able to recover the performer through an obtaining U.RoleAssignment, actual enactsMethod, temporal extent, exact containing system, affected referent, and the direct bindings and resource-use facts material to the occurrence. Add the exact continuity policy only when interruption, retry, changed method or bindings, or competing designators make occurrence identity material. Keep neighboring direct subject or resource-use claims, A.15.PROD production claims, measurement-result epistemes, evaluation results, C.11 choices or decisions, delivery occurrences, acceptance verdicts, and downstream-effect claims separately named under their direct governors.

When the underlying boundary wording still hides the relation, apply A.6.P.WMR. F.18 starts only after an exact governed value and its use are recovered through a direct subject relation, an exact A.6.1 application binding, or an exact local A.15.PROD/A.6.RCD claim. An exact non-assertability result independently records factually unsupported, missing-information, or missing-governor; none authorizes durable naming, and only missing-governor is an ontology blocker that names the affected use and future owner. This section selects and tests a name. It does not define a second work-occurrence or work-result recovery algorithm.

Method-relation and method-composition names are method-side names too. If a phrase names serial composition, parallel composition, guarded choice, iteration, refinement, substitution, decomposition, parameterization, method-family membership, fallback, or dispatch among methods, first decide which object the phrase names.

• If admitted submethods make one composite way of doing, name the composite U.Method. A.3.1 governs that Method, and its exact composition relation stays with B.1.5 or another direct composition owner.
• If the phrase names relations among methods without making one whole Method, select a U.Structure under A.22 and designate it MethodRelationStructure@BoundedContext. Each included composition, refinement, substitution, iteration, decomposition, family-membership, selector, fallback, description, or work-use relation stays with its direct A.3.1, G.5, A.15, or composition owner.
• If the current object is a separately identified episteme that describes one exact admitted Method, A.3.2 may classify it as U.MethodDescription; F.18 names that episteme separately from the Method.
• If an episteme instead describes the selected relation structure, C.2.1 keeps that structure as its exact EntityOfConcern; the episteme is not thereby a U.MethodDescription.

F.18 settles a durable name only after one of those exact objects has been recovered. Algebraic, graph, categorical, process-calculus, matrix, embedding, distributed, or neural notation names the lens or representation only when that lens is the governed value.

#Role-Relation, Method-Relation, Role-Method, and Lens Names

Role-relation expressions remain expressions or relations unless the direct role pattern admits a durable role value and the NameCard settles its by-value reference scheme and local sense. A role-algebra, graph, matrix, embedding, distributed, or neural description is a lens over the selected role relation structure; it is not automatically the named role, holder, method, or work.

First recover what the name is for:

#Status, Evidence, Source, and Publication Names

Status-like and evidence-like wording must go to direct patterns:

• status value or status assertion: F.10 or A.19.SPR;
• evidence-use relation: A.10;
• assurance use: B.3;
• source use: E.10.D2 or source-use patterns;
• description-episteme identity: C.2.1;
• multi-view publication face or form: E.17;
• availability of one selected edition, expression by a form, and bearing by a carrier: E.24.PUB;
• gate or admission result: the relevant gate, decision, or assurance pattern.

Do not name these as U.Role values unless a work-facing role value is actually current. "This standard plays the role of evidence" is repaired to the appropriate evidence-use, source-use, or status-use relation; it is not a work-role assignment for the standard.

#Relation, Slot, Interface, Port, and Signature Names

If a name touches relation, slot, interface, port, boundary, protocol, API, or signature wording, use A.6.RSIR and direct governing patterns.

• A.6.5 governs relation slot discipline and SlotSpecs.
• A.6.0 governs signatures and rule-governed declarations.
• A.6.M and architecture patterns govern module interfaces and architecture interfaces.
• A.6.F, transformation, and architecture patterns govern functional ports and functional structures.
• A.6.C, protocol, service-access, and commitment patterns govern API, protocol, and service-access cases.
• C.2.1 governs a claim-bearing interface-description episteme.
• E.17 governs a multi-view publication face or form.
• E.24.PUB governs availability of the selected edition and the separate form-expression and carrier-bearing relations.

Before naming a relation-facing object, keep these settlements distinct:

One token may be reused only where the reference scheme and local sense preserve these distinctions; it cannot collapse definition, kind, occurrence, representation, and designator into one object.

F.18 can settle a durable name for the recovered value. It does not decide which value the interface word names, create a public row, or make that row available.

#What Belongs In The Label

Belongs in the label:

• a head word that helps readers recognize the governed value;
• a stable qualifier that is part of the local sense;
• role morphology when the governed value is a role;
• relation, slot, method, work, or characteristic morphology when those kinds are current.

Does not belong in the label:

• numbers and thresholds;
• temporary admission state;
• holder identity;
• capability evidence;
• method fit unless the governed value is a method or method family;
• work occurrence;
• gate result;
• source or evidence authority;
• context label used as if it were universal.

Quick check: if removing the word changes only current admission, holder, evidence, date, or gate use, it does not belong in the durable label.

#Worked Cases

#Role, Holder, Capability, Method, And Work

A shipyard team wants one reusable name for the role used in shipbuilding work. It first separates the values that the source word "shipbuilder" could hide.

Recovered values:

• ShipbuilderRole, interpreted through the role-taxonomy episteme ShipyardProductionRoles-2026 under Shipyard-Production-Scheme;
• one holder-assignment occurrence under A.2.1, with its holder system, role value, taxonomy episteme, and scheme as participants and its known assignment interval stated separately;
• ShipbuildingCapability with envelope and measures under capability patterns;
• ShipbuildingMethod or method family under A.3.1; if a separately identified ShipbuildingMethodDescription : U.MethodDescription episteme is current, name it separately under A.3.2 only when its exact EntityOfConcern is that Method;
• HullAssemblyWork under work patterns.

Here HullAssemblyWork is a work-family label or a label in a plan or assignment episteme. A designator such as HullAssemblyWork-42@2026-07-15T09:10/11:35 names performed work only when the current record recovers its obtaining performer assignment, enacted method, temporal extent, containing system, affected hull referent, material bindings and resource-use facts, plus an applicable continuity policy when disambiguation is current. A changed hull state, measurement result, evaluation verdict, delivery occurrence, or acceptance verdict remains a separately governed and separately named value.

F.18 settlement: no separately recoverable F.17 coordinate is current for this local-only case, so the card states one direct LocalSenseRef using the expression shipbuilder role; the other candidates remain comparison alternatives, not extra sense coordinates.

NameCard:
  NameCardId: NameCard.ShipbuilderRole.ShipyardProduction.2026
  GovernedValueRef: ShipbuilderRole
  GovernedValueKindRef: U.Role
  GoverningPatternRef: A.2
  ReferenceScheme: Shipyard-Production-Scheme
  ClaimContent: NameCard.ShipbuilderRole.ShipyardProduction.2026.ClaimGraph — complete C.2.1 U.ClaimGraph constituted by all identity-bearing naming-settlement claims designated below
  LocalSenseRef: local expression `shipbuilder role`; sense claim: the ShipbuilderRole value interpreted under Shipyard-Production-Scheme
  LocalSenseBasisRelationRef: absent; no independently admitted local-sense basis relation is current for this case
  TechLabel: ShipbuilderRole
  PlainLabel: shipbuilder role
  CandidateSet: ShipbuilderRole; ShipbuildingCapability; HullAssemblyWorker; CertifiedShipbuilder
  CandidateCoverage: role head; capability head; holder-or-work head; certification-or-status head; no plausible live head family remains untested
  RejectedCandidates: ShipbuildingCapability; HullAssemblyWorker; CertifiedShipbuilder
  SelectionRationale: selected label names the role value without claiming capability, holder assignment, performed work, or certification
  BridgeRefs: absent; this local settlement makes no semantic-correspondence claim
  PublicRowStatus: localOnly; change to pending only if public or cross-context reuse opens and section 4.4 does not yet pass
  UnifiedTermRowRef: absent
  LineageEntries: initial durable settlement; source word "shipbuilder" split from capability, holder-or-worker, performed-work, and certification readings
  RefreshCondition: reopen if A.2 changes the role value, the taxonomy episteme or scheme edition changes its local sense, or repeated readers infer capability, assignment, work, or certification

The four candidates execute the section 4.3 stopping rule: each live head family is represented, and the already recovered method and work objects are not plausible alternative labels for this role value. The rejected candidates are not "worse synonyms." They name different governed values or add conditions not carried by this role value. If public, Core-facing, durable-across-context, or cross-context reuse becomes current, apply the section 4.4 gate. Until it passes, keep this card local and do not imply a row or publication occurrence.

#Engineer-Roboticist and Musician

A lab says: "Vasya is an engineer, does robot engineering, is therefore an engineer-roboticist. These are musical robots, and Vasya is also a musician, performs music, and teaches robots music."

Recovered values:

• Vasya as the admitted holder system; MusicalRobotLab_2026 is the lab and work locus in its direct relations, not a participant added to U.RoleAssignment;
• MusicalRobotLabRoles-2026 as the role-taxonomy episteme and MusicalRobotLab-Scheme as its effective reference scheme;
• an engineering role value or local engineering-role expression;
• robotics as a domain, practice, method-family, or work-field qualification of that engineering role expression;
• MusicianRole as an independent role value when music performance matters separately;
• robot-engineering method or work, music-performance work, and robot-music-teaching method or work under method and work patterns;
• an optional role-algebra, graph, matrix, embedding, or neural representation only if the project actually uses such a lens to describe the selected role relation structure.

If a durable qualified role value has been admitted, no separately recoverable F.17 coordinate is current for this local-only case, so the card states one direct LocalSenseRef using engineer-roboticist; robotics engineer remains a NameCard lineage alias and does not identify a second sense coordinate. Its naming settlement can be:

NameCard:
  NameCardId: NameCard.RoboticsEngineerRole.MusicalRobotLab.2026
  GovernedValueRef: RoboticsEngineerRole
  GovernedValueKindRef: U.Role
  GoverningPatternRef: A.2
  ReferenceScheme: MusicalRobotLab-Scheme
  ClaimContent: NameCard.RoboticsEngineerRole.MusicalRobotLab.2026.ClaimGraph — complete C.2.1 U.ClaimGraph constituted by all identity-bearing naming-settlement claims designated below
  LocalSenseRef: local expression `engineer-roboticist`; sense claim: the admitted engineering role qualified by the robotics work field under MusicalRobotLab-Scheme
  LocalSenseBasisRelationRef: absent; no separate source-bearing basis relation is current for this use
  TechLabel: RoboticsEngineerRole
  PlainLabel: engineer-roboticist
  CandidateSet: RoboticsEngineerRole; engineer-roboticist; robotics engineer; engineer and roboticist; RobotEngineeringMethod; engineer-roboticist-musician
  CandidateCoverage: Tech role head; two ordinary role-expression forms; method neighbour; compressed multi-role neighbour; no plausible live head family remains untested
  RejectedCandidates: engineer and roboticist; engineer-roboticist-musician; RobotEngineeringMethod
  SelectionRationale: Tech `RoboticsEngineerRole` and Plain `engineer-roboticist` are selected for this source-preserving lab use; robotics remains a qualification of engineering, musician remains a separate role assignment, and method or work names do not become role names
  BridgeRefs: absent; the card makes no semantic-correspondence claim
  PublicRowStatus: localOnly; change to pending only if public or cross-context reuse opens and section 4.4 does not yet pass
  UnifiedTermRowRef: absent
  LineageEntries: initial durable qualified-role settlement; `robotics engineer` retained as a Plain alias for the same value, scheme, sense, and declared use, not as a second selected PlainLabel; earlier local wording retained when no durable role value is admitted
  RefreshCondition: reopen if A.2 changes the role value, A.2.7 changes the qualification relation, the taxonomy episteme or scheme changes, or readers merge musician assignment, method, or work into this role name

The robotics qualification relation remains separately governed by [A.2.7](/generated/patterns/A.2.7); the card does not absorb it into role identity. If no durable qualified role value is admitted, keep engineer-roboticist as local ordinary wording rather than filling the card. In ordinary project communication, "Vasya is our engineer-roboticist and musician" is admissible when the two assignments remain recoverable. If the current object is a method, name RobotEngineeringMethod or the relevant method family under [A.3.1](/generated/patterns/A.3.1). If a separately identified RobotEngineeringMethodDescription : U.MethodDescription episteme is current, name it separately under [A.3.2](/generated/patterns/A.3.2) only when its exact EntityOfConcern is that Method. If the current object is performed work, name the work occurrence under [A.15.1](/generated/patterns/A.15.1). If public reuse becomes current, apply section 4.4; do not infer a current F.17 row from this local card.

#Method Relation Structure and Method Algebra Name

A lab says: "Use the robot-engineering method algebra: choose scouting, then calibration, then training; fall back to teleoperation if training fails."

Recovered values:

• one or more robot-engineering methods or method families under A.3.1;
• a method-family registry or selector outcome under G.5 when the family registry or selector result is current;
• MethodRelationStructure@MusicalRobotLab_2026 when the current claim is serial composition, guarded fallback, or family selection among methods;
• a method description when the source notation describes that structure;
• a C.29 mathematical-lens use when "algebra" is the selected representation for checking composition, fallback, or preserved/lost structure;
• work plan or dated work only when a concrete plan or occurrence is current.

F.18 settlement: RobotEngineeringMethod names a method or method family only when that is the governed value. RobotEngineeringMethodRelationStructure may be a Tech-register name for the selected method relation structure when durable naming is needed. RobotEngineeringMethodAlgebra names the lens only when the algebraic representation itself is the governed value. Do not use a role label such as RoboticsEngineerRole to name the method relation structure, and do not use "method algebra" to hide a work plan or performed work.

#Evidence-Like Source Phrase

A review table contains the phrase "model card evidence role".

Recovered values:

• a model-card episteme;
• an evidence-use relation to a target claim;
• possible source-currentness and assurance-use relations;
• no work-facing role unless an acting system is assigned one.

F.18 settlement: no durable role name is minted. If a public term is needed, first name the exact evidence-use relation, for example ModelCardEvidenceUse, with A.10 as governing pattern. Then apply the section 4.4 gate; until it passes, retain the durable relation name and NameCard locally and mark the public row pending.

#Interface-Like Source Phrase

A software team says "the payment interface owns customer identity".

Recovered candidates:

• module interface under A.6.M;
• API description or protocol under A.6.C;
• signature or SlotSpecs under A.6.0 and A.6.5;
• claim-bearing interface description under C.2.1;
• multi-view publication face or form under E.17;
• publication availability, form expression, or carrier bearing under E.24.PUB;
• responsible role assignment under A.2.1.

F.18 settlement: do not mint PaymentInterfaceRole. First recover which governed value the phrase names. Then name that value through its governing pattern.

#Cross-Context Name

Two teams use component, module, and unit for nearby meanings.

Recovered values:

• structural component under architecture and part-whole patterns;
• deployable module under module-interface patterns;
• management unit under organizational patterns.

F.18 settlement: first keep the three recovered values and their local labels separate. If only local speech is needed, stop there; do not name a claim merely because one team wants to explain the difference. If a public term use is proposed between different <ReferenceScheme, LocalSenseClaim> projections, identify the exact source and receiving F.17 cells and test the F.9 Bridge predicate between them. The same scheme with different LocalSenseClaim values qualifies; a different scheme only opens the question and never establishes the relation. When the Bridge obtains, state in ordinary C.2.1 wording whether it is suitable for this naming use, naming the direction, label-correspondence rule, tolerated loss, and polarity, and establish the current A.10 or B.3 reliance required by section 1. The Bridge does not choose the Tech label, the claim does not identify the governed value, and neither authorizes or performs publication. Only after those objects are current does section 4.4 send the naming settlement to F.17. If the F.17 gate fails, keep the name and card local and mark the row pending; if no correspondence use is current, stop with the local settlement and create no Bridge or use claim regardless of scheme count.

#Anti-Patterns And Repairs

#Conformance Checks

Use these checks before a durable name is reused in a pattern. If an F.17 row is current, run its own row checks after the section 4.4 gate; these F.18 checks neither create that row nor establish a publication occurrence for it.

Regression checks:

• When either the effective reference-scheme edition or the LocalSenseClaim changes, compare the resulting semantic-context projections. Re-check any obtaining Bridge, the separate claim about the named use between different projections, and that claim's current reliance; same-projection expression changes stay with designation, and no current correspondence use creates no Bridge or use claim.
• When a role description changes, re-check role name and any holder-assignment name.
• When a method, capability, work, evidence, or status pattern changes, re-check any name that borrowed morphology from that area.
• When repeated reader errors occur, reopen candidate comparison instead of adding aliases indefinitely.

#SoTA-Echoing

Source use was checked on 2026-07-23. F.18 uses only the following decision-governing lines; source prestige does not select an FPF value or name.

Currentness rule: when a direct value owner, C.2.1, F.9, A.10, B.3, or E.24.PUB changes the value, card, sense, Bridge, bounded-use claim, reliance, or publication boundary, reopen only the affected invariant, field, case, or check. A future F.17 edition is consumed only through section 4.4; its change does not reopen local NameCards unless their supported public citation use or object references change.

#Relations

Builds on F.0.1, F.1, F.2, F.3, F.5, F.8, F.9, F.13, F.14, F.15, C.2.1, and E.24.PUB.

Coordinates with:

• A.2, A.2.1, A.2.5, A.2.7, A.15, and A.15.1 for role value, role assignment, role state, exact role relation occurrences and selected RoleRelationStructure, role-algebra lens use, role-method-work alignment, and exact performed-work occurrence grounding;
• A.3.1 for method and method-family names; A.3.2 for a separately identified U.MethodDescription episteme whose exact EntityOfConcern is that Method, and for the description episteme's separate name;
• A.6.P, A.6.P.WMR, A.6.RCD, A.6.REL, A.6.5, A.6.RSIR, A.6.0, A.6.M, A.6.F, and A.6.C for relation-claim settlement, work/method-boundary relation recovery, relation-kind and occurrence boundaries, slot, signature, interface, port, and protocol names;
• A.10, B.3, F.10, E.10.D2, and C.2.1 for evidence-use, assurance-use, status-use, source-use, and description-episteme names;
• E.17 for multi-view publication-face and publication-form use;
• F.17 only after its current entry accepts the exact F.18 value, kind, card, and sense result and, for reuse between different semantic-context projections, the separate obtaining Bridge, affirmative C.2.1 use claim, and current A.10 or B.3 reliance; otherwise the local NameCard remains sufficient and the public row stays pending;
• E.24.PUB for the separate occurrence, form, carrier, audience, bounded-use, and currentness objects needed when an exact row-episteme edition is actually made available;
• C.16, C.18, and Part G search patterns when candidate comparison uses Pareto or quality-diversity vocabulary.

Constrained non-use:

• F.18 admits no new U-kind and creates none of the governed role, assignment, status, method, work, relation, signature, slot, interface, or other subject values it names. A NameCard is a separately constituted U.Episteme under C.2.1, not a kind minted by F.18.
• F.18 does not decide whether two values are the same across contexts. F.9 can establish an exact relation only between local senses whose <ReferenceScheme, LocalSenseClaim> projections differ; a separate C.2.1 claim and A.10 or B.3 reliance govern one proposed naming use between those projections; the direct value owner still governs any identity claim.
• F.18 does not turn a publication row, card, table, or glossary entry into the thing being named.

#F.18:End

Last Updated: 2026-08-05 — upstream FPF commit 3dbce514 (github.com/ailev/FPF)