#Unified Lexical Rules for FPF

E.10 · Stable · Part E lexical-governance pattern · Definitional pattern; normative for all FPF pattern text and for any Context that claims FPF conformance. · Part E - The FPF Constitution and Authoring Guides

#About this pattern

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

#How to use this pattern

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

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

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

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

#Relations

#Content

#Use this when

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

What this buys. E.10 gives one cheap trigger scan before heavier repair. Ordinary wording stays ordinary, local lexical mistakes close locally, and FPF-governed wording uses the smallest pattern that can recover the governed object, relation, claim, admissible use, and remaining reader use. The result is precise enough to compose with FPF without replacing one umbrella word with another or turning every phrase into a new pattern, card, 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 lexical scan. Restore the head kind and register of the local wording. If no FPF-governed use remains, make the small local rewrite under E.10 and stop. If an E.10:0.2 row selects a precision-restoration realization pattern or a governing pattern, apply that pattern instead of inventing a synonym. If the repaired wording becomes a durable reusable head, apply F.18 after the selected precision-restoration branch has recovered the kind and use. Governing FPF patterns are named only after that repair has made the EntityOfConcern, relation, claim, admissible use, project-side reference, or non-use disposition recoverable by value.

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

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

#One-screen ordinary use

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

1. BoundedTextSpan: the exact sentence, row, section, pattern version, DRR slice, or project text deliberately using FPF-governed terms, pattern references, relation names, or conformance claims under repair.
2. TriggerSpan: the word or phrase that carries possible FPF-governed use.
3. SelectedInterpretation: ordinary no FPF-governed use, local head repair, register repair, morphology repair, relation-like precision restoration, episteme precision restoration, publication precision restoration, source-use relation or source-ref target recovery, durable naming, or not-triggered false positive.
4. FinalWordingOrBlocker: the accepted local wording, the governing-pattern result, or the blocker that remains.
5. StopBackToSubstance: once the final wording or blocker is written, return to the domain question that made the phrase matter. Further lexical classification is non-use unless another phrase still hides an FPF-governed claim.

Plain branch rule for relation-like wording. Start with the ordinary sentence the reader needs to write, then select one branch. Do not make the reader classify all four.

1. World fact. If the sentence asserts that two or more world-side things are related, name those things and say what direct relation obtains: for example, Pump P feeds tank T. Apply the pattern that governs that predicate. Name a separate relation occurrence only when a later claim must refer to that same occurrence, compare or qualify it, track its change or continuity, or use it as a participant of another relation. A feeds column or an arrow labelled feeds is a near-miss: neither makes the fact obtain.
2. Reusable relation declaration. If the text tells later authors what the same relation means across several claims or consumers, state that reusable meaning and its participant meanings, then map them to one RelationSignature and its A.6.5 SlotSpec declarations. One fact such as P feeds T is a near-miss: it does not declare a reusable predicate or participant vocabulary.
3. Relation claim or report. If the text records that somebody or some source claims a relation, name the C.2.1 claim-bearing episteme and its participant designations: for example, Inspection note N states that P feeds T. The note is not a participant in the feeding relation, and recording the claim does not make feeding obtain.
4. Representation. If a field, table cell, graph element, or formula stands for something, name the representation element, represented object, and correspondence. Use C.29 when a mathematical-lens use is current; otherwise use the direct representation owner. A column position, argument place, or drawn arrow with no stated correspondence is a near-miss: its shape creates no participant, SlotSpec, kind, or obtaining relation.

If none of these branches applies, keep ordinary or quoted wording, name the other governed object and its direct owner, or leave an explicit blocker. The visible result is one readable domain sentence, one reusable declaration, one claim-bearing episteme, one representation with its correspondence, or an explicit non-use or blocker—not a catalogue of all possible owners.

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

Minimal first-use example. The sentence The candidate basis is required before pattern use has one trigger span: required. Here the sentence is about candidate-basis completeness, not an accountable undertaking. Apply the direct E.11 construction and write: The candidate basis is complete for this use only when every reusable basis position declared by the public candidate-use template has a current project filler admitted by that position's CandidatePatternUseBasisCompletenessCondition@FPFReadme. The repaired sentence preserves the practical consequence, creates no general Requirement object, and closes the E.10 use. Return to the candidate-pattern-use question; do not open the later lexical apparatus or create a wording-repair record. Replay the repair from the quoted sentence and the current E.11 template and completeness-condition definitions. Reopen it if those E.11 definitions change, or if the project statement acquires an accountable subject and authority relation; the latter case applies A.2.8 rather than the completeness construction.

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

When a wording-repair note needs formal fields, record one plainIntent and the selected branch from E.10:0.0a before the technical fields. Keep triggerSpan, boundedTextSpan, selectedInterpretation, LEX.TokenClass?, register, USM.Scope?, EntityOfConcern and Description-episteme boundary and specification use?, governingPattern, and finalWordingOrBlocker; then add only the fields required by the selected branch and its direct owner. If none of the four relation-like branches applies, name the concrete governed object and owner instead. Do not use slotOrUsePosition as a union field for actual participants, A.6.5 SlotSpec values, participant designations, or representation places.

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

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

#Scope split

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

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

#Problem and applicability table

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

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

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

exact is not a precision marker by itself. It is admissible only for literal identity or bounded source identity: an exact sentence, source passage, trigger span, formula, episteme edition whose claims define that formula, same referent, or same declared CharacteristicSpace. When exact modifies an FPF pattern, kind, relation, record, object, field, use, claim, gate, source, or governing pattern, write the ordinary identity claim and, for relation-like wording, select the applicable E.10:0.0a branch. Then name only the direct owner and branch-specific objects needed by that sentence. Add a source-use relation, admissible use, claim kind, value set, or scope only when omitting it would change what the sentence identifies or licenses. Exact without that local identity and use test closes nothing. If recovery fails, use a quote-only, reduced-use, blocked-use, or incomplete-rewrite disposition.

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

• local wording accepted or locally rewritten;
• selected precision-restoration pattern applied;
• direct governing FPF pattern applied because the primary EntityOfConcern, obtaining direct relation and actual participants, receiver-needed relation occurrence, reusable A.6.5 declaration, claim-bearing episteme and any participant designations, or C.29 representation and explicit correspondence are already recoverable;
• controlled precision-reduction result with declared loss and reopen condition;
• F.18 durable-name application after the kind under repair or relation is known;
• quote-only, reduced-use cue, blocked use, incomplete rewrite, ordinary prose, or not-triggered disposition.

Grouping-mark self-application. Slash marks, paired-register marks, and, plus, &, and compact grouping marks are triggers only when the grouping itself carries FPF-governed meaning. Retain conventional notation, formula symbols, ratios, discipline abbreviations, path-like quoted source tokens, product names, titles, URLs, or pattern-reference notation when the sentence's use is only notational; examples include CI/CD, 1/2, ≡/⋈/⊂/⟂, and exact source tokens. Rewrite claim-bearing grouped heads into explicit lists that keep unlike kinds separate; explicit alternative cases; obtaining direct relations with actual participants; reusable relation-declaration sets with their RelationSignature and A.6.5 SlotSpec values; claim-bearing epistemes; C.29 tuple or other representation elements with explicit represented objects and correspondences; or selected FPF kinds named by value. Do not let a slash hide one kind choice, an unresolved alternative, a relation claim, an admissible-use boundary, or a missing governing pattern.

Modifier, compound-head, and enumeration-as-kind self-application. A modifier without a recovered head, a compound whose head word is only a vague carrier such as source, support, basis, note, record, field, condition, or use, or a repeated enumeration that starts acting like one kind is an E.10 trigger when it carries FPF-governed use. First expand the phrase into one ordinary sentence. For relation-like wording, select one E.10:0.0a branch and recover only that branch's result; otherwise name the head kind, closed value set, explicit alternatives, or non-use and its direct owner. If the direct governing pattern is known, use it. If source-ref target wording, publication, carrier, or project-side reference is still hidden, use C.2.P; if move, step, action, or readiness wording is current, use E.10.MOVE; if architecture or stratification source-label wording is current, use E.10.ARCH, C.30.P, or C.30.STRAT. If no direct-owner result can be written, lower the phrase to ordinary prose, quote-only wording, a reduced-use cue, split alternatives, or blocked use; do not close by inventing a broader umbrella name.

Source-to-use continuity prompt. When the trigger word is source or a source-like modifier, conforming final wording preserves the source-to-use relation, not only the recovered head kind. Check five questions before closing: which concrete source expression, source U.Episteme, source U.EpistemePublication, publication face, carrier relation, source-ref marker with its referenced object kind named or, when it targets a reusable declaration, the exact A.6.5 SlotSpec named, source-currentness relation, source-bearing relation, relation-claim slice, project-side FPF kind and reference, declared-use boundary, or explicit non-use disposition is current; which exact governed entity from that source-side set is used now; which direct source-to-use, transformation, rendering, or other use relation carries it forward; which current use is admissible; and which reopen condition or governing pattern applies if the use becomes stronger. A source-ref marker alone is not a repair result: if the referenced object kind or exact declaration-local SlotSpec is not recoverable, close as source-finding, quote-only, reduced-use, or blocked use. Do not close on value unless the governing pattern actually has a value slot. If the answer is hidden, route to C.2.P, A.6.3.CSC, E.17, A.10, or the direct governing pattern rather than accepting a precise but unhelpful noun.

source-return condition is not this whole prompt. It is a narrower reverse or escalation condition used when a derivative, coarsened, extracted, compressed, rendered, or reused carrier has already moved away from a named source expression, source U.EpistemePublication, source-bearing relation, transform record, evidence relation, or governing pattern position and a stronger use opens return to that named endpoint or governing pattern. Use source-to-use path or the direct source relation when the current sentence is about departure from a source expression, source publication, or source-bearing relation into use.

reading, read, and quality-read are trigger wording only when the sentence uses the word to carry interpretation, publication use, source-use assignment, evaluation, comparison, evidence, gate, work, decision, release, assurance, or admissibility claim. Do not create ReadingPrecisionRestoration. Recover the actual EntityOfConcern; the exact publication, carrier, or source-use relation and its governed participants; the evaluation claim or bundle; an obtaining direct relation and actual participants; a world-side Work occurrence; or a separate claim-bearing episteme about one, then apply C.2.P, E.17.ID.CR, E.22 plus object-under-improvement evaluation named by value, A.6.P, or the direct FPF pattern governing that claim.

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

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

Description, publication, and representation mediation source words need the same recovery discipline. Treat stack, lane, profile, mediation, binding, representation, publication, model, space, graph, latent, weights, embedding, vector store, carrier, dashboard, posture, route, path, surface, and close compounds as trigger wording when the sentence has FPF-governed use and the exact governed object, obtaining direct relation and actual participants, reusable A.6.5 declaration, claim-bearing episteme, or representation correspondence is hidden. Recover the current EntityOfConcern; the direct relation and actual participants; a RelationSignature and A.6.5 SlotSpec values only when declaration is current; or the C.29 representation element, represented object, and explicit correspondence; then name the direct governing pattern, admissible use, blocked overread, and remaining reader use before writing the final phrase. Do not replace the trigger with another umbrella head; do not mint a durable name unless F.18 is explicitly selected.

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

#Bounded complete result and direct known governing-pattern rule

The direct known governing-pattern rule is:

If the governing pattern and the current EntityOfConcern, obtaining direct relation and actual participants, receiver-needed relation occurrence, reusable A.6.5 declaration, claim-bearing episteme and any participant designations, or C.29 representation and explicit correspondence are already recoverable by value, use that governing pattern directly.

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

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

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

After kind and governing pattern recovery, state the remaining admissible reader use: what the reader may now do, why the distinction matters, or which FPF pattern now carries the claim being made. If the repaired wording is kind-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 named governing patterns, less clear about the primary EntityOfConcern, obtaining direct relation and actual participants, receiver-needed relation occurrence, reusable A.6.5 declaration, claim-bearing episteme and any participant designations, or representation and correspondence, or less action-guiding. In that case, narrow the repair, keep ordinary wording with a recovery note that states the recovered kind and use, use the direct governing pattern, or leave the issue blocking by value. Do not trade real kind, relation, source-use, or admissible-use recovery for smooth prose; this check prevents precision-restoration theatre, not ontology repair.

Tool-assisted trigger inventories may help find candidate spans, but they cannot close ontological precision repair. Closure remains the exact governed object and direct owner; any obtaining direct relation and actual participants; any receiver-needed occurrence, reusable A.6.5 declaration, claim-bearing episteme and participant designations, or C.29 representation and explicit correspondence that is current; admissible use; non-admissible overread; and remaining reader use by value.

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

MG-DA cold-reader closure. A repair is closed only when a reader who has not read the DRR, campaign notes, or reviewer memory can recover the exact governed object and its FPF kind or ordinary non-FPF status; the obtaining direct relation and actual participants or the claim-bearing episteme; any separately current declaration, designation, or representation and correspondence; the admissible reader use; and the next governing pattern when a stronger claim is being made. Replacing a trigger with object, item, value, relation, record, condition, basis, material, specialization, or another broad head fails this check unless the sentence names the specific governed object and direct-owner use that make the wording meaningful: for example the obtaining relation and actual participants when a relation is claimed, the exact A.6.5 SlotSpec when a reusable value declaration is current, the condition bearer when a condition is claimed, or the receiving governing pattern when authority is being assigned. A complete specialization phrase says what specializes what, by which specialization relation or governing pattern, and which inherited or changed declarations or uses matter. This is the MG-DA test for wording repair: the repaired phrase preserves meaningful generality without losing the domain object a practitioner recognizes.

#Wording-Use Trigger Check Registry

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

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

#requirement and required recovery

Treat requirement and required as trigger wording, not as a shared engineering kind or a durable suffix. Recover the exact construction before rewriting:

1. Name the bearer: the entity, relation, claim, candidate basis, result expectation, dependency position, evaluation state, or accountable subject to which the wording applies.
2. Name the claim or relation kind. Do not stop at condition, item, value, record, or another container head.
3. Name the direct governing pattern. A lexical resemblance does not transfer ownership to E.10.
4. State the practical consequence: what use becomes admissible or blocked, which value is current, what return opens, or which accountable commitment exists.
5. Write the exact subject-owned construction and rescan the replacement wording. Close with ordinary prose only when no FPF-governed construction is being asserted.

