Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 05:29:54 UTC · snapshot created 2026-10-03 05:30:57 UTC · last check 2026-10-03 06:15:20 UTC

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.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 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.
  • subjectPatternLocator names the pattern description containing the exact ClaimGraph that defines or constrains the value. F.18 defines 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.
  • 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 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, 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.