Unified Lexical Rules for FPF

E.10 · Stable · Part E - The FPF Constitution and Authoring Guides

About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Status: Stable Definitional pattern; normative for all FPF pattern text and for any Context that claims FPF conformance.

Status and placement. Part E.10 (“Lexical Discipline and Stratification”); complements E.10.D1 (D.CTX), E.10.D2 (EntityOfConcern and Description-episteme boundary and specification-use gates), the DesignRunTag and CtxState boundary discipline (A.15; E.18), E.10.ARCH wording-use restoration architecture, A.6.P relation precision restoration, C.2.P epistemic precision restoration, A.19.SPR state-family precision restoration, and F.18 local-first naming. E.10:0.2 is the shared lexical trigger scan. The detailed LEX sections below supply register, naming, morphology, and local rewrite checks only for the selected wording problem; they are not a second wording-recognition table and do not replace E.10.ARCH, the selected precision-restoration realization patterns, governing patterns, or F.18.

Builds on: A.7 Strict Distinction (Clarity Lattice); E.5 Guard‑Rails (DevOps Lexical Firewall; Notational Independence; Unidirectional Dependency); F.5 Naming Discipline for U.Types and Roles. Coordinates with. A.2 and A.15 (Role–Method–Work alignment), A.10 (Evidence Graph Referring), B.1 and B.3 (Γ‑algebras and assurance), F‑cluster (context of meaning; Bridges).

What goes wrong if missed. Precision repair turns into taste or synonym replacement. A broad head such as support, surface, route, mapping, kind, basis, force, load, bearing, object, or record is replaced by another broad head, while the relation, source-use relation, admissible use, or neighbouring FPF pattern application remains unrecovered.

Relations

E.10builds onStrict Distinction (Clarity Lattice)

E.10builds onFour Guard-Rails of FPF

E.10builds onNaming Discipline for U.Types & Roles

E.10builds onLocal-First Unification Naming Protocol

E.10coordinates withWording-Use Ontological Precision Restoration Architecture

E.10coordinates withRelational Precision Restoration (RPR) — Kind-Explicit Qualified Relation Discipline

E.10coordinates withEpistemic Precision Restoration

E.10coordinates withState-Family Precision Restoration

E.10coordinates withOntic Candidate Detection

E.10coordinates withOntic Description and Publication Discipline

E.10coordinates withOntology-First Plain Technical Rewriting

E.10outline childWording-Use Ontological Precision Restoration Architecture

E.10outline childConceptual Prefixes (policy & registry)

E.10outline childLexical Discipline for “Context” (D.CTX)

E.10outline childEntityOfConcern, Description Episteme, and Specification-Use Discipline

E.10explicit referenceLexical Discipline for “Context” (D.CTX)

E.10explicit referenceEntityOfConcern, Description Episteme, and Specification-Use Discipline

E.10explicit referenceRole-Method-Work Alignment (Contextual Enactment)

E.10explicit referenceTransformation Flow Structure

E.10explicit referenceWording-Use Ontological Precision Restoration Architecture

E.10explicit referenceRelational Precision Restoration (RPR) — Kind-Explicit Qualified Relation Discipline

E.10explicit referenceEpistemic Precision Restoration

E.10explicit referenceState-Family Precision Restoration

E.10explicit referenceLocal-First Unification Naming Protocol

E.10explicit referenceStrict Distinction (Clarity Lattice)

E.10explicit referenceFour Guard-Rails of FPF

E.10explicit referenceNaming Discipline for U.Types & Roles

E.10explicit referenceRole Taxonomy

E.10explicit referenceEvidence Graph Referring (C-4)

E.10explicit referenceUniversal Algebra of Aggregation (Γ)

E.10explicit referenceTrust & Assurance Calculus (F–G–R with Congruence)

E.10explicit referenceDeclarative Representation Precision Restoration

E.10explicit referenceArchitecture and Structure Precision Restoration

E.10explicit referenceStratification Wording Precision Restoration

E.10explicit referenceCharacteristic and Scale Precision Restoration

E.10explicit referenceQuality-Term Precision Restoration

E.10explicit referenceFPF Pattern-Quality Evaluation CharacteristicSpace

E.10explicit referenceImprovement-Oriented Quality Evaluation Question Framing

E.10explicit referenceQuality Improvement Loop Method

E.10explicit referenceFPF Pillar-Adequacy Evaluation CharacteristicSpace

E.10explicit referenceU.BaseDeclarationDiscipline - Kind-explicit, scoped, witnessed base declaration discipline (with base-change lexicon)

E.10explicit referenceSignature Stack & Boundary Discipline

E.10explicit referenceU.RelationSlotDiscipline - SlotKind / ValueKind / RefKind discipline for n‑ary relations (with slot‑operation lexicon)

E.10explicit referenceU.Signature — Universal, law‑governed declaration

E.10explicit referenceU.RoleAssignment: Contextual Role Assignment

E.10explicit referenceModule Relation Repair

E.10explicit referenceFunction and Functional Precision Restoration (RPR-FUNCTION)

E.10explicit referenceU.ActionInvitationPrecisionRestoration — Affordance / Action-Invitation Precision Restoration (ACT-INV)

E.10explicit referenceDRR Decision-Adequacy Evaluation CharacteristicSpace

E.10explicit referenceOntic Candidate Detection

E.10explicit referenceOntic Description and Publication Discipline

E.10explicit referenceU.Method: The Abstract Way of Doing

E.10explicit referenceU.MethodDescription: The Recipe for Action

E.10explicit referenceMathematical Lens Use

E.10explicit referenceU.Mechanism - Law‑governed application to a SubjectKind over a BaseType

E.10explicit referenceMechanism Introduction Protocol (MIP)

E.10explicit referenceU.WorkPlan: The Schedule of Intent

E.10explicit referenceU.Work: The Record of Occurrence

E.10explicit referenceMulti‑Method Dispatcher & MethodFamily Registry

E.10explicit referenceMulti-View Publication Kit

E.10explicit referenceFPF Authoring Conventions and Style Guide

E.10explicit referenceOntology-First Plain Technical Rewriting

E.10explicit referenceGrounded Architecture and Selected-Structure Adequacy

E.10explicit referenceStructure and Structural Views (STRUCT-CAL)

E.10explicit referenceArchitecture Structural View Adequacy (ASV)

E.10explicit referenceA.CHR-NORM — Canonical “Characteristic” & rename (Dimension/Axis → Characteristic)

E.10explicit referenceA.CSLC-KERNEL — Minimal CSLC in Kernel (Characteristic/Scale/Level/Coordinate)

E.10explicit referenceMM-CHR — Measurement & Metrics Characterization

E.10explicit referenceCharacteristicSpace & Dynamics Hook (A.CHR-SPACE)

E.10explicit referenceQ-Bundle: Authoring "-ilities" as Structured Quality Bundles

E.10explicit referenceControlled Semantic Coarsening

E.10explicit referenceRepresentation-Scheme Transition: EntityOfConcern-Preserving Representation-Scheme Transition

E.10explicit referenceAlignment & Bridge across Contexts

E.10explicit referenceComparativeReviewUnit - bounded comparison over comparative review units

E.10explicit referenceControl Structure View Adequacy (LCA)

E.10explicit referenceTransformation Ontic Precision Restoration

E.10explicit referenceU.Episteme - Epistemes and their slot relation

E.10explicit referenceU.Flow.ConstraintValidity — Eulerian

E.10explicit referenceGateProfilization: OperationalGate(profile) (GateFit core)

E.10explicit referenceU.Commitment: Deontic Commitment Object

E.10explicit referenceDecision Theory (Decsn-CAL)

E.10explicit referenceU.SpeechAct: Communicative Work Object

E.10explicit referencePattern Quality Gates: Review and Refresh Profiles

E.10explicit referenceExplanationFaithfulnessProfile — explanation-use discipline over existing MVPK faces

E.10explicit referenceWork-Relevant Source Restoration

E.10explicit referenceLanguage-State Move Coordination

E.10explicit referenceU.LanguageStateMoveTrajectory — Optional trajectory-account normal form

E.10explicit referenceU.LanguageStateSpace — Language-state chart over U.CharacteristicSpace

E.10explicit referenceSupervisor–Subholon Feedback Loop

E.10explicit referenceU.EpistemicViewing - EntityOfConcern-Preserving Morphism

E.10explicit referenceU.EpistemicRetargeting - EntityOfConcern-Retargeting Morphism

E.10explicit referenceCausalUse-CAL: Causal-Use Questions, Causality-Ladder Rungs, Identification and Realizability

E.10explicit referencePublicationUnit Stability Discipline

E.10explicit referencePublicationUnit Stability Discipline and PublicationUnit Primary EntityOfConcern Discipline

E.10explicit referencePublicationUnit Stability Discipline and Local Head Restoration

E.10explicit referenceU.Dynamics: State-Space and Transition-Law Episteme

E.10explicit referenceTemporal Claim Adequacy: State Readings, Temporal Trends, and Intervention-Sensitive Temporal Change

E.10explicit referenceU.Ontic and Ontic Introduction Discipline

E.10explicit referenceRole Description (RCS + RoleStateGraph + Checklists)

E.10explicit referenceU.RoleStateGraph: The Named State Space of a Role

E.10explicit referenceU.RoleAlgebra: In-Context Role Relations (≤, ⊥, ⊗)

E.10explicit referenceMethod Quartet Harmonisation

E.10explicit referenceUnified Term Sheet (UTS)

E.10explicit referenceIntra‑Context Sense Clustering

E.10explicit referenceConcept‑Set Table Construction

E.10explicit referenceAnti‑Explosion Control (Roles & Statuses)

E.10explicit referenceSCR/RSCR Harness for Unification

E.10explicit referenceRole Assignment & Enactment Cycle (Six-Step)

E.10explicit referenceFirst-Practical Entry and Pattern-Use Discoverability Discipline

E.10explicit referenceExpanded Entry Disambiguation Cases

E.10explicit referenceUnified Scope Mechanism (USM): Context Slices & Scopes

E.10explicit referenceStatus Families Mapping (Evidence • Standard • Requirement)

E.10explicit referenceEvidence Graph & Provenance Ledger

E.10explicit referenceU.CrossContextSamenessDisambiguation — Repairing cross-context “same / equivalent / align” via explicit Bridges (RPR-XCTX)

E.10explicit referenceBridge Stance Overlay

Content

Use this when

What this buys. E.10 gives one cheap trigger scan before heavier repair: ordinary wording stays ordinary, local lexical mistakes are repaired locally, relation-like wording applies A.6.P; episteme, publication, or source-use wording applies C.2.P; declarative-representation wording overread as imperative action, method, work, permission, release, evidence, or pattern dispatch applies C.2.P.DR; method, algorithm, program, proof, solver, workflow, process, procedure, access-path, query-plan, and control-strategy wording recovers the current ontic slot, relation position, use relation, or claim kind before any replacement; architecture or structure wording applies C.30.P; stratification or source-label wording such as layer, level, tier, stack, ladder, rung, block, expert, cache, router, or gate applies C.30.STRAT; characteristic or scale wording applies C.16.P; quality or evaluative wording applies C.16.Q; state-family wording applies A.19.SPR; and already recoverable cases apply the governing pattern directly. The result is precise enough to compose with FPF without making every phrase into a new pattern or review artifact.

Use E.10 when a word, head, or local phrase in conformant FPF text is starting to hide what kind it names, which register it belongs to, which context of meaning governs it, or which relation or action claim it carries.

First useful move. Restore the head kind and register of the local wording. If no FPF-governed use remains, make the small local rewrite under E.10 and stop. If an E.10:0.2 row selects a precision-restoration realization pattern or a governing pattern, apply that pattern instead of inventing a synonym. If the repaired wording becomes a durable reusable head, apply F.18 after the selected precision-restoration branch has recovered the kind and use. Governing FPF patterns are named only after that repair has made the EntityOfConcern, relation, claim, admissible use, project-side reference, or non-use disposition recoverable by value.

Cheap stop. If one local lexical repair restores kind, relation, and admissible use without changing the normative meaning of FPF, stop with the repaired wording; do not create or use a Name Card, DRR, review profile, or larger epistemic precision restoration note by habit. Ordinary application starts at E.10:0.2, applies only the row selected by the sentence under repair, and then stops at local repair, the selected restoration pattern or governing pattern, controlled precision reduction, or F.18 when a durable reusable head is actually being minted. Later LEX sections are detailed checks for the selected case, not a universal interpretation sequence.

Not this pattern when. Do not use E.10 as the ontology that governs the recovered claim. If the use under repair is evidence, assurance, work, gate, decision, causal use, publication, relation precision, or epistemic precision, the accepted text must make the governing FPF pattern application explicit; E.10 contributes only the wording-problem classification. For non-FPF source prose, use C.2.P source-expression unpacking mode and borrow E.10 only as a repair test, not as a conformance verdict.

One-screen ordinary use

Ordinary E.10 use is one bounded FPF-governed wording repair, not a full lexical audit. The bounded complete accepted result is:

BoundedTextSpan: the exact sentence, row, section, pattern version, DRR slice, or project text deliberately using FPF-governed terms, pattern references, relation names, or conformance claims under repair.
TriggerSpan: the word or phrase that carries possible FPF-governed use.
SelectedInterpretation: ordinary no FPF-governed use, local head repair, register repair, morphology repair, relation-like precision restoration, episteme precision restoration, publication precision restoration, source-use restoration, durable naming, or not-triggered false positive.
FinalWordingOrBlocker: the accepted local wording, the governing-pattern result, or the blocker that remains.
StopBackToSubstance: after final wording or blocker is present, stop lexical work and return to the primary EntityOfConcern, relation or claim record named by value, source-use, mathematical-lens, architecture, project-action, evidence, assurance, gate, decision, or work problem that made the wording matter.

The detailed tables below are reference material for triggered cases. They are not a mandatory interpretation sequence. For a modest repair, one sentence, one trigger span, one selected interpretation, and one final wording or blocker is enough only when it discharges every FPF-governed use in that span.

When E.10 is applied beyond one sentence, add a bounded-text line: exact accepted DRR named by value, FPF pattern, monolith section, extracted host, review packet, pattern section, source span, or other named text span; trigger spans or grouped loci; selected interpretation; repair boundary; and expected non-use boundary. This prevents accidental whole-corpus sweeps and makes change impact inspectable.

When a wording-repair note needs formal fields, use only fields that preserve the current kind and relation: triggerSpan, boundedTextSpan, slotOrUsePosition, selectedInterpretation, LEX.TokenClass?, register, USM.Scope?, EntityOfConcern and Description-episteme boundary and specification use?, governingPattern, and finalWordingOrBlocker.

Local patterns may cite the relevant E.10 recognition row, but they should not reproduce large wording-recognition lists or create local lexical registries unless a named local application profile has its own primary EntityOfConcern, first useful move, and governing-pattern boundary. New recurring wording families enter E.10 only when they recur across FPF-governed texts and cannot be handled by one local pattern; specialized patterns carry the detailed ontology when the problem is no longer lexical. Stale or overly broad recognition rows are narrowed or retired.

Self-application is bounded. When E.10 is under improvement, use E.10 only for its own wording-trigger repairs; use E.21 for pattern-quality evaluation, E.22 for improvement-oriented quality-evaluation framing, E.23 for the improvement loop, E.2.DA for FPF-level Pillar effect, and neighboring pattern governing the claims for relation, episteme, publication, source-use, naming, or quality-word issues.

Scope split

E.10 governs lexical conformance for FPF pattern text, extracted pattern hosts, FPF-Spec monolith text, FPF governing documents, accepted DRR text, and any project, product, research, engineering, or review text that deliberately uses FPF terms, pattern references, FPF relation names, FPF kind claims, FPF admissibility claims, or claims FPF conformance.

For ordinary source text, intake notes, seminar transcripts, external reviews, project documents, source publications, tool outputs, or other text that does not itself claim FPF-governed use, use C.2.P source-expression unpacking mode. That use may borrow E.10 tests, A.6.P relation repair, A.6.6 basedness repair, F.18 naming tests, or another governing pattern as methods, but it does not judge the source text as failed FPF wording.

Problem and applicability table

E.10 is a lexical trigger scan and conformance pattern. Its primary EntityOfConcern for one pattern use is one wording use in conformant FPF text as a lexical or register sign: the head, register, morphology, local label, name candidate, kind-reference, relation-bearing cue, or replacement candidate used by the sentence.

E.10 recognizes which wording-use problem the sentence raises and selects the first applicable closure disposition. It does not itself become the ontology for the recovered relation, episteme, evidence, work, gate, decision, publication, architecture, characteristic, quality, or project-side FPF kind and reference named by value.

The full shared recovery order and applicability-row architecture belong to E.10.ARCH. E.10 keeps only the cheap scan, local rewrite option, direct known governing-pattern rule, compact applicability table, bounded complete result rule, and fail-closed non-use boundary.

exact is not a precision marker by itself. It is admissible only for literal identity or bounded source identity: exact sentence, source passage, trigger span, formula edition, same referent, or same declared CharacteristicSpace. When exact modifies an FPF pattern, kind, relation, record, object, field, use, claim, gate, source, or neighboring pattern, treat the phrase as trigger wording. Recover the governing pattern, FPF kind, relation record, source-use relation, admissible use, current ontic slot, relation position, use relation, or claim kind, value set, and scope by value, then write the recovered object. If recovery fails, use quote-only, reduced-use, blocked-use, or incomplete-rewrite disposition.

Classification is not closure. A conforming result must end in one of these by-value outcomes:

local wording accepted or locally rewritten;
selected precision-restoration pattern applied;
neighboring FPF pattern governing that claim applied directly because the primary EntityOfConcern, relation record, or claim record is already recoverable;
controlled precision-reduction result with declared loss and reopen condition;
F.18 durable-name application after the kind under repair or relation is known;
quote-only, reduced-use cue, blocked use, incomplete rewrite, ordinary prose, or not-triggered disposition.

Grouping-mark self-application. Slash marks, paired-register marks, and, plus, &, and compact grouping marks are triggers only when the grouping itself carries FPF-governed meaning. Retain conventional notation, formula symbols, ratios, standard designations, discipline abbreviations, path-like quoted source tokens, product names, titles, URLs, or pattern-reference notation when the sentence's use is only notational; examples include ISO/IEC, ISO/IEC/IEEE, CI/CD, 1/2, ≡/⋈/⊂/⟂, and exact source tokens. Rewrite claim-bearing grouped heads into explicit lists, alternatives, relation sets, tuple-like records, or selected FPF kinds named by value. Do not let a slash hide one kind choice, a lazy and-or, a relation head, an admissible-use boundary, or a missing governing pattern.

FPF-governed use found by `E.10`	First applicable restoration or governing pattern	Closure result
No FPF-governed use after context check	Keep ordinary prose, quote, didactic phrase, or not-triggered text.	No precision-restoration pattern opens.
Local lexical or register ambiguity only	Local rewrite under `E.10`.	Repaired wording plus remaining reader move, or ordinary-prose demotion.
Relation-like wording or relation-bearing use	Apply `A.6.P` or a retained A.6 relation specialization.	Named relation kind, slots and qualifiers, admissible relation use, blocked overread, and reader move.
Relation, signature, interface, role, assignment, enactment, slot, field, parameter, argument, endpoint, port, API, protocol, connector, capability, affordance, method, function, concern, interest, or role-holder wording whose current governed object or claim kind is hidden	Apply `A.6.RSIR` only when the direct governing pattern is not already clear. If the current object is already recovered, use the direct pattern instead: `A.6.P`, `A.6.5`, `A.6.0`, `A.2`, `A.2.1`, `A.15`, `A.6.M`, `A.6.F`, `A.6.A`, method and work patterns, publication and episteme patterns, evidence patterns, status patterns, gate patterns, or another governing pattern named by value.	Recovered project concern, current EntityOfConcern or claim kind, selected direct governing pattern, slot-discipline need, retained source-label use, blocked overread, and stop before minting generic `U.Interface`, a standalone role-slot ontology, `U.Concern`, `U.Interest`, or episteme-role ontology.

