LEX-BUNDLE: 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.

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

Status & placement. Part E.10 (“Lexical Discipline & Stratification”); complements E.10.D1 (D.CTX), E.10.D2 (I/D/S), the DesignRunTag / 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, 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 live problem; they are not a second trigger registry and do not replace E.10.ARCH, the selected precision-restoration realization patterns, exact receiving 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 & Roles. Coordinates with. A.2/A.15 (Role–Method–Work alignment), A.10 (Evidence Graph Referring), B.1/B.3 (Γ‑algebras & 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, object, or record is replaced by another broad head, while the live relation, source-transfer object, admissible use, or neighbouring FPF pattern application remains unrecovered.

Relations

E.10outline childWording-Use Ontological Precision Restoration Architecture

E.10outline childConceptual Prefixes (policy & registry)

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

E.10outline childIntension–Description–Specification Discipline (I/D/S)

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

E.10explicit referenceIntension–Description–Specification Discipline (I/D/S)

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

E.10explicit referenceTransduction Graph Architecture (E.TGA)

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 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 referenceArchitecture and Structure 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-Read 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 referenceDRR Decision-Adequacy Evaluation CharacteristicSpace

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

E.10explicit referenceArchitecture Description Adequacy (ADA)

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 referenceMathematical Lens Adequacy (MLA)

E.10explicit referenceControlled Semantic Coarsening

E.10explicit referenceMulti-View Publication Kit

E.10explicit referenceRepresentationTransduction - same-described-entity representation-scheme transition

E.10explicit referenceAlignment & Bridge across Contexts

E.10explicit referenceComparativeReading — bounded comparative reading over comparative review units

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

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.ActionInvitationPrecisionRestoration — Affordance / Action-Invitation Precision Restoration (ACT-INV)

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

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 Transduction Coordination

E.10explicit referenceU.LanguageStateTransductionTrajectory — 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 — describedEntity-Preserving Morphism

E.10explicit referenceU.EpistemicRetargeting — describedEntity-Retargeting Morphism

E.10explicit referencePublicationUnit Stability Discipline

E.10explicit referencePublicationUnit Stability Discipline and PublicationUnit Primary Described-Entity Discipline

E.10explicit referencePublicationUnit Stability Discipline and Local Head Restoration

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

E.10explicit referenceU.Dynamics: The Law of Change

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

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 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.Episteme — Epistemes and their slot graph

E.10explicit referenceSoTA Pack Shipping (pack-boundary governing definition; SoTA-Pack(Core))

E.10explicit referenceExternal Interop Hooks for SoTA Discipline Packs (conceptual; normative when used)

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

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

E.10explicit referenceFirst Practical Entry Neighborhood Index

E.10explicit referenceDetailed Walk-throughs

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

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

E.10explicit referenceBridge Stance Overlay

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

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 force exits to A.6.P, episteme/publication/source-transfer force exits to C.2.P, architecture/structure wording exits to C.30.P, characteristic/scale wording exits to C.16.P, quality/evaluative wording exits to C.16.Q, and already recoverable cases exit directly to the exact receiving pattern. 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 force 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 an exact receiving pattern, apply that pattern instead of inventing a synonym. If the repaired wording becomes a durable reusable head, apply F.18 after the live precision-restoration branch has recovered the kind and use. Exact FPF patterns are named only after that repair has made the live object, relation, admissible use, project-side reference, or non-transfer 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 open 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 live sentence, and then stops at local repair, the exact selected realization or receiving 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 reading sequence.

Not this pattern when. Do not use E.10 as the ontology that governs the recovered claim. If the live claim force is evidence, assurance, work, gate, decision, causal use, publication, relation precision, or epistemic precision, the accepted text must make the exact receiving 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 path

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

BoundedTextObject: the exact sentence, row, section, pattern version, DRR slice, or FPF-facing project text under repair.
TriggerSpan: the word or phrase that carries possible FPF force.
SelectedReading: ordinary no-FPF-force, local head/register/morphology repair, relation-like precision restoration, episteme/publication/source-transfer restoration, durable naming, or not-triggered false positive.
FinalWordingOrBlocker: the accepted local wording, the exact receiving-pattern result, or the blocker that remains.
StopBackToSubstance: after final wording or blocker is present, stop lexical work and return to the governed object, relation, 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 reading sequence. For a modest repair, one sentence, one trigger span, one selected reading, and one final wording or blocker is enough.

When E.10 is applied beyond one sentence, add a bounded-object line: exact text object, trigger spans or grouped loci, selected reading, repair boundary, and expected non-use boundary. This prevents accidental whole-corpus sweeps and makes change impact inspectable.

Formal fields from the older LEX substrate are live only when the selected wording problem needs them: triggerSpan, boundedTextObject, structuralRole, selectedReading, LEX.TokenClass?, register, USM.Scope?, I/D/S lane?, receivingPattern, and finalWordingOrBlocker.

Local patterns may cite the relevant E.10 trigger row, but they should not reproduce large trigger lists or create local lexical registries unless a named local application profile has its own governed object. New trigger families enter E.10 only when they recur across FPF-facing texts and cannot be handled by one local pattern; specialized patterns receive the detailed ontology when the problem is no longer lexical. Stale or overly broad trigger 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 reading, E.22 for improvement-oriented quality-read framing, E.23 for the improvement loop, E.2.DA for FPF-level Pillar effect, and exact neighbours for relation, episteme, publication, source-transfer, 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 FPF-facing project text that explicitly claims FPF conformance or is being promoted into FPF current content.

For ordinary source text, intake notes, seminar transcripts, external reviews, project documents, source publications, tool outputs, or other non-FPF prose, 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 exact pattern as methods, but it does not judge the source text as failed FPF text.

Problem and applicability table

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

E.10 recognizes which wording-use problem is live and selects the first applicable closure path. It does not itself become the ontology for the recovered relation, episteme, evidence, work, gate, decision, publication, architecture, characteristic, quality, or project-side object.

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-target rule, compact applicability table, minimum sufficient result rule, and fail-closed non-use boundary.

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

local wording accepted or locally rewritten;
exact precision-restoration pattern applied;
exact neighboring FPF pattern applied directly because the governed object is already recoverable;
controlled precision-reduction exit with declared loss and reopen condition;
F.18 durable-name path after the live object is known;
quote-only, reduced-use cue, blocked transfer, incomplete rewrite, ordinary prose, or not-triggered disposition.

FPF force found by `E.10`	First applicable restoration or receiving pattern	Closure result
No FPF force after context check	Keep ordinary prose, quote, didactic phrase, or not-triggered text.	No precision-restoration pattern opens.
Local lexical/register ambiguity only	Local rewrite under `E.10`.	Repaired wording plus remaining reader move, or ordinary-prose demotion.
Relation-like force	Apply `A.6.P` or an exact A.6 relation specialization.	Named relation kind, slots/qualifiers, admissible relation use, blocked overread, and reader move.
Source-expression, publication, carrier, face, `PublicationUnit`, FPF-transfer/conformance, or `reading` / `read` / `quality-read` wording whose object is not yet recovered	Apply `C.2.P` first. If the recovered object is evaluation for improvement, then use the exact evaluation pattern such as `E.22`, `E.21`, or `E.9.DA`.	Source-local meaning, publication/carrier stack, described entity, project-side FPF kind, transfer disposition, exact evaluation object when live, adjacent overread blocked, and reader move.
Architecture or structure wording with hidden live object	Apply `C.30.P`. If `A.22`, `C.30`, `C.30.ASV`, or an exact C.30 subpattern is already recoverable, use it directly.	Recovered selected structure, `ArchitectureOf@Context`, architecture description, structural view, source-return condition, exact receiving-pattern result, 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 an exact receiving pattern is already recoverable, use it directly.	Recovered `Characteristic`, `Scale`, `Coordinate`, `Value`, `Score`, unit, scoring method, comparison basis, indicator role, exact receiving-pattern result, or stop.
Quality or evaluative characterization wording	Apply `C.16.Q`, `C.25`, `E.21`, or another exact characterization pattern 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/bridge split when live, and blocked scalar/gate/release overread.
Function-like wording with hidden carrier: `function`, `functional`, `functionality`, `effect`, or close compounds	Apply `A.6.F` first when carrier recovery is needed. If the carrier is already recovered by value, use the exact receiving pattern directly.	Carrier assignment, exact receiving-pattern application, mathematical-lens exit, quality/characteristic exit, module/interface exit, ordinary-prose demotion, or stop.
Intentional loss of precision for a narrower admissible use	Apply the exact controlled precision-reduction pattern, normally `A.6.3.CSC`, with neighboring `E.17.*`, `A.6.3.RT`, `F.9`, or `C.29` when their relation is live.	Source-bearing side, declared loss, narrower admissible use, blocked downstream use, and reopen condition.
Durable reusable head, deprecated alias, concept-set row, cross-context name-use, or UTS-facing name	Apply `F.18` after the live repair has selected 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, receiving pattern, admissible use, or remaining reader move cannot be recovered	Fail closed.	Quote-only wording, reduced-use cue, blocked transfer, incomplete rewrite, ordinary prose, or not-current FPF content.

reading, read, and quality-read are trigger wording only when the sentence uses the word to carry interpretation, publication use, source transfer, evaluation, comparison, evidence, gate, work, decision, release, assurance, or admissibility force. Do not create ReadingPrecisionRestoration. Recover the actual carrier and apply C.2.P, E.17.ID.CR, E.22 plus exact object-under-improvement evaluation, A.6.P, or the exact neighboring FPF pattern.

function, functional, functionality, and effect are trigger wording when the carrier 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 live, and functional-architecture use goes to C.30, C.30.ASV, or C.30.TGA-FLOW-REL only when that architecture or flow relation is recovered. Local patterns may cite the relevant E.10 trigger row, but they must not reproduce the trigger registry or create local lexical registries unless a named local application profile has its own governed object. Specialized restoration patterns receive the detailed ontology when the problem is no longer lexical.

Minimum sufficient result and direct known-target rule

The direct known-target rule is:

If the exact receiving pattern and its governed object are already recoverable by value, use that receiving pattern directly.

Apply C.30.P, C.16.P, C.16.Q, A.6.P, or C.2.P only when wording hides the live object, relation, characteristic, scale, score, quality characterization, source-transfer posture, admissible use, or remaining reader move.

The minimum sufficient result is the smallest result that recovers the live kind and remaining reader move:

local rewrite for a one-sentence local ambiguity;
compact repair note or row when one precision-restoration pattern is needed;
exact receiving-pattern application when the object is already recoverable;
full restoration check only when several claim forces, source/current transfer, cross-pattern authority, or downstream reliance remain live;
fail-closed non-use when recovery is not possible.

After kind and receiving pattern recovery, state the remaining admissible reader move: what the reader may now do, why the distinction matters, or which exact FPF pattern now carries the live claim. 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 governed object, or less action-guiding. In that case, narrow the repair, keep ordinary wording with an exact recovery note, use the direct receiving pattern, or leave the issue blocking by value. Do not trade real kind, relation, source-transfer, 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.

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 pattern prose, FPF-facing project guidance, and non-FPF prose being unpacked before possible transfer into FPF. It does not create a second all-purpose ontology and does not create domain-pattern outcomes. It selects a closure path: local rewrite, exact precision-restoration realization pattern, exact receiving pattern, controlled precision reduction, F.18 durable-name path, or fail-closed non-use.

The words below are frequent in conformant FPF and FPF-facing project texts. 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, FPF-facing project guidance, 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 force. 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, an exact restoration or receiving-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"
`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`	characteristic-space position, status record, role assignment or status assertion, protocol state, publication posture, process state, or readiness claim with threshold basis	maturity adjective, authority, gate passage, release permission, or evidence by appearance
`claim`, `claim content`, `claim referent`	claim node or claim content in a claim-bearing episteme, claim-bearing publication, admissibility target, or described entity or referent relation	sentence, opinion, text fragment, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, 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
`profile`, `harness`, `catalog`, `registry`, `index`, `map`	profile with named source-basis/evidence-basis/architecture-basis/review-basis role, 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 exact named governing record	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 described entity, 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

Lexical Trigger Rewrite Rules

primary described entity and local topic wording

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

If local wording meant...	Rewrite as...
the entity described by a claim-bearing episteme	`describedEntity`, `DescribedEntityRef`, `primary described entity`
the described-entity stability requirement for one bounded publication unit	primary described entity of the claim-bearing episteme carried in that `PublicationUnit`; otherwise exact non-claim-bearing kind or reference, or plain `topic`, `subject` only when no normative slot is live
a review target	`review target`, exact review-facing target packet, FPF pattern, pattern section, or file-carrier set only when the file-carrier reading is live
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 role, or companion/projection material being improved	exact FPF pattern, pattern section, accepted `DRR`, FPF publication, FPF view, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, or companion/projection material
a project-side episteme, publication, record, carrier, or activity under work	exact project episteme, view, publication, `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:

described-entity rewrite:
  sentence under repair:
  claim-bearing episteme live? yes or no
  describedEntity, grounding, ClaimGraph, viewpoint slots triggered:
  PublicationUnit reading, if any:
  review-target reading, process-description reading, source-basis-document reading, if any:
  chosen replacement:
  distinction preserved:

publication-unit wording that implies authoring or reading work

When a phrase makes the bounded unit sound like authoring work or reading work, split the sentence by live kind.

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 live
a pattern body or section	exact 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 role
a publication form	publication form
a generic publication face	generic publication face, or `U.View` only when the governing pattern makes that relation live
a governed MVPK face	governed MVPK face, and `U.EpistemeView` only under MVPK constraints
a claim-bearing episteme or exact episteme species	`U.Episteme`, `U.EpistemePublication`, episteme-lane `U.View` with explicit episteme tether, or exact episteme species

Do not make a permanent technical modifier by joining authoring, reading, and unit-boundary roles. 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;
governed 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-force-bearing publication sentence must say which publication construction is live:

act or occurrence of publishing, or publishing work;
U.EpistemePublication;
publication form;
generic publication face;
governed MVPK face;
PublicationUnit;
carrier or rendering;
document with named source-basis, evidence-basis, architecture-basis, or review-basis role;
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 live, fill admissibleUse when a boundary-use claim is live, 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 live. 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, governed MVPK face, UI face, or public-facing companion publication
`surface`	If the final term is a `SurfaceKind` value, use only `PublicationSurface` or `InteropSurface`. Otherwise rewrite the occurrence to generic publication face, governed MVPK face, publication carrier, interop carrier, UI or front-end face, companion publication, companion/projection material, or carrier relation.

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 role, 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 exact project-side FPF kind and reference.

Split target into described entity, target U.Episteme, review target, receiving FPF pattern, project target, work target, target publication form, exact project-side FPF kind and reference, 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, ObjectVersionUnderQualityRead, review target, or one named relation endpoint whose exact endpoint kind is supplied nearby. When the exact kind is known, write the exact kind: FPF pattern version, DRR, FPF corpus slice, publication form, PublicationUnit, file carrier, system carrier, declared transduction 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 exact carrier kind.

Common repair examples:

Problem wording	Required recovery
`target version` in improvement prose	`ObjectVersionUnderImprovement` or `ObjectVersionUnderQualityRead`, 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 live
`object evaluation` when the object kind is known	exact object-under-improvement evaluation name, such as `PatternQualityQBundle`, `DRRDecisionAdequacyEvaluationCharacteristicSpace`, `FPFPillarAdequacyEvaluationCharacteristicSpace`, or declared local evaluation
`thing`, `object`, `target`, `artifact`, or `material` as final head	exact FPF kind, exact 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 readings first:

U.Episteme;
U.View, U.EpistemeView;
publication form;
generic publication face;
governed MVPK face;
PublicationUnit;
carrier, front-end, or rendering;
exact project-side FPF kind and reference;
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 role;
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;
governed MVPK face;
PublicationUnit;
carrier, front-end, or rendering;
exact project-side FPF kind and reference;
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, governed MVPK face, packet, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, 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 live kind 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;
receiving 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 stack 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 live, 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;
reading or interpreting a publication, view, record, cue, or carrier;
relying on a named project episteme, a named source-basis document, or an exact project-side FPF kind and reference for a named claim or effect;
admissible act, work, or claim under a named FPF pattern, A.6.P relation claim, relation phrase, or exact project-side FPF kind and reference;
non-admissible act, work, or claim requiring one other named value: FPF pattern, A.6.P relation claim, relation phrase, exact project-side FPF kind and reference, 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-force-bearing wording names the exact admissibleUse target and non-admissible stronger or adjacent use, relationClaimSlice when a relation claim is live, and projectSideFPFRef when an exact project-side FPF kind and reference is live. If the sentence says "supported", it must name the exact admissibleUse target and non-admissible stronger or adjacent use, relationClaimSlice when a relation claim is live, and projectSideFPFRef when an exact project-side FPF kind and reference is live. 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 live.

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 exact episteme species;
describedEntity, grounding, reference-plane relation;
U.View, U.EpistemeView;
publication form, generic publication face, governed 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 exact project-side FPF kind and reference;
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 live. Otherwise recover the exact episteme slot, relation, or typed record.

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 exact 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, governed MVPK face, PublicationUnit, carrier relation, front-end relation, exact project-side FPF kind and reference, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, 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 role, file carrying FPF pattern text, or review target and the sentence does not need a narrower FPF kind. For FPF-facing semantic work, these are candidate recoveries, not a group kind: exact 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, exact FPF row, 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-stack specification;
if the sentence is not making one relation claim, unpack the current context into exact FPF-side kind, reference, or relation and one exact 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 repair force, open 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, exact project-side FPF kind and reference, 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 live kind selected at minimal sufficient generality;
a relation stack with typed slots;
a tuple-like record;
several alternative cases;
an indicator of failed ontology.

If the list is a relation stack, 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 live.

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 live, coarsened rendering, or explicit abstain or reopen posture;
support -> one selected support reading under A.6.P, not a more polished synonym. If the selected reading is base/anchor/basedness, apply A.6.6 and state dependent, base, baseRelation, scope, live Γ_time, live witnesses, admissibleUse, and nonAdmissibleUse. For FPF-force-bearing support, first choose the support reading:
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;
described-entity or grounding-holon grounding: the claim-bearing episteme, view, representation, or pattern application is grounded in its described object, local world contact, observation setting, DescribedEntitySlot, or GroundingHolonSlot;
base/anchor/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 role, evidence path, witness carrier, observation, test, or evidence support basis bears on a claim;
assurance or engineering-justification support: an assurance argument, trust calculus, safety case, or engineering-justification claim is live;
causal-use support: a causal-use question, rung, estimand, CausalEvidenceSupportBasis, CausalUseSupportVerdict, supported use, and unsupported use are live;
mathematical-lens adequacy or lens-use posture: a mathematical lens, mapping, similarity, or formal object makes a bounded claim admissible or exposes preserved/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 force;
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, SupportPosture, SupportSection, SupportMaterial, support basis, support relation, support view, and supported use are diagnostic triggers; they are conformant only when rewritten to an exact governing FPF record, field, publication function, posture, 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, live Γ_time, live witnesses, admissibleUse, and nonAdmissibleUse. Otherwise rewrite the head to the selected reading: source-description relation, described-entity grounding, grounding-holon relation, evidence path, source-support posture, relation record, admissible-use boundary, assurance claim, causal-use support basis/verdict, lens-adequacy card, characteristic or measurement basis, bridge/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 exact reading, or leave the naming issue blocking by value.

If the sentence cannot name the scale, evidence class, threshold, relation, source-loss mode, grounding object, described entity, grounding holon, base relation, admissible-use target, or exact support reading, it is not ready for architecture or pattern prose. A.6.3.CSC governs FPF-force-bearing source-loss-mode governance; A.6.P governs support reading discrimination and relation precision restoration; C.2.P only forces the wording to recover the exact 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 is live, the text names the exact FPF pattern application and the exact ontology, conformance claim, or conformance section 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 is live. Do not use project action as a final class. For project-side activity, choose exactly one live kind 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 stack has named the live FPF kind.

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 roles, 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 live, split the sentence into relationClaimSlice when a relation claim is live, admissibleUse when a boundary-use claim is live, and projectSideFPFRef when an exact project-side FPF kind and reference are live. If one context is not live, 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 is live;
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 live A.15 object is work; A.2.9 SpeechActRef when the live act is a communicative act; A.2.8 U.Commitment when the act institutes a commitment.

P2W language from TGA 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 live.

Whole-corpus trigger use

When a whole-corpus cleanup is selected, use this pattern's trigger guide over claim-bearing FPF and FPF-facing project text.

Do not do a global string replacement. Classify each unclear term occurrence by the smallest sufficient 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 live object 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 live, and fill projectSideFPFRef when an exact project-side FPF kind and reference are live. If context changes the described entity, apply the describedEntity, 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, or source-support posture. 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 carries FPF force, recover the exact FPF kind, 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 is live. A translated PublicationUnit may preserve form while shifting primary described entity or carried publication move; apply E.17.AUD or E.17.AUD.OOTD when that shift is live. 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 language become a maturity adjective or gate claim.

Classify:

position in a named U.CharacteristicSpace;
language-state chart position;
protocol state or process state;
status record;
role assignment or status assertion;
publication posture;
release or gate readiness claim;
temporal claim under C.27;
dynamics claim under A.3.3.

If the word is used to justify movement, routing, gate entry, release, or work, the text must name the characteristic-space slot, threshold basis, evidence or witness, and publication lane or carrier lane that makes the claim reviewable.

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;
described entity or claim referent;
viewpoint and representation scheme when live;
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 exact FPF governing pattern or use the exact project-side FPF kind and reference 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 exact kind 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;
exact FPF pattern named by the live problem; if a cluster or relation between patterns is genuinely live, name the exact cluster phrase or relation phrase 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 described entity;
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 role;
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 eligibility row, coordinate value, status payload, stop condition, bounded non-use, or exact 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 exact source relation 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 reading work: distinguish U.Episteme, U.EpistemePublication, PublicationUnit, file, support 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 role;
primary-object field names: use primaryDescribedEntity when claim-bearing or exact non-claim-bearing kind or reference when no episteme slot is live;
surface: keep PublicationSurface or InteropSurface only when exact SurfaceKind discipline is live; otherwise rewrite to generic publication face, governed MVPK face, publication carrier, interop carrier, UI or front-end face, companion publication, exact named support 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 live relation slot 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, governed 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/publication ontology on a concept-sign-denotation triad;
generic FPF-side object wording, locus, row, host, or target: choose the exact recovered value: FPF pattern, pattern section, accepted DRR, FPF publication, FPF view, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, file carrier, review target, typed record, relation record, or relation phrase;
supported use: replace with the exact admissibleUse target and non-admissible stronger or adjacent use, relationClaimSlice when a relation claim is live, and projectSideFPFRef when an exact project-side FPF kind and reference is live;
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 live, coarsened rendering, or explicit abstain or reopen posture;
authority-bearing FPF pattern or row: split into exact FPF pattern or pattern section, relationClaimSlice when a relation claim is live, exact admissibleUse when a boundary-use claim is live, and projectSideFPFRef when an exact project-side FPF kind and reference are live;
route, call, invoke, or procedure-like pattern wording: replace with pattern application or with exact 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 exact recovered value, such as FPF pattern, pattern section, DRR, FPF publication, U.View, document with named source-basis, evidence-basis, architecture-basis, or review-basis role, 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 exact recovered value, such as publication, generic publication face, governed MVPK face, publication form, carrier relation, front-end relation, exact project-side FPF kind and reference, 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 current pattern, insufficient evidence-support posture, and similar formulas must name the exact admissibleUse target and non-admissible stronger or adjacent use, relationClaimSlice when a relation claim is live, and projectSideFPFRef when an exact project-side FPF kind and reference is live;
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, run trigger concordance when a high-pressure trigger is FPF-force-bearing across the bounded object.

Do not build a heavy concordance for every ordinary word. Trigger concordance is live 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/source-only wording, relation phrase, or publication/source-transfer phrase.
Group occurrences by reading, not by surface word alone: ordinary no-FPF-force wording, local lexical repair, relation-like force, episteme/publication/source-transfer force, durable naming force, quote-only or source-only wording, false positive, or blocker.
For each reading, choose and complete the repair consequence. Local repair may close under E.10. Relation-like force applies A.6.P or its retained specialization. Episteme/publication/source-transfer force applies C.2.P. Durable reusable naming applies F.18 after the live kind/use recovery. Quote-only or source-only wording needs a non-transfer disposition. Classification labels are not closure endpoints.
Rewrite the bounded object, or leave a blocker. A note saying apply A.6.P where live, apply C.2.P where live, apply the exact receiving pattern where live, 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-force-bearing trigger.
Reread saturation. If one trigger word still carries several different readings after repair, or dominates the selected names of the bounded object, the text has likely preserved an umbrella rather than repaired it. Split the readings into exact names or exact governing-pattern exits before accepting the wording.

Use this compact closure table when trigger concordance is live:

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

Allowed closure dispositions are only:

ordinary no-FPF-force wording 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/use recovery and integrated into the text;
quote-only, source-only, or non-transfer disposition stated by value;
false positive stated by value;
still blocking.

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

Recovery and disposition table

E.10 gives only a small local recovery/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 force.	Leave as ordinary prose.
local wording rewrite	Repaired phrase that names the exact local kind, 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 force: endpoint, qualifier, slot, scope, time, viewpoint, support-reading, 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 live episteme/publication/source-transfer object or transfer relation.	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 force and episteme/publication/source-transfer force.	Apply `C.2.P` for source/current transfer and the claim-bearing/publication stack; 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 no-FPF-force wording, and local lexical-repair outcomes.
What counts as `closed by value`?	The final wording or the recorded disposition names the recovered exact kind, relation phrase, relation record, admissible use, non-admissible stronger or adjacent use, source-transfer 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 receiving-pattern application is not the classification label. It is the completed recovery product: selected relation reading, exact relation phrase or record, endpoint/qualifier/scope/admissible-use repair, source-transfer disposition, exact episteme/publication construction, project-side reference, false-positive reason, quote-only/non-transfer 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 live problem is endpoint, qualifier, slot, scope, time, viewpoint, support-reading, 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 object or source-transfer wording by itself?	No. If the live problem is source wording, episteme, publication, view, face, carrier, publication unit, described entity, grounding, FPF transfer, project-side claim force, 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/use recovery, replace the head with exact wording, 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-force-bearing, the final wording must change, the receiving-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 live, representative examples may guide grouping, but the closure account must cover all FPF-force-bearing occurrences or exact grouped loci/counts and must say what remains ordinary, repaired, quote-only, rejected, or blocking.
Where do trigger words and examples live?	In this shared `E.10` scan architecture or in a named local application profile tied to its own governed object. Do not copy growing word lists into `F.18`, `A.6.P`, `C.2.P`, `E.19`, or local checklists.

Problem context

Current name stack. E.10 is the current FPF pattern. E.10:0.2 is the shared wording-use trigger scan. The older LEX-BUNDLE / 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 trigger registry, not a second pattern head, and not a replacement for E.10.ARCH, the selected precision-restoration realization pattern, an exact receiving pattern, or F.18.

Intent. Provide one normative rule-set that makes FPF language unambiguous, composable across contexts, and teachable by design. Authors, reviewers, and tooling can point to LEX-BUNDLE as the governing lexical pattern for:

Vertical stratification (Kernel ↔ Extensions ↔ Context ↔ Instance);
Twin registers (Tech/Plain) with safe synonyms;
Naming morphology (allowed suffixes & style) for the kernel’s core objects;
Minimal Generality tests (names are neither parochial nor vacuous);
Canonical rewrites 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/CHR), (c) Context glossaries that claim FPF conformity, and (d) Diagrams/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 vs. parochialism. Either hyper‑specific domain names leak into core types, or vague umbrella names obscure invariants.
I/D/S collapse. Authors mix intension (the thing), description (how we describe it), and specification (testable criteria).
Register soup. Tech terms bleed into Plain pedagogy and vice‑versa, inviting category errors.

Forces

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

Solution — the LEX‑BUNDLE rule‑set (overview)

LEX-BUNDLE aka ULR (Unified Lexical Rules) names the retained reference apparatus for register, naming, morphology, and rewrite checks inside the current E.10 pattern. Use it only after the E.10:0.2 scan has selected a lexical/register/naming problem that actually needs those details.

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

Below are the normative clauses

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/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 flows downward only: Kernel → Extention patterns → Context → Instance. No stratum may redefine a higher stratum’s term; it may only specialise or bridge it.

V‑2 (Strata vs 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 lives in the flow” 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/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, I/D/S morphology, disciplined treatment of Role / Holder, and Domain usage consistent with D.CTX and UTS. It aligns with F.4 Role Description (RCS/RSG), 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 & 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 / I/D/S 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, Flow, 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, FlowDescription.
- Don’t: IncidentBoard, TDD Tradition, Production Process (kernel), Service Function (kernel).

Onto2 — I/D/S in term morphology (Intension/Description/Specification morphology) (ref. E.10.D2)

Rule: Any intensional object is a bare head: Method, Tradition, Characteristic. Any description appends …Description: MethodDescription, TraditionDescription. Any testable specification appends …Spec and presupposes acceptance criteria and harnesses (normative in E.10.D2). 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.
Extension: Apply the same pattern to non‑method objects where appropriate: FlowDescription/FlowSpec, SystemDescription/SystemSpec.
Do: SamplingMethod - SamplingMethodDescription - SamplingMethodSpec.
Don’t: SamplingAlgorithm (when it is just prose), SamplingProcessSpec (head not signalling kind).

Onto3 — Roles, Holders, and Carriers (holonic) (ref. F.4 / F.5)

Rule: The playable intention is named …Role and described through F.4 Role Description (RCS/RSG), e.g., SafetyOfficerRole, ReviewerRole. The party assuming a role is the Holder. Use the Holder#Role:Context pattern to type the assumption (where Context is a U.BoundedContext), e.g., Team‑Alpha (U.Holon) is Holder#SafetyOfficerRole:Plant‑Ops. Carrier is reserved for a system that bears a symbol of episteme (U.Episteme, Tradition, Lineage, Profile, repertoire) independent of any concrete role assumption, e.g., LeanTraditionCarrier, CalibrationLineageCarrier. Avoid Artefact as a head in the kernel: it is ambiguous between a Carrier (e.g., document), a system “made by” some 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 the inconsistent “role carrier vs role holder” usage: use “Holder” for holonic role assumption, keep “Carrier” for the system that bears a symbol of episteme.
Migration note. Legacy …CarrierRole MUST be rewritten to Holder#…Role:Context. Use SCR‑LEX to enforce the rewrite.
Do: ReviewerRole (or AssessorRole), Holder#ReviewerRole:Journal‑Issue‑42 (or Holder#AssessorRole:Procurement‑Lot‑42); LeanTraditionCarrier (U.Holon), independent of any particular role. Don’t: Reviewer (as a kernel type), ReviewerCarrier (to mean a role holder), 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 & 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/aggregation belong to Discipline/CG‑Spec (ComparatorSet, ScaleComplianceProfile (SCP), MinimalEvidence, Γ‑fold, CL‑routing), 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 canonical rewrites (mirror E.10 § 9 L‑rules; do not duplicate tables)

process / function / activity → Work / MethodDescription / Flow (context‑dependent).
Tradition → Tradition (Tech); leave “Tradition” only as a Plain twin with an adjacent Tech label.
domain → DomainFamily + {ContextId list} + UTS twins.
legacy …CarrierRole → Holder#…Role:Context.
ambiguous Owner in role names → prefer StewardRole / CustodianRole / explicit responsibility head.
job titles (owner, lead, champion) in the kernel → use explicit …Role names; keep titles in Plain with twin‑labels.
Do: FlowDescription: ReturnsHandling, Tradition: Test‑Driven, Holder#CustodianRole:Asset‑Ledger.
Don’t: Returns Process, TDD Tradition (kernel), Ledger Owner (underspecified).

Worked mini‑examples across arenas

Software engineering: BuildFlowDescription, CIHarnessSpec; Holder#MaintainerRole:Repo‑X. Avoid Build Process, Repo Owner.
Applied research / experimentation: SamplingMethodSpec, CalibrationLineageCarrier; Holder#ReviewerRole:Grant‑Call‑Y. Avoid Sampling Algorithm (if prose), Lab Owner.
Production / service management: ShiftWork, SafetyOfficerRole; Holder#SafetyOfficerRole:Plant‑Ops. Avoid Safety Officer as a type, SafetyDomain Governance.
Operations research / optimisation: RoutingMethodDescription, CostCharacteristic; Holder#ModelStewardRole:OR‑Program. Avoid Routing Function, Model Owner.
Healthcare / clinical ops: CarePathwayFlowDescription, MedicationAdministrationWork; Holder#AttendingPhysicianRole:Ward‑12. Avoid Care Process, Ward Owner.
Finance & accounting: ReconciliationMethodSpec, JournalPostingWork; Holder#TreasuryStewardRole:Liquidity‑Book. Avoid Reconciliation Process, Account Owner (underspecified).
Legal / compliance: RetentionPolicySpec, InvestigationWork; Holder#DataProtectionOfficerRole:Org‑X. Avoid Compliance Function, Data Owner (underspecified).
Cloud / IT operations: IncidentFlowDescription, RunbookMethodSpec; Holder#OnCallEngineerRole:Service‑Y. Avoid Incident Process, Service Owner (underspecified).
Logistics / supply chain: PickingWork, RoutingMethodSpec; Holder#DispatcherRole:Hub‑Z. Avoid Picking Process, Fleet Owner.
Construction / civil engineering: PermitAcquisitionFlowDescription, InspectionMethodSpec; Holder#SiteStewardRole:Project‑Lot‑17. Avoid Inspection Process, Site Owner.
Emergency response: TriageMethodDescription, EvacuationFlowDescription; Holder#IncidentCommanderRole:Event‑R. Avoid Triage Function, Incident Owner.
Agriculture: IrrigationFlowDescription, SoilSamplingMethodSpec; Holder#FieldStewardRole:Plot‑17. Avoid Irrigation Process, Field Owner.

Checklist before minting a KernelToken

Head noun signals kind (Onto1).
I/D/S morphology correct (Onto2).
If role‑related: Role vs Holder vs 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 / legacy forms migrated (Onto6).

Note on registers. Keep figurative or business‑casual terms in the Plain register only, with strict twin‑label links to the Tech token (LEX‑BUNDLE). 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 intensional object name unless the object is an explicit deontic speech-act under the Gov lens (cf. E.3).

For interface/boundary invariants and public commitments of things (holons, interfaces, ports), prefer intensional names like InterfaceContract, ComplianceProfile, AcceptanceSpec, InteropProfile, etc.

Use the word standard for a Description/Specification publication that is intended to be complied with (and that has explicit compliance checks).

If an intensional object is currently named … Standard, rename it to a proper intensional name, and (optionally) add a separate Description/Specification publication 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) (alias acceptable during transition); Boundary‑Inheritance Standard (BIC) → Boundary‑Inheritance Standard (BIS) (alias acceptable during transition). Rationale. Keeps Core prose centred on intensional objects 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 / 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 & 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 Carrier vs Content (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 (I/D/S).
`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/Work; must carry envelope & 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 CL/Loss).

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 & 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/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)”, Services keep “(service)”, Methods keep “(method)”, Work keeps “(work record)”, Capability keeps “(capability)”. Examples: TransformerRole → “Transformer (role)”, U.PromiseContent → “Service (service)”, 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 reading 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] — mask borne by a system to enact a method step in OR_2025”.