RequirementWordingRecovery:
  GovernedTextSpan:
  BearerRef:
  BearerKindRef:
  ClaimOrRelationKindRef:
  DirectGoverningPatternRef:
  PracticalConsequenceDescriptionRef:
  ExactRecoveredConstructionRef:
  FinalWordingOrBlocker:

This is a temporary wording-restoration check, not a project record and not a Requirement ontology. Its positions take the exact values already governed by the subject pattern.

Name admission precedes slot verification. CandidatePatternUseBasisRelation@Context is admissible because the head exposes the basis relation and its two sides; CandidatePatternUseBinding is not repaired by kind-correct fields because Binding hides that subject relation. Likewise, BoundaryConditionKindSlot names a slot whose values classify boundary conditions; BoundaryRoleSlot would falsely suggest a role value. Apply F.18 only when a durable name is actually being minted.

#Lexical Trigger Rewrite Rules

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

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

Recovery check:

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

#publication-unit wording that implies authoring or interpretation work

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

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

#content

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

• claim-bearing episteme content;
• publication-unit text;
• publication form;
• generic publication face;
• declared MVPK face;
• carrier data;
• payload of a record kind named by its governing pattern;
• pattern section;
• source-basis excerpt;
• review target.

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

#publication

Every FPF-governed publication sentence names the publication construction being used:

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

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

#surface, view, face

Do not treat these as synonyms.

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

#source, target

These are relation words, not final kinds.

Split source into source U.Episteme, source U.EpistemePublication, U.View over a source U.Episteme, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation or use, A.10 evidence relation, authority-reference relation, named FPF pattern cited as source, file carrier, source frame or source context only when the named relation and endpoint kind are present, the actual source-side participant of an obtaining named relation, the source-side A.6.5 SlotSpec only when a reusable relation declaration is current, or project-side FPF kind and reference named by value.

Split target into EntityOfConcern, target U.Episteme, review target, governing FPF pattern, project target, work target, target publication form, project-side FPF kind and reference named by value, target frame, target context, the actual target-side participant of an obtaining named relation, or the target-side A.6.5 SlotSpec only when a reusable relation declaration is current.

Generic object and target are not final recovered kinds. Keep them only when the sentence explicitly declares a named field or participant designation inside a current episteme, such as ObjectKindUnderImprovement, ObjectVersionUnderImprovement, or ObjectVersionUnderQualityEvaluation; names a review target; or states one direct-relation participant meaning whose actual-participant kind is supplied by value nearby. If a reusable relation declaration is current, name its A.6.5 SlotSpec separately. When the governed kind is known, write that kind by value: FPF pattern version, DRR, FPF corpus slice, publication form, PublicationUnit, file carrier, system carrier, exact changed referent, exact entity or value bound as the result of one particular A.6.1 operation application, candidate proposal, evidence or provenance relation, 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. In C.2.1+ the Tech kind is U.PresentationCarrier; ordinary carrier wording names a publication-side relation to the system, medium, file, rendering, front-end, 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, rendered, front-end, or transport side, write file carrier, rendering, front-end relation, transport carrier, or another carrier relation named by value.

Common repair examples:

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

#input, raw material, source data, source material, artifact, output, result, outcome, deliverable

These are high-risk relation-dependent source-word umbrellas, not final kinds or one result family. First name the exact entity and the exact object relative to which the word is being used. For epistemic source data or source material, close the exact source expression, episteme or publication, and source-to-use relation under C.2.P first. Keep physical raw material with its direct physical constituent, affected-referent, resource-use, supply, transfer, or transformation governor.

When the remaining current claim is relative to a method, plan, dated work, transformation, evaluation, delivery, transfer, or receiving use, apply A.6.P.WMR. Recover claim subject, modality and exact temporal extent, polarity, and recovery/support state independently. Closure is exactly one of four truthful families: an exact direct subject-relation claim, positive or governed negative; an exact A.6.1 operation-application binding; an exact local A.15.PROD or A.6.RCD claim; or an exact non-assertability result whose reason is independently factually unsupported, missing-information, or missing-governor. A failed known predicate and an unavailable fact keep their known governor and name no future owner; only a genuinely absent predicate/condition/owner names the affected receiving use and future owner. Classification, a generic result relation, a method-description field, planned filling, a designation that merely type-checks against an A.6.5 SlotSpec, or a polarity inference is not closure.

Before opening that branch, test whether the phrase already names an independently governed U.Episteme; U.View or U.EpistemeView; publication form; publication face, including a declared MVPK face; PublicationUnit; carrier, front-end, or rendering relation; project-side FPF kind and reference named by value; evidence carrier or evidence relation; document under a named source-basis, evidence-basis, architecture-basis, or review-basis relation or use; review target; C.11 ChoiceResult; measurement-result episteme; evaluation result; diagnostic finding; decision; or another project object whose record kind and direct governor are named by value. Retain ordinary input, output, result, outcome, or deliverable only while the exact direct governor remains recoverable. If no governor closes the selected WMR claim, return the bounded blocker. If the missing item is instead a non-WMR kind, retain an architecture-first candidate disposition under its direct owner. Do not invent either one inside pattern prose or replace it with a universal kind or relation.

#record

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

• A.10 evidence or provenance relation 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, one A.15.1 dated Work occurrence admitted under U.Work, or a separately identified claim-bearing episteme about that occurrence; use a record-kind name only when its exact kind and direct record governor are recoverable;
• A.2.8 U.Commitment, exact A.2.8.PER permission result, or A.2.9 SpeechAct publication;
• a separately identified assignment-assertion or occurrence-description episteme that designates one exact RA : U.RoleAssignment, or a status-register entry under its named governing pattern; neither record is the world-side assignment occurrence;
• 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 a named support relation cannot be asserted because a required actual participant or governed value is absent, name that exact missing participant or value. If a reusable declaration is incomplete, name its missing SlotSpec or other missing declaration content and repair that declaration. If a receiving assertion or relation-occurrence-description episteme lacks a participant designation, name the missing designation under that episteme. If a U.WorkPlan lacks a planned participant designation or planned value, name that missing plan content under the WorkPlan. Create a prospective repair request, future decision request, prospective work-plan entry, or explicit missing-source-relation note as applicable; none backdates support, establishes actual participation, or makes the direct relation obtain.

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

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

• episteme or episteme publication;
• U.View, U.EpistemeView;
• publication form;
• generic publication face;
• declared MVPK face;
• PublicationUnit;
• carrier, front-end, or rendering;
• project-side FPF kind and reference named by value;
• explanation and source-finding relation under E.17.EFP;
• evidence, currentness, and provenance relation under A.10;
• gate-bearing claim or effect under A.20 or A.21;
• assurance and engineering-justification record under B.3;
• work and reliance encountered-item repair 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 also names what is facing that person: generic publication face, declared MVPK face, packet, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation or use, PublicationUnit, carrier, or UI or front-end.

#owner, home, host, locus

These are not interchangeable.

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

Split into:

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

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

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

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

• E.10.MOVE for project-move, first-move, working-move, next-move, pattern-use, work-entry-readiness, architecture-candidate-use, call-planning next-action, or other move-like wording whose direct FPF target is hidden;
• 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 graph path or PathSlice expression;
• A.6.3, A.6.4 episteme morphism or retargeting.

When handoff instead names an entity, package, result, delivery, transfer, acceptance, or receiving-use boundary, apply A.6.P.WMR to that exact relation-bearing claim. Use E.10.MOVE for a process-baton or project-move case only when that movement itself is current; a handoff record or package remains an episteme or governed entity, not the transfer.

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

#use, supported use, action, effect

Split the word before accepting it:

• applying an FPF pattern to a problem situation;
• interpreting or using a publication, view, record, cue, or carrier;
• relying on a named project episteme, a named source-basis document, or a project-side FPF kind and reference named by value for a named claim or effect;
• admissible act, work, or claim under a named FPF pattern; an obtaining direct relation recovered through A.6.P with its actual participants named; a literal or source-local relation phrase retained only as wording; or a project-side FPF kind and reference named by value;
• non-admissible act, work, or claim requiring one other named value: FPF pattern; an A.6.P-recovered direct relation with its actual participants; a literal or source-local relation phrase identified only as wording; project-side FPF kind and reference named by value; C.11 ChoiceResult; C.11 decision record; A.6.A action invitation; A.15 U.WorkPlan; one A.15.1 dated Work occurrence admitted under U.Work or a separate episteme about it; U.Method; U.MethodDescription; A.20 constraint or adjudication decision record; A.21 GateDecision; A.21 DecisionLogRef; A.10 evidence relation; 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;
• an actual Work occurrence admitted under U.Work, kept distinct from any assertion or record about it;
• evidence of interpretation or effect;
• gate or admission decision.

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

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

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

Possible recoveries include:

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

Use concept only where current FPF already has the relevant concept-set, UTS, local-meaning, or Part F machinery available. Otherwise recover the claim-bearing episteme; the obtaining direct relation and actual participants; the current A.6.5 declaration, participant designation, or C.29 representation and explicit correspondence when one of those is actually present; or the record kind and governor named by value.

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

Pattern is not a free synonym for regularity. If the intended object is an FPF pattern, write FPF pattern or name the governing pattern. If it is not an FPF pattern, do not write recovered FPF construction as the final value. Choose one recovered value by sentence function: episteme, view, publication, publication form, generic publication face, declared MVPK face, PublicationUnit, carrier relation, front-end relation, project-side FPF kind and reference named by value, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation or use, review target, obtaining direct relation and actual participants, receiver-needed relation occurrence, reusable RelationSignature and A.6.5 SlotSpec values, claim-bearing episteme with any current participant designations, C.29 representation element and explicit correspondence, C.11 ChoiceResult, C.11 decision record, A.6.A action invitation, A.15 U.WorkPlan, one A.15.1 dated Work occurrence admitted under U.Work or a separate episteme about it, U.Method, U.MethodDescription, A.20 constraint or adjudication decision record, A.21 GateDecision, A.21 DecisionLogRef, A.10 evidence relation, typed evidence record, B.3 assurance or engineering-justification record, or typed status record whose FPF status pattern is named.

Avoid generic FPF-side object wording, generic named-target wording, locus, row, and host when they hide kind. Use them only when the kind is literally a table row, document with named source-basis relation or use, file carrying FPF pattern text, or review target and the sentence does not need a narrower FPF kind. For FPF-facing wording that carries a claim being made, direct relation, admissible use, or remaining reader use, these are candidate recoveries, not a group kind: governing FPF pattern, pattern section, accepted DRR, FPF publication, FPF view, record kind named by its governor, obtaining direct relation and actual participants, receiver-needed relation occurrence, claim-bearing episteme, reusable A.6.5 declaration, or C.29 representation and explicit correspondence. Choose one by sentence function and keep separately governed objects separate.

#Union-field unpacking under A.6.P

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

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

• if the sentence is making a relation claim, recover the RelationKind, actual participants, qualifiers, scope, time, viewpoint, and admissibility target, then state the obtaining direct relation and those participants; distinguish one relation occurrence only for a named receiving use; add a reusable RelationSignature and A.6.5 SlotSpec values only when declaration is current; and keep any claim-bearing row or field as an assertion episteme, participant designation, or C.29 representation and explicit correspondence under its own owner rather than as the relation itself;
• if the sentence is not making one relation claim, unpack the context under repair into FPF-side kind, reference, or relation named by value and one project-side FPF kind with its reference, or state that no project-side FPF kind is triggered;
• if the same unpacking recurs across cases with one stable recovery shape, record a light A.6.P specialization candidate rather than minting a vocabulary-wide replacement field.

Apply this unpacking whenever a publication, display, cue, explanation, dashboard tile, schema, signature, badge, or generated output is being read as evidence, gate passage, work, deontic permission, work authorization, approval speech act, commitment, release authorization, safety assurance, evidence sufficiency, or engineering justification.

Do not fill one authoring union-field position with whichever nearby FPF kind is easiest to name. A project publication, claim-bearing episteme, or record of a kind named by its governor is a description-side object; one A.15.1 dated Work occurrence admitted under U.Work is a world-side individual, while A.6.A action invitation, A.2.9 SpeechActRef, A.2.8 U.Commitment, U.Method, and U.MethodDescription belong to other kinds or relations.

#Heterogeneous kind lists

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

• one kind under repair selected at bounded complete generality;
• several obtaining direct relations with actual participants;
• a reusable relation-declaration set with exact RelationSignature and A.6.5 SlotSpec values;
• a C.29 tuple representation with explicit represented objects and correspondences;
• several alternative cases;
• an indicator of failed ontology.

If the list asserts several direct relations, name each obtaining relation and its actual participants. If it declares reusable relation shapes, name each RelationSignature and A.6.5 SlotSpec value and do not infer that any relation obtains. If it is a C.29 tuple representation, name the representation elements, represented objects, and explicit correspondences; if the same material is also a reusable relation declaration, name its RelationSignature and A.6.5 SlotSpec values separately. If it is an alternative-case set, split the cases. If it is failed ontology, return to architecture before pattern or DRR prose depends on the list.

#strong, stronger, weak, weaker, support

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

Preferred rewrites:

• stronger claim -> wider claim scope, higher evidence-basis threshold, gate or admission threshold, claim requiring world-contact evidence or authority relation, authority claim, or named evidence-support class;
• weaker claim -> narrower claim scope, lower evidence-support class, bounded admissible act, work, or claim, source-loss mode under A.6.3.CSC when a source-to-rendering loss is being claimed, coarsened rendering, or explicit abstain or reopen condition;
• support -> keep ordinary or quoted source wording when no FPF claim relies on it. Otherwise recover the claim before replacing the word; do not coin a generic SupportRelation. If the reading is base, anchor, or basedness, apply A.6.6 and state dependent, base, baseRelation, scope, applicable Γ_time, witnesses, admissibleUse, and nonAdmissibleUse.

