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 11:52:20 UTC · snapshot created 2026-10-03 11:53:41 UTC · last check 2026-10-03 13:35:10 UTC

E.10:8.1 - Reserved suffixes (gated by LEX.TokenClass, EntityOfConcern and Description-episteme boundary, and specification use)

Use tables as a whitelist. Rows indicate when a suffix is permitted and what it means. The EntityOfConcern and Description-episteme boundary and specification-use gate prevents EntityOfConcern, Description episteme, specification use, and publication-relation confusion; “Examples” are illustrative.

SuffixKind named by suffixEntityOfConcern and Description-episteme boundary and specification-use gateLEX.TokenClass gateExamplesTypical inadmissible uses
SystemRole (compound ending)One exact local system-role kindThe kind is independently admitted under C.3 and A.2 through its U.System candidate domain, operative work-facing membership condition, member/non-member boundary, and continuity rule. Practice or source provenance only locates or prompts comparison of the definition. The name supplies no assignment, agency, capability, or Work.ContextTokenTransformerSystemRole, ApproverSystemRoleBare ...Role; participant, declaration, representation, evidence, status, standard, source, constraint, commitment, or publication-use readings.
MethodOne semantic way of doingEntityOfConcern sideKernelToken or ContextTokenSteriliseInstrumentMethodAttaching an episteme edition or carrier version to the Method. When one exact method-description edition matters, use a separate governed U.EpistemeRef and only the narrow edition selector defined by A.3.2; keep tooling and carrier versions separate.
MethodDescriptionClaim-bearing episteme about one exact admitted methodDescription episteme only when its claims make at least one substantive statement about that method as a way of doingKernelToken or ContextTokenSteriliseInstrumentMethodDescriptionAdmission by recipe, procedure, algorithm, code, diagram, document form, or label; calling it “process”; encoding runtime actuals; embedding an edition or carrier version in the conceptual name.
...SpecTestable specification (acceptance-bound)Description episteme admitted for specification useKernelToken or ContextTokenMethodSpec, TransformationFlowStructureSpec, SystemSpecUsing “Spec” without acceptance tests or harness; treating formal notation alone as specification; putting runtime actuals here.
WorkWork occurrence kind or an occurrence classified under itU.Work is the admitted world-side kind; one Work individual is a dated occurrence. A run log, ticket, assertion, description, or record about it is a separate U.Episteme.KernelToken for the kind; ContextToken for an individual or record with an explicit distinguishing headU.Work; W#Seam134WorkOccurrence; W#Seam134WorkRecordPlans and schedules; design-time recipes; using a run record as the occurrence; defining a Work subkind by an act label; storing actual relations as occurrence fields.
WorkPlanClaim-bearing episteme coordinating possible future performed workSame-individual dependent kind of U.Episteme only when A.15.2 recovers one present EntityOfConcern, one horizon, at least one PlanItem, and substantive coordination claimsContextToken after membershipMaintenanceWorkPlan_Q3 only after the A.15.2 gateAdmission by schedule, window, planned item, ticket, calendar, or plan-record form alone; logging actuals; claiming execution.
Service (recovery trigger only)No kind is named by this suffix before recovery; afterward use the head that names the recovered object or relationApply L-SERV and A.6.P:4.11a to recover the promise content, commitment, bearer, Method, Work, acceptance, publication or API description, or direct relation actually used; preserve the EntityOfConcern/Description-episteme boundary and specification-use gate under the pattern for that claim.Trigger wording only; any retained ContextToken must already name the recovered object or relation and its useobject-storage service promise; passport-issuance service-access claimUsing Service as a final durable head-kind; naming teams or APIs as Service; treating the possible readings as one bundle.
CapabilitySystem abilityEntityOfConcern sideKernelToken or ContextTokenScheduleGenerationCapabilityMislabeling system-role kinds, assignments, or methods as capabilities.
DynamicsClaim-bearing episteme stating a state space and transition lawSame-individual dependent kind of U.Episteme under A.3.3; the changing subject is its EntityOfConcernKernelToken or ContextToken after membershipLotkaVolterraDynamicsAdmission from a change label alone; confusing the model with the changing subject, a Capability or a Method.
ObservationObservation record or kind(run record; not EntityOfConcern and Description-episteme or specification use)ContextToken or DiscriminatorTokenVibrationObservationMixing with MethodDescription or Evaluation.
EvaluationEvaluation episteme or evaluation recordDescription episteme or Description episteme admitted for specification useContextToken or DiscriminatorTokenCalibrationEvaluationUsing to name system-role kinds, assignments, or methods.
EvidenceRole (retired trigger only)Source evidence-role wording; recover evidence-use, source-use, status-use, assurance-use, gate-use, or publication-use relation.Trigger wording, not a system-role kindTrigger wordingevidence-use, status-use, source-use, or publication-use relation named by its direct patternUsing as a system-role kind, U.SystemRoleAssignment, or generic evidence.
EpistemeEpistemic knowledge unit (structural)Description episteme or Description episteme admitted for specification useKernelToken or ContextTokenTraceabilityEpistemeColliding with CHR ReferencePlane (never suffix “Plane”).
System or HolonSubstantial entityEntityOfConcern sideKernelToken or ContextTokenAnesthesiaSystem, OrderFulfillmentHolonUsing to denote a source, scheme, local-use qualifier, or run record.
BoundarySystem boundaryEntityOfConcern sideKernelToken or ContextTokenSterileFieldBoundaryUsing as a system-role kind or method.
ObjectiveTarget stateEntityOfConcern side or Description episteme side, depending on formalizationKernelToken or ContextTokenHemostasisObjectiveEncoding acceptance tests in the objective. Put tests in the specification governed by their actual subject; use MethodDescription or MethodSpec only when that subject is one admitted U.Method, A.3.2 membership holds, and the specification-use gate is present.
Requirement (trigger only)No FPF-wide suffix meaning. Recover the constraint, commitment, completeness condition, result expectation, dependency, sufficiency condition, availability or relevance state, or coverage constraint.Trigger wording; a durable local-use token exists only after its lexical admission rule is satisfied.Trigger wording or a ContextToken named for the recovered constructionlatency constraint under its constraint pattern; U.Commitment when accountable undertaking is currentPublishing Requirement as a general head or suffix; treating unlike constructions as one kind.
Context or BoundedContext (trigger or established source term only)No FPF-wide kind or card is named by this suffixApply E.10.D1. For the established DDD term, use A.1.1 and name the exact model-use relations or selected BoundedModelUseStructure; for another use, name the actual source, scheme, scope, situation, frame, or local practice that changes the action.Trigger wording or an already admitted local-use tokenquoted DDD bounded context; source label retained as source wordingMinting U.BoundedContext, a mandatory Context Card, or a generic identity container.
surface (trigger only)Not a durable Tech head by itself; recover publication face, form, unit, carrier, rendering, UI face, physical surface, geometric surface, or another FPF object named by value.publication availability or ordinary source wordingTrigger wordingpublication face, interop publication form, carrier relationStructureSurface, MechanismSurface, PortfolioSurface
CardUTS or record unit (episteme)Description episteme, Description episteme admitted for specification use, or publication-unit use, depending on FPF kind named by valueContextTokenMethodCard, ExternalIndexCardEncoding runtime actuals; using as a ‘Service’
E.10:8.1.1 - Suffix conventions and retained-family boundaries
SuffixLexical classMeaning and ontologyWhere it livesExamples and notes
SpaceEntityOfConcern-side kindA typed state space (finite product of declared Characteristic×Scale components); no proceduresKernel A.19; CHR and space consumersCharacteristicSpace, CreativitySpace. Any episteme that defines or describes the Space remains separately identified. A selected definition edition is itself one exact U.Episteme; the Space is not editioned.
SpaceRefPointerGoverned reference to one exact SpaceDirect reference pattern; data fields and UTSCharacteristicSpaceRef resolves to the exact Space. When a use depends on one exact Space-definition episteme, carry a separate governed field typed by U.EpistemeRef whose referent is that episteme; only its direct reference pattern may define a narrow edition selector.
MapEntityOfConcern-side kind (method)One exact mapping U.Method from subjects to coordinates in a declared SpaceA.3.1 and the method-family pattern; Description epistemes remain separateDescriptorMap names the method only after A.3.1 admission. A claim-bearing episteme about that exact method may separately qualify as U.MethodDescription; a representation, record, or file does not.
MapRefPointerGoverned reference to one exact mapping U.MethodDirect method-reference pattern; data fields and UTSDescriptorMapRef resolves to the method. If the use depends on one exact method-description episteme, carry a separate governed field typed by U.EpistemeRef; do not attach an edition selector to the method reference.
DefRegistry-local alternate tokenA direct CG-Spec registry may use …Def for one exact governed definition or specification item; the suffix alone does not decide whether that item is an episteme, formal object, method, formula, or publication formExact CG-Spec registryDistanceDef is admissible only inside the registry that defines its referent kind and use. Prefer …Spec in new normative prose when an exact Description episteme has actually been admitted for specification use; do not generalize …Def as an FPF-wide suffix.
DefRefPointerRegistry-local reference whose exact referent kind and RefKind are defined by the direct CG-Spec registryExact CG-Spec reference pattern; data fields and UTSDistanceDefRef is admissible only when that registry says what it resolves to. If a use must pin one exact CG-Spec episteme, carry a separate governed field typed by U.EpistemeRef and use only a selector defined by that registry’s direct reference pattern for that episteme edition. Do not treat …DefRef as a global synonym for …SpecRef.
SpecDescription episteme admitted for specification useTestable invariants bound to acceptance harnessesE.10 and A.21Stable, testable definitions; normative by default; admitted for specification use. Use for normative calculi plus scoring and normalization specifications.
SlotRelation-declaration suffixDeclaration-local SlotKind inside one exact A.6.5 SlotSpec of a reusable RelationSignature; it distinguishes one relation-participant meaning and is neither the actual participant nor a representation placeA.6.0 RelationSignature; A.6.5 SlotSpec declarationEntityOfConcernSlot, GroundingHolonSlot. A mathematical operand or argument place remains a C.29 representation element until explicit correspondence; operation argument and result declarations remain under A.6.1. Position and place are not alternate FPF names for a declaration slot.
RefPointerReference or identifier whose RefKind is admitted by its direct reference pattern; a receiving assertion or relation-occurrence-description episteme may carry a field typed by that RefKind to designate an actual participant, but the reference, field, and participant remain distinctDirect reference pattern; receiving episteme fields and UTSU.EntityRef, U.HolonRef; episteme fields …Ref : U.EntityRef. …Ref never carries content and is never a ValueKind, SlotKind, or actual participant.
SeriesConditional collection or structure labelNot an edition mechanism. Several exact EpistemeEditionRelation occurrences may be selected as a lineage structure only when one named receiving use depends on their organization; any selected edition collection and its membership remain separateC.2.1 with A.22 for the selected structure and A.14 for any collectionDo not mint U.EditionSeries; order, shared title, or collection membership establishes no edition continuity.
edition selectorReference selector defined by its direct patternOptional only on a governed reference whose referent is one exact U.Episteme and whose direct reference pattern defines the selector; it selects an already recoverable edition and establishes neither episteme identity nor historical continuityDirect reference pattern and C.2.1signatureRef.edition is admissible where A.6.0 defines that narrow selector. Do not infer a universal <Thing>Ref.edition property.

