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.
| Suffix | Kind named by suffix | EntityOfConcern and Description-episteme boundary and specification-use gate | LEX.TokenClass gate | Examples | Typical inadmissible uses |
|---|---|---|---|---|---|
SystemRole (compound ending) | One exact local system-role kind | The 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. | ContextToken | TransformerSystemRole, ApproverSystemRole | Bare ...Role; participant, declaration, representation, evidence, status, standard, source, constraint, commitment, or publication-use readings. |
Method | One semantic way of doing | EntityOfConcern side | KernelToken or ContextToken | SteriliseInstrumentMethod | Attaching 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. |
MethodDescription | Claim-bearing episteme about one exact admitted method | Description episteme only when its claims make at least one substantive statement about that method as a way of doing | KernelToken or ContextToken | SteriliseInstrumentMethodDescription | Admission 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. |
...Spec | Testable specification (acceptance-bound) | Description episteme admitted for specification use | KernelToken or ContextToken | MethodSpec, TransformationFlowStructureSpec, SystemSpec | Using “Spec” without acceptance tests or harness; treating formal notation alone as specification; putting runtime actuals here. |
Work | Work occurrence kind or an occurrence classified under it | U.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 head | U.Work; W#Seam134WorkOccurrence; W#Seam134WorkRecord | Plans 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. |
WorkPlan | Claim-bearing episteme coordinating possible future performed work | Same-individual dependent kind of U.Episteme only when A.15.2 recovers one present EntityOfConcern, one horizon, at least one PlanItem, and substantive coordination claims | ContextToken after membership | MaintenanceWorkPlan_Q3 only after the A.15.2 gate | Admission 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 relation | Apply 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 use | object-storage service promise; passport-issuance service-access claim | Using Service as a final durable head-kind; naming teams or APIs as Service; treating the possible readings as one bundle. |
Capability | System ability | EntityOfConcern side | KernelToken or ContextToken | ScheduleGenerationCapability | Mislabeling system-role kinds, assignments, or methods as capabilities. |
Dynamics | Claim-bearing episteme stating a state space and transition law | Same-individual dependent kind of U.Episteme under A.3.3; the changing subject is its EntityOfConcern | KernelToken or ContextToken after membership | LotkaVolterraDynamics | Admission from a change label alone; confusing the model with the changing subject, a Capability or a Method. |
Observation | Observation record or kind | (run record; not EntityOfConcern and Description-episteme or specification use) | ContextToken or DiscriminatorToken | VibrationObservation | Mixing with MethodDescription or Evaluation. |
Evaluation | Evaluation episteme or evaluation record | Description episteme or Description episteme admitted for specification use | ContextToken or DiscriminatorToken | CalibrationEvaluation | Using 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 kind | Trigger wording | evidence-use, status-use, source-use, or publication-use relation named by its direct pattern | Using as a system-role kind, U.SystemRoleAssignment, or generic evidence. |
Episteme | Epistemic knowledge unit (structural) | Description episteme or Description episteme admitted for specification use | KernelToken or ContextToken | TraceabilityEpisteme | Colliding with CHR ReferencePlane (never suffix “Plane”). |
System or Holon | Substantial entity | EntityOfConcern side | KernelToken or ContextToken | AnesthesiaSystem, OrderFulfillmentHolon | Using to denote a source, scheme, local-use qualifier, or run record. |
Boundary | System boundary | EntityOfConcern side | KernelToken or ContextToken | SterileFieldBoundary | Using as a system-role kind or method. |
Objective | Target state | EntityOfConcern side or Description episteme side, depending on formalization | KernelToken or ContextToken | HemostasisObjective | Encoding 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 construction | latency constraint under its constraint pattern; U.Commitment when accountable undertaking is current | Publishing 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 suffix | Apply 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 token | quoted DDD bounded context; source label retained as source wording | Minting 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 wording | Trigger wording | publication face, interop publication form, carrier relation | StructureSurface, MechanismSurface, PortfolioSurface |
Card | UTS or record unit (episteme) | Description episteme, Description episteme admitted for specification use, or publication-unit use, depending on FPF kind named by value | ContextToken | MethodCard, ExternalIndexCard | Encoding runtime actuals; using as a ‘Service’ |
E.10:8.1.1 - Suffix conventions and retained-family boundaries
| Suffix | Lexical class | Meaning and ontology | Where it lives | Examples and notes |
|---|---|---|---|---|
| Space | EntityOfConcern-side kind | A typed state space (finite product of declared Characteristic×Scale components); no procedures | Kernel A.19; CHR and space consumers | CharacteristicSpace, 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. |
| SpaceRef | Pointer | Governed reference to one exact Space | Direct reference pattern; data fields and UTS | CharacteristicSpaceRef 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. |
| Map | EntityOfConcern-side kind (method) | One exact mapping U.Method from subjects to coordinates in a declared Space | A.3.1 and the method-family pattern; Description epistemes remain separate | DescriptorMap 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. |
| MapRef | Pointer | Governed reference to one exact mapping U.Method | Direct method-reference pattern; data fields and UTS | DescriptorMapRef 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. |
| Def | Registry-local alternate token | A 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 form | Exact CG-Spec registry | DistanceDef 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. |
| DefRef | Pointer | Registry-local reference whose exact referent kind and RefKind are defined by the direct CG-Spec registry | Exact CG-Spec reference pattern; data fields and UTS | DistanceDefRef 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. |
| Spec | Description episteme admitted for specification use | Testable invariants bound to acceptance harnesses | E.10 and A.21 | Stable, testable definitions; normative by default; admitted for specification use. Use for normative calculi plus scoring and normalization specifications. |
| Slot | Relation-declaration suffix | Declaration-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 place | A.6.0 RelationSignature; A.6.5 SlotSpec declaration | EntityOfConcernSlot, 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. |
| Ref | Pointer | Reference 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 distinct | Direct reference pattern; receiving episteme fields and UTS | U.EntityRef, U.HolonRef; episteme fields …Ref : U.EntityRef. …Ref never carries content and is never a ValueKind, SlotKind, or actual participant. |
| Series | Conditional collection or structure label | Not 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 separate | C.2.1 with A.22 for the selected structure and A.14 for any collection | Do not mint U.EditionSeries; order, shared title, or collection membership establishes no edition continuity. |
| edition selector | Reference selector defined by its direct pattern | Optional 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 continuity | Direct reference pattern and C.2.1 | signatureRef.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
CharacteristicSpaceis 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.Epistemefor the claim-bearing unit.U.EpistemePublicationis a rejected kind name: when the selected edition is available as a published episteme, name or make recoverable its exactEpistemePublicationRelationoccurrence, publication form, bounded use, and carrier underE.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.Viewand MVPK face separately from the publication form. APlainView,TechCard,InteropCard, orAssuranceLaneis 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
authoritySourceReftarget, evidence relation, gate decision, assurance claim, exactU.SystemRoleAssignmentoccurrence, status assertion, Work occurrence, deontic permission, or Work authorization. - Use an ordinary PatternID reference when a reader only needs to find the rule. Add
relationFunctionClaimRefand the defining or constrainingClaimGraphonly when admissible interpretation, comparison, migration, publication, or reuse depends on that exact rule identity. UseauthoritySourceRefwhen 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.WorkPlanbaseline, planned work, or one actual Work occurrence admitted underU.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. ApplyA.6.P.WMRonly while one such Work-to-Method boundary relation remains hidden after generic relation recovery. Do not let genericaction,use,material,work result, orresult measurementhide that distinction. - Use
C.2.Pwhen episteme-publication-heavy wording carries an episteme, publication, view, carrier, relation, admissibility, evidence, work, gate, decision, method, or pattern-use claim.E.10keeps the lexical and naming discipline;C.2.Precovers 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.
surfaceis 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
surfacewhen no FPF-governed use is carried. - Inadmissible final heads:
StructureSurface,MechanismSurface,PortfolioSurface, and any...Surfacethat hides a structural, mechanistic, measurement, review, assurance, explanation, comparison, or publication-unit object. - Preferred alternatives: name publication face, form, unit, carrier, and rendering; use
...Boundaryfor structural borders,...Viewfor episteme and view relations, and...Cardonly 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
SubjectKindandRangedValueKindas direct content fields. AddResultKind,SliceSet, andExtentRuleonly 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...Spacewhere appropriate; use...Setfor 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
SystemRoleonly as the common compound inside one concrete local system-role-kind designation such asReviewerSystemRole. 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
SlotKindor 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.