For FPF-governed support, test the direct-subject branch before consulting the common alternatives. Ask whether the sentence states a recognizable fact between subject-domain things rather than evidence, assurance, admissibility, work help, or reader help. If it does, name the things and say plainly what relation obtains between them; these are the actual participants and direct predicate. Go to the pattern that governs that relation. If the relation or a participant remains unclear, use A.6.P to recover it. Once the participants and needed predicate are clear, use A.6.RCD only when no current pattern governs that predicate.

When the sentence is not already a recognizable direct subject relation, the following are common alternatives, not a complete list:

• source-description relation: a source episteme, publication, view, model, graph, trace, generated representation, or document describes, exposes, renders, cites, or makes inspectable one claim-bearing item;
• EntityOfConcern or grounding-holon grounding: the claim-bearing episteme, view, representation, or pattern application is grounded in its actual EntityOfConcern participant, actual grounding holon, local world contact, or observation setting; EntityOfConcernSlot and GroundingHolonSlot remain A.6.5 SlotSpec values only inside a current reusable declaration and do not constitute those participants;
• base, anchor, or basedness relation: the phrase means relative-to, based-on, anchored-in, base change, or scoped grounding as a base relation; use A.6.6 support wording selection and rewrite as baseRelation(dependent, base) or SWBD, not as a generic SupportBasis, SupportRelation, or SupportRecord;
• evidence or witness support: an evidence-use relation, evidence-provenance relation, witness relation, witness carrier, observation, test, observation record, or test record bears on a claim;
• assurance or engineering-justification support: an assurance argument, trust calculus, safety case, or engineering-justification claim is being made;
• causal-use relation or evidence relation: a causal-use question, rung, estimand, CausalEvidenceSupportBasis, CausalUseSupportVerdict, supported use, and unsupported use are being claimed;
• mathematical-lens use or lens-use admissibility: a mathematical lens, mapping, similarity, or formal object makes a bounded claim admissible or exposes preserved structure and lost structure;
• characteristic, measurement, threshold, or comparison basis: a characteristic, metric, scale, benchmark, threshold, or comparison basis is being used;
• admissible-use or boundary-use basis: the sentence says what use, act, claim, publication use, or reliance is admissible;
• work, enablement, prerequisite, resource, or operational help: one thing helps, prepares, routes, resources, enables, or makes work easier without evidence, authority, truth, or admissibility claim;
• publication companion, entry, navigation, or reader help: a file, section, index, map, review packet, support document, or companion helps readers find, inspect, compare, or review another item.

Write the concrete sentence before choosing an owner. Test T supports claim C becomes Test T is evidence for claim C and goes to A.10. Index I supports readers can become Index I helps readers find section S and remains bounded reader help; it does not establish the truth of section S. Column C supports roof R remains a structural claim: state the structural relation it asserts, for example that C bears R's load, and use that relation's current owner. If its relation or a participant is unclear, use A.6.P; if both are clear but no current pattern owns the predicate, use A.6.RCD and return the missing-governor result.

For a common alternative, go straight to its owner once the sentence names the things involved, what one does for the other, the permitted use, and the blocked stronger conclusion. Use C.2.P and the direct description, source-use, grounding, or publication pattern; A.6.6 for basedness; A.10 for evidence; B.3 for assurance; C.28 for causal use; C.29 for mathematical-lens use; C.16 for characteristic, measurement, threshold, or comparison construction; or the pattern for the stated admissible use, work, resource, publication companion, or reader help. Do not send one of these common lexical choices to A.6.P to choose again.

Support-headed names such as SupportRecord, SupportSource, SupportLine, SupportForm, a support phrase that hides a state-family claim, SupportSection, SupportMaterial, support basis, support relation, support view, and supported use are diagnostic triggers. They are conformant only when rewritten to an exact governed object under its direct owner: a claim-bearing episteme or record kind named by value; an A.6.5 SlotSpec only when a reusable declaration is current; a publication function; a state-family value under A.19.SPR only when that claim is current; an obtaining direct relation and actual participants; an 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 conforming text exposes dependent, base, baseRelation, scope, applicable Γ_time, witnesses, admissibleUse, and nonAdmissibleUse. Otherwise rewrite the head to the selected interpretation: source-description relation, EntityOfConcern grounding, grounding-holon relation, evidence-provenance relation, source-use relation, source-currentness claim, source adoption decision, source adaptation decision, source rejection decision, obtaining direct relation and actual participants, admissible-use boundary, assurance claim, C.28 causal-use relation or causal-use verdict, C.29 lens-use output, C.16 characteristic construction, measure relation, comparability relation, bridge card, comparison card, work enablement relation, publication companion, or ordinary reader help.

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

If no FPF claim relies on support, keep the ordinary or quoted wording and do not invent an ontology for it. Otherwise the reader must be able to say what supports what, in what sense, for which use, and what must not be inferred. Keep a recognizable direct subject relation in its domain and choose a common lexical alternative here in E.10:0.2. Use A.6.3.CSC for a source-loss mode and C.2.P for the source expression and its use. Use A.6.P only when the direct predicate or a participant remains unclear; once both are clear, use A.6.RCD only when no current pattern governs that predicate.

#Applying patterns versus procedural calls

FPF patterns are applied in problem situations. When another FPF pattern governs the claim, the text names the FPF pattern application and the ontology, conformance claim, or conformance section named by value being applied. The pattern-governed relation is declarative: the text states which pattern applies and which exact governed object, claim-bearing episteme, obtaining direct relation and actual participants, current declaration, or representation use it governs.

Use apply pattern, use the pattern guidance, the pattern governs this problem situation, or the case falls under this pattern when the FPF-side pattern application is being made. Do not use project action as a final class. For project-side activity, choose exactly one kind or relation under repair for the sentence: U.Method; U.MethodDescription; U.Mechanism; A.15 U.WorkPlan; one A.15.1 dated Work occurrence admitted under U.Work; a separate claim-bearing episteme asserting a fact about that Work occurrence; exact entity plus a direct relation involving that occurrence recovered through A.6.P.WMR; exact A.6.1 operation-application binding; local A.15.PROD claim; measurement-result episteme; evaluation or diagnostic finding; 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 relation; typed evidence record; B.3 assurance or engineering-justification record; typed status record whose FPF status pattern is named; carrier relation; front-end relation; or another accepted project-side FPF kind. Use route, path, branch, handoff, trajectory, move, or flow only after the movement, control, and temporal relation set has named the FPF kind under repair.

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

Semioarchitecture often talks about two different described contexts:

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

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

#decision, action, work, method, plan

Do not let action cover every project-side event. An action nominal such as testing, assembly, maintenance, evaluation, or inspection is a morphology cue, not a governed kind. Placement in function- or flow-structure prose identifies no U.Function: apply A.6.F when the function-like use remains claim-bearing and its exact FPF object or relation is hidden; otherwise name the already recovered method, method description, required-transformation or required-effect claim, actual U.Transformation, TransformationFlowStructure locus, functional-view record, plan content, exact Work occurrence, or other governed value under its direct pattern. A WBS element, activity, or Work Package remains plan- or assignment-episteme content about intended work; none of these uses identifies an actual Work occurrence admitted under U.Work.

Split decision-making and decision records under C.11; role, method, work-plan, and actual-work alignment under A.15; planned work under A.15.2; exact dated Work occurrences under A.15.1; actual launch or performed values under independently obtaining direct relations or A.6.1 bindings; separate performed-work, finalization, result, telemetry, and gate records under their direct record or gate patterns; action invitation under A.6.A; communicative acts under A.2.9; commitments under A.2.8; and strong grants under A.2.8.PER. A method-description field, planned filling, compatible type, ticket, or nearby result record establishes no actual participant relation.

A reusable name for exact performed work goes to F.18 only after the occurrence is grounded under A.15.1: each actual performer is an admitted U.System; each exact obtaining covering RA : U.RoleAssignment has that System as holder; any explicit attribution uses performedUnderAssignment(W, RA) under F.6; and actual enactsMethod, temporal extent, containing system, affected referent, direct bindings, and resource-use facts remain separately recoverable. Add the applicable continuity policy only when occurrence identity is material. Keep separately current direct subject or resource-use claims, A.15.PROD production claims, measurement-result epistemes, evaluation results, C.11 choices or decisions, delivery occurrences, acceptance verdicts, and downstream-effect claims under their own governors.

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

#Whole-corpus trigger use

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

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

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

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

Split before use:

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

A case can illustrate or test a pattern. It does not by itself become evidence, a pattern, a DRR, a source basis, or an authority-reference relation. If the case is being used to justify a claim-bearing text change, choose and name each EntityOfConcern under repair or relation separately: evidence record or evidence-provenance relation, 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 are not admitted as final kinds.

Split:

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

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

#translation and multilingual heads

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

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

#state, status, posture, readiness

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

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

Minimum closure:

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

Typical governing patterns:

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

Do not replace support with a support phrase that hides a state-family claim, a source-use bucket, a basis-headed bucket, or another state-family substitute. First decide whether the sentence states a direct subject relation; if it does, name its participants and predicate and use its owner. Otherwise apply the common base-relation, source-use, evidence, assurance, lens-use, characteristic, admissible-use, work-help, or reader-help interpretation that actually carries the claim.

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

live, current, active, open, pending, and similar status-like modifiers are trigger wording when they attach to pattern, record, object, field, operation, route, locus, move, text, claim, question, use, or relation without saying which exact bearer and state or currentness value, temporal qualifier of an obtaining direct relation or assertion, source or use relation, or claim function the modifier adds.

First recover whether the modifier expresses a real FPF value:

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

Do not close this row by deleting live or replacing it with current, active, at issue, or another status word. Closure is a KindRestorationCheck: the modifier is ordinary prose; a state or currentness value under its direct owner; a temporal qualifier of an exact direct relation or assertion; a retained claim, use, or relation marker with named admissible use; an F.19 apparatus removal; or a blocker.

#claim, evidence, witness, ground, proof

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

For claim, recover:

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

For evidence-like words, recover:

• evidence record or evidence-provenance relation;
• 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, deontic permission, work authorization, safety assurance, evidence sufficiency, release authorization, or release confidence, apply the governing FPF pattern or use the project-side FPF kind and reference named by value instead of strengthening the evidence word.

#authority, permission, approval, commitment, obligation

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

Recover:

• role assignment or exact permission-beneficiary ref;
• speech act or issuing act;
• commitment record under A.2.8 for obligation, recommendation-as-duty, or prohibition;
• exact A.2.8.PER strong grant, weak non-prohibition/non-violation finding, exercise relation, or permission-conflict finding;
• policy claim and policy/currentness frame;
• authority relation;
• entry predicate or gate record or decision record when that is the actual claim;
• authority-changing decision;
• wording such as delegated permission: recover the exact A.2.9 granting or delegating speech-act occurrence and, only when the named current policy validly institutes one, the resulting current A.2.8.PER GrantedPermissionRelation@Context; retain the exact grantor assignment, beneficiary ref or role assignment, policy and currentness basis, scope and window, and any separately governed on-behalf-of or work relation. The cue mints neither DelegatedPermissionRelation nor another generic delegation or authorization kind; if the actual direct owner cannot be recovered, block operative use of the wording rather than name an ownerless relation;
• contestability, revocation, scope, window, and 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 or provenance relation selected by the direct authority pattern are named.

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

These usually point to a review profile, review harness, registry record, catalog publication, navigation index, map, publication form, companion publication, publication-companion relation, or relation between one companion publication and the publication unit or project record it helps readers inspect or use. Choose that kind named by value before writing; do not leave support record as the recovered head unless the named FPF pattern really defines that record kind. Treat one as a governing FPF pattern body, accepted campaign DRR, named current architecture document, or relation to one of them only when the named FPF pattern, accepted DRR, or architecture document and the obtaining direct relation with its actual participants are given by value; keep any row, index entry, or map element as a claim-bearing episteme or C.29 representation under its own owner.

Split:

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

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

#entry, front door, corridor, route

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

Split:

• entry publication or navigation aid;
• first-use recognition text;
• navigation-bearing publication;
• movement, control, and temporal relation;
• process sequence;
• corridor overview;
• governing FPF pattern named by the problem under repair; if source or local wording merely groups patterns, name the cluster phrase or relation phrase as literal wording and name the governing patterns by value; if an actual relation between patterns is being claimed, name the exact direct relation, its actual pattern participants, and its direct governor.

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

#same, parity, identity, equivalence, mirror

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

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

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

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

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

Split:

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

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

#quality, characteristic, metric, indicator, score

Do not let evaluation words float.

Split:

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

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

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

These words are not kinds by themselves.

Split:

• A.6.5 SlotSpec inside a current reusable episteme-constitution RelationSignature;
• actual participant of an obtaining direct relation;
• A.6.5 SlotSpec inside another current reusable RelationSignature;
• participant designation inside a current assertion or relation-occurrence-description episteme;
• 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, deontic permission, or release authorization unless the source relation and the evidence or provenance relation selected by the direct pattern are named by value.