| Source-expression, publication, publication form, face, PublicationUnit, FPF-governed use, or reading, read, or quality-read wording whose entity or construction is not yet recovered | Apply C.2.P first. If the recovered entity or construction is evaluation for improvement, then use the evaluation pattern governing that evaluation claim, such as E.22, E.21, or E.9.DA. | Source-local meaning, publication relation set, publication-form relation when that relation is being made, EntityOfConcern, project-side FPF kind, use disposition, evaluation claim or bundle named by value when that evaluation claim is being made, adjacent overread blocked, and reader move. | | Ontic, ontic candidate, concept cluster, semantic area, ontological neighborhood, slot relation, schema, data structure, record, card, table, or publication-form wording whose EntityOfConcern and publication boundary are hidden | Apply E.24.CD when repeated material may require an ontic candidate decision; apply E.24.PUB when the confusion is among ontic, ontic-description episteme, publication form, view, record, card, table, schema, or data-structure expression. Use E.24 or the direct governing pattern when the ontic or subject pattern is already recovered. | Candidate ontic cluster, EntityOfConcern, slot relation or slot-position, subject pattern, ontic-description episteme, publication form or source relation, admissible use, blocked publication-form overread, and remaining reader move. | | Admissibility-like, legal-looking, authority-looking, readiness-looking, validity-looking, pass-looking, fail-looking, or conformance-looking wording whose bearer, claim kind, source relation, value frame, bounded use, or governing pattern is hidden | Use the direct governing pattern when recoverable: evidence, assurance, gate, constraint validity, work, work plan, publication use, temporal use, source restoration, legal or external-rule claim, pattern-quality result, state-like value, or another claim-specific pattern. If the word is only the trigger, restore by E.10.ARCH and the claim-specific pattern; do not mint a generic admissibility object. | Bearer, claim kind, value frame or decision class, source relation when that relation is being made, bounded admissible use, non-admissible overread, reopen or stop condition, and governing pattern; otherwise quote-only, reduced-use, or blocked-use. | | Method, algorithm, program, solver, proof, recipe, workflow, process, procedure, access-path, query-plan, control-strategy, method algebra, method graph, selector calculus, or programming-paradigm wording whose slot or method-side relation is hidden | Recover the slot or method relation structure before rewriting: A.3.1 U.Method, MethodRelationStructure@BoundedContext when method composition or method-family relation is current, A.3.2 U.MethodDescription, A.6.0 formal-substrate declaration, C.29 mathematical-lens use, A.6.1 with E.20 mechanism claim, A.15.2 U.WorkPlan, A.15.1 U.Work, G.5 method-family registry or selector outcome, A.10 evidence relation, quote-only source wording, or another direct governing pattern. | Pre-repair and post-repair kind or relation position, current ontic slot, relation position, use relation, or claim kind, admissible use, blocked overread, and remaining reader move. Do not replace one umbrella with method, mechanism, algorithm, workflow, or method algebra by taste. | | Transformation, change, pipeline, dataflow, flow, network, circuit, path, slice, workflow, process, operation, or close change-situation wording whose object or slot is hidden | Apply A.3.4.P first. If U.Transformation, TransformationFlowStructure, mathematical description, method, method description, mechanism, work plan, dated work, functioning relation, temporal aspect, evidence, source, publication, gate, decision, assurance, result, or quote-only source wording is already recovered, use the direct governing pattern. | Recovered transformation identity or non-transformation value, recovered slot or filler, governing pattern, retained use, blocked overread, and remaining reader move. Do not replace one source label with flow, network, process, method, function, or transformation by taste. | | Declarative representation wording overread as imperative action, method, work, permission, release, evidence, or pattern dispatch: graph path, path slice, flow valuation, evidence path, state predicate, SQL-like query, checklist predicate, table, dashboard, publication face, mathematical representation, method-description representation, source-chain relation, file path, or FPF pattern relation | Apply C.2.P.DR unless the direct governing pattern already closes the repair. Accepted direct cases include E.18 graph path or PathSlice, A.10 evidence path for a claim, effect, or use, A.19.SPR state predicate or value, E.17 publication face, C.29 mathematical-lens use, A.3.1 method, A.3.2 method description, A.15.2 work plan, A.15.1 work occurrence, carrier file path, source-chain relation, and declarative pattern relation under E.8 or F.19. | Encountered representation, representation kind, represented object or claim, source expression or publication face when that relation is being made, tempting imperative overread, recovered governing pattern, admissible use now, non-admissible overread, stop or reopen condition. | | Architecture or structure wording with hidden selected structure, ArchitectureOf@Context relation, architecture-description use, structural-view use, source-return condition, or named C.30 subcase | Apply C.30.P. If A.22, C.30, C.30.ASV, or a named C.30 subpattern is already recoverable, use it directly. | Recovered selected structure, ArchitectureOf@Context, architecture description, structural view, source-return condition, governing-pattern result, or stop. | | Stratification or structure-source-label wording such as layer, level, tier, stack, ladder, rung, block, expert, cache, router, or gate when the FPF kind under repair, relation, claim-use, or source-use disposition is not yet recovered | Apply C.30.STRAT first. If a control-layer relation, module-interface relation, architecture-to-TransformationFlowStructure relation, mathematical scale relation, coarse-graining relation, publication relation set, gate relation, or neighboring use named by value is already recovered, use that governing pattern directly. | Recovered FPF kind, relation, claim-use, source-use disposition, and governing pattern; StratificationSourceLabelRepairNote; ordinary source label; quote-only, reduced-use, or blocked-use disposition; or stop. | | Characteristic, scale, score, coordinate, metric, indicator, threshold, comparison, or scalar-quality wording with hidden construction | Apply C.16.P. If A.17, A.18, C.16, A.19, C.25, C.29, E.21, or a governing pattern is already recoverable, use it directly. | Recovered Characteristic, Scale, Coordinate, Value, Score, unit, scoring method, comparison basis, indicator role, governing-pattern result, or stop. | | State-family wording with hidden bearer, state frame, value set, admissible use, or governing pattern: state, status, posture, readiness, stance, currentness, or close compounds | Apply A.19.SPR. If the governing pattern and state-like field are already recoverable by value, use that governing pattern directly. | Recovered bearer, state frame or governing pattern, value or classification, admissible use, non-admissible overread, reopen condition, governing-pattern result, or stop. | | Quality or evaluative characterization wording | Apply C.16.Q, C.25, E.21, or another characterization pattern governing the claim after any needed C.16.P repair. If the found problem is relation construction, apply A.6.P instead. | Quality-term repair, Q-bundle or pattern-quality coordinate use, relation split or bridge split when that relation or bridge claim is being made, and blocked scalar, gate, or release overread. | | Function-like wording with hidden FPF kind, relation, claim, view, or governing-pattern application: function, functional, functionality, effect, or close compounds | Apply A.6.F first when kind and relation recovery is needed. If the FPF kind named by value or pattern relation is already recovered by value, use the governing pattern directly. | FPF kind or relation named by value assignment, governing-pattern application, mathematical-lens use, quality pattern application, characteristic pattern application, module-interface pattern application, ordinary-prose demotion, or stop. | | Intentional loss of precision for a narrower admissible use | Apply the controlled precision-reduction pattern, normally A.6.3.CSC, with neighboring E.17.*, A.6.3.RT, F.9, or C.29 when that relation is being made. | Source-bearing side, declared loss, narrower admissible use, blocked downstream use, and reopen condition. | | Durable reusable head, lineage label, concept-set row, cross-context name-use, or UTS-facing name | Apply F.18 after the selected repair has recovered what the name would name. | Name card or naming row only for durable naming need; one-off local wording closes locally. | | Trigger found but kind, relation, substrate, governing pattern, admissible use, or remaining reader move cannot be recovered | Fail closed. | Quote-only wording, reduced-use cue, blocked use, incomplete rewrite, ordinary prose, or not FPF-governed wording. |

reading, read, and quality-read are trigger wording only when the sentence uses the word to carry interpretation, publication use, source-use assignment, evaluation, comparison, evidence, gate, work, decision, release, assurance, or admissibility claim. Do not create ReadingPrecisionRestoration. Recover the actual EntityOfConcern, publication relation position, evaluation claim or bundle, relation, or work-side kind and apply C.2.P, E.17.ID.CR, E.22 plus object-under-improvement evaluation named by value, A.6.P, or the neighboring FPF pattern governing that claim.

function, functional, functionality, and effect are trigger wording when the FPF kind named by value, relation, claim, view, or governing-pattern application is hidden. Do not assign the wording by architecture default. A.6.F remains the function-like wording unpacker; mathematical function, mapping, relation, loss, objective, value functional, or operator goes to C.29 when mathematical-lens use is being claimed. Functional-architecture use goes to C.30 or C.30.ASV when the architecture or structural-view claim is recovered by value; architecture-to-TransformationFlowStructure use goes to the current Architecture Transformation-Flow Structure Relation (C.30.TFS-REL).

layer, level, tier, stack, ladder, rung, block, expert, cache, router, and gate are source labels when they first arrive from engineering, mathematical, publication, or project prose without a recovered FPF kind. Do not mint U.Layer, U.Level, U.Tier, U.Stack, or a universal stratification kind. Use C.30.STRAT to recover the governing pattern, or go directly to the governing pattern when the FPF kind under repair, relation, claim-use, or source-use disposition is already recovered by value: C.30.LCA for control-layer relations, A.6.M for module-interface relations, the current Architecture Transformation-Flow Structure Relation (C.30.TFS-REL) for architecture-to-TransformationFlowStructure claims, E.18 for selected transformation-flow structure, C.16.P or C.29 for scale relation, coarse-graining relation, or mathematical use, C.2.P for publication relation set or source-use relation, and gate patterns, work patterns, or decision patterns when those claims are being made.

Description, publication, and representation mediation source words need the same recovery discipline. Treat stack, lane, profile, mediation, binding, representation, publication, model, space, graph, latent, weights, embedding, vector store, carrier, dashboard, posture, route, path, surface, and close compounds as trigger wording when the sentence has FPF-governed use and the relation position is hidden. Recover the current EntityOfConcern, relation position, direct governing pattern, admissible use, blocked overread, and remaining reader move before writing the final phrase. Do not replace the trigger with another umbrella head; do not mint a durable name unless F.18 is explicitly selected.

Local patterns may cite the relevant E.10 recognition row, but they must not reproduce the wording-recognition table or create local lexical registries unless a named local application profile has its own primary EntityOfConcern, first useful move, and governing-pattern boundary. Specialized restoration patterns carry the detailed ontology when the problem is no longer lexical.

Bounded complete result and direct known governing-pattern rule

The direct known governing-pattern rule is:

If the governing pattern and primary EntityOfConcern, relation record, or claim record are already recoverable by value, use that governing pattern directly.

Apply a precision-restoration realization pattern such as A.6.P, A.6.F, C.2.P, C.30.P, C.30.STRAT, C.16.P, C.16.Q, or A.19.SPR only when wording hides the EntityOfConcern under repair, relation, characteristic, scale, score, quality characterization, source-use disposition, state-family field, admissible use, or remaining reader move.

The bounded complete result is the shortest result that fully recovers the kind under repair and remaining reader move. Shortest is not lowest effort: every FPF-governed use has a by-value disposition, and not triggered or ordinary prose must be stated as such with the checked span.

local rewrite for a one-sentence local ambiguity;
compact repair note or row when one precision-restoration pattern is needed;
governing-pattern application when the FPF kind under repair, relation, claim-use, source-use disposition, or admissible-use boundary is already recoverable;
full restoration check only when several claims being made, admissible-use cases, source-currentness relations, cross-pattern authority, or downstream reliance remain under repair;
fail-closed non-use when recovery is not possible.

After kind and governing pattern recovery, state the remaining admissible reader move: what the reader may now do, why the distinction matters, or which FPF pattern now carries the claim being made. If the repaired wording is type-correct but inert, the repair is incomplete.

Value-substitution check. A wording repair also fails when it optimizes lexical purity while making the working text worse: less readable for its declared reader, less affordable to apply, less semantically composable with neighbors, less clear about the primary EntityOfConcern, relation record, or claim record, or less action-guiding. In that case, narrow the repair, keep ordinary wording with an recovery note with recovered kind and use, use the direct governing pattern, or leave the issue blocking by value. Do not trade real kind, relation, source-use, or admissible-use recovery for smooth prose; this check prevents precision-restoration theatre, not ontology repair.

Tool-assisted trigger inventories may help find candidate spans, but they cannot close ontological precision repair. Closure remains recovered kind, recovered relation or substrate, admissible use, non-admissible overread, and remaining reader move by value.

Replacement-candidate closure. A repair that replaces one trigger word with another word or phrase is not closed until the replacement candidate itself passes the same E.10 trigger scan. If the candidate is another umbrella word, quasi-scale, process metaphor, role-free deontic word, or untyped head, recover the kind named by value, relation, admissible use, and governing pattern, apply F.18 when a durable name is being minted, or fail closed. A bounded repair may therefore require repeated E.10 passes until the candidate wording reaches a stable closure point: ordinary wording with no FPF-governed use, local repair with recovered kind and use, governing-pattern application, F.18 durable-name result, controlled precision-reduction result, or explicit blocker. Do not accept a smoother synonym as repair evidence.

Wording-Use Trigger Check Registry

E.10:0.2 is the shared trigger scan. This section is the check registry for high-pressure wording in FPF-governed text and source prose being unpacked for possible FPF use. It does not create a second all-purpose ontology and does not create domain-pattern outcomes. It selects a closure disposition: local rewrite, selected precision-restoration realization pattern, governing pattern, controlled precision reduction, F.18 durable-name application, or fail-closed non-use.

The words below are frequent in conformant FPF text and in project texts that deliberately use FPF-governed terms, pattern references, relation names, or conformance claims. Files carrying FPF pattern text are useful search examples, not the boundary of language cleanup: the same rule applies wherever the text under repair is claim-bearing FPF, project guidance that deliberately uses FPF-governed terms, pattern references, relation names, or conformance claims, or source prose being unpacked for possible FPF use. They are not banned words. They are words that must trigger kind recovery when they carry ontology, authority, evidence, or admissibility claim. The table gives alternatives to recover from; it must not be copied as a group kind. The chosen result may be a local wording repair, a selected restoration pattern or governing-pattern application, controlled precision reduction, or an explicit not-triggered disposition.

Trigger words	Recovery choices; write the selected kind, relation record, relation phrase, tuple-like record, or not-triggered disposition before use	Must not mean
`case`, `scenario`, `example`, `pilot`, `anti-case`	worked case, recognition case, pilot case, negative control, project situation, evidence case, comparison case, or source example	proof, evidence, universal pattern, accepted `DRR`, source basis, or decision by itself
`basis`	source basis, decision basis, evidence basis, comparison basis, threshold basis, grounding basis, admissibility basis, or authority basis	generic reason, untyped support, or "whatever the text relies on"
`force`, `load`, `bearing`, `claim force`, `claim-force-bearing`, `force-bearing`, `claim-bearing`, `relation force`, `qualifier force`, `support force`, or close compounds	claim being made or admissible-use boundary, relation-bearing use, support-like interpretation under `A.6.P`, qualifier claim, action-guidance use whose governing pattern is named, evidence requirement, assurance use, gate use, work use, decision use, release use, admissibility use, or a conventional pattern-language `Forces` section entry naming a tension that shapes the pattern	unstated strength scale, hidden authority, unnamed evidence weight, unnamed importance, process load, generic pressure, or proof that a wording repair closed
`context`, `scope`, `frame`	bounded context, project operational context, review context packet, source context, reference frame, viewpoint frame, or claim scope	world, situation, authority, authority-reference status, or hidden qualifier
`state`, `status`, `posture`, `readiness`, `stance`, `currentness`, or close state-family compounds	state-like claim over a named bearer, state frame or governing pattern, value or classification, admissible use, non-admissible overread, and reopen condition; apply `A.19.SPR` when hidden	maturity adjective, authority, gate passage, release permission, evidence, assurance, source authority, work completion, or process state by appearance
`claim`, `claim content`, `claim referent`	claim node or claim content in a claim-bearing episteme, claim-bearing publication, admissibility target, EntityOfConcern, or referent relation	sentence, opinion, text fragment, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use, or whole publication unit
`evidence`, `witness`, `ground`, `proof`	evidence record or evidence path, witness, grounding relation, source pin, observation, validation result, or assurance argument component	authority, approval, gate, engineering justification, or truth by label
`authority`, `permission`, `approval`, `commitment`, `obligation`	role assignment, speech act, commitment record, authority relation, gate record, decision record, or policy claim	visible label, author confidence, reviewer praise, explanation, or provenance mark
`admissible`, `lawful`, `legal`, `legality`, `allowed`, `permitted`, `authorized`, `valid`, `pass`, `ready`, `conformant`, `eligible`, or close admissibility-like compounds	claim-specific value, gate decision, constraint-validity result, evidence or assurance use, source-currentness relation, work-plan readiness, dated-work result, external-rule or legal claim, publication-use boundary, state-like value, pattern-quality result, or bounded admissible use whose bearer, source relation, value frame, non-admissible overread, reopen condition, and governing pattern are named	generic permission, legal truth, gate passage, evidence strength, release decision, work completion, source authority, or conformance by label alone
`algorithm`, `program`, `solver`, `proof`, `recipe`, `method`, `workflow`, `process`, `procedure`, `access path`, `query plan`, `control strategy`, `method algebra`, `method graph`, `selector calculus`, or programming-paradigm labels	`U.Method` as semantic way of doing, `MethodRelationStructure@BoundedContext` when method-side relations or compositions are current, `U.MethodDescription` as episteme describing a method or method relation structure, `U.Signature(profile=FormalSubstrate)`, mathematical-lens use, `U.Mechanism` declaration or realization, `U.WorkPlan`, dated `U.Work`, method-family registry or selector outcome, evidence relation, control relation, source quote, or another direct governing pattern selected by current ontic slot, relation position, use relation, or claim kind	one generic method, software-only algorithm, method algebra as root object, mechanism by default, performed work by description, or instruction sequence by representation style
`transformation`, `change`, `pipeline`, `dataflow`, `flow`, `network`, `circuit`, `path`, `slice`, `workflow`, `process`, `operation`, or close change-situation labels	apply `A.3.4.P` when wording points to a situation of change; recover `U.Transformation`, transformed object, transformer or system-in-context, method, method description, mechanism, work plan, dated work, functioning or functional structure, `TransformationFlowStructure`, mathematical description, dynamics, temporal aspect, evidence, source, publication, gate, decision, assurance, result, quote-only source wording, or another direct governing pattern by value	one source-label ontology, generic flow or network head, continuity by older source label alone, graph proof, path proof, method by default, work by default, function by default, or transformation occurrence by wording alone
`route`, `path`, `workflow`, `lifecycle`, `dispatch`, `exit`, `receiver`, `call`, `invoke`, `run`, `flow`, `EvidencePath`, or close movement and control metaphors over representations or pattern relations	`C.2.P.DR` repair, `E.18` graph path or `PathSlice`, `A.10 evidence path for a claim, effect, or use`, state predicate, checklist predicate, SQL-like query, table representation, dashboard representation, publication face, source-chain relation, carrier file path, mathematical-lens use, method claim, method-description claim, work plan, dated work occurrence, or declarative FPF pattern relation under `E.8` or `F.19`	imperative program, action route, permission route, release route, evidence route, pattern dispatch, or work sequence unless that governing kind is recovered by value
`profile`, `harness`, `catalog`, `registry`, `index`, `map`	profile with a named source-basis relation, evidence-basis relation, architecture-basis relation, or review-basis relation/use; review harness; entry index; registry record; source-reference map with a named map kind; navigation index; catalog publication; benchmark harness; publication form; companion publication; publication-companion relation; or governing record named by value	governing FPF pattern, governing source, ontology, method, or release decision unless named by value
`entry`, `front door`, `corridor`, `route`	navigation aid, recognition entry, navigation-bearing publication, corridor overview, or movement, control, and temporal relation	governing pattern body, mandatory process sequence, release readiness, or proof that the target publication or target record is complete
`same`, `parity`, `identity`, `equivalence`, `mirror`	same EntityOfConcern, semantic equivalence, bridge relation, version identity, carrier mirror relation, or file mirror relation	similarity, substitutability, no-loss transform, source equality, or authority equality by wording resemblance
`file`, `path`, `host`, `packet`, `bundle`, `package`	carrier path, file carrying FPF pattern text, review-facing target packet, review-facing context packet, package-form decision, or transport bundle	episteme, publication form, pattern body, review result, `authoritySourceRef` target, governing FPF pattern, or authority-reference relation
`quality`, `characteristic`, `metric`, `indicator`, `score`	`U.Characteristic`, quality term, Q-bundle, scale, indicator, observed value, benchmark, or evaluation record	vague praise, scalar truth, success proof, or replacement for the named characteristic space
`slot`, `field`, `row`, `label`, `badge`, `mark`	schema slot, relation slot, table row, publication label, provenance mark, status badge, or cue	kind, evidence, authority, gate passage, or proof of currentness
`EntityOfConcern`, `EntityOfInterest`, `EoI`, `EoIClass`, `describedEntity`, `DescribedEntityRef`, `primary described entity`, or EntityOfConcern-like heads	EntityOfConcern, EntityOfConcern reference, EntityOfConcern class constraint, publication-unit primary entity of concern, source-side wording translated to the adopted EntityOfConcern family, ordinary topic or subject, or project-side kind and reference pair	universal object, second C.2.1 slot family, relation-valued bucket, free publication-unit field, authoring target, carrier, or reader interest

Lexical Trigger Rewrite Rules

EntityOfConcern, primary entity of concern, and local topic wording

Do not replace every topic-like or object-like phrase with EntityOfConcern. Classify the sentence first.

If local wording meant...	Rewrite as...
the EntityOfConcern named by a claim-bearing episteme or episteme-lane `U.View`	`EntityOfConcern`, `EntityOfConcernRef`, or `entityOfConcernRef` under C.2.1
the admissible class constraint on EntityOfConcern slot values	`EntityOfConcernClass` only where an episteme slot is used or an EntityOfConcern-preserving law is being applied
the primary entity of concern for one bounded `PublicationUnit`	`publicationUnitPrimaryEntityOfConcern` when the unit carries or exposes a claim-bearing episteme or episteme-lane `U.View`; otherwise non-claim-bearing kind or reference named by value, or plain `topic`, `subject` only when no normative slot is being used
wording such as `describedEntity`, `DescribedEntityRef`, `primary described entity`, `EntityOfInterest`, or `EoIClass`	recover the EntityOfConcern-family use named by value, publication-unit primary-EoC use, or local FPF kind; rewrite to `EntityOfConcernSlot`, `entityOfConcernRef`, `EntityOfConcernRef`, `EntityOfConcernChangeMode`, `EntityOfConcernClass`, `publicationUnitPrimaryEntityOfConcern`, or the local FPF kind named by value before FPF-governed use; if no use can be recovered by value, keep the old wording only as quoted source or trigger wording and block reliance
a review target	`review target`, review-facing target packet named by value, FPF pattern, pattern section, or file-carrier set only when the file-carrier interpretation is being made
a local table or paragraph topic with no claim-bearing slot	`topic`, `subject`, or direct noun
an FPF-side pattern, pattern section, accepted `DRR`, FPF publication, FPF view, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use, or companion or projection material being improved	governing FPF pattern, pattern section, accepted `DRR`, FPF publication, FPF view, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use, or companion or projection material
a project-side episteme, publication, record, carrier, or activity under work	project episteme, view, or publication named by value, `A.10` evidence path, typed evidence record, `A.20` constraint or adjudication decision record, `A.21` `GateDecision`, `A.21` `DecisionLogRef`, `B.3` assurance or engineering-justification record, typed status record whose FPF status pattern is named, `A.2.8` `U.Commitment`, `C.11` `ChoiceResult`, `C.11` decision record, `A.6.A` action invitation, `A.15.1` dated `U.Work` occurrence, `A.15` `U.WorkPlan`, `U.Method`, `U.MethodDescription`, carrier relation, or front-end relation

Required check:

EntityOfConcern rewrite:
  sentence under repair:
  claim-bearing episteme or episteme-lane view used? yes or no
  EntityOfConcern, grounding, ClaimGraph, viewpoint slots triggered:
  PublicationUnit primary entity of concern, if any:
  review-target interpretation, process-description interpretation, source-basis-document interpretation, if any:
  source wording retained? yes or no, with reason:
  chosen replacement:
  distinction preserved:
  remaining admissible reader move:

publication-unit wording that implies authoring or interpretation work

When a phrase makes the bounded unit sound like authoring work or interpretation work, split the sentence by kind under repair.