CC‑TWIN‑8 - Normative surface 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 & 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 & 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/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/validity semantics.

KernelToken — Minimal Generality (MG‑K)

MG‑K1 (Tri‑domain witness, MUST). Maintain a DRR/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 RCS (Role Characterisation Space). MG‑K2 (No parochial nouns, MUST). Kernel names MUST NOT contain domain nouns (Ticket, Microservice, Patient, Developer). Such nouns belong in Context or as RCS 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/role names encode intent, not mechanism. Mechanisms (algorithms, hardware form, recipe flavors) live in RCS or Capability. MG‑K5 (Notation independence, SHOULD). The intensional meaning is separable from any one notation/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 & Deprecation (aliases; Bridges for Cross‑context mappings).

DiscriminatorToken / 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 live object is an ability envelope. DA‑D5 (Mapping discipline, MUST). Cross‑context readings go through a Bridge (F.9). Discriminator names must not suggest global identity. DA‑D6 (Register discipline, SHOULD). Keep normative tokens stable; synonyms live in Plain register only and must not appear in constraints/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/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/implementation words; relocate to Method/Capability/RCS. MG-DA‑T4 (Enum clarity). For enumerations, list the closed value set and its CharacteristicSpace. MG-DA‑T5 (Collision & Uniqueness, MUST). Before merge, run 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 (Intensional ground, MUST). The definition card states the intensional criterion for membership explicitly; reviewers can check membership without reading external narrative.