#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 the actual EntityOfConcern or other governed participant of a claim-bearing episteme, the claim-bearing episteme itself, or a current A.6.5 episteme-constitution declaration and exact SlotSpec; otherwise recover the non-claim-bearing project kind;
• publication-unit wording that implies authoring or interpretation work: distinguish U.Episteme, U.EpistemePublication, PublicationUnit, file, source note, review target;
• content: usually one of claim graph, text span, publication unit, carrier bytes, or document with named source-basis, evidence-basis, architecture-basis, or review-basis relation or use;
• primary-entity field names: use publicationUnitPrimaryEntityOfConcern when a bounded PublicationUnit carries or exposes a claim-bearing episteme or episteme-lane U.View; otherwise use the non-claim-bearing kind or reference named by value when no claim-bearing episteme participant, A.6.5 declaration, or direct reference use is current;
• surface: keep publication face or publication form or interop publication form only when publication-face kind discipline is named by value; otherwise rewrite to generic publication face, declared MVPK face, publication carrier, interop carrier, UI or front-end face, companion publication, source named by value, evidence, assurance, obtaining direct relation and actual participants, C.29 representation and explicit correspondence, 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 actual source-side and target-side participants of the obtaining direct relation are named, or—when reusable declaration is current—the endpoint kinds and exact A.6.5 SlotSpec values are named; a schema field, table cell, graph endpoint, or mathematical argument stays a C.29 representation element until explicit correspondence is stated;
• reader, reviewer: safe only when the word really names a usability reader, review participant, or review process; otherwise name the generic publication face, declared MVPK face, packet, or PublicationUnit;
• pre-FPF sign vocabulary: recover FPF episteme kinds, publication kinds, view kinds, carrier kinds, and record kinds before reuse; do not rebuild FPF episteme and publication ontology on a concept-sign-denotation triad;
• generic FPF-side object wording, locus, row, host, or target: choose the recovered value named by value: FPF pattern, pattern section, accepted DRR, FPF publication, FPF view, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation or use, file carrier, review target, record kind named by its governor, obtaining direct relation and actual participants, receiver-needed relation occurrence, claim-bearing episteme, reusable A.6.5 declaration, or C.29 representation and explicit correspondence;
• supported use: replace with the admissibleUse target named by value and non-admissible stronger or adjacent use, relationClaimSlice when a relation claim is being made, and projectSideFPFRef when a project-side FPF kind and reference named by value is being used;
• strong, stronger, weak, weaker: replace with scope, evidence class, threshold, gate or admission threshold, source-loss mode under A.6.3.CSC when a source-to-rendering loss is being claimed, coarsened rendering, or explicit abstain or reopen condition;
• authority-bearing FPF pattern or row: split into governing FPF pattern or pattern section, relationClaimSlice when a relation claim is being made, admissibleUse named by value when a boundary-use claim is being made, and projectSideFPFRef when a project-side FPF kind and reference named by value is being used;
• route, call, invoke, or procedure-like pattern wording: replace with pattern application or with project-side Work occurrence admitted under U.Work, U.Method, C.11 decision value, or A.6.A action invitation.

High-risk residue classes:

• restore pre-FPF sign vocabulary to FPF kinds by context;
• unpack FPF-side umbrellas such as generic FPF-side object wording, generic named-target wording, locus, row, host, and source into the recovered value named by value, such as FPF pattern, pattern section, DRR, FPF publication, U.View, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation or use, file carrier, record kind named by its governor, obtaining direct relation and actual participants, receiver-needed relation occurrence, claim-bearing episteme, reusable A.6.5 declaration, C.29 representation and explicit correspondence, or file-carrier phrase;
• unpack project-side umbrellas such as input, raw material, source data, source material, artifact, output, result, outcome, deliverable, handoff, screen, dashboard, credential, badge, and explanation into the exact governed entity and relation: publication or carrier use; project-side FPF kind and reference named by value; exact direct subject-relation claim or exact A.6.1 operation-application binding; exact local A.15.PROD or A.6.RCD claim; A.10 evidence relation; measurement-result episteme; evaluation or diagnostic finding; C.11 ChoiceResult or decision record; gate, assurance, status, action-invitation, work-plan, dated-work, method, or method-description use under its direct pattern; or an exact A.6.P.WMR non-assertability result independently reasoned as factually unsupported, missing-information, or missing-governor. Only missing-governor names the affected receiving use and future owner. Do not leave a generic work-result or result-measurement record as the recovered value;
• make admissibility phrases such as supported use, stronger or adjacent use not carried by the pattern of concern, insufficient evidence relation, and similar formulas name the admissibleUse target named by value and non-admissible stronger or adjacent use, relationClaimSlice when a relation claim is being made, and projectSideFPFRef when a project-side FPF kind and reference named by value is being used;
• check pattern-control metaphors such as route, call, invoke, exit, path, branch, chooser, and workflow for declarative pattern application versus real movement, control, and temporal claims.

#Trigger Concordance And Closure Mechanism

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

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

• appears in a selected name, durable reusable name, heading, table column, schema field, coordinate name, status value, or selected reusable authoring 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 is carried into FPF wording;
• or remains the only word that lets the sentence appear precise.

The mechanism is:

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

Use this compact closure table when the governing review selects trigger concordance:

Allowed closure dispositions are only:

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

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

#Recovery and disposition table

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

#Closure rules

#Problem frame

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

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

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

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

#Problem

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

#Forces

#Solution - trigger scan, ontology recovery, and retained register

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

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

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

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

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

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

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

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

V-3 (Citation style). The first mention of a Context term exposes its Context (e.g., OwnerRole:ITIL_2020). Cross-context reuse is admitted through a Bridge with a stated Congruence Level (CL) (see F.9).

V-4 (Firewall). Tooling and Pedagogy idioms remain outside Kernel prose (DevOps Lexical Firewall). CI/CD jargon, file formats, and API names are not admitted in Core definitions. Pedagogy may use them only as Plain-register examples with Tech anchors present.

#Ontology Guards

#Tech register ontology guards

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

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

• Rule: The head noun of a term explicitly signals the kind (System, Holon, Role, Work, Episteme, Tradition, Lineage, Characteristic, Method, Profile, Description, Spec, TransformationFlowStructure, Card, Pack, Dashboard, …).
• Figurative heads with obvious overload (“Tradition”, “family”, “process”, “function”) are not admitted in the kernel. Plain twins are admitted only with a one-to-one Tech mapping and declared LEX.TokenClass for the Tech token. They appear in the Plain register as one-to-one mappings to a Tech token, not in the Tech register. Plain language minimizes lexical error from overloaded terms through plain-twin lexical guards.
  • Do: IncidentDashboard, MethodSpec, TraditionProfile, TransformationFlowStructureDescription.
  • Don’t: IncidentBoard, TDD Tradition, Production Process (kernel), Service Function (kernel).

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

• Rule: A term for the EntityOfConcern uses the bare head for the FPF kind under concern: Method, Tradition, Characteristic. A Description episteme appends …Description only under the membership rule of its direct owner. In particular, a claim-bearing episteme is U.MethodDescription only when its exact EntityOfConcern is one admitted U.Method and it makes at least one substantive claim about that method as a way of doing. Algorithm, code, pseudo-code, recipe, procedure, diagram, or other expression form first remains source wording, a C.29 representation, or a publication expression; none establishes that membership. A qualifying Description episteme appends ...Spec only after a named specification-use gate grants that use. Thus MethodSpec is available only when the same episteme passes both A.3.2 membership and the E.10.D2 specification-use gate; formal language, pseudo-code, or bundled tests alone settle neither condition.
• Formal-description guard: A formal mathematical or physical theorem, including a formal postulate theorem in physics, remains a Description episteme until a bounded use assigns specification use. Its formal language belongs to formality and publication-expression discipline; it becomes a specification only under acceptance criteria, harness checks, normative invariants, measurable anchors, verification use, or another specification-granting condition named by value.
• Extension: Apply the same morphology to non-method EntitiesOfConcern where appropriate: TransformationFlowStructureDescription, TransformationFlowStructureSpec, SystemDescription, and SystemSpec.
• Do: SamplingMethod - SamplingMethodDescription - SamplingMethodSpec.
• Don’t: SamplingAlgorithm (when it is just prose), SamplingProcessSpec (head not signalling kind). Onto3 — Roles, RoleAssignments, and carrier-relation separation (holonic) (ref. A.2, A.2.1, F.4, F.5, C.2.1+, C.2.P, E.17, A.10, and C.35)
• Role rule: A work-facing role value may use a Tech label ending in …Role and is described through F.4 Role Description, e.g., SafetyOfficerRole, ReviewerRole. Role-characteristic spaces, role-state relations, and role relation structures are separate governed values; they are not hidden inside the role name. A concrete U.RoleAssignment has exactly four actual participants: the admitted holder System, the role value, the exact role-taxonomy episteme, and the effective reference scheme. Its temporal extent is described separately as AssignmentInterval; neither that extent nor a generic context is another relation participant.
• Canonical complete assignment example:

RoleAssignmentAssertion:
  participantDesignations:
    HolderSystemSlot: TeamAlpha
    RoleValueSlot: ReviewerRole
    RoleTaxonomyEpistemeSlot: JournalReviewRoles-2026
    EffectiveReferenceSchemeSlot: JournalReview-Scheme-A
  assignmentInterval: [ReviewRound-42-start, open]

The four indented designations name the relation participants. assignmentInterval describes the currently known temporal extent outside that participant list. Recover the source label JournalIssue42Context separately. If it denotes a selected BoundedModelUseStructure that changes one receiving interpretation, the receiving assertion or work use designates that structure; generic U.RoleAssignment does not.

• Carrier rule: Carrier is not a free holon or system kind. In Tech use, recover the governed carrier relation: use U.PresentationCarrier only under its C.2.1+ publication and presentation discipline; if a reusable carrier-relation declaration is separately current, PresentationCarrierSlot remains the declaration-local SlotKind of one A.6.5 SlotSpec and is not the carrier or relation. Other exits are a file, transport, rendering, front-end, or access-carrier relation under [E.17](/generated/patterns/E.17); evidence or source-currentness carrier under [A.10](/generated/patterns/A.10) or [G.11](/generated/patterns/G.11); generated or produced carrier under [C.35](/generated/patterns/C.35); or a named episteme-symbol carrier relation only when a tradition, lineage, profile, repertoire, or other episteme is made available independently of any role assignment. Avoid Artefact as a head in the kernel: it is ambiguous between a carrier relation, a system made by a transformer, or an episteme abstracted from its carrier.
• Register note: Job titles (Reviewer, Owner, Lead) belong in the Plain register and twin-map to explicit Tech ...Role tokens.
• Why: This resolves inconsistent role-carrier, role-assigned holon or system, and generic carrier-kind usage: use U.RoleAssignment for assignment of an admitted System to a …Role under one named role taxonomy and effective scheme; use U.PresentationCarrier or another direct governing pattern only for the recovered carrier relation.
• Rewrite note. Repair ...CarrierRole used for a role-assigned holon or system to a readable four-participant assignment: say which admitted System holds which ...Role under which named role-taxonomy episteme and effective reference scheme. Use the canonical form above when a receiving use needs explicit occurrence identity, and describe temporal extent separately as assignmentInterval. Recover any source Context value independently; a selected model-use structure belongs in the receiving assertion or work use. Use SCR-LEX to check the rewrite.
• Do: ReviewerRole; TeamAlpha holds ReviewerRole as interpreted by JournalReviewRoles-2026 under JournalReview-Scheme-A; LeanTraditionCarrier only when declared as an episteme-symbol carrier relation over a holon independent of any particular role assignment. Don’t: Reviewer (as a U-kind), ReviewerCarrier (to mean a role-assigned holon or system), SystemReviewer (role collapsed into a system kind), or Carrier as an unstated system kind. 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.
• Domain stitching rule (see D.CTX and UTS). Any use of Domain presents: 1. the enumerated list of ContextId in D.CTX, and 2. the corresponding UTS strings (F.17) with twin labels.
• “Discipline is not Domain.” Domain labels are catalog-only (D.CTX plus UTS); Discipline is a CG-Spec-governed holon (U.Discipline). Cross-use is admitted through Bridge (F.9) plus CL; LexicalCheck returns failure for texts that equate Domain with Discipline.
• Governance. No “Domain ... governance”. Rules of comparability and aggregation belong to Discipline or CG-Spec (ComparatorSet, ScaleComplianceProfile (SCP), MinimalEvidence, Gamma-fold, CL policy), not to Domain. Prefer DomainFamily plus stitching over inventing new Domain kinds.
• 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 states the FPF kind or object named by the term: a U.Holon, U.System, U.Episteme, Tradition, Lineage, Profile, Role, U.Work as the admitted kind or a Work occurrence admitted under it, Characteristic, or Carrier.
• Do: “Kind named: ReviewerRole — a work-facing U.Role value for review work. A concrete assignment separately names its admitted holder U.System, role-taxonomy episteme, and effective reference scheme under [A.2.1](/generated/patterns/A.2.1).”
• Don’t: “Reviewer — a person who …” (blurs the kind named).

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

• process, procedure, workflow, function, or activity -> first recover the wording family: change-situation wording applies [A.3.4.P](/generated/patterns/A.3.4.P); function-like wording applies [A.6.F](/generated/patterns/A.6.F); possible recovered values include U.Method, U.MethodDescription, U.WorkPlan, one dated Work occurrence admitted under U.Work, a separate episteme about it, U.Transformation, and TransformationFlowStructure only after the exact governed object, method-side or other obtaining direct relation and actual participants, current declaration, representation use, or claim kind and its direct owner are named by value.
• Tradition → Tradition (Tech); leave “Tradition” only as a Plain twin with an adjacent Tech label.
• domain → DomainFamily + {ContextId list} + UTS twins.
• …CarrierRole used for a role-assigned holon or system -> recover the admitted holder System, exact ...Role value, role-taxonomy episteme, and effective reference scheme through the canonical four-participant U.RoleAssignment above; describe any AssignmentInterval separately. Recover a source Context value independently and, when it denotes a selected model-use structure that changes a receiving interpretation, designate it only in that receiving assertion or work use.
• ambiguous Owner in role names → prefer StewardRole, CustodianRole, or an explicit responsibility head.
• job titles (owner, lead, champion) in the kernel → use explicit …Role names; keep titles in Plain with twin-labels.
• Do: ReturnsTransformationFlowStructureDescription, Tradition: Test-Driven; LedgerTeam holds CustodianRole as interpreted by AssetLedgerRoles-v2 under AssetLedger-Scheme-A, while source AssetLedgerContext is recovered separately.
• Don’t: Returns Process, TDD Tradition (kernel), Ledger Owner (underspecified).

Worked mini-examples across arenas. These names illustrate morphology only. Every ...MethodDescription presupposes one claim-bearing episteme whose exact EntityOfConcern is one independently admitted U.Method and whose claims pass A.3.2; every ...Spec also presupposes its subject-specific specification-use gate. The label establishes neither condition.

The Onto3 block above is the one fully filled assignment example. The twelve rows below are recognition cues, not assignment assertions. Read each candidate System label and candidate role value separately. Before saying that an assignment obtains, confirm that the holder label names an admitted U.System, supply the named role-taxonomy episteme and effective reference scheme, and identify the exact assignment occurrence; describe its temporal extent separately. If any of those are missing, stop without asserting U.RoleAssignment. Recover every source ...Context cue separately. A schedule, place, office, desk, title, or other holder-like phrase does not fill HolderSystemSlot merely by wording.