If local wording meant...	Rewrite as...
bounded human-inspected unit inside a publication	`PublicationUnit`
the act of writing or editing	authoring work, editing work, or `U.Work`, `U.WorkPlan`, `U.MethodDescription` where the corresponding claim is being made
a pattern body or section	governing pattern body, pattern section, or `PublicationUnit` of that pattern
a file or rendered medium	carrier, front-end, rendering, or document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use
a publication form	publication form
a generic publication face	generic publication face, or `U.View` only when the governing pattern states that relation
a declared MVPK face	declared MVPK face, and `U.EpistemeView` only under MVPK constraints
a claim-bearing episteme or episteme species named by value	`U.Episteme`, `U.EpistemePublication`, episteme-lane `U.View` with explicit episteme tether, or episteme species named by value

Do not make a permanent technical modifier by joining authoring, interpretation, and unit-boundary concerns. That mix hides whether the sentence is about a publication unit, authoring work, reader inspection, or a carried claim.

content

Do not use content as a governing head. Split it into:

claim-bearing episteme content;
publication-unit text;
publication form;
generic publication face;
declared MVPK face;
carrier data;
record payload;
pattern section;
source-basis excerpt;
review target.

Plain explanatory prose may use content only when the sentence does not carry ontology, authority, or admissibility.

publication

Every FPF-governed publication sentence must say which publication construction is being used:

act or occurrence of publishing, or publishing work;
U.EpistemePublication;
publication form;
generic publication face;
declared MVPK face;
PublicationUnit;
carrier or rendering;
document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use;
external-standard publication;
project record publication.

If the sentence says a publication "supports", "authorizes", "proves", "permits", or "makes admissible" something, split the basis: fill relationClaimSlice when a relation claim is being made, fill admissibleUse when a boundary-use claim is being made, and fill projectSideFPFRef when project-side records, evidence paths, gate decisions, constraint or adjudication decisions, assurance records, work, action invitations, speech acts, commitments, methods, or carriers are being used. If either side is not triggered, say so explicitly rather than filling it with generic support.

surface, view, face

Do not treat these as synonyms.

Word	First split
`view`	`U.View`, `U.EpistemeView`, reader viewpoint, UI view, declared-substrate interpretive view, or review view
`face`	generic publication face, declared MVPK face, UI face, or public-facing companion publication
`surface`	Treat as trigger wording, not as an accepted Tech head. Recover one of: publication face, publication form, publication unit, carrier, rendering, UI or front-end face, physical or geometric surface, companion publication, companion or projection material, carrier relation, or neighboring pattern object named by value.

If the sentence can survive only because these are blurred, the sentence is not ready.

source, target

These are relation words, not final kinds.

Split source into source U.Episteme, source U.EpistemePublication, U.View over a source U.Episteme, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use, A.10 evidence path, authority-reference relation, named FPF pattern cited as source, file carrier, source frame, source context, relation slot on the source side of a named relation, or project-side FPF kind and reference named by value.

Split target into EntityOfConcern, target U.Episteme, review target, governing FPF pattern, project target, work target, target publication form, project-side FPF kind and reference named by value, target frame, target context, or relation slot on the target side of a named relation.

Generic object and target are not final recovered kinds. Keep them only when the sentence is explicitly declaring a variable slot, such as ObjectKindUnderImprovement, ObjectVersionUnderImprovement, ObjectVersionUnderQualityEvaluation, review target, or one named relation endpoint whose endpoint kind is supplied by value nearby. When the kind named by value is known, write the kind named by value: FPF pattern version, DRR, FPF corpus slice, publication form, PublicationUnit, file carrier, system carrier, declared transformation result, candidate proposal, evidence path, gate decision, work plan, method description, object-under-improvement evaluation, or another named FPF kind.

Do not recover an FPF pattern, publication form, PublicationUnit, pattern body, or view as a carrier. Use carrier only for the system, medium, file, rendering, or transport object that bears or renders a publication or symbol. If the text means the FPF pattern publication form, write FPF pattern publication form; if it means the file or rendered medium, write file carrier, system carrier, rendering, or another carrier kind named by value.

Common repair examples:

Problem wording	Required recovery
`target version` in improvement prose	`ObjectVersionUnderImprovement` or `ObjectVersionUnderQualityEvaluation`, unless `target` is a source-side quote
`pattern carrier`	`FPF pattern publication form` when the pattern is the publication form; file carrier or rendering only when the system-side bearer is being claimed
`object evaluation` when the evaluated kind is known	object-under-improvement evaluation name, such as `PatternQualityQBundle`, `DRRDecisionAdequacyEvaluationCharacteristicSpace`, `FPFPillarAdequacyEvaluationCharacteristicSpace`, or declared local evaluation
`thing`, `object`, `target`, `artifact`, or `material` as final head	FPF kind named by value, project-side FPF kind, or blocker

Do not publish "source and target" if the selected relation needs the actual FPF kind.

artifact, material, output, deliverable

These are high-risk umbrella words. Before accepting them, test publication-related and record-related interpretations first:

U.Episteme;
U.View, U.EpistemeView;
publication form;
generic publication face;
declared MVPK face;
PublicationUnit;
carrier, front-end, or rendering;
project-side FPF kind and reference named by value;
work result, work-occurrence output, or project record named by the governing FPF pattern;
evidence carrier;
document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use;
review target.

If none fits, record the candidate missing kind in architecture first; do not invent it inside pattern prose.

record

Use record only when the governing FPF pattern or project practice names the record kind and relation. The nearby wording must say which FPF kind the record instantiates or records, for example:

A.10 evidence path or evidence record for a named claim;
A.21 GateDecision or DecisionLogRef;
A.20 constraint or adjudication decision record;
C.11 ChoiceResult or decision record;
A.15 U.WorkPlan, A.15.1 dated U.Work occurrence, or other named work record;
A.2.8 U.Commitment or A.2.9 SpeechAct publication;
U.RoleAssignment or status-register entry under the named governing pattern;
E.19 review run record or another named review record whose review target and review relation are explicit;
process run record in process documents.

Do not let record mean "any file that remembers something", "the missing source", or "the thing to create when support is absent". If required support is absent, create a prospective repair request, future decision request, prospective work-plan entry, or explicit source-gap note; it does not backdate support.

model, diagram, screen, dashboard, table, note, memo, summary, explanation

These are recognition examples, not governing kinds. Classify each occurrence as one of:

episteme or episteme publication;
U.View, U.EpistemeView;
publication form;
generic publication face;
declared MVPK face;
PublicationUnit;
carrier, front-end, or rendering;
project-side FPF kind and reference named by value;
explanation and source-finding relation under E.17.EFP;
evidence, currentness, and provenance relation under A.10;
gate-bearing claim or effect under A.20 or A.21;
assurance and engineering-justification record under B.3;
work and reliance source-restoration relation under A.15.4.

Keep the ordinary example word only after the governing kind is visible nearby.

reader, reviewer, author, operator

Do not use people-position words as hidden kind names.

Use:

working reader or intended practitioner for ordinary usability;
engineer-manager when the FPF use case is the engineer-manager applying the pattern in work;
reviewer only for a participant in a named review relation; use review process, review gate, or review target for the process, gate, or object;
author only for authoring or editing work;
operator only for an actual U.Role, operator position or process operator in the selected context.

If a text says "reader-facing" or "review-facing", it must also name what is facing that person: generic publication face, declared MVPK face, packet, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use, PublicationUnit, carrier, or UI or front-end.

owner, home, host, locus

These are not interchangeable.

owner may be kept as architecture-discussion shorthand only when the kind under repair is an explicit responsibility assignment or stewardship assignment. It is not an admissible substitute for pattern, DRR, U.Episteme, U.EpistemePublication, publication unit, file carrier, or project record.

Split into:

governing FPF pattern relation or authority-reference relation;
named governing source set;
explicit source-maintenance role assignment;
file carrying FPF pattern text;
file carrier;
publication unit;
process-control role assignment;
role assignment;
evidence record or evidence source;
governing FPF pattern or project target;
support root.

Never use owner to avoid deciding whether the sentence is about a governing FPF pattern, authority-reference relation, file carrier, responsibility assignment, or process control.

route, branch, handoff, path, trajectory, move, flow

Recover the movement, control, and temporal relation set before using these words:

A.16 local move;
A.16.0 trajectory account;
A.19, C.2.2a position in characteristic space or state space;
B.2.5 control relation, control-layer relation;
process handoff;
selector relation or selection mechanism;
work transfer;
E.18 path publication;
A.6.3, A.6.4 episteme morphism or retargeting.

If no movement, control, and temporal relation is being made, keep the word ordinary and non-authorizing.

use, supported use, action, effect

Split the word before accepting it:

applying an FPF pattern to a problem situation;
interpreting or using a publication, view, record, cue, or carrier;
relying on a named project episteme, a named source-basis document, or a project-side FPF kind and reference named by value for a named claim or effect;
admissible act, work, or claim under a named FPF pattern, A.6.P relation claim, relation phrase, or project-side FPF kind and reference named by value;
non-admissible act, work, or claim requiring one other named value: FPF pattern, A.6.P relation claim, relation phrase, project-side FPF kind and reference named by value, C.11 ChoiceResult, C.11 decision record, A.6.A action invitation, A.15 U.WorkPlan, A.15.1 dated U.Work occurrence, U.Method, U.MethodDescription, A.20 constraint or adjudication decision record, A.21 GateDecision, A.21 DecisionLogRef, A.10 evidence path, typed evidence record, B.3 assurance or engineering-justification record, typed status record whose FPF status pattern is named, carrier relation, or front-end relation;
planned work;
actual U.Work;
evidence of interpretation or effect;
gate or admission decision.

Do not let supported use become a generic capability of a document. The FPF-governed wording names the admissibleUse target named by value and non-admissible stronger or adjacent use, relationClaimSlice when a relation claim is being made, and projectSideFPFRef when a project-side FPF kind and reference named by value is being used. If the sentence says "supported", it must name the admissibleUse target named by value and non-admissible stronger or adjacent use, relationClaimSlice when a relation claim is being made, and projectSideFPFRef when a project-side FPF kind and reference named by value is being used. Do not satisfy the rule by naming only a project record, evidence record, gate record, assurance record, engineering-justification record, only an FPF pattern, or one mixed project-side entry when several A.7 or A.15 role, method, work-plan, and actual-work kinds are being used.

sign, concept, denotat, and school-semiotic labels

Do not import the school-semiotic triad as architecture ontology. When a source or review text says sign, signifier, signified, concept, denotat, representamen, interpretant, or sign vehicle, apply the composite recovery order before the term appears in FPF-facing prose.

Possible recoveries include:

U.Episteme or episteme species named by value;
selected EntityOfConcern, grounding, reference-plane relation;
U.View, U.EpistemeView;
publication form, generic publication face, declared MVPK face, or PublicationUnit;
carrier, front-end, or rendering;
cue, displayed wording, mark, status display, credential display, provenance mark, signature evidence;
evidence record, gate record, work-state record, commitment record, role-assignment record, or another project-side FPF kind and reference named by value;
FPF pattern, pattern section, accepted DRR, FPF publication, or FPF view when the object is on the FPF side.

Use concept only where current FPF already has the relevant concept-set, UTS, local-meaning, or Part F machinery available. Otherwise recover the episteme slot, relation, or typed record named by value.

pattern, generic FPF-side object wording, locus, row, target

Pattern is not a free synonym for regularity. If the intended object is an FPF pattern, write FPF pattern or name the governing pattern. If it is not an FPF pattern, do not write recovered FPF construction as the final value. Choose one recovered value by sentence function: episteme, view, publication, publication form, generic publication face, declared MVPK face, PublicationUnit, carrier relation, front-end relation, project-side FPF kind and reference named by value, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use, review target, relation record, relation phrase, C.11 ChoiceResult, C.11 decision record, A.6.A action invitation, A.15 U.WorkPlan, A.15.1 dated U.Work occurrence, U.Method, U.MethodDescription, A.20 constraint or adjudication decision record, A.21 GateDecision, A.21 DecisionLogRef, A.10 evidence path, typed evidence record, B.3 assurance or engineering-justification record, or typed status record whose FPF status pattern is named.

Avoid generic FPF-side object wording, generic named-target wording, locus, row, and host when they hide kind. Use them only when the kind is literally a table row, document with named source-basis relation/use, file carrying FPF pattern text, or review target and the sentence does not need a narrower FPF kind. For FPF-facing wording that carries a claim being made, relation, admissible use, or reader move, these are candidate recoveries, not a group kind: governing FPF pattern, pattern section, accepted DRR, FPF publication, FPF view, typed record, relation record, or relation phrase. Choose one by sentence function.

Union-field unpacking under A.6.P

Do not write authority-bearing FPF pattern, authority-bearing FPF row, FPF row named by value, selected FPF pattern, record, or relation, governing FPF relation, or required project record or action as final fields.

When one of these union-fields appears, make the A.6.P choice explicit:

if the sentence is making a relation claim, recover the RelationKind, endpoints, slots, qualifiers, scope, time, viewpoint, and admissibility target, then express the result as a relation record or relation specification;
if the sentence is not making one relation claim, unpack the context under repair into FPF-side kind, reference, or relation named by value and one project-side FPF kind with its reference, or state that no project-side FPF kind is triggered;
if the same unpacking recurs across cases with one stable recovery apparatus, record a light A.6.P specialization candidate rather than minting a vocabulary-wide replacement field.

This unpacking is mandatory when a publication, display, cue, explanation, dashboard tile, schema, signature, badge, or generated output is being read as evidence, gate passage, work, permission, approval, commitment, release, safety proof, assurance, or engineering justification.

Do not fill one project-side slot with whichever nearby FPF kind is easiest to name. A project publication or record is a description-side item or record-side item; A.15.1 dated U.Work occurrence, A.6.A action invitation, A.2.9 SpeechActRef, A.2.8 U.Commitment, and U.Method and U.MethodDescription belong to different FPF kinds.

Heterogeneous kind lists

Do not repair a heterogeneous list by giving it one broader umbrella name. When a sentence lists unlike candidates such as pattern, DRR, publication, U.View, carrier relation, front-end relation, project-side FPF kind and reference named by value, C.11 ChoiceResult, C.11 decision record, A.6.A action invitation, A.15 U.WorkPlan, A.15.1 dated U.Work occurrence, U.Method, U.MethodDescription, A.20 constraint or adjudication decision record, A.21 GateDecision, A.21 DecisionLogRef, A.10 evidence path, typed evidence record, B.3 assurance or engineering-justification record, or typed status record whose FPF status pattern is named, do not promote the row to a new kind. Classify the list as one of:

one kind under repair selected at bounded complete generality;
a relation set with typed slots;
a tuple-like record;
several alternative cases;
an indicator of failed ontology.

If the list is a relation set, name the slots. If it is a tuple-like record, name the tuple object and its slot semantics. If it is an alternative-case set, split the cases. If it is failed ontology, return to architecture before pattern or DRR prose depends on the list.

strong, stronger, weak, weaker, support

Do not use strength metaphors unless a named FPF scale, evidence class, threshold, or characteristic space is being used.

Preferred rewrites:

stronger claim -> wider claim scope, higher evidence requirement, gate or admission threshold, claim requiring world-contact evidence or authority relation, authority claim, or named evidence-support class;
weaker claim -> narrower claim scope, lower evidence-support class, bounded admissible act, work, or claim, source-loss mode under A.6.3.CSC when a source-to-rendering loss is being claimed, coarsened rendering, or explicit abstain or reopen condition;
support -> one selected support-like interpretation under A.6.P, not a more polished synonym. If the selected interpretation is base, anchor, or basedness, apply A.6.6 and state dependent, base, baseRelation, scope, applicable Γ_time, witnesses, admissibleUse, and nonAdmissibleUse. For FPF-governed support, first choose the support-like interpretation:
source-description relation: a source episteme, publication, view, model, graph, trace, generated representation, or document describes, exposes, renders, cites, or makes inspectable one claim-bearing item;
EntityOfConcern or grounding-holon grounding: the claim-bearing episteme, view, representation, or pattern application is grounded in its EntityOfConcern, local world contact, observation setting, EntityOfConcernSlot, or GroundingHolonSlot;
base, anchor, or basedness relation: the phrase means relative-to, based-on, anchored-in, base change, or scoped grounding as a base relation; use A.6.6 support wording selection and rewrite as baseRelation(dependent, base) or SWBD, not as a generic SupportBasis, SupportRelation, or SupportRecord;
evidence or witness support: an evidence-use relation, evidence path, witness relation, witness carrier, observation, test, observation record, or test record bears on a claim;
assurance or engineering-justification support: an assurance argument, trust calculus, safety case, or engineering-justification claim is being made;
causal-use relation or evidence relation: a causal-use question, rung, estimand, CausalEvidenceSupportBasis, CausalUseSupportVerdict, supported use, and unsupported use are being claimed;
mathematical-lens use or lens-use admissibility: a mathematical lens, mapping, similarity, or formal object makes a bounded claim admissible or exposes preserved structure and lost structure;
characteristic, measurement, threshold, or comparison basis: a characteristic, metric, scale, benchmark, threshold, or comparison basis is being used;
admissible-use or boundary-use basis: the sentence says what use, act, claim, publication use, or reliance is admissible;
work, enablement, prerequisite, resource, or operational help: one thing helps, prepares, routes, resources, enables, or makes work easier without evidence, authority, truth, or admissibility claim;
publication companion, entry, navigation, or reader help: a file, section, index, map, review packet, support document, or companion helps readers find, inspect, compare, or review another item.

Support-headed names such as SupportRecord, SupportSource, SupportLine, SupportForm, a support phrase that hides a state-family claim, SupportSection, SupportMaterial, support basis, support relation, support view, and supported use are diagnostic triggers; they are conformant only when rewritten to a governing FPF record named by value, field, publication function, state-family value under A.19.SPR only when the selected claim is actually a state-family claim, relation, admissible-use boundary, or, for the A.19 case, DeclaredSubstrateInterpretiveView under A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW. If the phrase is base-dependence, A.6.6 is the governing pattern and the text must expose dependent, base, baseRelation, scope, applicable Γ_time, witnesses, admissibleUse, and nonAdmissibleUse. Otherwise rewrite the head to the selected interpretation: source-description relation, EntityOfConcern grounding, grounding-holon relation, evidence path, source-use relation, source-currentness claim, source adoption decision, source adaptation decision, source rejection decision, source-description relation, relation record, admissible-use boundary, assurance claim, C.28 causal-use relation or causal-use verdict, C.29 lens-use output, C.16 characteristic construction, measure relation, comparability relation, bridge card, comparison card, work enablement relation, publication companion, or ordinary reader help.

A support-headed phrase selected by an accepted DRR, pattern draft, table heading, schema field, coordinate name, or future drafting vocabulary is already durable enough to trigger F.18 unless the text explicitly marks it as source-only, quote-only, or rejected. Do not accept subject to F.18 later as E.10 closure when the phrase is already being used to guide authoring, review, landing, or reusable FPF wording. Either complete the naming decision now, replace the head with the selected interpretation named by value, or leave the naming issue blocking by value.

If the sentence cannot name the scale, evidence class, threshold, relation, source-loss mode, EntityOfConcern, grounding holon, base relation, admissible-use target, or support-like interpretation named by value, it is not ready for architecture or pattern prose. A.6.3.CSC governs FPF-governed source-loss-mode governance; A.6.P governs support-like interpretation discrimination and relation precision restoration; C.2.P requires the wording to recover the governing pattern and mode.

Applying patterns versus procedural calls

FPF patterns are applied in problem situations. They are not called, invoked, routed through, executed as procedure steps, or chained as an imperative program. When another FPF pattern governs the claim, the text names the FPF pattern application and the ontology, conformance claim, or conformance section named by value being applied; it does not describe a route, exit, or handoff as if the pattern controlled a sequence.

Use apply pattern, use the pattern guidance, the pattern governs this problem situation, or the case falls under this pattern when the FPF-side pattern application is being made. Do not use project action as a final class. For project-side activity, choose exactly one kind under repair for the sentence: U.Method; U.MethodDescription; U.Mechanism; A.15 U.WorkPlan; A.15.1 dated U.Work occurrence; work-result record or result-measurement record; C.11 ChoiceResult; C.11 decision record; A.6.A action invitation; A.20 constraint or adjudication decision record; A.21 GateDecision; A.21 DecisionLogRef; A.10 evidence path; typed evidence record; B.3 assurance or engineering-justification record; typed status record whose FPF status pattern is named; carrier relation; front-end relation; or another accepted project-side FPF kind. Use route, path, branch, handoff, trajectory, move, or flow only after the movement, control, and temporal relation set has named the FPF kind under repair.

FPF-side and project-side episteme and publication contexts

Semioarchitecture often talks about two different described contexts:

FPF-side episteme and publication context: FPF as episteme, FPF patterns, pattern sections, DRRs, FPF publications, FPF views, support documents and documents with named source-basis, evidence-basis, architecture-basis, or review-basis relations/uses, and review targets;
project-side episteme and publication context: the engineer-manager's project epistemes, publications, views, records, carriers, cues, evidence records, A.20 constraint or adjudication decision records, A.21 gate decisions, A.21 decision-log refs, B.3 assurance or engineering-justification records, commitments, A.15.1 dated U.Work occurrences, C.11 ChoiceResult values, C.11 decision records, and A.6.A action invitations.

Do not blur them with source, artifact, object, material, target, pattern, or broad semiosis. If both contexts are being used, split the sentence into relationClaimSlice when a relation claim is being made, admissibleUse when a boundary-use claim is being made, and projectSideFPFRef when a project-side FPF kind and reference named by value is being used. If one context is not being used, state not triggered rather than leaving a placeholder.

decision, action, work, method, plan

Do not let action cover every project-side event. Split:

decision-making and decision records under C.11 when a decision claim is being made;
role, method, and work-plan and actual-work alignment under A.15;
work occurrence, work plan, work record, launch value or finalization value, or gate record under the relevant work patterns or gate patterns;
action invitation under A.6.A when the representation invites an action without itself becoming authority;
A.15.1 dated U.Work occurrence when the A.15 object under repair is work; A.2.9 SpeechActRef when the act under repair is a communicative act; A.2.8 U.Commitment when the act institutes a commitment.

P2W language from E.18 transformation-flow structure is not a generic source-to-work slogan. Use it only when the chain from principles, theories, and signatures through method choice, work planning, work execution, result measurement, and cycle return is actually being made.

Whole-corpus trigger use

When a whole-corpus cleanup is selected, use this pattern's trigger guide over claim-bearing FPF text and project text that deliberately uses FPF-governed terms, pattern references, relation names, or conformance claims.