Compatibility with USM (how tokens and scopes meet)

USM applies to acts, not tokens. Mint/rename/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/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/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 & Domain Anchoring (MG-DA)”). SF‑2 (Uniqueness, MUST). Register short‑forms in the Reserved‑Names list; run 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; the Service is “data delivered under acceptance.”

Acceptance & regression checks (LEX/USM)

SCR‑LEX‑S01 (TokenClass declaration). Every normative token has a declared LEX.TokenClass. SCR‑LEX‑S02 (Collision & 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/3). SCR‑LEX‑S05 (USM compatibility). For each LexicalAct, USM.Scope ∈ AllowedScopes(LEX.TokenClass). SCR‑LEX‑S06 (Slot/Ref suffix discipline). Any token with suffix …Slot or …Ref is either (a) a SlotKind/RefKind declared under A.6.5, or (b) a 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/Policy as kinds; model them as lenses/flows/compositions inside G.5 or as …Description/…Spec in Contexts. (Prevents kernel overloading; aligns with C.22 “no minted Strategy head”.)

Morphology & Lexical Form (LEX.Morph)

Principle. Form follows the FPF kind being named. A token’s morphology (suffix/prefix/casing) must (a) express what kind of thing it names, (b) respect MG-DA (Minimal Generality & Domain Anchoring), and (c) pass LEX.TokenClass gates: LEX.TokenClass(token) ∈ {KernelToken | ContextToken | DiscriminatorToken}. Morphological choices never override I/D/S layers or CHR:ReferencePlane semantics.