Checklist before minting a KernelToken

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

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

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

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

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

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

#Twin‑Register Discipline (Tech and Plain)

Plain twin (LEX). A registry entry pairing the authoritative Tech label with a display-only Plain label for one governed Tech meaning in one U.BoundedContext: an admitted durable U-kind, C.3 U.Kind, Concept-Set row, imported signature symbol, or other directly governed value. 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 extension-pattern 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 admitted only in expository text and maps one-to-one to the Tech meaning inside the current Context.

#Allowed pairs (normative table; examples)

R‑1 (Plain first-use). At first use in a section, show the Tech label and, optionally, the Plain twin only after membership is known: "...one U.Method (the how-to); and, when a separately identified claim-bearing episteme has that method as its exact EntityOfConcern and passes A.3.2, one U.MethodDescription (an account of that how-to, sometimes called a recipe)..." R-2 (No unpaired Plain in CC). Conformance Checklists use Tech labels only.

Domains can mint aliases inside their U.BoundedContext glossary; each alias maps one-to-one to a Tech label through a SenseCell row in the Context's Concept-Set Table and, when exported across Contexts, through an Alignment Bridge with congruence-level and loss fields.

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

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

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

#Plain Twin Safety constraints (normative)

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

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

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

• Roles keep "(role)". When a relied-on use of service or access still hides its direct object or relation, follow L-SERV and A.6.P:4.11a; after recovery, keep that object's or relation's head—for example "(promise content)" or "(access relation)"—rather than a shared service head. Methods keep "(method)", U.Work as a kind keeps "(work kind)", one Work individual keeps "(work occurrence)", a separate episteme about it keeps "(work record)" only when its Tech name denotes that record, and Capability keeps "(capability)". Examples: TransformerRole → “Transformer (role)”, U.PromiseContent → “post-op monitoring service promise (promise content)”; an exact access relation → “service access (access relation)”, U.Work -> work (work kind); PumpInspection_2026-07-22T0900 -> inspection work occurrence; PumpInspectionRecord_2026-07-22 -> inspection work record only when that Tech name denotes a separate episteme.

CC‑TWIN‑4 - Kind‑consistent. A plain twin does not map across Kinds (C.3). If the twin's everyday interpretation can denote a different Kind (e.g., Tradition = organization, corpus, domain), it is admitted only with 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 are not admitted 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 is admitted through 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, show a plain twin as “Plain twin [Tech name] - Context gloss”, e.g.: “Transformer (role) [TransformerRole] — work-facing U.Role value for method-enacting work in the local OR_2025 use; an actual assignment separately names its admitted holder U.System, role-taxonomy episteme, and effective reference scheme under A.2.1, while any bounded context or selected model-use structure remains outside that assignment”.

CC-TWIN-8 - Normative publication-form overread ban. Plain twins are not admitted 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 non-conformant because they create uncontrolled vocabulary sprawl (see F.14).

CC‑TWIN‑10 - Registry entry and DRR. Every admitted plain twin has a registry entry in the LEX registry recording tech, plain, context, head, SenseFidelity = {3,2,1,0}, ambiguity notes, counterexamples, and DRR id. A change opens a DRR.

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

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

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

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

Definition. LEX.TokenClass : NameToken → {KernelToken | ContextToken | DiscriminatorToken}. This is a local lexical classification function on NameTokens with the closed value set {KernelToken | ContextToken | DiscriminatorToken}, used by the LEX registry and MG-DA checks. It is not thereby a U.Characteristic or a CharacteristicSpace; that CHR reading would require a separately named U.Characteristic with one declared CSLC scale. It is not a USM scope and carries no truth or validity semantics.

#KernelToken — Minimal Generality (MG‑K)

MG-K1 (Tri-domain witness). A DRR note or Glossary note provides at least three heterogeneous arenas where the invariants hold (e.g., manufacturing, healthcare, cloud ops). Otherwise reject or narrow the KernelToken candidate and recover each word or qualifier under its exact governed object and direct owner. Use a ContextToken only after the exact context-local lexical use and its governing semantic locality are recovered. Use RoleCharacteristicSpace only when one exact Role, one named U.Characteristic with one declared CSLC scale, the governing context, and the role-state use make that construction current. MG-K2 (No parochial nouns). Kernel names contain no domain nouns such as Ticket, Microservice, Patient, or Developer. Domain-looking wording is a direct-owner recovery trigger, not a destination: it may denote a C.3 local kind, a role value or U.RoleAssignment use, a system or architecture object, an episteme or exact record kind, one declared Characteristic and scale, source wording, an ordinary qualifier, a recovered ContextToken use, or another directly governed value. List or lexical shape alone makes it neither a context-local token nor a RoleCharacteristicSpace characteristic. MG-K3 (No vacuity). Avoid vacuous heads such as Thing, Event, Process, or Resource. Use existing U-kind heads such as U.Holon, U.Work, and U.Method. MG-K4 (Intent after recovery). U-kind names and role-description labels encode recovered semantic intent rather than notation, implementation, or local-realizer accidents. Algorithm, hardware-form, and recipe-flavor wording is a recovery trigger, not one ontological family: name one exact U.Method, qualifying U.MethodDescription, U.Capability, U.Mechanism, system or architecture object, RoleCharacteristicSpace, C.29 representation, formal substrate, source wording, or another value only when its direct owner's predicate is satisfied. Do not use Capability or RoleCharacteristicSpace as default disposal bins and do not use mechanism as an umbrella for these unlike cases. MG‑K5 (Notation independence, SHOULD). The EntityOfConcern-side kind criterion is separable from any one notation or toolchain. MG-K6 (Refactoring safety). If a name fails MG, record a DRR and apply F.13 Lexical Continuity and Deprecation rather than mutating it silently.

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

DA-D1 (kind anchoring). 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 (Enumeration direct owner, not axis). An enumerated property is a CHR construction only when one named U.Characteristic is bound to one declared CSLC scale in a CharacteristicSpace. Otherwise recover the exact closed value set, classified kind, local classifier, state/status frame, source wording, C.29 representation, example or alternative set, or other direct-owner construction. Avoid spatial metaphors (axis, dimension, plane, lane, tier, layer) unless the metaphor is a pattern-defined primitive in this spec. DA-D3 (Enum clarity). If the term denotes an enumeration, the value set is small and closed, membership criteria are obvious from the definition, and the kind being classified is explicit in the name (e.g., SenseFamily, not bare Family, RowPlane or overly general Facet). DA-D4 (Anti-recipe). Do not bake how-to or local methods into discriminator names. The way of doing belongs in one exact U.Method; a claim-bearing episteme belongs in U.MethodDescription only when that method is its exact EntityOfConcern and A.3.2's positive threshold is met. Use U.Capability instead when the kind under repair is an ability envelope. DA-D5 (Mapping discipline). Cross-context interpretations go through a Bridge (F.9). Discriminator names do not suggest global identity. DA-D6 (Register discipline). Keep normative tokens stable; synonyms belong in the Plain register only and stay outside constraints and tests. DA-D7 (Ban generic combinators). Reject vague composites like NameUseMode, NamingScope, RowFacet, RowPlane, or RowLane. Each candidate passes DA-D1 and DA-D3 for a kind-anchored head, an explicit classified kind, and a closed-value interpretation under its direct owner. Require a CharacteristicSpace only when one named U.Characteristic and its CSLC scale have independently been declared.

#Global tests (apply after 7.2 and 7.3)

MG-DA-T1 (Three-arena witness). A LEX.TokenClass(t)=KernelToken candidate includes the tri-domain witnesses from MG-K1. Other token classes 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 (Implementation-word recovery). Do not relocate mechanism- or implementation-looking wording by lexical category. First recover the governed object and direct owner; remove accidental implementation wording from the candidate token only after that recovery. Use U.Method, qualifying U.MethodDescription, U.Capability, U.Mechanism, a system or architecture object, RoleCharacteristicSpace, C.29 representation, formal substrate, source wording, or another exact value only when its own predicate is satisfied. MG-DA‑T4 (Enum clarity). For an enumeration, list the closed value set, the kind being classified, and the direct owner of that classification. Add a CharacteristicSpace only when the enumeration is one declared CSLC scale for a named U.Characteristic; list shape alone does not establish CHR membership. MG-DA-T5 (Collision and uniqueness). Before merge, perform a full-text search over the corpus and the Reserved-Names registry. A candidate colliding with an existing token used in another FPF sense is not admitted; rename it or raise a DRR to deprecate the prior token. MG-DA‑T6 (Teaching swap). In didactic prose (E.10.D2), the term can be swapped in without caveats. MG-DA-T7 (EntityOfConcern ground). The definition card states the EntityOfConcern-side kind criterion for membership explicitly; reviewers can check membership without consulting external narrative.

#Compatibility with USM (how tokens and scopes meet)

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

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

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

#Metaphor guidance (informative heuristics)

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

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

#Short‑form and acronym discipline

