E.10:8 - Morphology and Lexical Form (LEX.Morph)

Principle. Form follows the FPF kind being named. A token’s morphology (suffix, prefix, and casing) expresses what kind of thing it names, respects MG-DA (Minimal Generality and Domain Anchoring), and passes LEX.TokenClass gates: LEX.TokenClass(token) ∈ {KernelToken | ContextToken | DiscriminatorToken}. Morphological choices never override EntityOfConcern, Description episteme, specification use, publication faces, publication forms, PublicationUnits, carriers, renderings, or CHR:ReferencePlane semantics.

E.10:8.0 - Casing and basic forms

M‑0 (Casing and categories). Kind names and exact local system-role-kind labels: UpperCamelCase (IncisionOperatorSystemRole, MethodDescription). Relations and verbs: lowerCamelCase (performedUnderAssignment, isExecutionOf, bindsMethod). IDs and instances: flat with delimiters chosen by the exact local naming scheme or project profile, but never colliding with kind-name or system-role-kind-label forms (e.g., W#Seam134, ctx:Hospital.OR_2025). Register discipline: normative tokens use the Technical register; Plain synonyms are allowed in prose only, never in constraints.

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.

E.10:8.1.1 - Suffix conventions and retained-family boundaries

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.

E.10:8.2 - Inadmissible suffixes and the DevOps, Data Governance and Repository-Workflow Lexical Firewall

M-F (Inadmissible in Kernel tokens). KernelToken names do not use …Function, …Process, …Task, or …Activity. These are ambiguous or vacuous; recover the object through section 6 before naming it: one U.Method, one qualifying U.MethodDescription, one Work occurrence admitted under U.Work, or another accepted recovered value. The source suffix alone selects none.

M-FW (Tool and file markers). Abstract Kernel names do not acquire incidental tool or file suffixes such as …API, …JSON or …YAML. Keep those implementation designations in their local glossary or operational source. A rule governing a named concrete publication form, protocol or grammar may quote its necessary designation or syntax under E.5.1, with the edition/use boundary. Such a quoted subject designation is not thereby a new universal KernelToken. This distinction preserves exact subject rules without importing a data-management ontology.

E.10:8.3 - Prefix discipline

M-P1 (Reserved prefixes). U. is reserved for admitted U-kinds and dependent U.* forms admitted under their definitions; Γ_ for algebraic operators; CAL, LOG, and CHR for pattern packages. A local glossary, scheme, source label, or use never mints U.*.

M-P2 (Edition and version markers). Use a model-use marker only when A.1.1’s direct model-use relations or a selected BoundedModelUseStructure require it. Select one exact episteme edition only through a typed reference whose referent is that exact U.Episteme, with a narrow selector defined at its reference-pattern locator. Do not attach an edition selector to an EntityOfConcern-side Method, Space, system, bare Service, or their references. When a use depends on a defining, describing, CG-Spec, service-description, or service-offer episteme, reference that episteme separately. A service-access publication, publication occurrence, publication form, and carrier retain their own references and do not inherit the episteme selector. Tool and carrier versions remain separate. Authors may annotate local service labels for didactics only after every named value is recoverable. Norms (edition, release, and version).

1. edition — one exact U.Episteme with its own C.2.1 identity. A later episteme is related to an earlier one only when the exact EpistemeEditionRelation predicate obtains; shared label, order, file version, or selector value establishes none. PhaseOf may describe one unchanged episteme over a proper interval but never connects different episteme identities.
2. release — a separately governed publication or release occurrence, or the exact Work that performs it when that Work claim is current. Publication occurrence, publication form, and carrier remain distinct; release establishes neither episteme identity nor EpistemeEditionRelation.
3. version — a tooling or carrier identifier for a file, package, code object, rendering, or other carrier-specific use. It is not an episteme edition, publication occurrence, or release claim and does not belong in Core EntityOfConcern names.

Property discipline. There is no universal <Thing>Ref.edition property. A direct reference pattern may define a narrow edition selector only for a governed reference whose referent is one exact U.Episteme. A Space, U.Method, formula, system, publication form, or carrier reference remains a reference to that object; pair it with a separately governed episteme reference when one exact defining or describing edition matters. A selector value identifies neither an edition relation nor historical continuity.

E.10:8.4 - Morphology tests (apply with § 7 MG-DA)

M‑1 (Kind-side test). The candidate fits one admitted kind or one side in the Strict Distinction lattice (EntityOfConcern ≠ Description episteme ≠ publication carrier; exact local system-role kind ≠ U.SystemRoleAssignment occurrence ≠ Method ≠ Work). If not, rename or split.

M-2 (Classified-kind anchoring). The head noun names the classified FPF kind or exact subject construction: exact local system-role kind, U.SystemRoleAssignment occurrence, Method, Work, Characteristic, Capability, constraint claim, U.Commitment, publication form, service-access relation, service-offer record, exact source or practice boundary, local-use designation, or another direct FPF value. Bare role first uses E.10.ROLE; no free-floating metaphor, bare Service, bare Context, or bare Requirement head passes by lexical shape.

M-3 (Family congruence). Where eligibility clarity is needed, add the exact subject-specific characteristic or SystemRoleAssignmentStateRelation as a separate qualifier for the current value; do not hide either in a system-role-kind name. Do not turn standards, requirements, evidence, or status labels into ...SystemRole names, and do not fake families with bare metaphors such as RowPlane, senseFamily, or ...Lane.

M‑4 (Run and description split). Use Work only for executions. Treat recipe, code, diagram step, procedure, or document form as recognition evidence only: classify a claim-bearing episteme as U.MethodDescription only when its exact EntityOfConcern is one admitted U.Method and its claims pass the A.3.2 substantive-description threshold; keep the method, representation, publication form, plan, and Work occurrence separate.

M-5 (Kernel parochiality). KernelToken names carry no domain nouns. Recover domain markers under the objects and rules that define them. Use ContextToken only after the exact local source, practice, scheme, meaning, and receiving use are recovered; use A.19 CharacteristicSpace only after its named U.Characteristic, declared CSLC scale, and exact receiving use are current; use A.2.5 SystemRoleAssignmentStateRelation only when that direct predicate obtains. Lexical shape establishes none of them.

M‑6 (Vacuity ban). Avoid vacuous heads (Thing, Event, Process, Resource). Use established U-kind heads such as U.Holon, U.Work, and U.Method.

M-7 (Notation independence). The EntityOfConcern-side meaning survives notation and tool swaps.

M-8 (Collision and uniqueness). Before merge, perform full-text and Reserved-Names checks; a token colliding with another FPF meaning is not admitted (cf. MG-DA-T5).

E.10:8.5 - Alias hygiene

Aliases are permitted only in one named local source or practice glossary under an effective scheme and explicit local meaning claim. Each alias points to one Tech designation; it does not assert semantic equivalence or a Bridge. No global aliases.

E.10:8.5a - Entry lexeme support and lexical-query discipline

Public first-entry scenario text, ToC query rows, local Problem-frame recognition text, or worked entry comparisons in E.11 may use one compact entry lexeme cue block when the lexical issue changes the first useful FPF entry. That cue block should not be copied into every pattern body by default. Keep it instead in:

• FPF readme section,
• E.11 public-entry positions,
• worked entry comparisons in E.11,
• Table of Contents query rows,
• or one bounded lexical-query record governed by F.17, UTS, or F.18.

This block remains one editorial lexical-query set. It does not mint names, aliases, durable U-kinds, bridges, or semantic equivalences by itself. When visible, it should distinguish at least:

• canonical label,
• plain-language twin,
• domain alias,
• lexical-query cue,
• rejected cue,
• false friend or inadmissible synonym.

Minimal visible lexical-query shape may therefore use one compact field set such as:

canonical
noncanonical_visible
domain_query_examples
forbidden_aliases

Ordinary lexical-query support should stay compact:

• ordinary Table of Contents rows: prefer 2-5 query phrases;
• ordinary README scenario or E.11 entry-distribution cues: keep only the most discriminating domain phrases and false friends;
• fuller lexical sets belong under F.17, F.18, and E.10 only when one real naming, alias, bridge, or collision claim exists.

Lexical support should increase entry precision, not maximize keyword recall. The same boundary should be kept explicit in lexical support:

• lexical_hook is not one alias;
• one alias is not one canonical name;
• one search cue is not one semantic equivalence;
• one entry_orientation_label is not one RelationKind.

Language-specific query cues may be added as entry-lexeme support. They do not become canonical names, aliases, or semantic equivalents unless an accepted F.18 naming settlement admits that use; otherwise keep the phrase as ordinary local query wording. Such a practitioner phrase may help recover a canonical FPF pattern while remaining lexical-query support only.

E.10:8.6 - Compatibility with USM (acts and tokens)

LEX applies to tokens; USM applies to acts. Mint, rename, and use are LexicalActs that carry a USM scope (e.g., ClaimScope, WorkScope). LEX constrains where a token form may appear via AllowedScopes policies:

LEX.TokenClass(t)=c ⇒ USM.Scope(usage) ∈ AllowedScopes(c).

Example: use of a KernelToken in a locally scoped constraint is admitted only under the exact scheme and allowed-scope rule; an alias adds no Bridge. Logging Work inside a MethodDescription violates M-4 and the policy.

E.10:8.7 - Acceptance and regression checks (LEX and USM)

• SCR‑MOR‑S01 (Suffix whitelist). Every normative token with a reserved suffix matches § 8.1 row semantics and passes EntityOfConcern and Description-episteme boundary and specification-use gates.
• SCR-MOR-S02 (Kernel exclusions). KernelToken names contain none of the inadmissible suffixes from section 8.2.
• SCR-MOR-S03 (Prefixes). Reserved prefixes obey § 8.3; no local glossary, source, scheme, or use mints U.*.
• SCR‑MOR‑S04 (Run and design gate). Work appears only for executions; MethodDescription has no runtime actuals.
• SCR‑MOR‑S05 (Collision). Full‑text + Reserved‑Names checks pass (no other sense of the token elsewhere).
• SCR‑MOR‑S06 (Object‑of‑talk). Heads pass M‑2; no bare metaphors as heads.
• RSCR-MOR-E01 (DevOps firewall). Tool and file suffixes stay in local glossaries or operational configurations; none leak into KernelToken names.
• RSCR‑MOR‑E02 (USM compliance). For each LexicalAct, verify USM.Scope ∈ AllowedScopes(LEX.TokenClass) (see § 7.5).

E.10:8.8 - Autonomy lexicon (L‑AUTO )

Inadmissible in Core: bare “validity”, bare “actor” or “agent” as free-standing nouns, “kill switch”, “process” for behavior, and “envelope” when used as scope. Use instead: Scope (G) for epistemic scope; WorkScope for capability bounds; an admitted U.System for an ordinary actor or doer. When a precise Agent or performed-Work claim is current, use A.13 for the exact local agential kind and criterion, classification, obtaining assignment, scope, working situation, window, and adequate core evidence; require a characteristic profile only when its Grade, autonomy, criterion-dependent, profile, or assurance use consumes it. Then let A.15.1 independently admit the dated Work from its actual performer, Method, time, and containment facts. Add F.6 only when the wording or receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. Use a ...SystemRole designation only when that classification itself matters. Use SpeechAct for overrides and SafeStop instead of “kill switch”. Named prefixes (policy and registry):

• aut: for AutonomyBudgetDecl fields (e.g., aut:action_tokens, aut:risk_bands);
• guard: for guard checks bound to AdmissibilityConditionsId;
• ovr: for override SpeechActs (ovr:PauseAutonomy, ovr:ResumeAutonomy, …).

Notes.

1. Scope-sensitive guards declare the Gamma_time window selector used for admission checks.
2. Proper names of patterns and components that already include “Agent” or “Agency” (e.g., Agency‑CHR, Agent‑Tools‑CAL) are permitted as titled terms; avoid re‑introducing “agent” as a free‑standing noun in new prose.

E.10:8.9 - LEX-CHR-STRICT — Reserve Characteristic for CSLC-measurable aspects

Intent. Prevent calling non-measurable objects (sets, statuses, scopes, policies, bridges, contexts, guards) “characteristics”.

Rule L-CHR-S1 (Reservation). Use Characteristic only for variables that declare a CSLC scale (nominal, ordinal, interval, or ratio) with admissible values, units, and polarity (Part C.16 and A.17–A.18). Rule L-CHR-S2 (USM). U.Scope, U.ClaimScope (G), and U.WorkScope are USM scope objects, not Characteristics or CHR components of a CharacteristicSpace. Rule L-CHR-S3 (Status). Episteme statuses, SystemRoleAssignmentStateRelation occurrences or assertions, deontic statuses, and epistemic statuses are not Characteristics by label alone; each remains governed by its direct pattern. Rule L-CHR-S4 (Lexical classifiers). Keep a lexical classifier or tag under its classification rule: a local classification function and value set, source wording, C.29 representation element, example or alternative set, status or state-frame value set, local kind or classifier, or another construction defined for that classifier. Call it a U.Characteristic only when that characteristic and one CSLC scale are declared. Do not default the residue to Facet, attribute, or another umbrella kind. Checks.

• CC-L-CHR-1. scope characteristic(s) is banned in Kernel and local-use Tech wording.
• CC-L-CHR-2. CharacteristicSpace near Scope is a cue to inspect the claimed relation. Reject wording that treats a scope as a CHR component. A scope may qualify use of a characteristic space while remaining a distinct USM scope object.
• CC-L-CHR-3. Kind-preserving repair: F–G–R characteristics → F–G–R components only when the recovered kind is component rather than characteristic.

E.10:8.10 - LEX-QA-1 - Using terms with the -ility and -ilities suffixes

Rule. Tokens ending with -ility or -ilities or widely used quality names (Availability, Reliability, Security, Safety, Scalability, Maintainability, Usability, …) are Quality‑Family labels, not automatically CHR Characteristics.

Authoring choice:

• Keep ordinary praise or quoted wording ordinary when it carries no FPF-governed claim; use C.16.Q if the evaluative meaning remains hidden.
• Use one named U.Characteristic and its declared CSLC Scale when that one measure carries the engineering quality claim.
• Use C.25 Q-Bundle-shaped claim content only when several differently typed contributors jointly determine the claim or receiving action. Include only the load-bearing measures, scopes, windows, mechanisms, statuses and evidence.

Rationale. Scope is set-valued (USM) and not a CHR measurement. Q-Bundle mechanism and status fields carry mechanism references, control presences, certification states, or other status values admitted by their specific patterns; they are not generic governance records or measurements. Claim scope, work scope, CHR measures, qualification window, mechanisms, status values, and evidence keep their own kinds even when one Q-Bundle authoring structure coordinates them. (A.2.6 § 6.2; A.6.1; C.16, A.18, and C.25).