Casing & basic forms

M‑0 (Casing and categories). Types & role kinds: UpperCamelCase (IncisionOperatorRole, MethodDescription). Relations/verbs: lowerCamelCase (performedBy, isExecutionOf, bindsMethod). IDs/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 and I/D/S)

Use tables as a whitelist. Rows indicate when a suffix is permitted and what it means. “Layer gate” prevents I/D/S confusion; “Examples” are illustrative.

Suffix	Kind named by suffix	Layer gate	LEX.TokenClass gate	Examples	Forbidden misuses (typical)
`Role`	Role kind (intensional)	I‑layer	KernelToken/ContextToken	`TransformerRole`, `ApproverRole`	Appearing in BoM/mereology; mixing with run logs.
`Method`	Abstract way of doing (recipe type)	I‑layer	KernelToken/ContextToken	`SteriliseInstrumentMethod`	Versioning on `Method` (version the `MethodDescription` instead).
`MethodDescription`	Recipe/description (notation‑agnostic)	D‑layer	KernelToken/ContextToken	`JS_Schedule_v4_MethodDescription`	Calling it “process”; encoding runtime actuals here.
`…Spec`	Testable specification (acceptance‑bound)	S‑layer	KernelToken/ContextToken	`MethodSpec`, `FlowSpec`, `SystemSpec`	Using “Spec” without acceptance tests/harness; putting runtime actuals here.
`Work`	Execution (runs or kinds of runs)	(run record; not I/D/S)	KernelToken/ContextToken	`SpeechActWork`, `W#Seam134`	Plans/schedules; design‑time recipes.
`WorkPlan`	Schedule of intent	D‑layer (plan record)	ContextToken	`MaintenanceWorkPlan_Q3`	Logging actuals; claiming execution.
`Service`	External promise object	I‑layer (Standarded intension)	KernelToken/ContextToken	`ObjectStorageService`, `PassportIssuanceService`	Naming teams/APIs as “Service”.
`Capability`	System ability	I‑layer	KernelToken/ContextToken	`ScheduleGenerationCapability`	Mislabeling roles or methods as capabilities.
`Dynamics`	Law/model of change	I‑layer	KernelToken/ContextToken	`LotkaVolterraDynamics`	Using for abilities (`Capability`) or recipes (`Method`).
`Observation`	Observation record/kind	(run record; not I/D/S)	ContextToken/DiscriminatorToken	`VibrationObservation`	Mixing with `MethodDescription` or `Evaluation`.
`Evaluation`	Evaluation episteme or evaluation record	D/S‑layer (epistemic episteme)	ContextToken/DiscriminatorToken	`CalibrationEvaluation`	Using to name roles or methods.
`EvidenceRole`	Role in evidence assembly	I‑layer (role kind)	KernelToken/ContextToken	`WitnessStatementEvidenceRole`	Using as a generic “evidence”.
`Episteme`	Epistemic knowledge unit (structural)	D/S‑layer	KernelToken/ContextToken	`TraceabilityEpisteme`	Colliding with CHR ReferencePlane (never suffix “Plane”).
`System`/`Holon`	Substantial entity	I‑layer	KernelToken/ContextToken	`AnesthesiaSystem`, `OrderFulfillmentHolon`	Using to denote Context or run record.
`Boundary`	System boundary	I‑layer	KernelToken/ContextToken	`SterileFieldBoundary`	Using as a role or method.
`Objective`	Target state	I/D‑layer (depends on formalization)	KernelToken/ContextToken	`HemostasisObjective`	Encoding acceptance tests here (put tests in Spec/MethodDescription).
`Requirement`	Obligation at acceptance	D/S‑layer	KernelToken/ContextToken	`LatencyRequirement`	Using as a role or capability.
`BoundedContext`	Context card	(meta‑structural; not I/D/S)	ContextToken	`ITIL_2020_BoundedContext`	Treating Context as domain; minting `U.*` inside a Context.
`Surface`	`PublicationSurface` or `InteropSurface` over an episteme	D and S layer (publication)	ContextToken	PublicationSurface, InteropSurface	StructureSurface, MechanismSurface, PortfolioSurface
`Card`	UTS/record unit (episteme)	D-layer (publication)	ContextToken	MethodCard, ExternalIndexCard	Encoding runtime actuals; using as a ‘Service’