Notes.

  • Kernel‑only ban list remains in § 8.3.
  • CHR guard: the only token that may use the word plane is CHR:ReferencePlane.
  • Axis and dimension metaphors are not selected FPF heads; use Characteristic only for one declared measured aspect. For an enumeration, name its closed value set, classified kind, and classification rule; use CharacteristicSpace only when that enumeration is the declared CSLC scale of the named Characteristic (see § 7).

Not only suffix guard

  • Suffixes are closely related to kinds and should be clearly guarded by MG-DA.
  • Other morphemes, not only suffixes, also respect kinds. Use Space for a space construction defined by its subject pattern; an A.19 CharacteristicSpace is a product of declared Scale value sets and need not have a geometric overlay. Prefer Set, Kind or Kit when only membership is intended.

L-EPI-PUB — episteme, publication, view, carrier, direct-relation, representation, and authority-reference discipline

  • Use U.Episteme for the claim-bearing unit. U.EpistemePublication is a rejected kind name: when the selected edition is available as a published episteme, name or make recoverable its exact EpistemePublicationRelation occurrence, publication form, bounded use, and carrier under E.24.PUB. The rejected spelling may remain only in an explicit rejection explanation or a negative test, never as a positive object, kind, reference, or field.
  • Name the publication form separately from the episteme: for example PreArticulationCuePack, U.AbductivePrompt, typed bounded projection, partial normal form, endpoint-specific publication form, or another declared form. A publication form is not itself the governing FPF source.
  • Name U.View and MVPK face separately from the publication form. A PlainView, TechCard, InteropCard, or AssuranceLane is an episteme-level view or publication face, not the source claim, not the publication form itself, and not the SCR or RSCR carrier.
  • Name the carrier or rendering relation separately. Documents, dashboards, generated screens, trace files, cards, and transport formats hold or render a publication; they are not the U.Episteme, not the claim or effect being relied on, and do not supply the rule for that claim.
  • Name source-finding cues separately from source epistemes. A cue, badge, credential view, dashboard tile, heading, signature-looking mark, or generated explanation may help find a source; it does not by itself create an authoritySourceRef target, evidence relation, gate decision, assurance claim, exact U.SystemRoleAssignment occurrence, status assertion, Work occurrence, deontic permission, or Work authorization.
  • Use an ordinary PatternID reference when a reader only needs to find the rule. Add relationFunctionClaimRef and the defining or constraining ClaimGraph only when admissible interpretation, comparison, migration, publication, or reuse depends on that exact rule identity. Use authoritySourceRef when a non-pattern target such as an external standard, editioned register, DRR, gate decision, policy record, system-role-assignment register, or status register carries the relevant authority. Do not use generic sign, source, project-work, or container-placement wording as solution terms.
  • When a published episteme is used for work, name the P2W chain element being used: intended method family, selected method or method of work, one exact U.WorkPlan baseline, planned work, or one actual Work occurrence admitted under U.Work. Then name any separate claim-bearing episteme about that occurrence and any separately current direct resource-use, affected-referent, operation-application, measurement, evaluation, decision, delivery, acceptance, or receiving-use relation under the pattern that defines it; when a production-work, entity-inception, or production-completion claim is current, name one local A.15.PROD claim instead of implying a universal production relation. Apply A.6.P.WMR only while one such Work-to-Method boundary relation remains hidden after generic relation recovery. Do not let generic action, use, material, work result, or result measurement hide that distinction.
  • Use C.2.P when episteme-publication-heavy wording carries an episteme, publication, view, carrier, relation, admissibility, evidence, work, gate, decision, method, or pattern-use claim. E.10 keeps the lexical and naming discipline; C.2.P recovers the FPF kind; obtaining relation and participants; receiver-needed occurrence; reusable A.6.5 declaration; claim-bearing episteme and participant designations; C.29 representation and correspondence; or project-side FPF kind and reference. Ordinary wording may close locally when it carries no such FPF claim.