Do not do a global string replacement. Classify each unclear term occurrence by the bounded complete rewrite mode and preserve accepted FPF names unless a separate accepted naming decision changes them.

case, scenario, example, pilot, anti-case

These words are useful for recognition and testing, but they often hide whether the text is talking about a project situation, evidence, a worked slice, a negative control, or a decision basis.

Split before use:

working problem situation;
worked case or example;
pilot case;
anti-case, negative control;
evidence case;
comparison case;
source example;
benchmark case;
candidate corpus example.

A case can illustrate or test a pattern. It does not by itself become evidence, a pattern, a DRR, a source basis, or an authority-reference relation. If the case is being used to justify a claim-bearing text change, choose and name each EntityOfConcern under repair or relation separately: evidence record or evidence path, decision basis or decision record, authority relation, relation to a governing FPF pattern, or relation to an accepted DRR.

basis, context, scope, frame

These are boundary, context, relation, and scope words. They must not stand as final kinds.

Split:

source basis;
decision basis;
evidence basis;
comparison basis;
threshold basis;
grounding basis;
admissibility basis;
review context packet;
bounded context;
claim scope;
viewpoint frame or reference frame.

If a basis changes what may be done, fill admissibleUse; fill relationClaimSlice only when a relation claim is being made, and fill projectSideFPFRef when a project-side FPF kind and reference named by value is being used. If context changes the EntityOfConcern, apply the EntityOfConcern, grounding, and reference-plane checks before any bridge, parity, or identity claim.

translation and multilingual heads

A translated term is not automatically the same FPF head. A translation may preserve reader access while losing kind precision, admissible use, source-use boundary, or source-description relation. A bilingual alias is not a Bridge by itself and does not create equivalence, substitution, UTS admission, or cross-context naming relation.

When translated wording has FPF-governed use, recover the FPF kind named by value, local head, publication construction, source relation, and admissible use before accepting the translation. A translated explanation is a derivative rendering; operative claims need source links and E.17.EFP or A.10 when reliance use is being made. A translated PublicationUnit may preserve form while shifting publicationUnitPrimaryEntityOfConcern or carried publication move; apply E.17.AUD or E.17.AUD.OOTD when that shift is being claimed. Local translated heads may use E.17.AUD.LHR or C.2.P without full F.18 unless durable cross-context naming, UTS row, Core-facing term, or reusable FPF head is intended.

state, status, posture, readiness

Do not let state-family wording become a maturity adjective, evidence claim, assurance result, gate passage, release permission, source authority, work completion, or process state by appearance.

When a state-family word has FPF-governed use, apply A.19.SPR unless the governing pattern and local state-like field are already recoverable by value.

Minimum closure:

State-family wording:
  triggerSpan:
  bearerRef:
  stateFrameOrGoverningPatternRef:
  stateValueOrClassification:
  criteriaOrEvidenceRef?:
  admissibleUse:
  nonAdmissibleOverread:
  validityWindowOrReopenCondition?:
  finalWordingOrBlocker:

Typical governing patterns:

If the wording means...	Use...
position in a declared `CharacteristicSpace`	`[A.19](/generated/patterns/A.19)`, with `[C.16.P](/generated/patterns/C.16.P)` first if characteristic, scale, coordinate, score, or threshold construction is hidden
reusable state-transition or dynamics law	`[A.3.3](/generated/patterns/A.3.3)`
language-state position for an episteme, publication, or wording-use object	`[C.2.P](/generated/patterns/C.2.P)` where source-publication recovery is needed, then `[C.2.2a](/generated/patterns/C.2.2a)` and `[A.16](/generated/patterns/A.16).*`
source use, source currentness, source publication, or source-use disposition	`[C.2.P](/generated/patterns/C.2.P)`, `[E.17](/generated/patterns/E.17)`, `[E.9.DA](/generated/patterns/E.9.DA)`, or the source-use field named by value
evidence path state, evidence relation, or reliance disposition	`[A.10](/generated/patterns/A.10)`
assurance result, assurance claim, or assurance input	`[B.3](/generated/patterns/B.3)`
local CV, constraint, adjudication, gate, or release readiness	`[A.20](/generated/patterns/A.20)`, `[A.21](/generated/patterns/A.21)`, or the release pattern governing the claim or gate pattern
temporal claim status or temporal-use classification	`[C.27](/generated/patterns/C.27)`, retaining `dynClaimPosture` only as a declared C.27 field
mathematical-lens use admissibility	`[C.29](/generated/patterns/C.29)`, retaining `LensUseAdmissibilityValue` only as a declared C.29 field
`DRR` decision-adequacy result or source-use classification	`[E.9.DA](/generated/patterns/E.9.DA)`
pattern-quality result or quality-evaluation status	`[E.21](/generated/patterns/E.21)`; `[E.19](/generated/patterns/E.19)` remains review and admission profile
landing, monolith, review, queue, handoff, transport, or current campaign state	the process file or release carrier named by value, not user-facing pattern prose unless that state is the pattern's own object

A retained ...Posture, ...Status, ...Readiness, or ...State field must declare field name, bearer kind, governing pattern, value set or classification source, admissible use, non-admissible overread, and reopen or change condition when applicable. If those are missing, rewrite to the governing-pattern phrase or record, mark quote-only or reduced-use, or leave the rewrite blocked.

Do not replace support with a support phrase that hides a state-family claim, a source-use bucket, a basis-headed bucket, or another state-family substitute. Apply the support-like interpretation, base-relation, source-use, evidence, assurance, lens-use, characteristic, or admissible-use pattern that actually carries the claim.

live, current, active, and status or article overwrap

live, current, active, open, pending, and similar status-like modifiers are trigger wording when they attach to pattern, record, object, field, operation, route, locus, move, text, claim, question, use, or relation without saying what state, time window, relation position, use relation, or claim function the modifier adds.

First recover whether the modifier expresses a real FPF value:

If it means source currentness, state, status, readiness, publication-use disposition, quality result, admission state, campaign state, or process state, apply A.19.SPR, C.2.P, E.9.DA, E.21, E.19, the release or process carrier named by value, or the governing pattern for that value.
If it means a claim, question, use, or relation is currently asserted, relied on, or action-bearing in the described situation, keep the modifier only when the sentence also names the claim named by value, relation, admissible use, and governing pattern or says why ordinary prose is enough.
If it only points to "the thing under discussion", treat it as phrase-level apparatus and apply F.19: write the pattern, pattern of concern, record named by value kind, affected field, operation claim, relation claim, or other object named by value instead of live X.
If it is development, review, projection, landing, or current-campaign state about an FPF pattern version, keep it in the process, quality, projection, release, or campaign carrier rather than in the pattern unless that state is the pattern's own primary EntityOfConcern.

Do not close this row by deleting live or replacing it with current, active, at issue, or another status word. Closure is a KindRestorationCheck: the modifier is ordinary prose, a state, currentness, relation-position value, use-relation value, a retained claim marker, use marker, or relation marker with named admissible use, an F.19 apparatus removal, or a blocker.

claim, evidence, witness, ground, proof

Claim is not a synonym for sentence or prose. Evidence is not a synonym for source, proof, approval, or confidence.

For claim, recover:

claim-bearing episteme;
claim node, claim content;
EntityOfConcern or claim referent;
viewpoint and representation scheme when needed for the claim;
admissibility target when the claim is used.

For evidence-like words, recover:

evidence record or evidence path;
witness or source pin;
grounding relation;
validation result;
assurance argument component;
provenance mark only as provenance, not as evidence by itself.

If evidence is being read as engineering justification, gate passage, permission, safety proof, or release confidence, apply the governing FPF pattern or use the project-side FPF kind and reference named by value instead of strengthening the evidence word.

authority, permission, approval, commitment, obligation

These are deontic claims or claims carrying an authority-reference relation, not visual or rhetorical properties.

Recover:

role assignment;
speech act or issuing act;
commitment record;
policy claim;
authority relation;
gate record or decision record;
authority-changing decision;
delegated permission;
contestability, revocation, expiry condition.

Labels, badges, signatures, dashboards, certificates, comments, reviewer praise, and generated explanations may cue authority-looking cases. They do not carry authority unless the authority act, authority record, authority-reference relation, and evidence path are named.

profile, harness, catalog, registry, index, map

These usually point to a review profile, review harness, registry record, catalog publication, navigation index, map, publication form, companion publication, publication-companion relation, or relation between one companion publication and the publication unit or project record it helps readers inspect or use. Choose that kind named by value before writing; do not leave support record as the recovered head unless the named FPF pattern really defines that record kind. Treat one as a governing FPF pattern body, accepted campaign DRR, named current architecture document, or relation to one of them only when the named FPF pattern, accepted DRR, architecture document, relation record, or relation phrase is given by value.

Split:

review profile;
review harness;
source map;
navigation index;
registry record;
catalog publication;
benchmark harness;
entry aid or discoverability aid;
governing pattern body.

If the named companion publication, review profile, review harness, registry record, index, or map mainly helps readers find, compare, test, or review something, keep it as a companion, navigation, or testing aid until a named FPF pattern or accepted DRR records the recurring action-guidance gain by value.

entry, front door, corridor, route

These terms often mix navigation, recognition, movement, and authority.

Split:

entry publication or navigation aid;
first-use recognition text;
navigation-bearing publication;
movement, control, and temporal relation;
process sequence;
corridor overview;
governing FPF pattern named by the problem under repair; if a cluster or relation between patterns is being made, name the cluster phrase or relation phrase named by value and the governing FPF patterns by value.

An entry can make the right pattern easier to find. It does not prove the pattern is sufficient, complete, or ready for gate use.

same, parity, identity, equivalence, mirror

Similarity is not identity. Before accepting same, parity, or equivalence wording, name which relation is being claimed:

mirror file in parity with a governing source;
same EntityOfConcern;
same claim content;
semantic equivalence;
bridge relation;
version identity;
file or carrier equality;
source-publication identity;
no-loss transform.

If the relation is about mirror parity, verify against the governing source or state that the check is not performed. If the relation is semantic, use A.6.3, A.6.4, F.9, or the selected bridge pattern or equivalence pattern rather than relying on matching labels.

file, path, host, packet, bundle, package

These are carrier, transport, or package-form words.

Split:

file or carrier;
mirror file;
file carrying FPF pattern text;
document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use;
review-facing target packet;
review-facing context packet;
release package;
pattern package, pattern family, or pattern group under an accepted decision;
governing source section.

A packet or bundle can carry a review target by value. It is not automatically the authority-reference status, the target pattern, the accepted review result, or the FPF authoritySourceRef target.

quality, characteristic, metric, indicator, score

Do not let evaluation words float.

Split:

U.Characteristic;
characteristic space;
Q-bundle;
E.21 PatternQualityQBundle;
scale;
indicator;
observed value;
benchmark result;
review finding;
decision threshold;
qualitative judgment with no scale.

metric is especially risky because FPF often treats it as imprecise shorthand for scale, value, or indicator machinery. If the text says a quality improved, name what changed: characteristic, scale, observed value, threshold, decision consequence, or admissible act, work, or claim. If "quality improved" refers to an FPF pattern version, name whether the change affects an E.21 required coordinate value, status payload, stop condition, bounded non-use, or governing-pattern application.

slot, field, row, label, badge, mark, cue

These words are not kinds by themselves.

Split:

episteme slot;
relation slot;
schema field;
table row;
row in a pattern body;
publication label;
provenance mark;
status badge;
pre-articulation cue;
displayed cue;
evidence marker.

A label, badge, mark, or cue may trigger review. It does not prove currentness, identity, authority, evidence, gate passage, or release permission unless the source relation named by value and evidence path are named.

Current Scan Reading

For conformant text cleanup and source-expression unpacking, high-risk phrases are not automatically wrong. The shared scan is E.10:0.2; the rows below are episteme-publication-heavy candidate recovery prompts, not a second registry and not group kinds. Choose the recovered value by sentence function before reuse:

topic-like or object-like wording: recover episteme slots or non-claim-bearing project kind;
publication-unit wording that implies authoring or interpretation work: distinguish U.Episteme, U.EpistemePublication, PublicationUnit, file, source note, review target;
content: usually one of claim graph, text span, publication unit, carrier bytes, or document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use;
primary-entity field names: use publicationUnitPrimaryEntityOfConcern when a bounded PublicationUnit carries or exposes a claim-bearing episteme or episteme-lane U.View; otherwise non-claim-bearing kind or reference named by value when no episteme slot is being used;
surface: keep publication face or publication form or interop publication form only when publication-face kind discipline is named by value; otherwise rewrite to generic publication face, declared MVPK face, publication carrier, interop carrier, UI or front-end face, companion publication, source named by value, evidence, assurance, or relation record, or carrier relation;
artifact, material, output, and content: do not let them stay as heads in architecture or pattern prose when they carry ontology or authority;
source, target: acceptable only when the recovered source kind, target kind, and any relation slot being used are also named;
reader, reviewer: safe only when the word really names a usability reader, review participant, or review process; otherwise name the generic publication face, declared MVPK face, packet, or PublicationUnit;
pre-FPF sign vocabulary: recover FPF episteme kinds, publication kinds, view kinds, carrier kinds, and record kinds before reuse; do not rebuild FPF episteme and publication ontology on a concept-sign-denotation triad;
generic FPF-side object wording, locus, row, host, or target: choose the recovered value named by value: FPF pattern, pattern section, accepted DRR, FPF publication, FPF view, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use, file carrier, review target, typed record, relation record, or relation phrase;
supported use: replace with the admissibleUse target named by value and non-admissible stronger or adjacent use, relationClaimSlice when a relation claim is being made, and projectSideFPFRef when a project-side FPF kind and reference named by value is being used;
strong, stronger, weak, weaker: replace with scope, evidence class, threshold, gate or admission threshold, source-loss mode under A.6.3.CSC when a source-to-rendering loss is being claimed, coarsened rendering, or explicit abstain or reopen condition;
authority-bearing FPF pattern or row: split into governing FPF pattern or pattern section, relationClaimSlice when a relation claim is being made, admissibleUse named by value when a boundary-use claim is being made, and projectSideFPFRef when a project-side FPF kind and reference named by value is being used;
route, call, invoke, or procedure-like pattern wording: replace with pattern application or with project-side U.Work occurrence, U.Method, C.11 decision value, or A.6.A action invitation.

High-risk residue classes:

pre-FPF sign vocabulary must be restored to FPF kinds by context;
FPF-side umbrellas: generic FPF-side object wording, generic named-target wording, locus, row, host, and source must be unpacked into the recovered value named by value, such as FPF pattern, pattern section, DRR, FPF publication, U.View, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation/use, file carrier, relation record, relation phrase, or file-carrier phrase;
project-side umbrellas: artifact, material, output, screen, dashboard, credential, badge, and explanation must be unpacked into one recovered value named by value, such as publication, generic publication face, declared MVPK face, publication form, carrier relation, front-end relation, project-side FPF kind and reference named by value, A.10 evidence path, typed evidence record, A.20 constraint or adjudication decision record, A.21 GateDecision, A.21 DecisionLogRef, B.3 assurance or engineering-justification record, typed status record whose FPF status pattern is named, C.11 ChoiceResult, C.11 decision record, A.6.A action invitation, A.15 U.WorkPlan, A.15.1 dated U.Work occurrence, U.Method, U.MethodDescription, work-result record, or result-measurement record;
admissibility phrases: supported use, stronger or adjacent use not carried by the pattern of concern, insufficient evidence relation, and similar formulas must name the admissibleUse target named by value and non-admissible stronger or adjacent use, relationClaimSlice when a relation claim is being made, and projectSideFPFRef when a project-side FPF kind and reference named by value is being used;
pattern-control metaphors: route, call, invoke, exit, path, branch, chooser, and workflow must be checked for declarative pattern application versus real movement, control, and temporal claims.

Trigger Concordance And Closure Mechanism

E.10 is applied to a bounded FPF-facing text object, not only to one remembered example sentence. Before claiming E.10 closure over an accepted DRR, FPF pattern, extracted pattern host, monolith section, review-facing packet, or FPF-facing guidance, complete trigger concordance when a high-pressure trigger is FPF-governed across the bounded object.

Do not build a heavy concordance for every ordinary word. Trigger concordance applies when one trigger word or trigger-headed phrase:

appears in a selected name, durable reusable name, heading, table column, schema field, coordinate name, status value, or future drafting vocabulary;
recurs across the problem frame, decision, selected names, validation, and handoff-like action claims or conformance subjects often enough to carry the local architecture;
acts as a replacement head for another broad head;
appears in a returned finding or accepted basis as a term whose meaning must survive into FPF wording;
or remains the only word that lets the sentence appear precise.

The mechanism is:

Inventory the trigger spans inside the bounded object, with loci or grouped loci and count. Mark structural role: ordinary prose, selected name, heading, table column, field, example, quote-only wording, source-only wording, relation phrase, publication phrase, or source-use phrase.
Group occurrences by local interpretation, not by trigger word alone: ordinary no FPF-governed use, local lexical repair, relation-like use, episteme use, publication use, source-use, durable naming need, quote-only or source-only wording, false positive, or blocker.
For each local interpretation, choose and complete the repair consequence. Local repair may close under E.10. Relation-like wording applies A.6.P or its retained specialization. Episteme wording, publication wording, or source-use wording applies C.2.P. Durable reusable naming applies F.18 after the kind under repair and use recovery. Quote-only or source-only wording needs a non-use disposition. Classification labels are not closure endpoints.
Rewrite the bounded object, or leave a blocker. A note saying apply A.6.P when triggered, apply C.2.P when triggered, apply the governing pattern when the recovered claim is being made, subject to F.18 later, classified under A.6.P, classified under C.2.P, or boundaries are stated nearby is not closure unless the recovered result is already present in the final wording or the missing required repair is explicitly blocking. The Final wording or blocker cell must not be empty for any FPF-governed trigger.
Reread saturation. If one trigger word still carries several different local interpretations after repair, or dominates the selected names of the bounded object, the text has likely preserved an umbrella rather than repaired it. Split the local interpretations into names or governing-pattern applications named by value before accepting the wording.

Use this compact closure table when trigger concordance is required:

Trigger span or name	Loci and count with structural role	selected interpretation	Required recovery	Final wording or blocker	Closure disposition
		ordinary no FPF-governed use; local repair; relation-like use; episteme, publication, or source-use; durable naming; quote-only; false positive; blocker	`E.10`, `A.6.P`, `C.2.P`, `F.18`, or not triggered		closed locally; recovered and integrated; quote-only; not triggered by value; still blocking

Allowed closure dispositions are only:

ordinary wording with no FPF-governed use accepted;
local lexical repair closed under E.10;
A.6.P recovery completed and integrated into the text;
C.2.P recovery completed and integrated into the text;
F.18 naming decision completed after kind and use recovery and integrated into the text;
quote-only, source-only, or non-use disposition stated by value;
false positive stated by value;
still blocking.

Do not close trigger concordance with a summary statement that E.10 was applied, with a citation to A.6.P or C.2.P alone, with a correct classification but no governing-pattern repair product, with a later-work promise, or with a table that covers only representative examples while the remaining FPF-governed occurrences keep the same unresolved head.

Recovery and disposition table

E.10 gives only a small local recovery and disposition form. It does not unpack relation-like or episteme-publication-heavy source meaning by itself.

`E.10` result	Recovery product	Disposition
local wording accepted	Ordinary wording with no FPF-governed use.	Leave as ordinary prose.
local wording rewrite	Repaired phrase that names the local kind named by value, register, ordinary sense, or admissible lighter wording.	Accept locally after the replacement-candidate anti-umbrella rule.
relational precision restoration required	Trigger span plus the relation-like wording or relation-bearing use: endpoint, qualifier, slot, scope, time, viewpoint, support-like interpretation, basedness, service, bridge wording, whole-part, mapping, comparison, or dependency.	Apply `A.6.P` or its retained specialization before accepting current FPF wording; if the trigger is a false positive, state that reason by value.
epistemic precision restoration required	Trigger span plus the episteme, publication, source-use relation, or source-expression relation under repair.	Apply `C.2.P` before accepting current FPF wording; if the trigger is a false positive, state that reason by value.
combined precision restoration required	Trigger span plus both relation-like wording and episteme, publication, or source-use wording.	Apply `C.2.P` for source-currentness relation and the claim-bearing episteme or publication relation set; apply `A.6.P` for the relation-bearing slice.

Closure rules

Closure question	Conforming answer
Can `E.10` alone close the case?	Yes only for `not-triggered`, false-positive by value, ordinary wording with no FPF-governed use, and local lexical-repair outcomes whose replacement candidate has also passed `E.10`.
What counts as `closed by value`?	The final wording or the recorded disposition names the recovered kind named by value, relation phrase, relation record, admissible use, non-admissible stronger or adjacent use, source-use disposition, publication construction, durable naming decision, or false-positive reason. The reader must not need chat memory or a future pass to recover what the trigger meant.
What counts as `A.6.P` or `C.2.P` application?	A governing-pattern application is not the classification label. It is the completed recovery product: selected relation interpretation, relation phrase or record named by value, endpoint repair, qualifier repair, scope repair, admissible-use repair, source-use disposition, episteme construction or publication construction named by value, project-side reference, false-positive reason, quote-only disposition, non-use disposition, or named blocker integrated by value into the text or closure account.
Can `E.10` close relation-like wording by itself?	No. If the problem under repair is endpoint, qualifier, slot, scope, time, viewpoint, support-like interpretation, basedness, service, bridge wording, whole-part, mapping, comparison, or dependency, the conforming text applies `A.6.P` or a retained specialization, or states the false-positive reason by value.
Can `E.10` close episteme-publication or source-use wording by itself?	No. If the problem under repair is source wording, episteme, publication, view, face, carrier, publication unit, EntityOfConcern, grounding, FPF transfer, project-side claim, admissible-use claim, or pattern-application wording, the conforming text applies `C.2.P` or states the false-positive reason by value.
Can a replacement term close the case because it sounds more precise?	No. A repair is not conforming merely because the old overloaded word was replaced. The replacement candidate must pass the same trigger scan and anti-umbrella test.
Can a trigger-headed selected name close with `F.18 later`?	No, not when the name is already selected by an accepted `DRR`, table heading, schema field, coordinate, pattern draft, or future drafting vocabulary. Complete `F.18` now after kind and use recovery, replace the head with wording named by value, or leave the naming issue blocking by value.
Can a correct classification close the case without changing the text?	No. Correct classification only starts the consequence. If the trigger is FPF-governed, the final wording must change, the governing-pattern result must be recorded by value, or the issue must remain blocking.
Can a high-frequency trigger close through representative examples?	No. When trigger concordance is required, representative examples may guide grouping, but the closure account must cover all FPF-governed occurrences or exact grouped loci and counts and must say what remains ordinary, repaired, quote-only, rejected, or blocking.
Where do trigger words and examples belong?	In this shared `E.10` scan architecture or in a named local application profile tied to its own primary `EntityOfConcern`, relation record, or claim record. Do not copy growing word lists into `F.18`, `A.6.P`, `C.2.P`, `E.19`, or local checklists.