Suffix	Lexical class	Meaning / Ontology	Where it lives	Examples / Notes
Space	Intensional kind	A typed state space (finite product of Characteristic×Scale slots); no procedures	Kernel A.19; CHR/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 / UTS	`CharacteristicSpaceRef`. Use `.edition` on the Ref when pinning a historical phase.
Map	Intensional kind (method)	A mapping method from subjects to coordinates in a declared Space (encoder/featurizer)	Kernel/Method family (I‑layer), described/spec’d via I/D/S	`DescriptorMap` (declares invariances, corpus typing). Not a record or file.
MapRef	Pointer	Registry reference to a Map	Data fields / UTS	`DescriptorMapRef`. Pin the method phase via `DescriptorMapRef.edition`.
Def	S‑layer alias (CG‑Spec family)	A definition/specification publication that fixes a formula or distance over a space; synonym of …Spec within CG‑Spec registries only	Part G (CG‑Spec family)	`DistanceDef` ≍ `DistanceSpec`. Prefer …Spec in new normative prose; …Def retained where already published.
DefRef	Pointer	Registry reference to a …Spec/…Def	Data fields / UTS	`DistanceDefRef`. Use `DistanceDefRef.edition` to pin the exact formula edition.
Spec	S‑layer	Testable invariants bound to acceptance harnesses	E.10 and A.21	Stable, testable definitions; normative by default; S‑layer, Spec‑gated. Use for normative calculi and scoring/normalization specifications.
Slot	Structural position	Named argument position in a relation/morphism signature (SlotKind in A.6.5)	Kernel A.6.0/A.6.5	`DescribedEntitySlot`, `GroundingHolonSlot`. Always names a position; never used for ValueKinds or episteme fields.
Ref	Pointer	Reference/identifier to a registry item of some ValueKind (RefKind in A.6.5), not the thing itself	Data fields / 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 / 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 deprecated; 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/Kit instead of Space where membership is intended).