Publication face, form, unit, and carrier discipline - surface as trigger wording

  • Definition. surface is trigger wording, not a durable FPF Tech head by itself. When it has FPF-governed use, recover whether the sentence means publication face, publication form, publication unit, carrier, rendering, UI face, front-end face, physical surface, geometric surface, companion publication, projection material, carrier relation, or another FPF kind or relation named by value.
  • Allowed final heads: publication or carrier terms named by value, or deliberately ordinary physical or geometric surface when no FPF-governed use is carried.
  • Inadmissible final heads: StructureSurface, MechanismSurface, PortfolioSurface, and any ...Surface that hides a structural, mechanistic, measurement, review, assurance, explanation, comparison, or publication-unit object.
  • Preferred alternatives: name publication face, form, unit, carrier, and rendering; use ...Boundary for structural borders, ...View for episteme and view relations, and ...Card only for a UTS or record unit when that is exact.

L-Space - Disciplined use of Space

  • Use Space for a measurement, state or other formal space whose construction is defined by the applicable subject pattern, including an A.19 CharacteristicSpace. Do not infer a Space from a set, portfolio or publication form. Publish a portfolio or archive in the set, view or card form its use actually needs.
  • Field-name and direct-declaration guard. In A.6.0 and A.6.1 declarations, write SubjectKind and RangedValueKind as direct content fields. Add ResultKind, SliceSet, and ExtentRule only when their distinctions are current. A heading that merely wraps these fields is presentation, not another declaration component, and receives no Tech name. Use Space only when the governed value has the space construction stated by its subject pattern. Let the referenced C.3 kind, admitted durable U-kind, Concept-Set row, or imported signature symbol carry ...Space where appropriate; use ...Set for an ordinary set-valued universe.
  • A.19 topology and distance are separately declared overlays. Their absence does not disqualify a CharacteristicSpace. For a portfolio, publication form or ordinary set, use the name of that actual construction rather than adding Space without its defining basis.

L‑ROLE — guarded recovery from role

  • Bare claim-bearing role is a lexical trigger with no default Tech reading. Apply E.10.ROLE, write the ordinary sentence with its recognizable object and action or relation, and stop as soon as one exact object or relation and its direct pattern are clear.
  • Use SystemRole only as the common compound inside one concrete local system-role-kind designation such as ReviewerSystemRole. Recover the kind through C.3’s candidate domain, operative membership distinction, member/non-member boundary, and continuity rule. Practice or source provenance is a locator and comparison cue; the spelling creates no system admission, assignment, agency, capability, responsibility, participation, Work, evidence use, or status.
  • A participant meaning or actual participant remains under its direct relation; a reusable declaration place remains an A.6.5 SlotKind or A.6.1 declaration; a tuple, table, formula, graph, diagram, schema, or call position remains under its representation pattern and explicit correspondence. None becomes a system-role kind by wording.
  • Preserve ordinary or quoted role when no FPF claim relies on it. Preserve owner when a precise ownership relation is current—for example, an architectural, organizational, policy, source, or responsibility relation. This rule forbids lexical cleansing as well as default formalization.