Problem context

Current name set. E.10 is the current FPF pattern. E.10:0.2 is the shared wording-use trigger scan. The older LEX-BUNDLE or ULR material below is retained as detailed reference apparatus for selected lexical, register, naming, morphology, and local rewrite problems. It is not a second current ontology, not a second wording-recognition table, not a second pattern head, and not a replacement for E.10.ARCH, the selected precision-restoration realization pattern, a governing pattern, or F.18. When the retained material conflicts with E.10:0.2, E.10.ARCH, A.3.4.P, A.6.F, C.2.P, E.24.*, F.18, or a governing pattern named by value, the current applicability table and that governing pattern control the repair.

Intent. Provide one normative trigger-and-repair rule set that makes FPF language unambiguous, composable across contexts, and teachable by design. Authors, reviewers, and tooling use the retained reference apparatus only for the selected wording problem after E.10:0.2 has chosen the closure disposition:

Vertical stratification (Kernel ↔ Extensions ↔ Context ↔ Instance);
Twin registers (Tech and Plain) with safe synonyms;
Naming morphology (allowed suffixes and style) for the kernel’s core objects;
Minimal Generality tests (names are neither parochial nor vacuous);
Ontology recovery rows for overloaded words (e.g., process, function, service);
Conformance checks and minimal examples.

Scope. Applies to: (a) Core (Parts A–G), (b) Extensions patterns specs (CAL, LOG, and CHR), (c) Context glossaries that claim FPF conformity, and (d) Diagrams and prose in normative text. It does not constrain Tooling or Pedagogy wording other than where they quote Core semantics.

Problem

Polysemy drift. Process, function, service, agent, activity slide between structure, recipe, execution, and promise.
Cross‑context collision. A label (e.g., Owner) is assumed “global” though meanings differ per U.BoundedContext.
Name-bloat and parochialism tension. Either hyper‑specific domain names leak into core types, or vague umbrella names obscure invariants.
EntityOfConcern and Description-episteme boundary and specification-use collapse. Authors mix EntityOfConcern (the thing under concern), Description episteme (how we describe it), and specification use (testable criteria, formality, acceptance, and harness-gated use of a Description episteme).
Register soup. Tech terms bleed into Plain pedagogy and vice‑versa, inviting category errors.

Forces

Force	Tension to resolve
Universality and local fit	Kernel must stay universal while allowing domain nuance in a Context of meaning.
Brevity and clarity	Short names help, but only if morphology signals the right kernel slot.
Stability and evolution	Names should survive refactors while accommodating new roles and types without explosion.
Pedagogy and precision	Plain words aid learners; Tech labels anchor formal checks.

Retained register and naming reference

LEX-BUNDLE and ULR (Unified Lexical Rules) are retained labels for reference apparatus inside the current E.10 pattern. They name register, naming, morphology, and local rewrite checks only; they do not name a second pattern, a second ontology, or a second mandatory audit. Use this material only after the E.10:0.2 scan has selected a lexical, register, morphology, or naming problem that actually needs those details.

Vertical Stratification (E.10 -> four strata);
Twin‑Register Discipline (Tech and Plain pairs);
Minimal Generality (MG) principle + tests;
Morphology and Style (suffixes, casing, reserved prefixes);
Canonical Rewrites for overloaded words (L‑rules);
Conformance Checklist (CC‑LEX) and Regression Stubs (RSCR‑LEX).

The retained clauses below apply only within that selected problem and only insofar as they do not contradict the current applicability table or the governing pattern selected by value.

Vertical Stratification (four strata; no cross-bleed)

Rule V‑0 (Strata). Every lexical item in a conformant text belongs to exactly one stratum:

Kernel — U.* types, kernel relations, invariants (e.g., U.Holon, U.Role, U.Method, U.Work, U.PromiseContent).
Extension patterns — CAL, LOG, and CHR exports (e.g., Sys‑CAL, KD‑CAL, Agency‑CHR) that extend but do not override Kernel.
Context — a U.BoundedContext with its Glossary, Invariants, Roles, and Bridges (local Context of meaning).
Instance — concrete identifiers (holders, role assignments, works, carriers).

V‑1 (Unidirectional meaning). Meaning is constrained from Kernel to extension patterns to Context to Instance. No stratum may redefine a higher stratum’s term; it may only specialise or bridge it.

V‑2 (Strata and authoring stances). The four lexical strata above constrain tokens. They are independent of a claim-bearing unit's stance (its CtxState pins such as DesignRunTag, ReferencePlane, and Locus). Strata answer “what words mean here”; stance answers “where this claim is situated” and which evidence-lane expectations apply.

V‑3 (Citation style). When a Context term is used, its Context must be visible at first mention (e.g., OwnerRole:ITIL_2020). If an author needs Cross‑context reuse, they MUST cite a Bridge with a stated Congruence Level (CL) (see F.9).

V‑4 (Firewall). Tooling and Pedagogy idioms shall not leak into Kernel prose (DevOps Lexical Firewall). CI/CD jargon, file formats, or API names MUST NOT appear in Core definitions. (Pedagogy may use them as examples only, in the Plain register, with Tech anchors present.)

Ontology Guards

Tech register ontology guards

Purpose. This section stabilises the Tech register of the kernel lexicon by enforcing head‑anchored naming, explicit kind naming, EntityOfConcern and Description-episteme boundary and specification-use morphology, disciplined treatment of Role and Holder, and Domain usage consistent with D.CTX and UTS. It aligns with F.4 Role Description, A.2.5 role-state relation, A.2.7 role relation structure, F.11 Method Quartet Harmonisation, and F.17 UTS. Scope: Guidance is register‑agnostic and applies to the whole FPF; examples are illustrative and MUST pass Minimal Generality and Domain Anchoring (MG-DA) and other rules of lexical governance pattern E*. This guidance applies to kernel and non‑kernel components (including Part G and patterns in Part C) and SHOULD be reused across extensions.

Onto1 — Head‑anchoring (use Kernel heads + pass LEX.TokenClass, EntityOfConcern and Description-episteme boundary, and specification-use gates)

Rule: The head noun of a term MUST explicitly signal the kind (System, Holon, Role, Work, Episteme, Tradition, Lineage, Characteristic, Method, Profile, Description, Spec, TransformationFlowStructure, Card, Pack, Dashboard, …).
Figurative heads with obvious overload (“Tradition”, “family”, “process”, “function”) are forbidden in the kernel. Use plain twins only with a 1:1 Tech mapping and declare LEX.TokenClass for the Tech token. They MAY appear only in the Plain register as 1:1 twin‑mappings to a Tech token, but MUST NOT appear in the Tech register. Plain language should minimise lexical error from overloaded terms; use plain‑twin lexical guards.
- Do: IncidentDashboard, MethodSpec, TraditionProfile, TransformationFlowStructureDescription.
- Don’t: IncidentBoard, TDD Tradition, Production Process (kernel), Service Function (kernel).

Onto2 — EntityOfConcern and Description-episteme boundary and specification-use morphology (ref. E.10.D2)

Rule: A term for the EntityOfConcern uses the bare head for the FPF kind under concern: Method, Tradition, Characteristic. A Description episteme appends …Description: MethodDescription, TraditionDescription. A Description episteme admitted for specification use appends ...Spec and presupposes acceptance criteria, harnesses, measurable anchors, formal checkability, verification use, or another specification-granting gate named by value (normative in E.10.D2 and neighbouring patterns). E.g., Algorithm is a species of MethodDescription for a computer (a system in the role of information transformer); if expressed in a formal language and bundled with acceptance tests, it is MethodSpec (per F.11). If expressed as pseudo-code, it is MethodDescription.
Formal-description guard: A formal mathematical or physical theorem, including a formal postulate theorem in physics, remains a Description episteme until a bounded use assigns specification use. Its formal language belongs to formality and publication-expression discipline; it becomes a specification only under acceptance criteria, harness checks, normative invariants, measurable anchors, verification use, or another specification-granting condition named by value.
Extension: Apply the same morphology to non-method EntitiesOfConcern where appropriate: TransformationFlowStructureDescription, TransformationFlowStructureSpec, SystemDescription, and SystemSpec.
Do: SamplingMethod - SamplingMethodDescription - SamplingMethodSpec.
Don’t: SamplingAlgorithm (when it is just prose), SamplingProcessSpec (head not signalling kind). Onto3 — Roles, RoleAssignments, and episteme-symbol carriers (holonic) (ref. A.2, A.2.1, F.4, and F.5)
Rule: A work-facing role value may use a Tech label ending in …Role and is described through F.4 Role Description, e.g., SafetyOfficerRole, ReviewerRole. Role-characteristic spaces, role-state relations, and role relation structures are neighboring governed values; they are not hidden inside the role name. The concrete assignment relation is a U.RoleAssignment with explicit holderRef, roleRef, boundedContextRef, and optional windowRef; do not use a compact role-assignment display string as the normative model. Carrier is reserved for a system that carries or makes available a symbol of episteme (U.Episteme, Tradition, Lineage, Profile, repertoire) independent of any concrete role assignment, e.g., LeanTraditionCarrier, CalibrationLineageCarrier. Avoid Artefact as a head in the kernel: it is ambiguous between an episteme-symbol carrier, a system made by a transformer, or an episteme abstracted from its carrier.
Register note: Job titles (Reviewer, Owner, Lead) belong in the Plain register and MUST twin-map to explicit Tech …Role tokens.
Why: This resolves inconsistent “role carrier” and “role-assigned holon/system” usage: use U.RoleAssignment for the contextual assignment of a holon/system to a …Role; keep “Carrier” for the system that carries or makes available a symbol of episteme.
Rewrite note. …CarrierRole used for a role-assigned holon/system MUST be rewritten to an explicit U.RoleAssignment(holderRef=..., roleRef=...Role, boundedContextRef=..., windowRef?=...). Use SCR-LEX to enforce the rewrite.
Do: ReviewerRole (or AssessorRole), U.RoleAssignment(holderRef=TeamAlpha, roleRef=ReviewerRole, boundedContextRef=JournalIssue42Context); LeanTraditionCarrier (U.Holon), independent of any particular role assignment. Don’t: Reviewer (as a kernel type), ReviewerCarrier (to mean a role-assigned holon/system), SystemReviewer (role collapsed into a type). Onto4 — Domain only as a catalog mark (ref. E.10.D1 D.CTX; publish stitching on UTS)
Rule: Domain is not a kernel kind and carries no semantics, inheritance, or reasoning rights. It is a catalog mark that groups several U.BoundedContext entries.
Required stitching (see D.CTX and UTS). Any use of Domain MUST present: 1. the enumerated list of ContextId in D.CTX, and 2. the corresponding UTS strings (F.17) with twin labels.
“Discipline ≠ Domain.” Domain labels are catalog‑only (D.CTX + UTS); Discipline is a CG‑Spec‑governed holon (U.Discipline). Cross‑use requires Bridge (F.9) + CL; LexicalCheck MUST fail texts that equate Domain with Discipline.
Governance. No “Domain … governance”. Rules of comparability and aggregation belong to Discipline or CG‑Spec (ComparatorSet, ScaleComplianceProfile (SCP), MinimalEvidence, Γ‑fold, CL policy), not to Domain. Prefer DomainFamily + stitching over inventing new “Domain” types.
Do: DomainBundle: ClinicalSafety → {ContextId: AdverseEvents, DeviceLabelling, …} + UTS twins.
Don’t: ClinicalSafetyDomain as a type with inheritance; Domain Governance sections in Tech.

Onto5 — Always state what the term names

Rule. The definition or first line of a gloss MUST state the FPF kind named by the term: a U.Holon, U.System, U.Episteme, Tradition, Lineage, Profile, Role, U.Work execution, Characteristic, or Carrier.
Do: “Kind named: ReviewerRole — a role intention playable by a holon within an editorial context.”
Don’t: “Reviewer — a person who …” (blurs the kind named).

Onto6 — Bans and ontology recovery hints (mirror E.10 § 9 L-rules; do not duplicate tables; not a substitution table)

process, procedure, workflow, function, or activity -> first recover the wording family: change-situation wording applies A.3.4.P; function-like wording applies A.6.F; possible recovered values include U.Method, U.MethodDescription, U.WorkPlan, dated U.Work, U.Transformation, and TransformationFlowStructure only after the governing kind, relation position, use relation, or claim kind is named by value.
Tradition → Tradition (Tech); leave “Tradition” only as a Plain twin with an adjacent Tech label.
domain → DomainFamily + {ContextId list} + UTS twins.
…CarrierRole used for a role-assigned holon/system -> explicit U.RoleAssignment(holderRef=..., roleRef=...Role, boundedContextRef=..., windowRef?=...).
ambiguous Owner in role names → prefer StewardRole, CustodianRole, or an explicit responsibility head.
job titles (owner, lead, champion) in the kernel → use explicit …Role names; keep titles in Plain with twin-labels.
Do: ReturnsTransformationFlowStructureDescription, Tradition: Test-Driven, U.RoleAssignment(holderRef=LedgerTeam, roleRef=CustodianRole, boundedContextRef=AssetLedgerContext).
Don’t: Returns Process, TDD Tradition (kernel), Ledger Owner (underspecified).

Worked mini-examples across arenas

Software engineering: BuildTransformationFlowStructureDescription, CIHarnessSpec; U.RoleAssignment(holderRef=RepoTeam, roleRef=MaintainerRole, boundedContextRef=RepoXContext). Avoid Build Process, Repo Owner.
Applied research and experimentation: SamplingMethodSpec, CalibrationLineageCarrier; U.RoleAssignment(holderRef=ReviewPanel, roleRef=ReviewerRole, boundedContextRef=GrantCallYContext). Avoid Sampling Algorithm (if prose), Lab Owner.
Production and service management: ShiftWork, SafetyOfficerRole; U.RoleAssignment(holderRef=TeamAlpha, roleRef=SafetyOfficerRole, boundedContextRef=PlantOpsContext). Avoid Safety Officer as a type, SafetyDomain Governance.
Operations research and optimisation: RoutingMethodDescription, CostCharacteristic; U.RoleAssignment(holderRef=AnalysisGroup, roleRef=ModelStewardRole, boundedContextRef=ORProgramContext). Avoid Routing Function, Model Owner.
Healthcare and clinical ops: CarePathwayTransformationFlowStructureDescription, MedicationAdministrationWork; U.RoleAssignment(holderRef=DrK, roleRef=AttendingPhysicianRole, boundedContextRef=Ward12Context). Avoid Care Process, Ward Owner.
Finance and accounting: ReconciliationMethodSpec, JournalPostingWork; U.RoleAssignment(holderRef=TreasuryTeam, roleRef=TreasuryStewardRole, boundedContextRef=LiquidityBookContext). Avoid Reconciliation Process, Account Owner (underspecified).
Legal and compliance: RetentionPolicySpec, InvestigationWork; U.RoleAssignment(holderRef=PrivacyOffice, roleRef=DataProtectionOfficerRole, boundedContextRef=OrgXContext). Avoid Compliance Function, Data Owner (underspecified).
Cloud and IT operations: IncidentTransformationFlowStructureDescription, RunbookMethodSpec; U.RoleAssignment(holderRef=OnCallRotation, roleRef=OnCallEngineerRole, boundedContextRef=ServiceYContext). Avoid Incident Process, Service Owner (underspecified).
Logistics and supply chain: PickingWork, RoutingMethodSpec; U.RoleAssignment(holderRef=DispatchDesk, roleRef=DispatcherRole, boundedContextRef=HubZContext). Avoid Picking Process, Fleet Owner.
Construction and civil engineering: PermitAcquisitionTransformationFlowStructureDescription, InspectionMethodSpec; U.RoleAssignment(holderRef=SiteOffice, roleRef=SiteStewardRole, boundedContextRef=ProjectLot17Context). Avoid Inspection Process, Site Owner.
Emergency response: TriageMethodDescription, EvacuationTransformationFlowStructureDescription; U.RoleAssignment(holderRef=IncidentLead, roleRef=IncidentCommanderRole, boundedContextRef=EventRContext). Avoid Triage Function, Incident Owner.
Agriculture: IrrigationTransformationFlowStructureDescription, SoilSamplingMethodSpec; U.RoleAssignment(holderRef=FieldTeam, roleRef=FieldStewardRole, boundedContextRef=Plot17Context). Avoid Irrigation Process, Field Owner. Checklist before minting a KernelToken

Head noun signals kind (Onto1).
EntityOfConcern and Description-episteme boundary and specification-use morphology correct (Onto2).
If role-related: Role, RoleAssignment, and episteme-symbol carrier separation observed; holonic scope explicit (Onto3).
Any Domain mention stitched to D.CTX and UTS; no norms on Domain (Onto4, Onto6).
Object‑of‑talk declared (Onto5).
SCR-LEX rewrites checked for current role-assignment and episteme-symbol carrier separation (Onto6).

Note on registers. Keep figurative or business-casual terms in the Plain register only, with strict twin-label links to the Tech token under current E.10. In the Tech register, speak in KL-CAL: episteme-about-epistemes (Tradition, Lineage, Profile), not in catalogue-admin idioms.

Onto‑Deon — Deontic lexicon guard (Core register) Rule. In the Conceptual Core, avoid using “Standard” as the head noun of an EntityOfConcern name unless the object is an explicit deontic speech-act under the Gov lens (cf. E.3).

For interface and boundary invariants and public commitments of things (holons, interfaces, ports), prefer EntityOfConcern-side names named by value like InterfaceContract, ComplianceProfile, AcceptanceSpec, InteropProfile, etc.

Use the word standard for a publication of a Description episteme, possibly admitted for specification use, that is intended to be complied with and has explicit compliance checks.

If an EntityOfConcern-side item is currently named … Standard, rename it to a proper EntityOfConcern-side name, and (optionally) add a separate publication of the relevant Description episteme under the needed compliance or specification use that contains the standard text and the intended compliance checks. Rewrite hints (Tech → Tech). publication Standard → publication standard; frame Standard → frame standard; measurement Standard → measurement standard; Method Interface Standard (MIC) → Method Interface Standard (MIS); Boundary-Inheritance Standard (BIC) → Boundary-Inheritance Standard (BIS). Rationale. Keeps Core prose centred on EntitiesOfConcern and their boundary invariants; reserves deontic obligations for governance contexts and U.PromiseContent‑like promises. Do not misuse “plane”: deontic speech‑acts are analysed via the Gov lens, while ReferencePlane remains {world | concept | episteme}.

Twin‑Register Discipline (Tech and Plain)

Plain twin (LEX). A registry entry pairing the authoritative Tech label with a display‑only Plain label for one U.Type in one U.BoundedContext; governed by PTG (Plain Twin Governance; in the LEX registry) and referenced by Twin‑Map ID (LEX). “Plain twin” ≠ the Plain register (the register is where twins may be used; the twin is the 1:1 mapping). Convention. In this spec, Plain (capitalized) names the register; plain twin (lowercase) names the 1:1 mapping entry.

Rule R‑0 (Registers). Every Kernel and Extenstion patterns concept has a Tech label (the testable semantic token) and an optional Plain label (didactic synonym). The Tech label is authoritative; the Plain label is permitted only in expository text and must map 1:1 to the Tech meaning inside the current Context.

Allowed pairs (normative table; examples)

Tech (authoritative)	Plain (didactic)	Notes and guards
`U.System`	system, machine, team	Bare “service” is never a safe Plain twin for `U.System`; treat it as an always‑unpack token (L‑SERV, A.6.8). Avoid “service‑instance”; prefer “system instance”, “service access point”, or “service offering” depending on facet.
`U.Episteme`	body of knowledge, document, dataset, model	Pair must respect the Carrier and Content distinction (A.7).
`U.Method`	how‑to, procedure (abstract)	Do not call this “process” (L‑PROC).
`U.MethodDescription`	recipe, SOP, playbook, code, spec‑text	If testable, call out Spec explicitly per E.10.D2 (EntityOfConcern and Description-episteme boundary and specification use).
`U.Work`	run, execution, activity, job, case	Never use “process” or “procedure” here.
`U.Role`	role, hat, mask	Always context‑indexed per D.CTX.
`U.PromiseContent`	promise, offering, service offering	Never equate to provider system or API (L‑SERV).
`U.Capability`	ability, capacity (within bounds)	Separate from Role, Method, and Work; must carry envelope and measures.
`U.Dynamics`	law of change, model of evolution	Not a capability or a method.

R‑1 (Plain first‑use). At first use in a section, show Tech label and (optionally) the Plain twin: “…a U.Method (the how‑to), described by a U.MethodDescription (the recipe) …” R‑2 (No unpaired Plain in CC). Conformance Checklists must use Tech labels only.

Domains can mint aliases inside their U.BoundedContext glossary; all aliases must map 1:1 to a Tech label (SenseCell row in the Context’s Concept-Set Table), and if exported across Contexts, via an Alignment Bridge with congruence-level and loss fields.

Make “plain twins” (reader‑friendly labels) safe by construction, not just style. The plain twin must not change kind, scope, or reader expectations versus the canonical Tech name; it is display‑only and context‑local.

Tech name (tech) — the canonical, kernel‑conformant label used in normative clauses (e.g., U.RoleAssignment, TransformerRole).
Plain twin (plain) — a didactic display alias permitted in expository prose and UI display contexts inside one U.BoundedContext.

Principle: Meaning lives in the Tech name; the plain twin may never move meaning. (Locality is enforced by U.BoundedContext and Bridges.)

Plain Twin Safety constraints (normative)

CC‑TWIN‑1 - One‑to‑one and local. Each Tech name has at most one plain twin per U.BoundedContext; the same plain twin MUST NOT point at more than one Tech name in the same Context.

CC‑TWIN‑2 - Sense‑equivalence proof. A plain twin MUST bind to the same SenseCell as its Tech name in that Context (F.3 and F.7). Authors MUST record at least one counter‑example test showing how the twin could be misread and why it still passes in this Context (SenseCell notes).

