F.18:4.2 - 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 subject pattern, effective scheme and local-sense claim, one selected Tech/Plain pair, candidate set, rejections, rationale, lineage, and reopen condition. Its subject pattern 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 subject pattern, or a consumer needs the exact kind reference]
SubjectPatternLocator:
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 admitted under section 4.4]
LineageEntries:
RefreshCondition:
Field discipline:
- The card is a
C.2.1episteme.GovernedValueRefis its exactEntityOfConcern; the completeU.ClaimGraphconstituted by all identity-bearing naming-settlement claims is itsClaimContent; andReferenceSchemeis the effective by-valueU.ReferenceSchemeunder 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
ClaimContentfield 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 displayedClaimContentreference string stays the same. NameCardIddesignates the card episteme. It is not another identity discriminator and does not create a card kind.GovernedValueRefresolves to the exact already-governed object or value being named.GovernedValueKindRefis added when the kind is not already unambiguous from that value and its subject pattern, 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.subjectPatternLocatornames the pattern description containing the exact ClaimGraph that defines or constrains the value.F.18defines only the naming-settlement predicate recorded in the card; a pattern that merely presents or teaches the name defines neither the value nor this settlement.LocalSenseRefin a progressive-minimum card states the exact local-sense claim directly under the card’s by-value scheme.LocalSenseCellRefin an expanded card resolves to the current F.17 coordinate<ReferenceScheme by value, LocalExpression, LocalSenseClaim>and does not require a context holon.LocalSenseBasisRelationRefis present only when a separately governed relation to a basis episteme is current; a source title, card field, or publication is not that relation.CandidateSetrecords the plausible labels considered by head-term family. When family coverage or an exception is not already recoverable from the set, rejections, and rationale, addCandidateCoverageto state which live families and neighbouring-object readings were tested and whether any plausible alternative remains open.RejectedCandidatesrecords why tempting names were not selected. A usable alias is recorded in lineage as an alias, not left as a second selected Plain label.BridgeRefscontains 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; omitBridgeRefswhen the settlement makes no Bridge claim.PublicRowStatusis exactly one oflocalOnly,pending, orcurrentwhen public-row use is current.UnifiedTermRowRefseparately resolves to the exact row and is present only when status iscurrentafter the section 4.4F.17entry/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.RefreshConditionnames the smallest value, kind, scheme, local-sense, Bridge, subject-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 has settled the governed value and kind, by-value reference scheme, exact local sense, rejected candidates, and admissible short form.