L-EPI-PUB — episteme, publication, view, carrier, and authority-reference lane 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/E.17 discipline.
Name the exact publication form separately from the episteme: for example U.PreArticulationCuePack, RoutedCueSet, U.AbductivePrompt, typed route-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 lane 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/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 live P2W chain element: intended method family, selected method/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 force. This parent pattern keeps the lexical and naming discipline; C.2.P supplies the epistemic precision-restoration profile that recovers the exact FPF kind, relation record, relation phrase, tuple-like record, exact project-side FPF kind and reference, or not-triggered disposition before final wording is accepted.

**L‑SURF — disciplined use of Surface **

Definition. Surface is reserved for PublicationSurface and InteropSurface: UTS, shipping, and interop publication surfaces that present admissible, plane-aware summaries for a stated audience and purpose. A Surface is a conceptual bundle of views in the ISO 42010 sense, with declared viewpoint. Serialisations live in Annex and Interop. Surfaces package D and S projections produced via Describe_ID and Specify_DS in A.7 and do not change object ontology.
Allowed: PublicationSurface, InteropSurface (G.10/G.13).
Forbidden: StructureSurface, MechanismSurface, PortfolioSurface, and any …Surface that denotes a structural, mechanistic, measurement, review, assurance, explanation, comparison, or publication-unit object.
Preferred alternatives: use …Boundary (structural border), …View (publication view), or …Card (UTS record).

**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/A.6.1 lists), do not name a field …Space; reserve Space to the types (CHR/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 geomertic concept, neve use it even not as a suffix for naming non-geometric spaces (e.g. instead of Sets with membership)

L‑ROLE — disciplined use of Role

Role is always Role Enactment for the U.Holon/U.System kind (agentive use).
Param‑slot / relation‑endpoint guard. Do not use the morpheme Role for formal parameter positions in operator algebra declarations (OperationAlgebra) or Signature arguments. Reserve Role for agentive kinds only (A.2/F.4/F.6). 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/SlotIndex. Same for similar situations (table columns, tuple placements): use MG-DA with domain‑specific terminology, never “Role”.

Forbidden suffixes & 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/file markers). Tooling/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/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/CHR for pattern packages. Never mint U.* inside a Context.

M‑P2 (Edition markers). Apply explicit edition/version markers to Contexts and to MethodDescription / Service—not to Method (e.g., BPMN_2.0_BoundedContext, JS_Schedule_v4_MethodDescription, PassportIssuanceService_v2025). Authors MAY annotate Context or Service names for didactics. Norms (edition vs release vs version).