CC‑TWIN‑3 - Head‑term discipline (HND). The plain twin MUST preserve the head term of the Tech name, or append an explicit bracketed head on first use:

Roles keep “(role)”, service-facet labels keep “(service promise/access)” after the direct governed value is recovered, Methods keep “(method)”, Work keeps “(work record)”, Capability keeps “(capability)”. Examples: TransformerRole → “Transformer (role)”, U.PromiseContent → “post-op monitoring service promise”; service-access publication or access relation → “service access”, U.Work → “work (work record)”.

CC‑TWIN‑4 - Kind‑consistent. A plain twin MUST NOT map across Kinds (C.3). If the twin’s everyday interpretation could denote a different Kind (e.g., Tradition = organization, corpus, domain), it is forbidden unless qualified by a bracketed head and Context gloss on first use (see CC‑TWIN‑7).

CC‑TWIN‑5 - Ambiguity stop‑list. The following base nouns are reserved and MUST NOT be used as unqualified plain twins: Tradition, service, process, function, model, system, method, standard, library, dataset, evidence, activity, task, action. They are allowed only with an explicit head per CC‑TWIN‑3 and a Context gloss (CC‑TWIN‑7). (This list MAY be extended in the registry.)

CC‑TWIN‑6 - No cross‑context by label. Plain twins are not portable. Reuse in another U.BoundedContext requires a Bridge with CL and loss notes; names alone carry no authority.

CC‑TWIN‑7 - First‑use gloss. At first occurrence in a document or screen, a plain twin MUST be shown as “Plain twin [Tech name] — Context gloss”, e.g.: “Transformer (role) [TransformerRole] — work-facing role value assigned through U.RoleAssignment to a system or acting holon for method-enacting work in OR_2025”.

CC-TWIN-8 - Normative publication-form overread ban. Plain twins MUST NOT appear in Conformance Checklists, predicates, type signatures, or acceptance clauses. Only Tech names are normative. (Plain twins are strictly didactic.)

CC‑TWIN‑9 - Twin budget. At most one plain twin per Tech name per Context. Synonym piles are prohibited (control vocabulary sprawl; see F.14).

CC‑TWIN‑10 - Registry entry and DRR. Every plain twin MUST have a registry entry (in the LEX registry) recording: tech, plain, context, head, SenseFidelity = {3,2,1,0}, ambiguity notes, counter‑examples, DRR id. Any change requires a DRR.

CC‑TWIN‑11 - Tests. Twin entries MUST pass the Twin Harness (see F.15): Head term, Kind consistency, SenseCell match, Stop‑list compliance, and First‑use gloss.

Minimal Generality and Domain Anchoring (MG-DA) — names neither parochial nor vacuous

Principle (MG-DA). A minted name is as general as necessary and no more, and its head noun is anchored to the FPF kind being named. First classify the NameToken (name of a concept: term, lexical unit) itself using LEX.TokenClass, then apply the guardrails corresponding to that class: kernel tokens must unify across domains; discriminator tokens and context tokens must make the domain legible from the name itself. Names too general to have obvious domain are banned.

LEX.TokenClass (meta‑lexical; not a USM Scope)

Definition. LEX.TokenClass : NameToken → {KernelToken | ContextToken | DiscriminatorToken}. This is a Characteristic on NameTokens (symbols), used by the LEX registry and MG-DA checks. It is not a USM scope and carries no truth or validity semantics.

KernelToken — Minimal Generality (MG‑K)

MG‑K1 (Tri‑domain witness, MUST). Maintain a DRR note or Glossary note with ≥ 3 heterogeneous arenas where the invariants hold (e.g., manufacturing, healthcare, cloud ops). If you cannot, narrow to a Context name or move qualifiers into RoleCharacteristicSpace. MG‑K2 (No parochial nouns, MUST). Kernel names MUST NOT contain domain nouns (Ticket, Microservice, Patient, Developer). Such nouns belong in Context or as RoleCharacteristicSpace characteristics. MG‑K3 (No vacuity, MUST). Avoid vacuous heads (Thing, Event, Process, Resource). Use existing kernel heads (U.Holon, U.Work, U.Method, U.Resrc, …). MG‑K4 (Intent over mechanism, MUST). Kernel type and role names encode intent, not mechanism. Mechanisms (algorithms, hardware form, recipe flavors) belong in RoleCharacteristicSpace or Capability. MG‑K5 (Notation independence, SHOULD). The EntityOfConcern-side kind criterion is separable from any one notation or toolchain. MG‑K6 (Refactoring safety, MUST). If a name fails MG, do not mutate it silently. Record a DRR and apply F.13 Lexical Continuity and Deprecation (aliases; Bridges for Cross‑context mappings).

DiscriminatorToken and ContextToken — Domain Anchoring (DA‑D)

DA‑D1 (kind anchoring, MUST). The head noun names the FPF kind being classified (e.g., Sense, Context, Role, Bridge, Characteristic). Readers can answer “X of what?” without external context. DA‑D2 (Characteristic, not axis, MUST). Enumerated properties are named as Characteristic within a CharacteristicSpace (MM‑CAL). Avoid spatial metaphors (axis, dimension, plane, lane, tier, layer) unless the metaphor is a pattern‑defined primitive in this spec. DA‑D3 (Enum clarity, MUST). If the term denotes an enumeration, (a) the value set is small and closed, (b) membership criteria are obvious from the definition, (c) the kind being classified is explicit in the name (e.g., SenseFamily, not bare Family, RowPlane or overly general Facet). DA‑D4 (Anti‑recipe, MUST). Do not bake how-to or local methods into discriminator names; those belong in U.Method or U.MethodDescription, or in U.Capability when the kind under repair is an ability envelope. DA‑D5 (Mapping discipline, MUST). Cross‑context interpretations go through a Bridge (F.9). Discriminator names must not suggest global identity. DA‑D6 (Register discipline, SHOULD). Keep normative tokens stable; synonyms belong in Plain register only and must not appear in constraints or tests. DA‑D7 (Ban generic combinators, MUST). Reject vague composites like NameUseMode, NamingScope, RowFacet/RowPlane/RowLane. Each candidate must pass DA‑D1 and DA‑D3 (kind-anchored head and explicit CharacteristicSpace).

Global tests (apply after 7.2 and 7.3)

MG-DA‑T1 (Three‑arena witness). If LEX.TokenClass(t)=KernelToken, you MUST provide the tri‑domain witnesses (7.2‑MG‑K1). Otherwise this is SHOULD (document at least one contrasting arena). MG-DA‑T2 (Object‑of‑talk). The head noun uniquely signals the subject area; avoid free‑floating metaphors. MG-DA‑T3 (Anti‑recipe). Remove mechanism or implementation words; relocate to Method, Capability, or RoleCharacteristicSpace. MG-DA‑T4 (Enum clarity). For enumerations, list the closed value set and its CharacteristicSpace. MG-DA-T5 (Collision and Uniqueness, MUST). Before merge, perform a full-text search over the corpus and the Reserved-Names registry. The candidate MUST NOT collide with any existing token used in another sense anywhere in FPF. If a collision exists, either rename or raise a DRR to deprecate the prior token. MG-DA‑T6 (Teaching swap). In didactic prose (E.10.D2), the term can be swapped in without caveats. MG-DA-T7 (EntityOfConcern ground, MUST). The definition card states the EntityOfConcern-side kind criterion for membership explicitly; reviewers can check membership without consulting external narrative.

Compatibility with USM (how tokens and scopes meet)

USM applies to acts, not tokens. Mint, rename, and use are LexicalActs that carry a USM scope. LEX.TokenClass constrains where a token may be used via an AllowedScopes policy: Conformance rule. For any usage u of a token t: LEX.TokenClass(t)=c ⇒ USM.Scope(u) ∈ AllowedScopes(c).

The LEX registry defines AllowedScopes(c) (e.g., KernelToken usage in normative kernel constraints is allowed; in Plain register outside a glossary is restricted; Context emissions of KernelToken require a Bridge or alias, etc.).

Audit. Violations are flagged as SCR‑LEX‑Sxx (see acceptance tests below).

Metaphor guidance (non‑binding heuristics)

Prefer object‑anchored heads to metaphors. If a metaphor is unavoidable, ensure it is (a) explicitly defined by a pattern here, and (b) unambiguous within the NameClass. Example families (use sparingly):

Progression metaphors (level, tier, ladder): only where a gate or upgrade is defined by the pattern.
Separation metaphors (lane, track): only where parallel, non‑interfering flows are enforced by rules.
Grouping metaphors (family, class): only for small, closed enumerations attached to a clearly named classified kind (e.g., SenseFamily rather than bare Family).

Short‑form and acronym discipline

SF‑1 (First expansion, MUST). On first use, expand the term; place the short‑form in parentheses (e.g., “Minimal Generality and Domain Anchoring (MG-DA)”). SF-2 (Uniqueness, MUST). Register short-forms in the Reserved-Names list; perform the collision check (7.4-MG-DA-T5). SF‑3 (Form, SHOULD). Prefer typographic separators (MG-DA) to fused acronyms (MGDA). Use the fused form only in code or identifiers where punctuation is disallowed, and only after registration.

Examples (illustrative, canonical)

Prefer U.PromiseContent (promise) over BusinessService; U.Capability over Function; U.Dynamics over NaturalProcess; U.WorkPlan over ScheduleProcess. Do not mint ETLService at kernel level. Model ETL as MethodDescription; recover the service-side claim as promise content, access relation, acceptance condition, delivery work, or publication/API-description use before naming it.

Acceptance and regression checks (LEX and USM)

SCR‑LEX‑S01 (TokenClass declaration). Every normative token has a declared LEX.TokenClass. SCR‑LEX‑S02 (Collision and uniqueness). Full‑text + Reserved‑Names check passes (no other meaning in FPF). SCR‑LEX‑S03 (kind anchoring). Heads name the FPF kind classified (DA‑D1). SCR‑LEX‑S04 (CharacteristicSpace). Enumerations declare their value set and space (DA‑D2 and DA‑D3). SCR‑LEX‑S05 (USM compatibility). For each LexicalAct, USM.Scope ∈ AllowedScopes(LEX.TokenClass). SCR‑LEX‑S06 (Slot and Ref suffix discipline). Any token with suffix …Slot or …Ref is either (a) a SlotKind or RefKind declared under A.6.5, or (b) an episteme field whose type is a RefKind; no ValueKind or other type class may end with these suffixes. SCR‑LEX‑S07 (Manifest provides covers SlotKinds and RefKinds). If a SignatureManifest is present (A.6.0), its provides list MUST include any public SlotKinds (…Slot) and RefKinds (…Ref) introduced by that signature or mechanism, in addition to types, relations, and operators, so SD and lexical linters can treat them as exported API. RSCR‑LEX‑E01 (Banned generics). Reject tokens matching the banned combinators list (DA‑D7). RSCR‑LEX‑E02 (Metaphor hygiene). If a metaphor is used, show the pattern that defines it; otherwise rename. RSCR‑LEX‑E03 (Strategy token minting). Reject new Kernel tokens named Strategy or Policy as kinds; model them as lenses, flows, or compositions inside G.5, or as …Description or …Spec in Contexts. (Prevents kernel overloading; aligns with C.22 “no minted Strategy head”.)

Morphology and Lexical Form (LEX.Morph)

Principle. Form follows the FPF kind being named. A token’s morphology (suffix, prefix, and casing) must (a) express what kind of thing it names, (b) respect MG-DA (Minimal Generality and Domain Anchoring), and (c) pass 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.

Casing and basic forms