SF-1 (First expansion). On first use, expand the term and place the short form in parentheses (e.g., “Minimal Generality and Domain Anchoring (MG-DA)”). SF-2 (Uniqueness). Register short forms in the Reserved-Names list and perform the collision check (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. Replace ScheduleProcess with U.WorkPlan only when one exact episteme passes A.15.2: one present EntityOfConcern, one horizon, at least one PlanItem, and substantive coordination claims about possible future performed work. Otherwise retain the exact schedule representation, planning cue, or other direct-owner construction. Do not mint ETLService at kernel level. Recover the ETL claim first: the way of doing may be one exact U.Method; a separately identified claim-bearing episteme may be U.MethodDescription only when that method is its exact EntityOfConcern and the A.3.2 substantive-description threshold is met. An ETL label, pipeline diagram, code expression, mechanism, work plan, dated Work occurrence, or API publication establishes neither membership. If a relied-on service use still hides another subject or relation, apply L-SERV and A.6.P:4.11a and let its direct owner name it; the suffix alone requires no promise, access, acceptance, Work, or publication branch.

#Acceptance and regression checks (LEX and USM)

SCR‑LEX‑S01 (TokenClass declaration). Every normative token has a declared LEX.TokenClass. SCR‑LEX‑S02 (Collision and uniqueness). Full‑text + Reserved‑Names check passes (no other meaning in FPF). SCR‑LEX‑S03 (kind anchoring). Heads name the FPF kind classified (DA‑D1). SCR‑LEX‑S04 (Enumeration direct-owner gate). Every enumeration names its closed value set, classified kind, and direct owner. Require a CharacteristicSpace only when one named U.Characteristic is bound to one declared CSLC scale; otherwise retain the exact local classifier, state/status value set, source or representation, example or alternative set, local kind, or other governed construction. SCR‑LEX‑S05 (USM compatibility). For each LexicalAct, USM.Scope ∈ AllowedScopes(LEX.TokenClass). SCR‑LEX‑S06 (Slot and Ref suffix discipline). A token ending in …Slot names the declaration-local SlotKind inside one exact A.6.5 SlotSpec of one reusable RelationSignature. A token ending in …Ref names either a RefKind admitted by its direct reference owner or a receiving-episteme field explicitly typed by that RefKind; the field remains designation or reference apparatus and does not become the participant or SlotSpec. No ValueKind or representation field may acquire either suffix by shape alone. SCR-LEX-S07 (Manifest provides follows exact signature claims). If a SignatureManifest is present, its provides entry is used only when that signature's exact U.ClaimGraph states that the signature introduces public names for dependent use. The entry carries that claim content or visibly represents it; list membership alone establishes neither provision nor a consumer dependency. Include only names actually introduced by this signature under their direct owners, such as its own A.6.5 relation-participant SlotKinds and RefKinds whose direct reference owners admit them. A RefKind owned elsewhere remains owned there, and membership in an A.6.1 operation-argument or result declaration list does not transfer ownership to the manifest. A mathematical operand, table column, tuple place, or other C.29 representation element becomes no provided SlotKind by shape; any reuse still needs its independently governed declaration and explicit correspondence. RSCR‑LEX‑E01 (Banned generics). Reject tokens matching the banned combinators list (DA‑D7). RSCR‑LEX‑E02 (Metaphor hygiene). If a metaphor is used, show the pattern that defines it; otherwise rename. RSCR‑LEX‑E03 (Strategy token minting). Reject new Kernel tokens named Strategy or Policy as kinds; model them as lenses, flows, or compositions inside G.5, or as …Description or …Spec in Contexts. (Prevents kernel overloading; aligns with C.22 “no minted Strategy head”.)

#Morphology and Lexical Form (LEX.Morph)

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

#Casing and basic forms

M‑0 (Casing and categories). Kind names and work-facing role-value labels: UpperCamelCase (IncisionOperatorRole, MethodDescription). Relations and verbs: lowerCamelCase (performedUnderAssignment, isExecutionOf, bindsMethod). IDs and instances: flat with delimiters (context‑defined) but never collide with kind-name or role-value-label forms (e.g., W#Seam134, ctx:Hospital.OR_2025). Register discipline: normative tokens use the Technical register; Plain synonyms are allowed in prose only, never in constraints.

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

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

#Suffix conventions and retained-family boundaries

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

Not only suffix guard

• Suffixes are closely related to kinds and should be clearly guarded by MG-DA.
• Other morphemes, not only suffixes, also respect kinds. For example, Space is a geometric concept and is not admitted as a suffix (...Space...) or other morpheme for naming non-geometric entities. Prefer Set, Kind, or Kit where membership is intended.

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

• Use U.Episteme for the claim-bearing unit. Use U.EpistemePublication or governed U.Episteme publication only when that episteme is available as a published episteme under C.2.1 and E.17 discipline.
• Name the publication form separately from the episteme: for example U.PreArticulationCuePack, U.AbductivePrompt, typed bounded projection, partial normal form, endpoint-pattern-governed publication, or another declared form. A publication form is not itself the governing FPF source.
• Name U.View and MVPK face separately from the publication form. A PlainView, TechCard, InteropCard, or AssuranceLane is an episteme-level view or publication face, not the source claim, not the publication form itself, and not the SCR or RSCR carrier.
• Name the carrier or rendering relation separately. Documents, dashboards, generated screens, trace files, cards, and transport formats hold or render a publication; they are not the U.Episteme, not the claim or effect being relied on, and not the governing pattern.
• Name source-finding cues separately from source epistemes. A cue, badge, credential view, dashboard tile, heading, signature-looking mark, or generated explanation may help find a source; it does not by itself create an authoritySourceRef target, evidence relation, gate decision, assurance claim, role assignment, status assertion, work occurrence, deontic permission, or work authorization.
• 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 record, or role-assignment or status register carries the relevant authority. Do not use generic sign wording, generic episteme-publication wording, generic source wording, generic project-work wording, or container-placement wording as solution terms.
• When a published episteme is used for work, name the P2W chain element being used: intended method family, selected method or method of work, U.WorkPlanning baseline, planned work, or one actual Work occurrence admitted under U.Work. Then name any separate claim-bearing episteme about that occurrence and any separately current direct resource-use, affected-referent, operation-application, A.15.PROD production, measurement, evaluation, decision, delivery, acceptance, or receiving-use relation under its own governor. Apply A.6.P.WMR only while one such work/method-boundary relation remains hidden after generic relation recovery. Do not let generic action, use, material, work result, or result measurement hide that distinction.
• Use C.2.P when episteme-publication-heavy wording carries episteme, publication, view, carrier, relation, admissibility, evidence, work, gate, decision, method, or FPF-pattern-application claim. This parent pattern keeps the lexical and naming discipline; C.2.P supplies the epistemic precision-restoration profile that recovers the FPF kind named by value; obtaining direct relation and actual participants; receiver-needed relation occurrence; reusable A.6.5 declaration; claim-bearing episteme and participant designations; C.29 representation and explicit correspondence; project-side FPF kind and reference named by value; or not-triggered disposition before final wording is accepted.

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

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

L-Space - Disciplined use of Space

• Use Space 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 and direct-declaration guard. In A.6.0 and A.6.1 declarations, write SubjectKind and RangedValueKind as direct content fields. Add ResultKind, SliceSet, and ExtentRule only when their distinctions are current. A heading that merely wraps these fields is presentation, not another declaration component, and receives no Tech name. Reserve Space for CHR-grounded measurement, state, and ReferencePlane constructs when those are the governed value kinds. Let the referenced C.3 kind, admitted durable U-kind, Concept-Set row, or imported signature symbol carry ...Space where appropriate; use ...Set for an ordinary set-valued universe.
• Space is a geometric concept. Do not use it as a suffix or morpheme for non-geometric sets, portfolios, or publication forms; use Set, Kit, Bundle, Portfolio, or another direct FPF kind when that is the current object.

L‑ROLE — disciplined use of Role

• Role names a work-facing U.Role value or an explicitly governed source label recovered to that value. A role assignment, role state, role relation structure, holder, method, work, evidence, source, status, or publication claim is not created by the suffix.
• Parameter, declaration, and representation guard. Do not use the morpheme Role for formal parameter places in operator-algebra representations or for reusable relation-declaration participants. Reserve Role for work-facing role values governed by A.2, F.4, F.5, F.6, and A.2.7 naming boundaries. Use A.6.5 SlotKinds and SlotSpec values only for participant meanings inside one current reusable RelationSignature; keep operation argument and result declarations under A.6.1. An operator-algebra operand, table column, tuple place, or didactic list entry remains a C.29 representation element, with domain-specific terminology and an explicit correspondence when a declaration consumes it. A ValueKindView may present declared ValueKinds for teaching, but neither the view nor a representation place becomes a SlotSpec or U.Role.

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

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

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

#Prefix discipline

M‑P1 (Reserved prefixes). U. is reserved for admitted U-kinds and governed dependent U.* forms; Γ_ for algebraic operators; CAL, LOG, and CHR for pattern packages. Never mint U.* inside a Context.

M‑P2 (Edition and version markers). Use a context marker only under the direct U.BoundedContext owner. Select one exact episteme edition only through a governed reference whose referent is that exact U.Episteme and whose direct reference owner defines a narrow selector. Do not attach an edition selector to an EntityOfConcern-side Method, Space, system, bare Service, or their references. When a use depends on a defining, describing, CG-Spec, service-description, or service-offer episteme, reference that episteme separately. A service-access publication, publication occurrence, publication form, and carrier retain their own governed references and do not inherit the episteme selector. Tool and carrier versions remain separately governed. Authors MAY annotate context-local service labels for didactics only after every governed value is recoverable. Norms (edition, release, and version).

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

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

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

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

M-2 (Classified-kind anchoring). The head noun names the classified FPF kind or exact subject construction: Role, Method, Work, Context, Characteristic, Capability, constraint claim, U.Commitment, publication form, service-access relation, service-offer record, or another direct FPF value. No free-floating metaphors and no bare Service or Requirement head before recovery.

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

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

M‑5 (Kernel parochiality). KernelToken names carry no domain nouns. Recover domain markers under their exact governed objects and direct owners; use ContextToken or RoleCharacteristicSpace only after the MG-K1 and MG-K2 gates, never by lexical shape.

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

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

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

#Alias hygiene

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

#Entry lexeme support and lexical-query discipline

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

• FPF readme section,
• E.11 public-entry positions,
• I.2 expanded entry-disambiguation cases,
• Table of Content query rows,
• or one bounded lexical-query record governed by F.17, UTS, or F.18.

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

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

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

canonical
noncanonical_visible
domain_query_examples
forbidden_aliases

Ordinary lexical-query support should stay compact:

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

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

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

Language-specific query cues may be added as entry-lexeme support. They do not become canonical names, aliases, or semantic equivalents unless [F.18](/generated/patterns/F.18) admits that naming use; otherwise E.10 keeps the phrase as ordinary context-local query wording. Such a practitioner phrase may help recover a canonical FPF pattern while remaining lexical-query support only.

#Compatibility with USM (acts and tokens)

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

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

Example: use of a KernelToken in a Context constraint can be admitted through a Bridge or alias; logging Work inside a MethodDescription violates M-4 and the policy.

#Acceptance and regression checks (LEX and USM)

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

#Autonomy lexicon (L‑AUTO )

Inadmissible in Core: bare “validity”, bare “actor” or “agent” as free-standing nouns, “kill switch”, “process” for behavior, and “envelope” when used as scope. Use instead: Scope (G) for epistemic scope; WorkScope for capability bounds; an admitted U.System for the actor or doer. When exact performed Work is current, recover one dated W : U.Work, one exact obtaining RA : U.RoleAssignment with that System as RA.HolderSystemSlot, and F.6 performedUnderAssignment(W, RA); use RoleAssignment only for the work-facing assignment relation. Use SpeechAct for overrides and SafeStop instead of “kill switch”. Named prefixes (policy and registry):

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

Notes.

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

#LEX-CHR-STRICT — Reserve Characteristic for CSLC-measurable aspects

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

Rule L-CHR-S1 (Reservation). Use Characteristic only for variables that declare a CSLC scale (nominal, ordinal, interval, or ratio) with admissible values, units, and polarity (Part C.16 and A.17–A.18). Rule L-CHR-S2 (USM). U.Scope, U.ClaimScope (G), and U.WorkScope are USM scope objects, not Characteristics, and do not appear in a CharacteristicSpace. Rule L-CHR-S3 (Status). Episteme statuses, role-state values, deontic statuses, and epistemic statuses are not Characteristics by label alone; they are statuses or states governed by their direct patterns. Rule L-CHR-S4 (Lexical classifiers). Keep a lexical classifier or tag under its exact direct owner: a local classification function and value set, source wording, C.29 representation element, example or alternative set, status or state-frame value set, local kind or classifier, or another governed construction. Call it a U.Characteristic only when that exact characteristic and one CSLC scale are declared. Do not default the residue to Facet, attribute, or another umbrella kind. Checks. — CC-L-CHR-1. scope characteristic(s) is banned in Core and Context. — CC-L-CHR-2. CharacteristicSpace near Scope — error. — CC-L-CHR-3. Kind-preserving repair: F–G–R characteristics → F–G–R components only when the recovered kind is component rather than characteristic.

#LEX-QA-1 - Using terms with the -ility and -ilities suffixes

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

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

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

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

What this section does. LEX L-rules standardise how we recover kind and use in Core and Context when overloaded everyday words hide FPF concepts. What this section does not do. It does not restate naming (see § 7 MG-DA) or morphology, casing, and suffix rules (see § 8 LEX.Morph); it depends on them. Guards. Tokens are classified by LEX.TokenClass ∈ {KernelToken, ContextToken, DiscriminatorToken} (§ 7.1). Only CHR:ReferencePlane may use the bare word plane. E.10.D2 names the boundary between EntityOfConcern and Description epistemes with DescriptionContext; specification use needs a granting gate named by value; publication faces, publication forms, PublicationUnits, carriers, and renderings stay separate. An enumeration becomes a CHR construction only when it names a U.Characteristic with one declared CSLC scale. Without that declaration, recover the exact construction instead of defaulting to a non-measurable attribute: it may be source wording, a C.29 field or other representation element, an example set, unresolved alternatives, a status or state-frame value set, a local kind or classifier, or another directly governed value. It becomes an A.6.5 SlotSpec only inside one exact reusable RelationSignature.

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

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

Red and Green pattern (example). ✗ "The process ensures quality." → ✓ "M_quality : U.Method names the recovered way of doing. D_quality is U.MethodDescription only because it is a separately identified claim-bearing episteme whose exact EntityOfConcern is M_quality and whose claims state the method's steps and applicability. Dated Work is evaluated against an acceptance condition, constraint relation, or commitment relation named by the direct governing pattern."

#Diagnostic examples, not substitutions

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

#Acceptance tests (LEX‑AC)

A text passes LEX if all answers are Green:

1. Context named. Polysemous terms appear inside a named U.BoundedContext (or the page declares a local context card).
2. Right EntityOfConcern and Description-episteme boundary and specification use. EntityOfConcern, Description-episteme, specification-use, publication relation, and run-record uses are not conflated (cf. § 8.1 gates).
3. Promise, ability, and performance split. PromiseContent (promise clause), Capability (ability), Work (performance) are not conflated.
4. No anthropomorphism. Documents, datasets, and models do not “do”; Systems do.
5. Scheduling hygiene. No actuals belong in a U.WorkPlan. U.Work is the admitted kind; one exact Work individual is a world-side dated occurrence admitted under it. Actual performer, method, temporal, containing-system, affected-referent, binding, and resource-use facts obtain through their direct relations. When those facts must be stated, a separate assertion or description episteme designates the occurrence; it neither is nor creates the occurrence.
6. 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.
7. MG-DA ok. New or refactored tokens pass § 7 MG-DA (anchored head noun; collision check; an enumeration names its closed value set, classified kind, and direct owner; use U.Characteristic and CharacteristicSpace only when the enumeration is the declared CSLC scale of that exact Characteristic).
8. Morphology ok. Suffix, prefix, and casing respect § 8 LEX.Morph (e.g., …Role, MethodDescription, Work, reserved prefixes).
9. Banned tokens absent or recovered. No process, practice, function, task, or activity in Kernel senses unless the sentence applies the selected recovery pattern (A.3.4.P, A.6.F, work patterns, method patterns, C.36.P, or another governing pattern) and names the recovered value by value; no tooling or file suffixes in Kernel tokens.
10. State gating present (when needed). Readiness is expressed via a role-state relation value plus StateAssertion, not vague “approved” or “ready”.

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

• With E.10.D1 D.CTX (Context discipline). E10-CTX-1: Every Core meaning that can vary names its U.BoundedContext. E10-CTX-2: Same-spelled labels are distinct senses across Contexts; reuse is admitted through a Bridge (F.9) with CL and loss notes.

• With E.10.D2 (EntityOfConcern and Description-episteme boundary and specification use and refinement discipline). Speak in the right EntityOfConcern and Description-episteme boundary and specification use. E10-EOC-DESC-SPEC-1..3 apply: the EntityOfConcern is named directly; Description suffixes name Description-episteme use; Spec suffixes name specification use on a Description episteme; a work assertion or description is a separate U.Episteme about one Work individual and is not the occurrence; a state assertion is a separately governed claim about a state and is not that state; an evaluation-result episteme is neither the evaluated object nor an occurrence. Upgrade a Description episteme to specification use only when checkable acceptance or another specification-granting gate named by value exists.

• With A.2 and A.15 (Role–Method–Work alignment). Role = work-facing role value; RoleAssignment = assignment relation; Method = one admitted way of doing; MethodDescription = one claim-bearing episteme whose exact EntityOfConcern is that method and whose claims substantively describe it; U.Work = the admitted kind; one Work individual = one world-side dated occurrence admitted under it; an assertion, description, log, or record about that occurrence = a separate U.Episteme. Its performer, enacted-method, temporal, containing-system, affected-referent, binding, and resource-use facts obtain through their direct relations. Conforming sentences preserve this split.

• With F‑cluster (Unification) and UTS (F.17). Harvest in one Context → SenseCell → Concept‑Set row with relation (≡/⋈/⊂/⟂) and losses. UTS is the human‑readable roll‑up.

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

#Conformance checklist (LEX‑CC)

1. LEX‑CC‑1 (Bans). Any banned token in Core or architecture prose fails unless the canonical appears (or the token is a registered Context alias).
2. LEX‑CC‑2 (Context). Each polysemous term names its U.BoundedContext.
3. LEX‑CC‑3 (EntityOfConcern and Description-episteme boundary and specification-use morphology). Usage passes § 8 gates (suffix, prefix, and casing), EntityOfConcern and Description-episteme boundary checks, and specification-use checks.
4. LEX‑CC‑4 (Bridge). Cross‑context reuse cites Bridge id and CL; same‑spelled labels without a Bridge are non‑conformant.
5. LEX‑CC‑5 (MG-DA). New tokens pass MG-DA tests, including full‑text collision and Reserved‑Names checks.
6. LEX‑CC‑6 (Service, acceptance, and evidence). Service or access wording establishes neither Work nor acceptance. An acceptance claim names the selected criterion episteme, any separately admitted evaluation or acceptance Work that applied it, the returned value or result episteme, and the exact acceptance predicate with its participants under their direct owners; delivery Work, evidence, or a positive display proves none by itself. Evidence use is a relation over an Episteme, target claim or use, scope, polarity, time, and provenance named by the direct governing pattern.
7. LEX‑CC‑7 (USM compatibility). For each LexicalAct, USM.Scope ∈ AllowedScopes(LEX.TokenClass).
8. LEX-CC-8 (Naming discipline). If overload cleanup yields one local replacement phrase, the text records the repaired phrase and the governing local repair pattern. If cleanup yields one durable reusable name, the text first records the applicable F.8 decision for the already governed value, then completes an F.18 NameCard; public, Core-facing, durable, or cross-context publication also supplies the F.17 term row. Intuition-first labels, partial NameCards, and naming acts that substitute for value or kind admission are non-conformant.

#Worked micro‑examples (short, cross‑domain)

Factory. ✗ “The process failed; the service restarted itself.” ✓ The compact strings PLC_17#ObserverRole:PipelineOps, CAB_Chair#ApproverRole:ChangeControl, and OpsBot#DeployerRole:CD_Pipeline_v7 remain source cues only; they are not assignment occurrences or complete performer claims. In each following attribution, the named admitted U.System is HolderSystemSlot of the named exact obtaining assignment; the source suffix remains separate. PLC_17 : U.System performed ObservationLoggingWork_4711 : U.Work under exact obtaining PLCObserverAssignment_4711 : U.RoleAssignment (performedUnderAssignment(ObservationLoggingWork_4711, PLCObserverAssignment_4711)). That assignment names ObserverRole, PipelineOpsRoles-v1, and PipelineOps-Scheme-A; the log episteme separately records the observations, and source PipelineOps is recovered separately. ChangeControlBoardSystem : U.System performed ApproveRestartWork_4711 : U.Work under exact obtaining CABApproverAssignment_4711 : U.RoleAssignment; that assignment names ApproverRole, ChangeControlRoles-v1, and ChangeControl-Scheme-A, while source title CAB_Chair remains outside its holder slot. The approval speech-act content remains separately governed. OpsBot : U.System performed RestartRun_4711 : U.Work under exact obtaining OpsBotDeployerAssignment_4711 : U.RoleAssignment; that assignment names DeployerRole, CDRoles-v7, and CD-Scheme-v7, while source CD_Pipeline_v7 remains separate. The fulfillment claim against CoolingUtilityPromiseContent is another relation, not part of Work identity.

Cloud. ✗ “The process owner approved; the API service deployed.” ✓ The source strings ProductLead#AuthorizerRole:Rollout_2025 and sCG‑Spec_ci_bot#DeployerRole:CD_Pipeline_v7 remain cues only. In each following attribution, the named admitted U.System is HolderSystemSlot of the named exact obtaining assignment; the source title or context suffix remains separate. ProductLeadershipSystem : U.System performed RolloutApprovalWork_F123 : U.Work under exact obtaining RolloutAuthorizerAssignment_F123 : U.RoleAssignment; that assignment names AuthorizerRole, RolloutRoles-2025, and Rollout-Scheme-2025, while source ProductLead and Rollout_2025 remain separate. sCGSpecCIBot : U.System performed DeployWork_F123 : U.Work under exact obtaining DeploymentAssignment_F123 : U.RoleAssignment (performedUnderAssignment(DeployWork_F123, DeploymentAssignment_F123)); that assignment names DeployerRole, CDRoles-v7, and CD-Scheme-v7, while source CD_Pipeline_v7 remains separate. RESTAccessMethod : U.Method names the exact API access method; RESTAccessDescription is U.MethodDescription only if its claim content substantively describes that method as its exact EntityOfConcern, and it is an access Spec only after the named specification-use gate. Any selected description edition is reached through a separate governed U.EpistemeRef, while file or carrier version remains separate. FeatureAccessPromiseContent states the acceptance condition; telemetry measurements provide evidence for the evaluation that the deployment fulfilled that promise content.

Research. ✗ “Dataset X proves the theory; the process is reproducible.” ✓ DatasetX is used in an evidence relation for claim C with model-fit scope, polarity, time, and provenance named by A.10, B.3, G.6, F.10, or the direct governing pattern; replication is recorded through evidence-use, source-use, status-use, or reproducibility-status relations named by the direct governing pattern; procedure wording first recovers one exact U.Method; a separately identified claim-bearing episteme is U.MethodDescription only when that method is its exact EntityOfConcern and its claims pass A.3.2, while re-runs are exact Work occurrences only on the A.15.1 basis.

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, recover its governed value, record the applicable F.8 decision, and then use F.18 plus F.17 when public publication is current; otherwise retain the source expression or local phrase explicitly rather than flattening both interpretations into one umbrella rewrite.

Editorial note. This section inherits section 7 MG-DA (anchored head nouns; enumeration direct-owner gate; U.Characteristic and CharacteristicSpace only when one exact named Characteristic has that enumeration as its declared CSLC scale; collision checks) and section 8 LEX.Morph (suffix, prefix, and casing). It deliberately omits their details to avoid duplication. The only admitted uses of plane in the Core are CHR:ReferencePlane and the derived operators CL^plane and Phi_plane; policy flags do not introduce new planes. To distinguish pre-operational and operational states within ReferencePlane=world, use WorldRegime in {prep | live} (formerly PlaneRegime).

#Guarded-head cross-reference (normative lexical caution)

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

If cleanup reveals that no admissible existing token can carry the needed meaning, use the local repair pattern for one-off wording. If the change needs one durable reusable name, first recover the governed value and record the applicable F.8 decision, then use F.18 for the NameCard and F.17 when public, Core-facing, durable, or cross-context publication is current. Do not invent an ad hoc synonym or let naming settle an unresolved object.

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

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

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

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

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

0.1 Name the Context card you’re writing in (title, edition, scope note). 0.2 For every new or renamed token, declare LEX.TokenClass ∈ {KernelToken, ContextToken, DiscriminatorToken}. 0.3 Apply the MG-DA pre-check (anchored head noun; no metaphor heads; if an enumeration is current, name its closed value set, classified kind, and direct owner; declare a CharacteristicSpace only when the enumeration is the declared CSLC scale of one exact named U.Characteristic). 0.4 Perform collision and uniqueness checking: full-text grep plus Reserved-Names registry (see § 7). If collides -> rename or DRR deprecate.

#Pass 1 — Harvest in the Context

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

#Pass 2 — Recover Core anchors (not substitution)

Pass 2 is not a lexical replacement table. For each underlined word or phrase, first write one Plain-register sentence saying what the text is trying to assert or ask. Select the applicable E.10:0.0a branch when the use is relation-like; otherwise name the concrete governed object, direct owner, admissible use, and scope. Compare the same selected object and owner before and after repair, then choose one disposition: keep with a guarded-head note, split into several kinds named by value, rewrite locally, record a durable naming case under F.18, apply the governing pattern, or leave blocking. A replacement phrase is admissible only when the selected branch or other governed object remains recoverable and the repair introduces no umbrella flattening, semantic narrowing, accidental widening, declaration-participant collapse, representation-as-obtaining, or slot-as-kind substitution.

2.1 Recover underlined words through § 9 L‑rules table:  • recipe -> the exact U.Method when the wording denotes one way of doing; U.MethodDescription only for a separately identified claim-bearing episteme whose exact EntityOfConcern is that admitted method and whose claims pass A.3.2; otherwise a C.29 representation, publication form, source wording, or ordinary wording under its direct owner  • planned work window or dated occurrence -> a planning cue, schedule representation, or PlanItem content until one exact episteme passes A.15.2's present-EntityOfConcern, horizon, PlanItem, and substantive-coordination predicate; only then U.WorkPlan. A dated performed individual is independently admitted as a Work occurrence under U.Work only on the A.15.1 basis  • promise -> U.PromiseContent  • ability -> U.Capability  • actor or doer wording -> the admitted U.System that acts. When exact performed Work is current, also recover one dated W : U.Work, one exact obtaining RA : U.RoleAssignment with that System as RA.HolderSystemSlot, and F.6 performedUnderAssignment(W, RA); use ...Role only when the role value is being named and U.RoleAssignment only when the work-facing assignment relation is being named  • document or evidence-bearing publication cue → Episteme used in an evidence-use, source-use, status-use, constraint, commitment, gate, or publication-use relation named by the direct governing pattern 2.2 Apply LEX.Morph (§ 8): suffix gates such as ...Role, ...Work, MethodDescription, service-description episteme, service-access publication, or service-offer record labels, casing, and reserved prefixes. 2.3 Pass EntityOfConcern and Description-episteme boundary and specification-use check: name the EntityOfConcern directly; do not type a recipe, procedure, code expression, diagram, ETL label, document form, or relation-structure description as U.MethodDescription by appearance. Admit only a claim-bearing episteme whose exact EntityOfConcern is one admitted U.Method and whose claims pass A.3.2; use Spec only where a named specification-granting gate is present. Recover actual performed facts as independently obtaining relations involving a Work occurrence, and keep run records as separate epistemes. 2.4 Attach Context tags on first use; set twin labels (Tech and Plain) in the local Glossary. 2.5 Record one local KindRestorationCheck for every changed FPF-governed phrase; keep it with the bounded repair result rather than creating a second ledger:

• Situation: quote the sentence and say in ordinary words why the phrase matters to its reader.
• Action: write the intended sentence and select one E.10:0.0a branch, another concrete governed object, or explicit ordinary/quoted non-use.
• Before/after: name the governed object, claim, direct owner, admissible use, and scope on both sides; add only the distinctions required by the selected branch.
• Visible result and stop: give the accepted wording, direct governing-pattern result, or exact blocker, plus the nearby case that must not be read into it. Stop when that result lets the reader return to the domain task.

Mark the disposition preserved, split, intentionally changed, or blocker. A changed phrase without this check remains an unresolved lexical finding. Cite the direct governing pattern for any current relation, declaration, representation, role, method, work, evidence, assurance, gate, or decision use; E.10 detects the wording problem and does not replace that ontology.

#Pass 3 — Stitch and publish

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

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

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

1. Context prompt. Is each potentially polysemous noun interpreted inside a named U.BoundedContext?
2. EntityOfConcern and Description-episteme boundary and specification-use prompt. Does each sentence use the correct boundary (the EntityOfConcern named directly; Description-episteme use for descriptions; specification use only where a direct gate pattern grants it; run: actuals)?
3. Token prompt. For new or renamed tokens, is LEX.TokenClass declared and consistent with where the token appears?
4. Head-kind prompt. Does the head noun name what kind of thing the phrase is actually about: Role, Method, Work, Context, Characteristic, Capability, constraint claim, commitment, publication form, service-access relation, service-offer record, interpretation, U.Transformation, TransformationFlowStructure, or authority use? A narrowing qualifier alone does not answer this question.
5. Qualifier-claim prompt. If an adjective, participle, genitive, or comparative modifier carries a claim being made, comparison criterion, relation, or admissible-use boundary, has that use been restored explicitly rather than left inside the modifier alone?
6. Direct relation, declaration, designation, and representation prompt. Can a reader select exactly one E.10:0.0a branch from the sentence and point to its visible result? If yes, name that branch's direct owner and preserve only the objects named by that branch. If no branch fits, state the other governed object or ordinary non-use. If the sentence still mixes branches or only lists possible owners, rewrite it before applying E.10.ARCH or the direct governing pattern.
7. Support interpretation prompt. If support, supported, supporting, or a support-headed compound appears, first keep it unchanged when it is ordinary or quoted wording and no FPF claim relies on it. Otherwise ask whether it already states a direct subject-domain fact. If so, name the things and relation and go to that relation's owner; use A.6.P only when the predicate or a participant is unclear, and A.6.RCD only when both are clear but no owner exists. If it is not a direct subject relation, choose the matching common alternative in E.10:0.2, write the concrete sentence, and go straight to that alternative's owner. Thus Test T supports claim C reaches A.10, Index I supports readers can remain bounded reader help, and Column C supports roof R reaches a structural relation or a missing-governor result; none is forced into another bucket. For base, anchor, or basedness, apply A.6.6 and state dependent, base, baseRelation, scope, applicable Γ_time, witnesses, admissibleUse, and nonAdmissibleUse. Do not mint SupportRelation or ask A.6.P to choose among the common alternatives.
8. Comparison-basis prompt. If the sentence compares, ranks, escalates, or downgrades something, is the comparison basis ontologically homogeneous after head-kind and qualifier restoration?
9. Morphology prompt. Do suffix, prefix, and casing pass LEX.Morph gates (e.g., …Role, MethodDescription, Work)?
10. Promise, ability, access, and performance split. Are service promise or acceptance content, service-access relation, Capability (ability), and Work (performance) distinct and governed by direct patterns?
11. Plan and execution split. Are a planning cue or admitted U.WorkPlan kept separate from one exact Work individual admitted under U.Work, each admitted performer U.System, each exact obtaining covering RA : U.RoleAssignment, any explicit F.6 performedUnderAssignment(W, RA) attribution, and the independently obtaining method, temporal, containing-system, affected-referent, binding, and resource-use relations, plus any separate assertion or description episteme that states them?
12. Evidence prompt. Do documents, epistemes, and publications stay in source-use, evidence-use, specification-use, or publication-use relations? When performed work is current, is the actor an admitted U.System, and are exact W : U.Work, exact obtaining RA : U.RoleAssignment, and performedUnderAssignment(W, RA) or S performed W under RA recoverable?
13. Bridge prompt. If sameness spans Contexts, is there an explicit Bridge with CL and loss notes?
14. Collision prompt. Were full-text and Reserved-Names checks completed, with no other meaning of this token anywhere in FPF?
15. Naming-procedure prompt. If one durable reusable name is needed because no admissible existing token carries the needed meaning beyond one local repair, was the governed value settled first, was the applicable F.8 decision recorded, and were the F.18 NameCard and any required F.17 public term row completed rather than picking a label by intuition or filling publication apparatus around an unresolved object?
16. Value-substitution prompt. After the repair, can the declared reader still see the remaining admissible reader use, and did the repair preserve usability, affordability, semantic composability, governing-pattern fit, and local action guidance? If not, narrow the repair, keep ordinary wording with a recovery note with recovered kind and use, or leave the issue blocking instead of optimizing for lexical purity.

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

#Archetypal Grounding - three worked micro-examples - E.10 across domains (informative)

#Healthcare (OR context)

Messy: “The surgical process is scheduled at 08:00; the SOP approves the incision and the service documents recovery.” E.10-clean rewrite: "OR_Case_221_WorkPlan is used as U.WorkPlan only after A.15.2 membership is established: its already identified present EntityOfConcern is Patient_221, its horizon is the bounded surgical-planning interval, and Incision_221 : PlanItem substantively coordinates the intended surgeon-role condition, operating-room resource reservation, planned start of 08:00, IncisionMethod : U.Method, and the incision-readiness target. It cites IncisionMethodDescription, a separately identified claim-bearing episteme. That episteme is U.MethodDescription only because the method is its exact EntityOfConcern and its claims substantively describe how the method is carried out. Any exact edition needed by the plan is selected through a separate governed U.EpistemeRef; carrier version remains separate. SOP_OR_v4 is used as a specification-use episteme for the incision-readiness constraint; it does not approve the incision. Source title QA_Officer does not identify the performer. ORApprovalAssignment_221 : U.RoleAssignment obtains with QAApprovalSystem : U.System as holder, ApproverRole, ORRoles-v4, and OR-RoleScheme-v4; ApprovalSpeechActWork_221 : U.Work is one exact dated occurrence, and QAApprovalSystem performed ApprovalSpeechActWork_221 under ORApprovalAssignment_221 through F.6. The approval speech-act content and resulting GateDecision are separately governed, and that decision admits the planned run. PostOpMonitoringPromiseContent states the promised monitoring and its vitals acceptance envelope. WardAccessMethod : U.Method names the exact access method; WardProtocol is U.MethodDescription only if it is a separately identified claim-bearing episteme about that method and passes A.3.2, while its publication form and carrier remain separate."

#Manufacturing (assembly line)

Messy: “The welding function provides air‑tight seams; the process costs 3 min.” E.10-clean rewrite: “Robot_SN789 has Capability ‘execute Weld_MIG_v3 within envelope E at measures M’. For one run, WeldAssignment_SN789_4711 : U.RoleAssignment obtains with Robot_SN789 : U.System as holder, WelderRole, WeldingRoles-v3, and WeldingCell-Scheme-A; WeldWork_SN789_4711 : U.Work is one exact dated occurrence, and Robot_SN789 performed WeldWork_SN789_4711 under WeldAssignment_SN789_4711 through F.6. For any later run, identify its exact Work occurrence and the exact assignment obtaining over that occurrence before making the same attribution. Each such Work occurrence enacts Weld_MIG_v3 and has the workpiece joint as its affected referent. Each actual bounded change of that joint must first be identified independently under A.3.4 at the resolution and boundary required by the receiving use. Exact direct work-to-change facts may then relate the Work to those already identified transformations; neither the Work, method enactment, nor that relation supplies transformation identity, and none by itself establishes a new seam entity. If the receiving use claims that one distinct seam entity was first constituted, A.15.PROD must recover its exact identity-specification basis and inception boundary. Separate measurement-result epistemes record seam-characteristic and duration values: the acceptance evaluation compares the seam values with the bounds published in Seal_Acceptance.md, while duration measurements are used under their direct evidence relation for the three-minute-average claim. Recover source WeldingCellContext separately. Any assignment interval is described outside the four participant designations.”

#Cloud and SRE (production Context)

Messy: “The storage service wrote logs and the deployment process failed after 2 min.” E.10-clean rewrite: “Source string sCG‑Spec_ci_bot#DeployerRole:CD_v7 is a recovery cue, not a performer or assignment. DeployAssignment_r4711 : U.RoleAssignment obtains with sCGSpecCIBot : U.System as holder, DeployerRole, CDRoles-v7, and CD-Scheme-v7; DeployWork_r4711 : U.Work is one exact dated occurrence, and sCGSpecCIBot performed DeployWork_r4711 under DeployAssignment_r4711 through F.6. That Work failed at T+120 s. Recover source CD_v7 separately. ObjectStoragePromiseContent states durability and availability targets; S3_API_Spec_vX describes the access method. LogWriterAssignment_r4711 : U.RoleAssignment obtains with LogWriterSystem : U.System as holder, TransformerRole, LoggingRoles-v2, and Logging-Scheme-A; recover source LoggingContext separately. LogWritingWork_r4711 : U.Work is one exact dated occurrence, and LogWriterSystem performed LogWritingWork_r4711 under LogWriterAssignment_r4711 through F.6, while the service promise did not act.”

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: FPF-governed wording-use repair; ordinary ungoverned language remains outside this pattern.

#Conformance Checklist

Use this checklist for the accepted wording span, not for the whole corpus by reflex.

1. Bounded span named. The exact sentence, row, section, pattern, or project text under repair is recoverable.
2. Trigger and use separated. The trigger word is identified, and the FPF-governed use carried by that word is stated separately from the word itself.
3. Plain result and direct owner recovered. The repaired wording states the ordinary sentence or action first, selects one E.10:0.0a branch when the use is relation-like, and names that result's direct owner and admissible use. A different governed object, source-use relation, explicit non-use, or blocker is named instead when no branch applies.
4. Governing pattern selected. If the issue is no longer lexical, the direct governing pattern or precision-restoration realization pattern is named by value.
5. The four relation-like branches remain distinct. An obtaining world-side relation is not its reusable declaration, a report that claims it, or a field, table, graph, or formula that represents it. A declaration position, participant designation, label, or representation place creates no actual participant, obtaining relation, or new U-kind by itself.
6. Math lens kept separate from ontology. Graphs, tuples, algebras, spaces, mappings, and similar mathematical expressions are used as mathematical lenses only when that is the current claim.
7. Final wording closes the local wording-use case. The result is accepted wording, direct governing-pattern use, controlled precision reduction, quote-only use, reduced-use cue, blocked use, incomplete rewrite, ordinary prose, or not-triggered disposition.
8. No umbrella replacement. The repair does not replace one broad head with another broad head such as basis, support, route, path, status, record, object, role, method, mechanism, flow, or structure without the recovered object and relation.
9. Reader use remains visible. The user can still see what to do next with the project object, relation, source, evidence, publication, method, work, architecture, characteristic, or other EntityOfConcern that made the wording important.
10. Work/method boundary words close through a governor. input, raw material, source data, source material, output, result, outcome, deliverable, handoff, and work-name wording either retain an already exact direct pattern use or return one A.6.P.WMR exit. Classification, a generic result relation, method-description filling, or a designation that merely type-checks against an A.6.5 SlotSpec is not closure.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• Wording repair becomes ontology-first precision restoration rather than taste-based editing.
• New names, field names, and pattern prose stay composable with FPF kinds, slot discipline, and named governing patterns.
• FPF can admit ordinary prose, source quotations, and local names without letting them become hidden ontology.

Costs:

• A quick lexical replacement often becomes a short ontological check.
• Some attractive phrases remain blocked until the governing pattern, relation, bearer, value set, or admissible use is named.
• Broad source wording sometimes needs a precision-restoration pattern rather than a one-word replacement.

#Rationale

Wording mistakes in FPF usually matter because they hide an ontology choice; an obtaining direct-relation claim and its actual participants; a declaration-local A.6.5 SlotSpec; an assertion-side participant designation; a C.29 representation correspondence; a source-use relation; an admissible-use boundary; or a direct governing-pattern application. A synonym replacement can make the sentence smoother while changing the claim. E.10 therefore starts with a cheap trigger scan and then returns the work to the smallest pattern that can govern the recovered object.

The pattern stays deliberately limited. It is not the ontology for evidence, assurance, work, gate, decision, publication, architecture, characteristic, temporal, role, method, mathematical-lens, or source-use claims. It only prevents wording from smuggling those claims in under broad heads. Once the recovered object or relation is visible, the direct governing pattern carries the substantive decision.

The conformance prompts are bounded so lexical governance does not become a corpus-wide purity ritual. A local repair should restore composability, reader action, and admissible use; when it cannot do that, the honest result is quote-only use, reduced-use cue, blocked use, or an incomplete rewrite rather than a more polished umbrella word.

#SoTA-Echoing - lexical governance

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

The practical result is simple: lexical governance improves action guidance and semantic composability instead of becoming language-police work. A SoTA row that does not change a rewrite, an inadmissible shortcut, a governing-pattern application, a conformance prompt, or a reopen cue remains decorative and does not carry E.10. Reopen these source-use decisions when a named FPF precision-restoration pattern changes its kind or authority boundary, stronger language-scent evidence overturns the usefulness of in-situ cues, or a reference practice no longer supports the publication or discoverability use assigned to it.

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

Re-review your prose when any of these happen:

• Context edition changes → re-affirm twin labels, Bridges, and acceptance wording.
• A role or kind name grows (“and”, “plus”, or “--”) -> apply MG-DA: split or bundle (A.2).
• A slash, and, plus, &, or similar grouping mark appears in FPF-governed wording -> classify the span before editing the mark. The trigger is the FPF-governed grouping use, not the character itself: LLM output, review text, intake notes, or draft prose often uses a slash as an unresolved alternative, an untyped bundle, or an attempt to point at a hidden kind. If the grouped words are claim-bearing heads, relation heads, kind candidates, an unresolved alternative, or an attempt to point at a hidden kind, apply MG-DA, A.6.P, or the selected restoration pattern: split, bundle, or recover the relation named by value and admissible use. If the mark is part of accepted notation or a conventional designation such as a source name, discipline abbreviation, established compound name, formula, ratio, fraction, unit, path-like quoted source token, title, product name, or URL, keep the notation and classify its use; do not rewrite 1/2 or similar conventional forms merely to remove the mark.
• A “service” statement broadens scope → use L-SERV and A.6.P:4.11a to recover the exact hidden subject, relation, and receiving use. Update only the claim whose direct owner says it changed; do not apply a fixed reading list or rewrite every nearby service-related claim.
• Recipes gain or lose steps -> first recover the exact U.Method, the claim-bearing episteme, and the changed claim. Update U.MethodDescription only when that episteme has the method as its exact EntityOfConcern and passes A.3.2; a code, diagram, recipe, procedure, or document-form change remains under its representation or publication owner unless claim content actually changes. Never move the change into service labels or Role names.
• Evidence verbs creep into actor sentences → re-apply L-rules (documents do not act).
• A generic head or support-headed compound acquires an FPF claim or admissible use (comparative, safe, interactive, reliable, support, supported, supporting, support-looking, and similar modifiers or heads) → restore the head kind first; then decide whether support states a direct subject relation or one of the common lexical alternatives, and route it as E.10:0.2 requires before broader publication.
• Method, practice, technique, algorithm, program, proof, solver, workflow, process, procedure, access path, query plan, control-strategy, method-algebra, method-graph, or selector-calculus wording changes -> recover the governed method-side object or direct relation before rewriting: U.Method, MethodRelationStructure@BoundedContext, U.MethodDescription, formal-substrate declaration, C.29 mathematical-lens use and correspondence, U.Mechanism, U.WorkPlan, one dated Work occurrence admitted under U.Work, a separate episteme about it, role assignment or role relation, bounded context, discipline or cultural-evolution source label, method-family registry or selector outcome, evidence relation, or quote-only source wording. Do not replace one umbrella with another.
• A declarative representation starts to sound imperative (graph path, path slice, evidence-path wording, query, predicate, table, dashboard, publication face, mathematical representation, method-description representation, source-chain relation, carrier path, or FPF pattern relation "runs", "routes", "calls", "dispatches", "authorizes", or "flows" without a recovered kind) → apply C.2.P.DR or the direct governing pattern such as E.18, A.10, A.19.SPR, E.17, C.29, A.3.1, A.3.2, A.15.2, A.15.1, E.8, or F.19.
• New token minted → ensure LEX.TokenClass is declared and perform collision checks. If an enumeration is current, name its closed value set, classified kind, and direct owner; add a CharacteristicSpace only when the enumeration is the declared CSLC scale of one exact named U.Characteristic.
• Suffix drift (e.g., …Work on a plan) → fix via LEX.Morph.
• Cross-Context reuse by label appears -> use 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, settle the governed value, record the applicable F.8 decision, and use F.18 plus an F.17 row when public publication is current.

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

Say it cleanly, once (memorise): Role = role value - RoleAssignment = assignment relation - Method = one admitted way of doing - MethodDescription = one claim-bearing episteme about that exact method with at least one substantive way-of-doing claim - U.Work = admitted kind - one Work individual = one world-side dated occurrence admitted under it - work assertion, description, log, or record = a separate U.Episteme; occurrence facts obtain through their direct relations Capability = can-do within bounds (envelope + measures) - service or access wording = recover the exact subject or relation through L-SERV and A.6.P:4.11a, then use its direct owner; no default service bundle EntityOfConcern and Description-episteme boundary separates the EntityOfConcern from Description epistemes; specification use is a gated use of a Description episteme; publication faces, forms, units, and carriers do not act; meaning use is interpreted within named Contexts; Bridge records state cross-context correspondence, direction, loss, and scope.

Name forms (allowed morphology):

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

#Closing notes (governance and purity)

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

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

#Relations

• Builds on: A.7, C.2.1, E.17, E.24, A.6.0, A.6.5, F.18, and F.19 for EntityOfConcern discipline, description and publication separation, ontic discipline, slot discipline, naming, and phrase-level repair.
• Coordinates with precision-restoration patterns: E.10.ARCH, A.6.P, A.6.P.WMR, A.6.RCD, C.2.P, A.19.SPR, E.10.MOVE, and the direct domain restoration pattern selected by the current trigger; A.15.PROD governs local production-work, entity-inception, and production-completion claims when that exit is current.
• Coordinates with governing patterns for governed objects: architecture, transformation, work, evidence, assurance, gate, publication, source-use, mathematical-lens, characteristic, temporal, role, method, and relation patterns when those claims are current.
• Returns to: the direct governing pattern whenever the issue is no longer wording-use precision but an object, relation, evidence, authority, work, publication, or admissible-use claim.

#E.10:End

Last Updated: 2026-08-05 — upstream FPF commit 3dbce514 (github.com/ailev/FPF)