edition — the content phase of an episteme (Concept/Object/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/dates; does not change episteme identity or phase.
version — a tooling/carrier identifier (file/package/code). Use only in Tooling/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 in the Strict Distinction lattice (Object ≠ Description ≠ Carrier; Role ≠ Method ≠ Work). If not, rename or split.

M‑2 (Object‑of‑talk anchoring). The head noun names the object being classified (Role/Method/Service/Work/Context/Characteristic). No free‑floating metaphors.

M‑3 (Family congruence). Where eligibility clarity is needed, add a Context‑specific characteristic (RCS) as a qualifier (e.g., NormativeStandardRole). Do not fake families with bare metaphors (no RowPlane, senseFamily, …Lane).

M‑4 (Run vs design). 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 RCS.

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). Intensional meaning survives notation/tool swaps.

M‑8 (Collision & uniqueness). Before merge, run full‑text + Reserved‑Names checks; the token must not collide with any other meaning anywhere in FPF (cf. § 7 MG-DA‑T5).

Alias hygiene

Aliases live 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

Canonical entry-neighborhoods may use one compact entry lexeme support block when the lexical force is real. That support should not live in every pattern body by default. Keep it instead in:

J.4,
I.2,
Table of Content query rows,
or one bounded lexical-support 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,
deprecated 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 [J.4](/generated/patterns/J.4) neighborhoods: 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 force 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) / [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 vs tokens)

LEX applies to tokens; USM applies to acts. Mint/rename/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/alias; logging Work inside a MethodDescription violates M‑4 and the policy.

Acceptance & regression checks (LEX/USM)

SCR‑MOR‑S01 (Suffix whitelist). Every normative token with a reserved suffix matches § 8.1 row semantics and passes Layer 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/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/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”, “actor/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 & 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/components that already include “Agent/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/ratio) with admissible values/units/polarity (Part C.16/A.17–A.18). Rule L-CHR-S2 (USM). U.Scope / U.ClaimScope (G) / U.WorkScope are USM scope objects, not Characteristics; they must not appear in any CharacteristicSpace. Rule L-CHR-S3 (Status). ESG/RSG statuses and deontic/epistemic statuses — not Characteristics; its statuses/states. Rule L-CHR-S4 (Lexical classifiers). Lexical classifiers/tags — Facets/attributes; do not name them as Characteristics, if not declared CSLC. Checks. — CC-L-CHR-1. scope characteristic(s) is banned in Core/Context. — CC-L-CHR-2. CharacteristicSpace near Scope — error. — CC-L-CHR-3. Canonical rewrite: F–G–R characteristics → F–G–R components.

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/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) and windows/mechanism/status fields.

Rationale. Scope is set‑valued (USM) and not a CHR measurement; mechanisms/statuses 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/A.18).

Canonical rewrites for overloaded words (LEX L‑rules; normative)

What this section does. LEX L‑rules standardise how we speak in Core/Context by mapping overloaded everyday words to canonical FPF concepts. What this section does not do. It does not restate naming (see § 7 MG-DA) or morphology/casing/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; I/D/S are layers; enumerations are Characteristics in a CharacteristicSpace only when a CSLC scale is declared; otherwise treat such slots as non-measurable attributes (not Characteristics).

Guarded-head cross-reference (normative lexical caution)

When one surface head already carries several FPF-force-bearing local readings, 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 readings, and point readers to the local canonical reading 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 reading.

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 reading, not one umbrella rewrite that erases the distinction.

Quick substitutions (common rewrite hints)

Use these as quick rewrite hints; accept only if the transformed sentence passes § 7 MG-DA and § 8 LEX.Morph gates.

Ban	Canonical rewrite
“the process owner approves”	`SystemX#ApproverRole:Context` performs a SpeechAct Work “approve …”
“the document enforces policy”	`Policy_vN#RequirementRole:Context` gates Work; 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”	Team Y plays `Role`; the team (as system) has Capability C within envelope E
“process health green”	StateAssertion for `ObserverRole`/`Service` KPI passes acceptance window
“function of component A fails”	Work performed by `SystemA#Role` 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 layer. I/D/S layer respected: types/roles on I; recipes/docs on D; actuals on runs (cf. § 8.1 gates).
Promise vs ability vs performance. PromiseContent (promise clause), Capability (ability), Work (performance) are not conflated.
No anthropomorphism. Documents/datasets/models do not “do”; Systems do.
Scheduling hygiene. No actuals on WorkPlan; all actuals live 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/casing respect § 8 LEX.Morph (e.g., …Role, MethodDescription, Work, reserved prefixes).
Banned tokens absent. No process/function/task/activity in Kernel senses; no tooling/file suffixes in Kernel tokens.
State gating present (when needed). Readiness is expressed via RSG state + StateAssertion, not vague “approved/ready”.

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

With E.10.D1 D.CTX (Context discipline). ULR–CTX‑1: Every Core meaning that can vary names its U.BoundedContext. ULR–CTX‑2: Same‑spelled labels are distinct senses across Contexts; reuse requires a Bridge (F.9) with CL & loss notes.
With E.10.D2 (I/D/S discipline). Speak in the right I/D/S layer. ULR–IDS‑1..3 apply (types/roles = I; descriptions/specs = D/S; work/state assertions = evaluations/occurrences). Upgrades D→S only when checkable acceptance exists.
With A.2 / A.15 (Role–Method–Work alignment). Role = assignment; Method = way‑of‑doing; MethodDescription = documented recipe; Work = dated occurrence. Sentences must keep this split.
With F‑cluster (Unification) & UTS (F.17). Harvest in one Context → SenseCell → Concept‑Set row with relation (≡/⋈/⊂/⟂) and losses. UTS is the human‑readable roll‑up.

Acts vs tokens. LEX applies to tokens; USM applies to acts (mint/rename/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/Arch 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 (Layer/Morph). Usage passes § 8 gates (suffix/prefix/casing) and I/D/S layer 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 & evidence). Service acceptance computed from Work; evidence is an EvidenceRole on an Episteme with provenance.
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 runs 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 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#ModelFitEvidenceRole:Theory_Context supports claim C within scope S; reproducibility via StateAssertions on ReplicationEvidenceRole; 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 DocumentLegacy rather than flattening both readings into one umbrella rewrite.

