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 07:20:10 UTC

E.10:7.5b - Role-Precision Token Classes and Allowed Uses

The eight selected names below are KernelToken values under FPFCoreReferenceScheme. Each names one value already defined or constrained by its subject pattern; the lexical rule admits no kind, relation occurrence, declaration, judgment, description, structure, NameCard, row, or publication occurrence.

U.NameTokenLEX.TokenClassNamed value and subject patternStable admitted use
U.SystemRoleAssignmentKernelTokendirect assignment family under A.2.1exact Core definition, directly declared species, typed reference constraint, conformance check, worked case for the same family, F.18 NameCard, or F.17 row
KindUseAdaptationDeclarationKernelTokenC.3.4 declaration-episteme familyexact Core definition, typed declaration or constraint, conformance check, worked case for the same family, F.18 NameCard, or F.17 row
KindUseAdaptationCorrespondenceDeclarationKernelTokenC.3.4 correspondence-declaration familyexact Core definition, typed declaration or constraint, conformance check, worked case for the same family, F.18 NameCard, or F.17 row
KindUseAdaptationJudgmentKernelTokenC.3.4 three-valued judgment familyexact Core definition, typed judgment or constraint, conformance check, worked case for the same family, F.18 NameCard, or F.17 row
SystemRoleKindDescriptionKernelTokenF.4 description-episteme constructionexact Core definition, typed description or constraint, conformance check, worked case for the same construction, F.18 NameCard, or F.17 row
SystemRoleAssignmentStateRelationKernelTokenA.2.5 direct relation kindexact Core definition, directly declared relation use or typed constraint, conformance check, worked case for the same relation, F.18 NameCard, or F.17 row
SystemRoleAssignmentStatePredicateKernelTokenA.2.5 predicate-value familyexact Core definition, directly declared predicate use or typed constraint, conformance check, worked case for the same family, F.18 NameCard, or F.17 row
SystemRoleKindRelationStructureKernelTokenA.2.7 selected-structure constructionexact Core definition, typed structure use or constraint, conformance check, worked case for the same construction, F.18 NameCard, or F.17 row

For all eight names, Plain wording that silently turns the token into a neighboring object is prohibited. Reuse under another local practice, source, scheme, or meaning uses that value’s own identity and designation rules; when two exact cells are compared, any Bridge and use claim remain separately admitted. A change to the named value, TokenClass classification, or stable allowed-use rule reopens only the affected NameCard and row. A collision or conformance result for one dated corpus or candidate is evidence for its publication decision; it is not a reusable lexical rule or a currentness participant in the public pattern.

SystemRole alone is not a universal token with its own FPF kind or a NameCard subject. It is common morphology inside a concrete local designation such as ReviewerSystemRole. C.3 and A.2 recover that kind through its system-candidate domain, operative work-facing membership condition, intended member/non-member boundary, and continuity rule; practice or source provenance only locates or prompts comparison of the definition. AssignedSystemRoleKindSlot, SystemRoleAssignmentSlot, and fields ending in ...SystemRoleKindRef or ...SystemRoleAssignmentRef remain declaration-local ContextToken uses; the token-class name adds no Context object, and the fields are typed by existing U.KindRef or U.RelationRef, not by newly minted RefKinds. J_kindUse remains local notation. None receives a public row merely because the spelling recurs.