M‑0 (Casing and categories). Types and role kinds: UpperCamelCase (IncisionOperatorRole, MethodDescription). Relations and verbs: lowerCamelCase (performedBy, isExecutionOf, bindsMethod). IDs and instances: flat with delimiters (context‑defined) but never collide with type 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.

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	Forbidden misuses (typical)
`Role`	Work-facing role value (EntityOfConcern-side)	EntityOfConcern side	KernelToken or ContextToken	`TransformerRole`, `ApproverRole`	Appearing in BoM or mereology; mixing with run logs; using for evidence, status, standard, source, requirement, or publication-use relations.
`Method`	Abstract way of doing (recipe type)	EntityOfConcern side	KernelToken or ContextToken	`SteriliseInstrumentMethod`	Versioning on `Method` (version the `MethodDescription` instead).
`MethodDescription`	Recipe description (notation‑agnostic)	Description episteme	KernelToken or ContextToken	`JS_Schedule_v4_MethodDescription`	Calling it “process”; encoding runtime actuals here.
`...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`	Execution (runs or kinds of runs)	(run record; not EntityOfConcern and Description-episteme or specification use)	KernelToken or ContextToken	`SpeechActWork`, `W#Seam134`	Plans and schedules; design‑time recipes.
`WorkPlan`	Schedule of intent	Description episteme (plan record)	ContextToken	`MaintenanceWorkPlan_Q3`	Logging actuals; claiming execution.
`Service` (service-facet trigger)	Service promise, access, acceptance, delivery-work, or publication/API-description facet named by the direct governing pattern	Recover promise content, commitment, service-access point, delivery system, delivery work, acceptance claim, or publication/API description before naming.	Trigger wording or ContextToken after recovery	object-storage service promise; passport-issuance service-access claim	Using `Service` as a final durable head-kind beside Role, Method, Work, Capability, or Requirement; naming teams or APIs as "Service".
`Capability`	System ability	EntityOfConcern side	KernelToken or ContextToken	`ScheduleGenerationCapability`	Mislabeling roles or methods as capabilities.
`Dynamics`	Law or model of change	EntityOfConcern side	KernelToken or ContextToken	`LotkaVolterraDynamics`	Using for abilities (`Capability`) or recipes (`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 roles or methods.
`EvidenceRole` (retired trigger only)	Old evidence-role wording; recover evidence-use, source-use, status-use, assurance-use, gate-use, or publication-use relation.	Trigger wording, not a role kind	Trigger wording	evidence-use relation, status-use relation, source-use relation, or publication-use relation named by the direct governing pattern	Using as `U.Role`, `U.RoleAssignment`, 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 Context or run record.
`Boundary`	System boundary	EntityOfConcern side	KernelToken or ContextToken	`SterileFieldBoundary`	Using as a role or method.
`Objective`	Target state	EntityOfConcern side or Description episteme side, depending on formalization	KernelToken or ContextToken	`HemostasisObjective`	Encoding acceptance tests here (put tests in `...Spec` or `MethodDescription`).
`Requirement`	Acceptance condition, requirement claim, or commitment record where binding condition is being made	Description episteme or Description episteme admitted for specification use	KernelToken or ContextToken	`LatencyRequirement`	Using as a role or capability.
`BoundedContext`	Context card	(meta-structural; not EntityOfConcern and Description-episteme or specification use)	ContextToken	`ITIL_2020_BoundedContext`	Treating Context as domain; minting `U.*` inside a Context.
`surface` (trigger only)	Not a durable Tech head by itself; recover publication face, form, unit, carrier, rendering, UI face, physical surface, geometric surface, or the neighboring FPF object.	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’

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 Characteristic×Scale slots); no procedures	Kernel A.19; CHR and space consumers	`CharacteristicSpace`, `CreativitySpace`. Edition of a Space is a phase of the episteme that defines it.
SpaceRef	Pointer	Registry reference to a Space	Data fields and UTS	`CharacteristicSpaceRef`. Use `.edition` on the Ref when pinning a historical phase.
Map	EntityOfConcern-side kind (method)	A mapping method from subjects to coordinates in a declared Space (encoder or featurizer)	Kernel method family (EntityOfConcern side), described through Description epistemes and admitted for specification use only when gates named by value grant specification use	`DescriptorMap` (declares invariances and corpus typing). Not a record or file.
MapRef	Pointer	Registry reference to a Map	Data fields and UTS	`DescriptorMapRef`. Pin the method phase via `DescriptorMapRef.edition`.
Def	Spec-family alternate token (CG-Spec family)	A definition or specification publication that fixes a formula or distance over a space; accepted only inside an explicit CG-Spec registry that already publishes this token	Part G (CG-Spec family)	`DistanceDef` is registry-local CG-Spec wording. Prefer ...Spec in new normative prose; do not generalize ...Def as an FPF-wide suffix.
DefRef	Pointer	Registry reference to the exact CG-Spec registry item that uses ...Def or ...Spec	Data fields and UTS	`DistanceDefRef`. Use `DistanceDefRef.edition` to pin the exact formula 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	Structural position	Named argument position in a relation or morphism signature (SlotKind in A.6.5)	Kernel A.6.0 and A.6.5	`EntityOfConcernSlot`, `GroundingHolonSlot`. Always names a position; never used for ValueKinds or episteme fields.
Ref	Pointer	Reference or identifier to a registry item of some ValueKind (RefKind in A.6.5), not the thing itself	Data fields and UTS; RefKind types	`U.EntityRef`, `U.HolonRef`; episteme fields `…Ref : U.EntityRef`. Reserved for RefKinds and episteme fields typed as them; `…Ref` never carries content and is never used for ValueKinds or SlotKinds.
Series	Governance object	A PhaseOf chain (“editions”) for an episteme	Edition governance	`U.EditionSeries`. Holds immutability and provenance rules.
.edition	Attribute (on Ref)	The phase id of the referenced record; attaches to `…Ref`, not to the record name	Data fields and UTS	Use `XRef.edition`, not bare `XEdition` fields. Lower camelCase for keys.

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 for a measured aspect and CharacteristicSpace for a declared characteristic space where an enumeration is intended (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 must respect kinds. For example, Space is a geometric concept — never use it as a suffix (…Space…) or other morpheme in beginning or in the middle of a term to name non‑geometric entities (e.g. prefer Set, Kid, or Kit instead of Space where membership is intended).

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

Use U.Episteme for the claim-bearing unit. Use U.EpistemePublication or governed U.Episteme publication only when that episteme is available as a published episteme under C.2.1 and E.17 discipline.
Name the publication form separately from the episteme: for example U.PreArticulationCuePack, U.AbductivePrompt, typed bounded projection, partial normal form, endpoint-pattern-governed publication, 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 not the governing pattern.
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, role assignment, status assertion, work occurrence, or permission.
Use governingPatternRef for a named FPF pattern that governs admissible interpretation or use. Use authoritySourceRef when a non-pattern authoritySourceRef target such as an external standard, editioned register, DRR, gate decision, policy source, or role-assignment or status register carries the relevant authority. Do not use generic sign wording, generic episteme-publication wording, generic source wording, generic project-work wording, 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, U.WorkPlanning baseline, planned work, actual U.Work or U.WorkEnactment, work result, result measurement, or non-work reliance on a claim or effect. Do not let generic action, use, or material hide that distinction.
Use C.2.P when episteme-publication-heavy wording carries episteme, publication, view, carrier, relation, admissibility, evidence, work, gate, decision, method, or FPF-pattern-application claim. This parent pattern keeps the lexical and naming discipline; C.2.P supplies the epistemic precision-restoration profile that recovers the FPF kind named by value, relation record, relation phrase, tuple-like record, project-side FPF kind and reference named by value, or not-triggered disposition before final wording is accepted.

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.
Forbidden 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 only for CHR‑grounded measurement and state constructs such as CharacteristicSpace per A.19. Do not coin generic …Space for sets, portfolios, or publication forms. Publish portfolios and archives as sets via admissible selectors; publish them on UTS as views or cards, not as spaces.
Field‑name guard (Kernel blocks). In Kernel conceptual blocks (e.g., A.6.0 and A.6.1 lists), do not name a field …Space; reserve Space to the types (CHR and ReferencePlane families). Use BaseType as the field name and let the referenced U.Type carry …Space where appropriate; otherwise, for set‑valued universes, use …Set.
Space is a geometric concept. Do not use it as a suffix or morpheme for non-geometric sets, portfolios, or publication forms; use Set, Kit, Bundle, Portfolio, or another direct governed kind when that is the current object.

L‑ROLE — disciplined use of Role

Role names a work-facing U.Role value or an explicitly governed source label recovered to that value. A role assignment, role state, role relation structure, holder, method, work, evidence, source, status, or publication claim is not created by the suffix.
Param-slot and relation-endpoint guard. Do not use the morpheme Role for formal parameter positions in operator algebra declarations (OperationAlgebra) or Signature arguments. Reserve Role for work-facing role values governed by A.2, F.4, F.5, F.6, and A.2.7 naming boundaries. Prefer SlotKinds + SlotSpecs (A.6.5) to type formal slots; if a didactic list is useful, use a ValueKindView (name→ValueKind) projection derived from SlotSpecs and SlotIndex. Same for similar situations (table columns, tuple placements): use MG-DA with domain‑specific terminology, never “Role”.

Forbidden suffixes and the DevOps, Data Governance and Repository-Workflow Lexical Firewall

M‑F (Forbidden in Kernel tokens). In KernelToken names, do not use: …Function, …Process, …Task, …Activity. These are ambiguous or vacuous—map using § 6 typing rules (often to Method, MethodDescription, or Work).

M‑FW (Tool and file markers). Tooling and file suffixes (…API, …JSON, …YAML, …CI, …Kafka, …Postgres) are not part of conceptual names. Place them in Context glossaries or operational configs (DevOps Lexical Firewall). Kernel names never carry tool, format, or notation marks. It is pure conceptual, no data management and data governance intended.

Prefix discipline

M‑P1 (Reserved prefixes). U. reserved for Kernel types; Γ_ for algebraic operators; CAL, LOG, and CHR for pattern packages. Never mint U.* inside a Context.

M‑P2 (Edition markers). Apply explicit edition and version markers to Contexts and to MethodDescription, service-description epistemes, service-access publications, or service-offer records named by their direct governing pattern—not to Method and not to bare Service as a head kind (e.g., BPMN_2.0_BoundedContext, JS_Schedule_v4_MethodDescription, PassportIssuanceOfferRef.edition). Authors MAY annotate context-local service labels for didactics after the governed value is recoverable. Norms (edition, release, and version).

edition — the content phase of an episteme (Concept, Object, and Symbol where Symbol‑only notation swaps do not force a phase). Lives in U.EditionSeries. Never embedded in labels (see R‑RD‑7); bind via data: …Ref.edition.
release — a Work of making a Carrier public; may carry tags and dates; does not change episteme identity or phase.
version — a tooling or carrier identifier (file, package, or code). Use only in Tooling and Pedagogy families; not in Core names.

Property discipline. When a field pins a referenced record’s phase, write it as <Thing>Ref.edition (dot notation), never as a standalone …Edition key. E.g., replace DHCMethodEdition with DHCMethodRef.edition.

Morphology tests (apply with § 7 MG-DA)

M‑1 (Slot test). The candidate fits one slot or side in the Strict Distinction lattice (EntityOfConcern ≠ Description episteme ≠ publication carrier; Role ≠ Method ≠ Work). If not, rename or split.

M‑2 (Classified-kind anchoring). The head noun names the classified FPF kind or reference: Role, Method, Work, Context, Characteristic, Capability, Requirement, publication form, service-access relation, service-offer record, or another direct governed kind. No free-floating metaphors and no bare Service head before the service facet is recovered.

M‑3 (Family congruence). Where eligibility clarity is needed, add a context-specific characteristic or role-state relation as a qualifier for the current governed value (e.g., NightShiftOperatorRole for a work-facing role value only when that role value is actually declared). Do not turn standards, requirements, evidence, or status labels into ...Role names, and do not fake families with bare metaphors (no RowPlane, senseFamily, ...Lane).

M‑4 (Run and design split). Use Work only for executions; use MethodDescription for recipes; never cross.

M‑5 (Kernel parochiality). KernelToken names carry no domain nouns; push domain markers to Context or RoleCharacteristicSpace.

M‑6 (Vacuity ban). Avoid vacuous heads (Thing, Event, Process, Resource). Use established kernel heads (U.Holon, U.Work, U.Method, U.Resrc, …).

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; the token must not collide with any other meaning anywhere in FPF (cf. § 7 MG-DA-T5).

Alias hygiene

Aliases are permitted only inside a Context Glossary and map to one technical label with an equivalence note (≡). No global aliases.

Entry lexeme support and lexical-query discipline

Public first-entry scenario text, ToC query rows, local Problem-frame recognition text, or expanded I.2 entry-disambiguation cases 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 entry-distribution loci,
I.2 expanded entry-disambiguation cases,
Table of Content 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, U.Types, 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 forbidden 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 Content rows: prefer 2-5 query phrases;
ordinary README scenario or [E.11](/generated/patterns/E.11) entry-distribution cues: keep only the most discriminating domain phrases and false friends;
fuller lexical sets belong under [F.17](/generated/patterns/F.17), [F.18](/generated/patterns/F.18), and [E.10](/generated/patterns/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 admitted through [F.18](/generated/patterns/F.18) or [E.10](/generated/patterns/E.10). One Russian practitioner phrase may therefore help recover one English canonical pattern while remaining lexical-query support only.

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: using a KernelToken in a Context constraint may require a Bridge or alias; logging Work inside a MethodDescription violates M‑4 and the policy.

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 bans). KernelToken names contain none of the forbidden suffixes (§ 8.2).
SCR‑MOR‑S03 (Prefixes). Reserved prefixes obey § 8.3; no U.* minted in Context.
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 quarantined to Context; none leak into KernelToken names.
RSCR‑MOR‑E02 (USM compliance). For each LexicalAct, verify USM.Scope ∈ AllowedScopes(LEX.TokenClass) (see § 7.5).

Autonomy lexicon (L‑AUTO )

Forbidden (Core): bare “validity”, bare “actor” or “agent” as free‑standing nouns, “kill switch”, “process” for behavior, “envelope” when used as scope. Use instead: Scope (G) for epistemic scope; WorkScope for capability bounds; RoleAssignment for who acts; SpeechAct for overrides; 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.

Scope‑sensitive guards must declare the Γ_time window selector used for admission checks.
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.

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; they must not appear in any CharacteristicSpace. Rule L-CHR-S3 (Status). Episteme statuses, role-state values, deontic statuses, and epistemic statuses are not Characteristics by label alone; they are statuses or states governed by their direct patterns. Rule L-CHR-S4 (Lexical classifiers). Lexical classifiers and tags are Facets or attributes; do not name them as Characteristics, if not declared CSLC. Checks. — CC-L-CHR-1. scope characteristic(s) is banned in Core and Context. — CC-L-CHR-2. CharacteristicSpace near Scope — error. — 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.

LEX‑QA‑1 — Using “‑ility/‑ilities” terms (availability, reliability, …)

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

Authoring choice: — To use such a term as a CHR characteristic, bind it to a named U.Characteristic with one CSLC Scale (A.18) and refer to that Characteristic in guards and UTS; — Otherwise publish a Q‑Bundle (see C.25) that includes Measures (CHR) (the measurable slots) and, where relevant, Scope (USM set over U.ContextSlice) plus window, mechanism, and status fields.

Rationale. Scope is set‑valued (USM) and not a CHR measurement; mechanism fields and status fields are governance records. Keeping them outside the CHR CSLC avoids illegal scalarisation and preserves set‑algebra semantics for scope. (A.2.6 § 6.2; A.6.1; C.16 and A.18).

Ontology recovery rows for overloaded words (LEX L-rules; normative)

What this section does. LEX L-rules standardise how we recover kind and use in Core and Context when overloaded everyday words hide FPF concepts. What this section does not do. It does not restate naming (see § 7 MG-DA) or morphology, casing, and suffix rules (see § 8 LEX.Morph); it depends on them. Guards. Tokens are classified by LEX.TokenClass ∈ {KernelToken, ContextToken, DiscriminatorToken} (§ 7.1). Only CHR:ReferencePlane may use the bare word plane. E.10.D2 names the boundary between EntityOfConcern and Description epistemes with DescriptionContext; specification use needs a granting gate named by value; publication faces, publication forms, PublicationUnits, carriers, and renderings stay separate. Enumerations are Characteristics in a CharacteristicSpace only when a CSLC scale is declared; otherwise treat such slots as non-measurable attributes (not Characteristics).

Hard bans and ontology recovery rows (single table; normative)

Use this table mechanically. “Ban” means the listed phrase is not allowed in Core prose, identifiers, or diagrams unless the canonical appears alongside it (or as a registered Context alias). EntityOfConcern and Description-episteme boundary, specification-use gates, and token gates prevent EntityOfConcern, Description episteme, specification use, publication-position, and TokenClass leaks (cf. § 8.1).

L‑rule	Ambiguous or low-precision word (Ban)	Canonical FPF target(s)	EntityOfConcern and Description-episteme boundary and specification-use gate	TokenClass gate	Notes
L‑PROC	process, procedure, workflow, activity, process-like function step, method-algebra, method-graph, or selector-calculus wording	Recover the current family before choosing the value: `A.3.4.P` for change-situation wording; `U.Method` for semantic way of doing; `MethodRelationStructure@BoundedContext` for method-side composition, substitution, iteration, fallback, selector, or method-family relation; `U.MethodDescription` for description episteme; `U.WorkPlan` for planned work window; dated `U.Work` for occurrence; `U.Transformation` or `TransformationFlowStructure` only when the transformation or transformation-flow-structure claim is named by value; `C.29` when algebraic or graph notation is the selected lens.	EntityOfConcern side for `Method`, method relation structure, `U.Transformation`, and `TransformationFlowStructure`; Description episteme for `MethodDescription` and `WorkPlan`; dated occurrence for `Work`; lens-use for method-algebra notation	Kernel or Context for types; Context for occurrences; lens/register when representation is current	“Industrial process” as line role -> model system plus `...Role`; chemistry in `U.Transformation`, `U.Dynamics`, or `Method` only after the claim is recovered.
L‑FUNC	function, functional, functionality, effect	Apply `A.6.F` first when kind or relation is hidden. Possible recovered values include `U.Capability`, `U.PromiseContent`, `U.Method`, dated `U.Work`, mathematical function or operator under `C.29`, and functional-architecture or architecture-to-`TransformationFlowStructure` relation under `C.30`, `C.30.ASV`, or `C.30.TFS-REL`.	EntityOfConcern side for Capability, PromiseContent, Method, mathematical object, architecture relation, or transformation-flow relation; dated occurrence for Work	Kernel or Context	Never use function as a Core type name or as default architecture meaning.
L‑SERV	service used for team, system, API, ticket, or process	Always unpack to the facet: `U.PromiseContent` (service offering or promise clause), `U.Commitment` (SLA obligation), `U.SpeechAct` (promise or offer act), `accessSpec : U.MethodDescription` (API or interface spec), service access point (`SystemRef`, addressable endpoint), service delivery system (`SystemRef`), service delivery method (`U.MethodDescription`), or `U.Work` (delivery run, case, or ticket).	EntityOfConcern side for PromiseContent, Commitment, and Method; Description episteme for specs; system-side for systems; run record for Work	Kernel, Context, or Discriminator, per facet	“API = service” is forbidden; name the facet head phrase (A.6.8).
L‑SLA	SLA or service level agreement used for SLO, contract, or document	Unpack: (i) SLOs or acceptance thresholds -> `U.PromiseContent.acceptanceSpec`; (ii) binding obligation or penalty -> `U.Commitment`; (iii) packaged “the SLA” -> Contract Bundle (A.6.C); (iv) published terms -> `U.SpeechAct` + clause carrier (`U.Episteme`).	EntityOfConcern side for PromiseContent and Commitment; Description episteme for clause carriers and specs; run record for Work plus evidence	Kernel, Context, or Discriminator	Treat “SLA” as polysemic shorthand; never store it as a single type name.
L‑SCHED	schedule, plan, or calendar as execution	`U.WorkPlan` as intent window; `U.Work` as actuals or telemetry	Description episteme versus run record	Context	Never attach actuals to a plan.
L‑ACT	activity, action, or task as type	`U.Work` (execution); steps belong to `U.MethodDescription` (with `requiredRoles`, capability bounds)	run record versus Description episteme	Context	Reserve verbs: assign for role assignment, admit for role-state relation, execute for Work, actuate for System, and approve for SpeechAct Work.
L‑AGENT	agent, actor, or doer (bare)	recover the acting system or holon as role-assignment holder and name the `U.RoleAssignment(holderRef, roleRef, boundedContextRef)` when a work-facing role is current; use `U.AgentialRole` only where the role value itself is being named	system or holon plus role-assignment relation	Kernel or Context	Org titles (Owner, Operator, Reviewer) are role values assigned in a Context.
L‑OWNER	owner of X (global)	Recover ownership wording as a work-facing role value plus `U.RoleAssignment` in a `U.BoundedContext` when actual responsibility is being assigned (e.g., `OwnerRole:ITIL_2020` assigned to a holder); otherwise recover commitment, authority, source-maintenance, or publication-use relation by direct governing pattern.	role value plus assignment relation, or the direct non-role relation	Context	No global “owner” property in Kernel.
L‑CAP	capability for assignment, recipe, run, or promise	`U.Capability` only = ability with envelope; assignments are `…Role`; recipes `U.Method` or `U.MethodDescription`; runs `Work`; promises `U.PromiseContent` (service promise clause or offering)	EntityOfConcern side, Description episteme, or run record	Kernel or Context	Holder of a Capability is a `U.System`.
L‑DYN	process of diffusion, growth, or learning	`U.Dynamics` (law or model of change)	I	Kernel or Context	Reserve for uncaused change models.
L‑EVID	“paper or dataset proves or ensures”	Recover the evidence-use, source-use, status-use, assurance-use, gate-use, or publication-use relation under `A.10`, `B.3`, `F.10`, `G.6`, `E.17`, `C.28`, or the direct governing pattern named by value; do not route the episteme through `U.RoleAssignment` unless an acting holon is actually assigned a work-facing role.	Description episteme or admitted specification-use episteme, with claim target, scope, polarity, time, provenance, status, or publication-use slots governed by the direct pattern	Context or Discriminator	Evidence use is a relation over an episteme and claim or use; it is not a work-facing role.
L‑CTX	context (fuzzy trope)	`U.BoundedContext` (named card)	—	Context	Never use “depends on context” in Core; name the Context.
L‑BRIDGE	cross‑context equivalence “by same label”	Explicit Bridge Card (F.9): state kind, direction, congruence level, loss, and scope; apply A.6.9 (RPR‑XCTX) for disambiguation and licence-revealing name or verb choice.	—	—	Same label ≠ same concept; umbrella wording such as “same”, “equivalent”, “align”, or “map” must be repaired into a Bridge before it can justify reuse, rows, or substitution.

Red and Green pattern (example). ✗ “The process ensures quality.” → ✓ “The MethodDescription defines steps; dated Work is evaluated against an acceptance condition or requirement relation named by the direct governing pattern.”

Diagnostic examples, not substitutions

Use these rows as compact diagnostics for common ontology recoveries, not as a replacement table. A proposed repaired sentence is accepted only after the EntityOfConcern, head kind, relation or claim kind, admissible use, and scope under repair are recovered and the transformed sentence passes § 7 MG-DA, § 8 LEX.Morph, and the KindRestorationCheck from E.10:10.2. If the example row would change the kind in the local sentence, split the sentence or leave a blocker; do not copy the example as a ready-made rewrite.

Trigger symptom	Recovered ontology example
“the process owner approves”	`U.RoleAssignment(holderRef=SystemX, roleRef=ApproverRole@Context, boundedContextRef=Context)` attributes the SpeechAct Work “approve …” to SystemX under that role assignment.
“the document enforces policy”	`Policy_vN` is a policy or requirement episteme used in a gate, requirement, commitment, or evidence relation named by the direct pattern; enforcement = SpeechAct + audit
“our service runs nightly jobs”	Nightly Work claimsPromiseContent(BatchProcessing); promise content defines acceptance
“the API is the service”	API = `accessSpec : MethodDescription`; promise content defines acceptance
“capability assigned to team Y”	`U.RoleAssignment(holderRef=TeamY, roleRef=NamedRole@Context, boundedContextRef=ContextY)` records the work-facing role assignment; the team (as system) has Capability C within envelope E
“process health green”	StateAssertion for an `ObserverRole` KPI or a service-acceptance KPI passes the named acceptance window
“function of component A fails”	Apply `A.6.F`; if the recovered claim is performed behavior, the `U.Work` occurrence performed by `U.RoleAssignment(holderRef=SystemA, roleRef=NamedRole@Context, boundedContextRef=Context)` failed acceptance (observations show …).
“context is unclear here”	Name the `U.BoundedContext`; else split and Bridge

Acceptance tests (LEX‑AC)

A text passes LEX if all answers are Green:

Context named. Polysemous terms appear inside a named U.BoundedContext (or the page declares a local context card).
Right EntityOfConcern and Description-episteme boundary and specification use. EntityOfConcern, Description-episteme, specification-use, publication relation, and run-record uses are not conflated (cf. § 8.1 gates).
Promise, ability, and performance split. PromiseContent (promise clause), Capability (ability), Work (performance) are not conflated.
No anthropomorphism. Documents, datasets, and models do not “do”; Systems do.
Scheduling hygiene. No actuals on WorkPlan; all actuals belong on Work.
Cross‑context reuse. Any reuse across Contexts cites a Bridge id with kind, direction, congruence level, loss, and scope. Apply A.6.9 (RPR‑XCTX) when the published prose uses “same”, “equivalent”, “align”, “map”, or similar bridge wording.
MG-DA ok. New or refactored tokens pass § 7 MG-DA (anchored head noun; collision check; CharacteristicSpace for enums).
Morphology ok. Suffix, prefix, and casing respect § 8 LEX.Morph (e.g., …Role, MethodDescription, Work, reserved prefixes).
Banned tokens absent or recovered. No process, function, task, or activity in Kernel senses unless the sentence applies the selected recovery pattern (A.3.4.P, A.6.F, work patterns, method patterns, or another governing pattern) and names the recovered value by value; no tooling or file suffixes in Kernel tokens.
State gating present (when needed). Readiness is expressed via a role-state relation value plus StateAssertion, not vague “approved” or “ready”.

Coordination map (how LEX plugs into the rest of FPF)

With E.10.D1 D.CTX (Context discipline). E10-CTX-1: Every Core meaning that can vary names its U.BoundedContext. E10-CTX-2: Same-spelled labels are distinct senses across Contexts; reuse requires a Bridge (F.9) with CL and loss notes.
With E.10.D2 (EntityOfConcern and Description-episteme boundary and specification use and refinement discipline). Speak in the right EntityOfConcern and Description-episteme boundary and specification use. E10-EOC-DESC-SPEC-1..3 apply (the EntityOfConcern is named directly; Description suffixes name Description-episteme use; Spec suffixes name specification use on a Description episteme; work assertions and state assertions are evaluations or occurrences). Upgrades Description to specification use only when checkable acceptance or another specification-granting gate named by value exists.
With A.2 and A.15 (Role–Method–Work alignment). Role = work-facing role value; RoleAssignment = assignment relation; Method = way‑of‑doing; MethodDescription = documented recipe; Work = dated occurrence. Sentences must keep this split.
With F‑cluster (Unification) and UTS (F.17). Harvest in one Context → SenseCell → Concept‑Set row with relation (≡/⋈/⊂/⟂) and losses. UTS is the human‑readable roll‑up.

Acts and tokens. LEX applies to tokens; USM applies to acts: mint, rename, and use. Conformance: LEX.TokenClass(t)=c ⇒ USM.Scope(usage) ∈ AllowedScopes(c) (see § 7.5).

Conformance checklist (LEX‑CC)

LEX‑CC‑1 (Bans). Any banned token in Core or architecture prose fails unless the canonical appears (or the token is a registered Context alias).
LEX‑CC‑2 (Context). Each polysemous term names its U.BoundedContext.
LEX‑CC‑3 (EntityOfConcern and Description-episteme boundary and specification-use morphology). Usage passes § 8 gates (suffix, prefix, and casing), EntityOfConcern and Description-episteme boundary checks, and specification-use checks.
LEX‑CC‑4 (Bridge). Cross‑context reuse cites Bridge id and CL; same‑spelled labels without a Bridge are non‑conformant.
LEX‑CC‑5 (MG-DA). New tokens pass MG-DA tests, including full‑text collision and Reserved‑Names checks.
LEX‑CC‑6 (Service and evidence). Service acceptance is computed from Work; evidence use is a relation over an Episteme, target claim or use, scope, polarity, time, and provenance named by the direct governing pattern.
LEX‑CC‑7 (USM compatibility). For each LexicalAct, USM.Scope ∈ AllowedScopes(LEX.TokenClass).
LEX-CC-8 (Minting discipline). If overload cleanup requires one local replacement phrase, the text records the repaired phrase and the governing local repair pattern. If cleanup requires one durable reusable name, the text completes the full F.18 MintNew or DocumentLegacy procedure; intuition-first partial Name Cards are non-conformant.

Worked micro‑examples (short, cross‑domain)

Factory. ✗ “The process failed; the service restarted itself.” ✓ PLC_17#ObserverRole:PipelineOps logged Observations; CAB_Chair#ApproverRole:ChangeControl performed a SpeechAct “approve restart”; OpsBot#DeployerRole:CD_Pipeline_v7 executed Work RestartRun‑4711 which claimsPromiseContent(CoolingUtility); post-run Evaluation shows the service-acceptance condition passed.

Cloud. ✗ “The process owner approved; the API service deployed.” ✓ ProductLead#AuthorizerRole:Rollout_2025 performed a SpeechAct; sCG‑Spec_ci_bot#DeployerRole:CD_Pipeline_v7 performed Work Deploy‑F123; API = accessSpec : MethodDescription#REST_v12; promise content “Feature Access” declares acceptance; telemetry Work shows fulfilPromiseContent.

Research. ✗ “Dataset X proves the theory; the process is reproducible.” ✓ DatasetX is used in an evidence relation for claim C with model-fit scope, polarity, time, and provenance named by A.10, B.3, G.6, F.10, or the direct governing pattern; replication is recorded through evidence-use, source-use, status-use, or reproducibility-status relations named by the direct governing pattern; procedures are U.MethodDescription; re‑runs are Work.

Semioarchitecture. ✗ “projection has one meaning in routing and bridge prose.” ✓ A.16 keeps projection as a move name for route-bounded partialization; F.9.1 keeps projection as a bridge stance label. If one durable reusable replacement name is really needed, handle the naming question with F.18 MintNew or an explicit source-retention naming decision rather than flattening both local interpretations into one umbrella rewrite.

Editorial note. This section inherits § 7 MG-DA (anchored head nouns; Characteristic and CharacteristicSpace for enums; collision checks) and § 8 LEX.Morph (suffix, prefix, and casing). It deliberately omits their details to avoid duplication. The only legitimate uses of plane in the Core are CHR:ReferencePlane and the derived operators CL^plane and Φ_plane; policy flags MUST NOT introduce new “planes”. To distinguish pre-operational and operational states within ReferencePlane=world, use WorldRegime ∈ {prep|live} (formerly PlaneRegime).

Guarded-head cross-reference (normative lexical caution)

When one wording head already carries several FPF-governed local interpretations, lexical cleanup should prefer a guarded-head note over silent flattening. The note may record that the head remains risky, name the cited texts or patterns that govern the local interpretations, and point readers to the local canonical interpretation in each cited text.

If cleanup reveals that no admissible existing token can carry the needed meaning, use the local repair pattern for one-off wording. If the change needs one durable reusable name, handle the naming question with F.18 MintNew or DocumentLegacy rather than inventing an ad hoc synonym by feel.

This cross-reference is lexical only. It does not create a new repair-side definition site, does not establish Cross-context equivalence, and does not overrule cited local definitions. It simply keeps overloaded heads from being normalized into one false global interpretation.

projection is the main current example: A.16 keeps it as a move name for route-bounded partialization, while F.9.1 keeps it as a bridge stance label. E.10 therefore requires deconfliction notes and explicit naming of the cited text that governs each local interpretation, not one umbrella rewrite that erases the distinction.

Reference routine for turning messy language into E.10-clean prose (informative)

A pragmatic three-pass routine. It is subordinate to E.10:0.2 and is used only when the selected wording problem needs register, naming, morphology, or local rewrite details. It works with plain text, diagrams, or models; no tools required.

Pass 0 — Pre‑flight (2 minutes per page)

0.1 Name the Context card you’re writing in (title, edition, scope note). 0.2 For every new or renamed token, declare LEX.TokenClass ∈ {KernelToken, ContextToken, DiscriminatorToken}. 0.3 Apply the MG-DA pre-check (anchored head noun; no metaphor heads; if enum -> declare its CharacteristicSpace). 0.4 Perform collision and uniqueness checking: full-text grep plus Reserved-Names registry (see § 7). If collides -> rename or DRR deprecate.

Pass 1 — Harvest in the Context

1.1 Underline overloaded words (process, service, function, workflow, ticket, approval, spec, plan, …). 1.2 For each, write a one‑line intent in Plain register (what FPF kind or relation is meant). 1.3 Mark any cross‑Context reuse candidates.

Pass 2 — Recover Core anchors (not substitution)

Pass 2 is not a lexical replacement table. For each underlined word or phrase, first record the pre-repair object kind, relation or claim kind, current ontic slot, relation position, use relation, or claim kind, admissible use, and scope. Then choose one disposition: keep with a guarded-head note, split into several kinds named by value, rewrite locally, record a durable naming case under F.18, apply the governing pattern, or leave blocking. A replacement phrase is admissible only after the post-repair kind, relation or claim kind, current ontic slot, relation position, use relation, or claim kind, admissible use, and scope are recoverable and no umbrella flattening, semantic narrowing, accidental widening, or slot-as-kind substitution has occurred.

2.1 Recover underlined words through § 9 L‑rules table: • recipe -> U.Method or U.MethodDescription, depending on whether the EntityOfConcern is the way of doing or its description episteme • planned work window or dated occurrence -> U.WorkPlan or U.Work • promise -> U.PromiseContent • ability -> U.Capability • actor/doer wording -> ...Role role value or explicit U.RoleAssignment, depending on whether the value or the assignment relation is being named • document or evidence-bearing publication cue → Episteme used in an evidence-use, source-use, status-use, requirement, gate, or publication-use relation named by the direct governing pattern 2.2 Apply LEX.Morph (§ 8): suffix gates such as ...Role, ...Work, MethodDescription, service-description episteme, service-access publication, or service-offer record labels, casing, and reserved prefixes. 2.3 Pass EntityOfConcern and Description-episteme boundary and specification-use check: the EntityOfConcern named directly; recipes and docs as Description epistemes; Spec only where the specification-granting gate is present; actuals as run records. 2.4 Attach Context tags on first use; set twin labels (Tech and Plain) in the local Glossary. 2.5 Record a local KindRestorationCheck for every changed FPF-governed phrase: pre-repair kind, relation, slot position or use position, use, and scope; post-repair kind, relation, slot position or use position, use, and scope; and preserved, split, intentionally changed, or blocker disposition. A changed word without this check remains an unresolved lexical finding. If a relation, signature, field, mathematical-lens, role, method, work, evidence, assurance, gate, or decision use position is being used, cite the governing pattern for that position; E.10 detects the wording-use problem and does not replace the selected ontology.

Pass 3 — Stitch and publish

3.1 Add safe rewrites for any anti‑patterns you found (use § 9.2 quick table). 3.2 If sameness is needed across Contexts, create a Bridge (F.9) with explicit kind, direction, congruence level, loss, and scope; apply A.6.9 (RPR‑XCTX) when quoted or imported source wording uses umbrella language such as “same”, “equivalent”, “align”, or “map”. 3.3 Publish a one‑page UTS (F.17) for the Context (columns: Context, Tech label, Plain label, Kernel anchor, Warnings). 3.4 Log a short DRR when renames or aliases occur (F.13), linking to grep results that motivated the change.

E.10 conformance prompts (normative, concept-only questions)

Use these prompts during review. They reference § 7 (MG-DA) and § 8 (LEX.Morph) instead of repeating them.

Context prompt. Is each potentially polysemous noun interpreted inside a named U.BoundedContext?
EntityOfConcern and Description-episteme boundary and specification-use prompt. Does each sentence use the correct boundary (the EntityOfConcern named directly; Description-episteme use for descriptions; specification use only where a neighbouring gate grants it; run: actuals)?
Token prompt. For new or renamed tokens, is LEX.TokenClass declared and consistent with where the token appears?
Head-kind prompt. Does the head noun name what kind of thing the phrase is actually about: Role, Method, Work, Context, Characteristic, Capability, Requirement, publication form, service-access relation, service-offer record, interpretation, process, or authority use? A narrowing qualifier alone does not answer this question.
Qualifier-claim prompt. If an adjective, participle, genitive, or comparative modifier carries a claim being made, comparison criterion, relation, or admissible-use boundary, has that use been restored explicitly rather than left inside the modifier alone?
Slot, relation-position, and use-relation prompt. If the sentence names an object through a relation slot, signature slot, schema field, mathematical-lens relation position, use relation, or another FPF-governed position, are the object kind, position name, reference mode when required, admissible use, and governing pattern recoverable? If not, apply E.10.ARCH or the governing pattern before rewriting.
Support-like interpretation prompt. If support, supported, supporting, or a support-headed compound has FPF-governed use, apply E.10:0.2 first and then use A.6.P support-like interpretation discrimination instead of a synonym swap. If the selected interpretation is base, anchor, or basedness, apply A.6.6 and state dependent, base, baseRelation, scope, applicable Γ_time, witnesses, admissibleUse, and nonAdmissibleUse. If no interpretation can be selected, do not use support wording for reliance, publication, gate, decision, assurance, work, architecture, pattern-quality, or cross-context reuse.
Comparison-basis prompt. If the sentence compares, ranks, escalates, or downgrades something, is the comparison basis ontologically homogeneous after head-kind and qualifier restoration?
Morphology prompt. Do suffix, prefix, and casing pass LEX.Morph gates (e.g., …Role, MethodDescription, Work)?
Promise, ability, access, and performance split. Are service promise or acceptance content, service-access relation, Capability (ability), and Work (performance) distinct and governed by direct patterns?
Plan and execution split. Are WorkPlan windows separated from Work actuals?
Evidence prompt. Do documents, epistemes, and publications stay in source-use, evidence-use, specification-use, or publication-use relations, while systems or acting holons hold work-facing role assignments and act?
Bridge prompt. If sameness spans Contexts, is there an explicit Bridge with CL and loss notes?
Collision prompt. Were full-text and Reserved-Names checks completed, with no other meaning of this token anywhere in FPF?
Naming-procedure prompt. If one durable reusable name is needed because no admissible existing token carries the needed meaning beyond one local repair, was the full F.18 MintNew or DocumentLegacy procedure completed rather than picking a label by intuition and filling a partial Name Card afterward?
Value-substitution prompt. After the repair, can the declared reader still see the remaining admissible move, and did the repair preserve usability, affordability, semantic composability, neighbor-pattern fit, and local action guidance? If not, narrow the repair, keep ordinary wording with an recovery note with recovered kind and use, or leave the issue blocking instead of optimizing for lexical purity.

Working order for precision repair on FPF-governed prose. Restore the head kind first; a narrowing qualifier such as comparative, safe, interactive, or reliable does not by itself restore that kind. Then unpack the qualifier claim, then check whether the comparison or escalation basis is homogeneous. Only after that may a later Plain, didactic, or coarsened rendering admissibly relax the sentence, and even then the more precise upstream interpretation must remain recoverable.

SoTA-Echoing for lexical governance

E.10 lexical governance is not a private FPF style preference. It is a compact authoring discipline for communication, comprehension, term formation, discoverability, and error prevention. These external practice rows are admitted only where they change what an author or reviewer does in a wording repair.

Practice source	Use of source and source-currentness claim	What E.10 adopts	What E.10 rejects
ISO 704:2022 and ISO 1087:2019 terminology work on concepts, definitions, designations, and term formation.	Current-standard and reference-only for terminology work; official status does not make it complete SoTA for FPF semantic repair.	Mutates `E.10:0.2`, `E.10:0.2a`, and `E.10:11`: use explicit designation and definition discipline when a term is minted, repaired, or made reusable; keep head kind, context, and intended use recoverable.	Do not solve FPF wording by dictionary substitution, synonym stuffing, or global alias registry. Do not turn every term into a class hierarchy.
ISO 9241-110:2020 interaction principles and W3C WCAG 2.2 Understanding SC 2.4.6, 3.2.4, and 3.3.2 on descriptive headings and labels, consistent identification, and visible labels and instructions.	Current-standard and reference plus current practice anchor for comprehension, task suitability, predictable identification, and error prevention.	Mutates `E.10:0.2a`, `E.10:0.2c.15`, `E.10:0.2c.28`, and `E.10:11`: require a repair to preserve the remaining reader move, usable local label, and predictable repeated label; treat label clarity as a usability constraint after kind recovery.	Do not accept readability, friendliness, or a nicer label as proof that the term is semantically safe. Do not let a label change kind, scope, authority, or downstream use.
W3C SKOS Reference for controlled structured vocabularies and lexical labels, with heavier OWL and RDF ontology practice used only by ontology-bearing neighboring patterns named by value.	Current reference source for controlled-vocabulary publication and label relations; not current-best source for every FPF wording repair.	Mutates `E.10:0.2b`, `E.10:0.2c.18`, and `E.10:0.2c.28`: keep vocabulary labels, concept-like heads, registries, maps, and reusable names recoverable as publication or naming objects named by value before reuse; durable naming remains governed by `F.18`, while relation, source, or domain ontology remains governed by the neighboring pattern carrying that claim.	Do not make OWL-style term-to-class modeling the default answer to every vague term. Do not let a controlled vocabulary become a second FPF ontology or replacement wording-recognition table.
W3C WCAG 2.2 headings and labels guidance plus consistent-identification guidance, with FPF-internal `E.11`, README, ToC, and `I.2` entry-distribution practice.	Current reference source for discoverability and label consistency; FPF entry projection remains the governing local architecture.	Mutates `E.10:0.2b`, `E.10:0.2c.29`, `E.10:12`, and `E.11` coordination: keep trigger wording discoverable enough for first repair, but make final wording, governing-pattern application, and entry projection govern the result.	Do not turn wording-recognition lists into local lexical registries, front-door taxonomies, or accepted replacement vocabulary. Do not let search convenience select ontology.

The practical result is simple: lexical governance must improve action guidance and semantic composability, not become language-police work. A SoTA row that does not change a rewrite, a forbidden shortcut, a governing-pattern application, a conformance prompt, or a reopen cue remains decorative and does not carry E.10.

E.10 regression cues (concept-only “diff” triggers)

Re-review your prose when any of these happen:

Context edition changes → re-affirm twin labels, Bridges, and acceptance wording.
A role or type name grows (“and”, “plus”, or “--”) → apply MG-DA: split or bundle (A.2).
A slash, and, plus, &, or similar grouping mark appears in FPF-governed wording → classify the span before editing the mark. The trigger is the FPF-governed grouping use, not the character itself: LLM output, review text, intake notes, or draft prose often uses a slash as lazy and/or, as an untyped bundle, or as an attempt to point at a hidden kind. If the grouped words are claim-bearing heads, relation heads, kind candidates, a lazy and/or join, or an attempt to point at a hidden kind, apply MG-DA, A.6.P, or the selected restoration pattern: split, bundle, or recover the relation named by value and admissible use. If the mark is part of accepted notation or a conventional designation such as a standard name, source name, discipline abbreviation, established compound name, formula, ratio, fraction, unit, path-like quoted source token, title, product name, or URL, keep the notation and classify its use; do not rewrite ISO/IEC, ISO/IEC/IEEE, 1/2, or similar conventional forms merely to remove the mark.
A “service” statement broadens scope → recover the service facet first. Check whether the changed claim is promise content, commitment, access point, delivery system, delivery work, publication/API description, or acceptance condition; then update the direct governed value rather than a bare Service name.
Recipes gain or lose steps → update MethodDescription, not service labels or Role names.
Evidence verbs creep into actor sentences → re-apply L-rules (documents do not act).
A generic head or support-headed compound acquires FPF-governed claim or admissible use (comparative, safe, interactive, reliable, support, supported, supporting, support-looking, and similar modifiers or heads) → restore the head kind first, then unpack the qualifier claim or support-like interpretation before broader publication.
Method, algorithm, program, proof, solver, workflow, process, procedure, access path, query plan, control-strategy, method-algebra, method-graph, or selector-calculus wording changes -> recover the slot or method-side relation before rewriting: U.Method, MethodRelationStructure@BoundedContext, U.MethodDescription, formal-substrate declaration, mathematical-lens use, U.Mechanism, U.WorkPlan, dated U.Work, method-family registry or selector outcome, evidence relation, or quote-only source wording. Do not replace one umbrella with another.
A declarative representation starts to sound imperative (graph path, path slice, evidence path, query, predicate, table, dashboard, publication face, mathematical representation, method-description representation, source-chain relation, carrier path, or FPF pattern relation "runs", "routes", "calls", "dispatches", "authorizes", or "flows" without a recovered kind) → apply C.2.P.DR or the direct governing pattern such as E.18, A.10, A.19.SPR, E.17, C.29, A.3.1, A.3.2, A.15.2, A.15.1, E.8, or F.19.
New token minted → ensure LEX.TokenClass declared; perform collision checks; add CharacteristicSpace if enum.
Suffix drift (e.g., …Work on a plan) → fix via LEX.Morph.
Cross-Context reuse by label appears → require a Bridge (F.9) or split senses.
A guarded head needs a new label → prefer a guarded-head note first; if no admissible existing token remains for one durable reusable name, handle the naming question with full F.18 MintNew or DocumentLegacy.

Teaching deck — the E.10 quick card (reusable in any Context)

Say it cleanly, once (memorise): Role = role value - RoleAssignment = assignment relation - Method = way-of-doing - MethodDescription = recipe (document) - Work = run (dated) Capability = can-do within bounds (envelope + measures) - service wording = recover promise, access, acceptance, delivery work, or publication/API-description facet before naming EntityOfConcern and Description-episteme boundary separates the EntityOfConcern from Description epistemes; specification use is a gated use of a Description episteme; publication faces, forms, units, and carriers do not act; meaning use is interpreted within named Contexts; Bridge records state cross-context correspondence, direction, loss, and scope.

Name forms (allowed morphology): • Types and roles: <Noun><Role> for work-facing roles and <Noun><Type> for types (IncidentCommanderRole, ShiftOperatorRole, WorkItemType). Standards, evidence, requirements, and status labels do not become roles by suffix. • Statuses: <Noun>Status inside the Context’s role space (ApprovedStatus) — status‑only; not enactable. • No suitcase nouns: avoid the words and, plus, and & in names; use bundles (A.2) or separate roles. • Acronyms: first expansion + register; short‑form registered per § 7.7.

Three worked micro-examples — E.10 across domains (informative)

Healthcare (OR context)

Messy: “The surgical process is scheduled at 08:00; the SOP approves the incision and the service documents recovery.” E.10-clean rewrite: “WorkPlan OR‑Case‑221 starts 08:00 and will execute MethodDescription Incision_v4. SOP_OR_v4 is used as a specification-use episteme for the applicable requirement or gate relation; a SpeechAct Work by QA_Officer#ApproverRole authorises the run. The hospital records a post-op monitoring service promise (access = ward protocol; acceptance = vitals envelope).”

Manufacturing (assembly line)

Messy: “The welding function provides air‑tight seams; the process costs 3 min.” E.10-clean rewrite: “Robot_SN789 has Capability ‘execute Weld_MIG_v3 within envelope E at measures M’. Work instances that satisfy the promise content ‘Provide seam S’ average 3 min; acceptance bounds are in Seal_Acceptance.md. The MethodDescription is Weld_MIG_v3; the Role is WelderRole.”

Cloud and SRE (production Context)

Messy: “The storage service wrote logs and the deployment process failed after 2 min.” E.10-clean rewrite: “sCG‑Spec_ci_bot#DeployerRole:CD_v7 performed Work ‘Deploy r4711’ (failed at T+120 s). The platform records an object-storage service promise (access = S3_API_Spec_vX; acceptance = durability and availability targets). U.RoleAssignment(holderRef=LogWriter, roleRef=TransformerRole@Context, boundedContextRef=LoggingContext) records the work-facing assignment for the system that wrote the records; the service promise did not act.”

Closing notes (governance and purity)

Notation-agnostic. E.10 is a wording-use governance pattern, not a scanner or template. Apply it in prose, sketches, or formal models.
Where checks belong. Convenience checks belong to Tooling; E.10 itself stays notation-agnostic. Conformance code belongs in SCR-LEX or RSCR-LEX as referenced above.
Acts and tokens. LEX applies to tokens; USM applies to acts: mint, rename, and use. Conformance: LEX.TokenClass(t)=c ⇒ USM.Scope(usage) ∈ AllowedScopes(c) (§ 7.5).
Guards honoured. DevOps Lexical Firewall and Unidirectional Dependency remain intact.
Reserved “plane”. Only CHR:ReferencePlane uses the bare word plane. E.10.D2 is the EntityOfConcern and Description-episteme boundary plus specification-use gates, with publication faces, publication forms, PublicationUnits, carriers, and renderings kept separate; all other category talk is expressed as Characteristics in a CharacteristicSpace when scale semantics are declared.

One-line memory: “E.10 keeps words honest so ideas stay composable.”

E.10:End

Last Updated: 2026-06-17 — this section last modified in upstream FPF commit 205de763 (github.com/ailev/FPF)

#Unified Lexical Rules for FPF

#About this pattern

#How to use this pattern

#Relations

#Content

#Use this when

#One-screen ordinary use

#Scope split

#Problem and applicability table

#Bounded complete result and direct known governing-pattern rule

#Wording-Use Trigger Check Registry

#Lexical Trigger Rewrite Rules

#EntityOfConcern, primary entity of concern, and local topic wording

#publication-unit wording that implies authoring or interpretation work

#content

#publication

#surface, view, face

#source, target

#artifact, material, output, deliverable

#record

#model, diagram, screen, dashboard, table, note, memo, summary, explanation

#reader, reviewer, author, operator

#owner, home, host, locus

#route, branch, handoff, path, trajectory, move, flow

#use, supported use, action, effect

#sign, concept, denotat, and school-semiotic labels

#pattern, generic FPF-side object wording, locus, row, target

#Union-field unpacking under A.6.P

#Heterogeneous kind lists

#strong, stronger, weak, weaker, support

#Applying patterns versus procedural calls

#FPF-side and project-side episteme and publication contexts

#decision, action, work, method, plan

#Whole-corpus trigger use

#case, scenario, example, pilot, anti-case

#basis, context, scope, frame

#translation and multilingual heads

#state, status, posture, readiness

#live, current, active, and status or article overwrap

#claim, evidence, witness, ground, proof

#authority, permission, approval, commitment, obligation

#profile, harness, catalog, registry, index, map

#entry, front door, corridor, route

#same, parity, identity, equivalence, mirror

#file, path, host, packet, bundle, package

#quality, characteristic, metric, indicator, score

#slot, field, row, label, badge, mark, cue

#Current Scan Reading

#Trigger Concordance And Closure Mechanism

#Recovery and disposition table

#Closure rules

#Problem context

#Problem

#Forces

#Retained register and naming reference

#Vertical Stratification (four strata; no cross-bleed)

#Ontology Guards

#Tech register ontology guards

#Twin‑Register Discipline (Tech and Plain)

#Allowed pairs (normative table; examples)

#Plain Twin Safety constraints (normative)

#Minimal Generality and Domain Anchoring (MG-DA) — names neither parochial nor vacuous

#LEX.TokenClass (meta‑lexical; not a USM Scope)

#KernelToken — Minimal Generality (MG‑K)

#DiscriminatorToken and ContextToken — Domain Anchoring (DA‑D)

#Global tests (apply after 7.2 and 7.3)

#Compatibility with USM (how tokens and scopes meet)

#Metaphor guidance (non‑binding heuristics)

#Short‑form and acronym discipline

#Examples (illustrative, canonical)

#Acceptance and regression checks (LEX and USM)

#Morphology and Lexical Form (LEX.Morph)

#Casing and basic forms

#Reserved suffixes (gated by LEX.TokenClass, EntityOfConcern and Description-episteme boundary, and specification use)

#Suffix conventions and retained-family boundaries

#Forbidden suffixes and the DevOps, Data Governance and Repository-Workflow Lexical Firewall

#Prefix discipline

#Morphology tests (apply with § 7 MG-DA)

#Alias hygiene

#Entry lexeme support and lexical-query discipline

Unified Lexical Rules for FPF

About this pattern

How to use this pattern

Relations

Content

Use this when

One-screen ordinary use

Scope split

Problem and applicability table

Bounded complete result and direct known governing-pattern rule

Wording-Use Trigger Check Registry

Lexical Trigger Rewrite Rules

EntityOfConcern, primary entity of concern, and local topic wording

publication-unit wording that implies authoring or interpretation work

content

publication

surface, view, face

source, target

artifact, material, output, deliverable

record

model, diagram, screen, dashboard, table, note, memo, summary, explanation

reader, reviewer, author, operator

owner, home, host, locus

route, branch, handoff, path, trajectory, move, flow

use, supported use, action, effect

sign, concept, denotat, and school-semiotic labels

pattern, generic FPF-side object wording, locus, row, target

Union-field unpacking under A.6.P

Heterogeneous kind lists

strong, stronger, weak, weaker, support

Applying patterns versus procedural calls

FPF-side and project-side episteme and publication contexts

decision, action, work, method, plan

Whole-corpus trigger use

case, scenario, example, pilot, anti-case

basis, context, scope, frame

translation and multilingual heads

state, status, posture, readiness

live, current, active, and status or article overwrap

claim, evidence, witness, ground, proof

authority, permission, approval, commitment, obligation

profile, harness, catalog, registry, index, map

entry, front door, corridor, route

same, parity, identity, equivalence, mirror

file, path, host, packet, bundle, package

quality, characteristic, metric, indicator, score

slot, field, row, label, badge, mark, cue

Current Scan Reading

Trigger Concordance And Closure Mechanism

Recovery and disposition table

Closure rules

Problem context

Problem

Forces

Retained register and naming reference

Vertical Stratification (four strata; no cross-bleed)

Ontology Guards

Tech register ontology guards

Twin‑Register Discipline (Tech and Plain)

Allowed pairs (normative table; examples)

Plain Twin Safety constraints (normative)

Minimal Generality and Domain Anchoring (MG-DA) — names neither parochial nor vacuous

LEX.TokenClass (meta‑lexical; not a USM Scope)

KernelToken — Minimal Generality (MG‑K)

DiscriminatorToken and ContextToken — Domain Anchoring (DA‑D)

Global tests (apply after 7.2 and 7.3)

Compatibility with USM (how tokens and scopes meet)

Metaphor guidance (non‑binding heuristics)

Short‑form and acronym discipline

Examples (illustrative, canonical)

Acceptance and regression checks (LEX and USM)

Morphology and Lexical Form (LEX.Morph)

Casing and basic forms

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

Suffix conventions and retained-family boundaries

Forbidden suffixes and the DevOps, Data Governance and Repository-Workflow Lexical Firewall

Prefix discipline

Morphology tests (apply with § 7 MG-DA)

Alias hygiene

Entry lexeme support and lexical-query discipline