Editorial note. This section inherits § 7 MG-DA (anchored head nouns; Characteristic/CharacteristicSpace for enums; collision checks) and § 8 LEX.Morph (suffix/prefix/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 vs operational states within ReferencePlane=world, use WorldRegime ∈ {prep|live} (formerly PlaneRegime).

Guarded-head cross-reference (normative lexical caution)

Migration playbook — turning messy language into ULR‑clean prose (informative)

A pragmatic three‑pass routine. 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 Run MG-DA pre‑check (anchored head noun; no metaphor heads; if enum → declare its CharacteristicSpace). 0.4 Run collision/uniqueness: full‑text grep + 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 — Map to Core anchors (mechanical)

2.1 Replace underlined words via § 9 L‑rules table: • recipe → U.Method / U.MethodDescription • scheduled run → U.Work / U.WorkPlan • promise → U.PromiseContent • ability → U.Capability • actor‑mask → …Role / RoleAssignment • document/evidence carrier → Episteme with EvidenceRole/RequirementRole 2.2 Apply LEX.Morph (§ 8): suffix gates (…Role/…Work/MethodDescription/Service), casing, reserved prefixes. 2.3 Pass I/D/S layer check: types/roles on I; recipes/docs on D; actuals on runs. 2.4 Attach Context tags on first use; set twin labels (Tech/Plain) in the local Glossary.

Pass 3 — Stitch & 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/dir/CL/Loss/scope (apply A.6.9 (RPR‑XCTX) when quoted or imported source wording uses umbrella “same/equivalent/align/map/…” language). 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/aliases occur (F.13), linking to grep results that motivated the change.

ULR 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. Does each potentially polysemous noun live inside a named U.BoundedContext?
Layer prompt. Is each sentence in the correct I/D/S layer (I: type/role; D: description/spec; run: actuals)?
Token prompt. For new/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/Service/Work/Context/Characteristic/publication form/reading/process/authority use)? A narrowing qualifier alone does not answer this question.
Qualifier-force prompt. If an adjective, participle, genitive, or comparative modifier is doing semantic work, has that semantic force been restored explicitly rather than left inside the modifier alone?
Support-force prompt. If support, supported, supporting, or a support-headed compound carries FPF force, apply E.10:0.2 first and then use A.6.P support-reading discrimination instead of a synonym swap. If the selected reading is base/anchor/basedness, apply A.6.6 and state dependent, base, baseRelation, scope, live Γ_time, live witnesses, admissibleUse, and nonAdmissibleUse. If no reading 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/casing pass LEX.Morph gates (e.g., …Role, MethodDescription, Work)?
Promise vs ability vs performance. Are Service (promise), Capability (ability), and Work (performance) distinct?
Plan vs execution. Are WorkPlan windows separated from Work actuals?
Evidence prompt. Do documents hold roles and justify, while systems act?
Bridge prompt. If sameness spans Contexts, is there an explicit Bridge with CL and loss notes?
Collision prompt. Did we run full-text + Reserved-Names checks (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, did we run the full F.18 MintNew or DocumentLegacy procedure 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 exact recovery note, or leave the issue blocking instead of optimizing for lexical purity.

Working order for precision repair on FPF-force-bearing 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 qualifier force, 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 reading 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 live wording repair.

Practice basis	Source posture	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/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/labels, consistent identification, and visible labels/instructions.	Current-standard/reference and 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/RDF ontology practice used only by exact ontology-bearing neighbours.	Current reference support for controlled-vocabulary publication and label relations; not current-best support 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 exact publication or naming objects before reuse; send durable naming to `F.18` and relation/source/domain ontology to exact neighbours.	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 trigger registry.
W3C WCAG 2.2 headings/labels and consistent-identification guidance, plus FPF-internal `J.4` / `E.11` entry-neighbour practice.	Current discoverability/reference support; FPF entry projection remains the governing local architecture.	Mutates `E.10:0.2b`, `E.10:0.2c.29`, `E.10:12`, and `J.4` coordination: keep trigger wording discoverable enough for first repair, but make final wording, exact receiving-pattern application, and entry projection govern the result.	Do not turn trigger 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, an exact governing-pattern application, a conformance prompt, or a reopen cue remains decorative and does not carry E.10.

ULR 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/type name grows (“and/plus/--”) → apply MG-DA: split or bundle (A.2).
A “service” statement broadens scope → check that acceptance terms cover the new target; else split the Service.
Recipes gain/lose steps → update MethodDescription, not Service 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-force-bearing force (comparative, safe, interactive, reliable, support, supported, supporting, support-looking, and similar modifiers or heads) → restore the head kind first, then unpack qualifier or support force before broader publication.
New token minted → ensure LEX.TokenClass declared; run 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 ULR quick card (reusable in any Context)

Say it cleanly, once (memorise): Role = assignment (mask) - Method = way‑of‑doing - MethodDescription = recipe (document) - Work = run (dated) Capability = can‑do within bounds (envelope + measures) - Service = promise (access + acceptance) I/D/S are layers; documents don’t act; Contexts own meanings; Bridges move meanings.

Name forms (allowed morphology): • Types/roles: <Noun><Role/Type> (IncidentCommanderRole, NormativeStandardRole, WorkItemType). • Statuses: <Noun>Status inside the Context’s role space (ApprovedStatus) — status‑only; not enactable. • No suitcase nouns: avoid “and/plus/&” in names; use bundles (A.2) or separate roles. • Acronyms: first expansion + register; short‑form registered per § 7.7.

Three worked micro‑examples — ULR 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.” ULR rewrite: “WorkPlan OR‑Case‑221 starts 08:00 and will execute MethodDescription Incision_v4. SOP_OR_v4 holds RequirementRole; a SpeechAct Work by QA_Officer#ApproverRole authorises the run. The hospital offers Service ‘Post‑op monitoring’ (access = ward protocol; acceptance = vitals envelope).”

Manufacturing (assembly line)

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

Cloud/SRE (production Context)

Messy: “The storage service wrote logs and the deployment process failed after 2 min.” ULR rewrite: “sCG‑Spec_ci_bot#DeployerRole:CD_v7 performed Work ‘Deploy r4711’ (failed at T+120 s). The platform offers Service ‘Object Storage’ (access = S3_API_Spec_vX; acceptance = durability/availability targets). LogWriter is a System bearing TransformerRole that wrote the records; the service did not act.”

Closing notes (governance & purity)

Notation‑agnostic. ULR is a language constitution, not a scanner or template. Apply it in prose, sketches, or formal models.
Where checks live. Convenience checks belong to Tooling; ULR itself stays notation‑agnostic. Conformance code lives in SCR‑LEX / RSCR‑LEX as referenced above.
Acts vs tokens. LEX applies to tokens; USM applies to acts (mint/rename/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; I/D/S are layers; all other category talk is expressed as Characteristics in a CharacteristicSpace.

One‑line memory: “ULR keeps words honest so ideas stay composable.”

E.10:End

Last Updated: 2026-05-31 — this section last modified in upstream FPF commit 16cd3138 (github.com/ailev/FPF)

#LEX-BUNDLE: Unified Lexical Rules for FPF

#About this pattern

#How to use this pattern

#Relations

#Content

#Use this when

#One-screen ordinary-use path

#Scope split

#Problem and applicability table

#Minimum sufficient result and direct known-target rule

#Wording-Use Trigger Check Registry

#Lexical Trigger Rewrite Rules

#primary described entity and local topic wording

#publication-unit wording that implies authoring or reading 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

#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

#Solution — the LEX‑BUNDLE rule‑set (overview)

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

#Ontology Guards

#Tech register ontology guards

#Twin‑Register Discipline (Tech / Plain)

#Allowed pairs (normative table; examples)

#Plain Twin Safety constraints (normative)

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

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

#KernelToken — Minimal Generality (MG‑K)

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

#Global tests (apply after 7.2/7.3)

#Compatibility with USM (how tokens and scopes meet)

#Metaphor guidance (non‑binding heuristics)

#Short‑form and acronym discipline

#Examples (illustrative, canonical)

#Acceptance & regression checks (LEX/USM)

#Morphology & Lexical Form (LEX.Morph)

#Casing & basic forms

#Reserved suffixes (gated by LEX.TokenClass and I/D/S)

#Forbidden suffixes & 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

#Compatibility with USM (acts vs tokens)

#Acceptance & regression checks (LEX/USM)

LEX-BUNDLE: Unified Lexical Rules for FPF

About this pattern

How to use this pattern

Relations

Content

Use this when

One-screen ordinary-use path

Scope split

Problem and applicability table

Minimum sufficient result and direct known-target rule

Wording-Use Trigger Check Registry

Lexical Trigger Rewrite Rules

primary described entity and local topic wording

publication-unit wording that implies authoring or reading 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

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

Solution — the LEX‑BUNDLE rule‑set (overview)

Vertical Stratification (four strata; no cross-bleed)

Ontology Guards

Tech register ontology guards

Twin‑Register Discipline (Tech / Plain)

Allowed pairs (normative table; examples)

Plain Twin Safety constraints (normative)

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

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

KernelToken — Minimal Generality (MG‑K)

DiscriminatorToken / ContextToken — Domain Anchoring (DA‑D)

Global tests (apply after 7.2/7.3)

Compatibility with USM (how tokens and scopes meet)

Metaphor guidance (non‑binding heuristics)

Short‑form and acronym discipline

Examples (illustrative, canonical)

Acceptance & regression checks (LEX/USM)

Morphology & Lexical Form (LEX.Morph)

Casing & basic forms

Reserved suffixes (gated by LEX.TokenClass and I/D/S)

Forbidden suffixes & 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

Compatibility with USM (acts vs tokens)

Acceptance & regression checks (LEX/USM)