#Unified Lexical Rules for FPF

E.10 · Stable · Part E lexical-governance pattern · Definitional pattern; normative for text that claims FPF-governed wording use. · 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 — Recovering What “Context” Means in Use, 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, E.10.LRN for recovery from claim-bearing learn/learning/learned/taught/trained wording, E.10.ROLE for recovery from bare claim-bearing role, 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, the patterns that define, constrain, or test the recovered claim, 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 SystemRoleKindDescription Labels. Coordinates with. E.10.D1 for action-changing uses of context; E.10.ROLE, A.2, and A.2.1 for system-role kinds and assignments; A.15 and F.6 for Method, Work, and performed-Work attribution; A.10 for evidence use; B.1 and B.3 for Γ‑algebras and assurance; and F.17 with F.9 for source-local meaning and 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 the FPF pattern that supplies the applicable rule 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 the FPF pattern that supplies the applicable rule 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 the practitioner uses the smallest applicable pattern to recover the 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 subject-defined boundary makes it meaningful—for example, a scheme, scope, situation, or use—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 identifies an applicable precision-restoration pattern or another named pattern, apply that pattern instead of inventing a synonym. If the repaired wording becomes a durable reusable head, apply F.18 after the selected branch has recovered the kind and use. Cite a neighboring FPF pattern only after the EntityOfConcern, relation, claim, admissible use, project-side reference, or non-use is recoverable, and say what that pattern contributes: a definition, constraint, test, method, or lookup.

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 result obtained by applying the selected rule, 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 to supply the domain rule for the recovered claim. If the use under repair is evidence, assurance, work, gate, decision, causal use, publication, relation precision, or epistemic precision, use the FPF pattern for that claim and state the rule, result, or test it contributes; 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: one applicable repair-path classification from this closed value set—ordinary no FPF-governed use, local head repair, register repair, morphology repair, context-word recovery through E.10.D1, learning-word recovery through E.10.LRN, bare-role meaning recovery through E.10.ROLE, 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 result returned by the selected repair or pattern, 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 defines or constrains 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 applicable representation pattern. 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 object and—when needed—the pattern that defines, constrains, or tests it, 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 subject patterns.

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 whether the candidate basis is ready for use, not about an accountable undertaking. Use the ordinary E.11 contribution and write: Use E.11 to identify the candidate-basis information needed for this use; provide it before relying on the candidate. This states the practical action, retains an ordinary PatternID citation, creates no general Requirement object, and closes the E.10 use. Stop and continue with the candidate-pattern-use question.

Identity-sensitive replay, only when needed. If a named later use must reproduce or compare the exact public-template position or its completeness rule, name that later use and the live alternative first; then record the exact E.11 template reference and, when that rule identity is needed, CandidatePatternUseBasisCompletenessCondition@FPFReadme. Reopen the ordinary wording only if the E.11 contribution it uses changes 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?, patternRef?, and finalWordingOrBlocker; add patternRef only when pattern identity changes the result. Add an exact assertion, predicate, or ClaimGraph only when the current claim or a named later use depends on that identity. Otherwise name the concrete object and the ordinary claim. 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 claim boundary. Add a new recurring wording family to E.10 only when it recurs 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 relevant pattern for relation, episteme, publication, source-use, naming, or quality-word claims.

#Scope split

E.10 applies to lexical conformance in 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 tests or rules from E.10, A.6.P, A.6.6, F.18, or another relevant pattern, 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.

Use E.10 to recognize which wording-use problem the sentence raises and to select the first applicable closure disposition. The E.10 text does not 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, already-known-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, direct, current, subject, owner, defining, or a similar qualifier modifies an FPF pattern, kind, relation, record, object, field, use, claim, gate, or source, name the live alternative it distinguishes and write the ordinary identity claim. For relation-like wording, select the applicable E.10:0.0a branch. Add a pattern reference, source-use relation, claim kind, value set, scope, assertion, predicate, or ClaimGraph only when omitting it would change truth, action, stop, publication, reuse, or reliance. An ordinary PatternID citation does not require that formal expansion. 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;
• applicable FPF pattern used 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 rule.

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. If a relevant pattern is known, state the definition, constraint, or test it contributes. 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 concrete 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, selected source U.Episteme, EpistemePublicationRelation occurrence or reference when availability is material, publication form, publication face, carrier relation, source-ref target, source-currentness relation, source-bearing relation, project-side FPF kind and reference, declared-use boundary, or explicit non-use is current; which entity is used now; which source-to-use, transformation, rendering, or other relation carries it forward; which use is admissible; and which claim must be reconsidered if the use becomes stronger. Name an exact assertion or ClaimGraph only when return, comparison, publication, or reuse depends on that identity. A source-ref marker alone is not a repair result: if its target kind or a declaration-local SlotSpec is needed but not recoverable, close as source-finding, quote-only, reduced-use, or blocked use. If the answer is hidden, use C.2.P, A.6.3.CSC, E.17, A.10, or the pattern that defines the needed rule 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, selected source U.Episteme, exact publication occurrence when availability is material, source-bearing relation, transform record, evidence relation, or exact defining ClaimGraph and a stronger use opens return to that named endpoint or reconsideration of the exact subject assertion under its predicate. 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 actual 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 FPF pattern for that claim.

function, functional, functionality, and effect are trigger wording when the FPF kind, relation, claim, view, or application of the pattern for that claim 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 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 relevant rule, or apply the rule for the already recovered kind, relation, claim-use, or source-use: C.30.LCA for control-layer relations, A.6.M for module-interface relations, C.30.TFS-REL for architecture-to-TransformationFlowStructure claims, E.18 for selected transformation-flow structure, C.16.P or C.29 for scale, coarse-graining, or mathematical use, C.2.P for publication or source use, and gate, work, 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 object, obtaining relation, reusable declaration, claim-bearing episteme, or representation correspondence is hidden. Recover the current EntityOfConcern, relation and participants, declaration, or representation and correspondence; then state the applicable pattern contribution only when it is needed, plus admissible use, blocked overread, and remaining reader use. 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 claim boundary. Specialized restoration patterns carry the detailed ontology when the problem is no longer lexical.

#Bounded complete result and already-known-pattern rule

The already-known-pattern rule is:

If the applicable 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 correspondence are already recoverable by value, use that pattern directly and state its concrete contribution.

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;
• pattern application when the FPF kind, relation, claim-use, source-use, 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 applicable-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. 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 patterns, less clear about the primary EntityOfConcern, relation, declaration, claim-bearing episteme, representation, 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 relevant 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 object under repair; any obtaining relation, receiver-needed occurrence, reusable declaration, claim-bearing episteme, or representation and correspondence that is current; the selected pattern contribution when needed; admissible use; non-admissible overread; and remaining reader use.

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

MG-DA cold-reader closure. A reader who has not read the DRR, campaign notes, or reviewer memory must still recover the object under repair and its FPF kind or ordinary non-FPF status, the relation or claim, any declaration or representation needed by the current use, the admissible reader use, the next practical action, and—when a stronger claim opens—the pattern that handles it. Broad heads such as object, item, value, relation, record, condition, basis, material, or specialization fail unless the sentence names the practitioner-recognizable object and use. A complete specialization phrase says what specializes what and which inherited or changed declarations or uses matter.

#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 pattern, direct application of a pattern whose contribution is already known, 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, direct application of a pattern whose contribution is known, 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 pattern whose rule supplies the recovered construction when that identity matters. A lexical resemblance does not transfer the claim 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 recovered construction and rescan the replacement wording. Close with ordinary prose only when no FPF-governed construction is being asserted.

RequirementWordingRecovery:
  GovernedTextSpan:
  BearerRef:
  BearerKindRef:
  ClaimOrRelationKindRef:
  PatternRef?:
  PracticalConsequenceDescriptionRef:
  ExactRecoveredConstructionRef:
  FinalWordingOrBlocker:

This is a temporary wording-restoration check, not a project record and not a Requirement ontology. Its positions take only the values needed by the recovered construction.

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 catch-all 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 the pattern that defines that record;
• 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;
• selected U.Episteme plus the exact EpistemePublicationRelation occurrence when availability to a declared audience for a bounded use is current;
• 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.

Recover the relation or use that makes something a source; common cases include a selected source U.Episteme, exact EpistemePublicationRelation occurrence or reference when availability is material, publication form or carrier when either is the source object, 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, exact source edition, source-local meaning under an effective scheme, source frame only when its defining pattern 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.

Recover the relation or use that makes something a target; common cases include an EntityOfConcern, target U.Episteme, review target, FPF rule being applied, project target, work target, target publication form, project-side FPF kind and reference named by value, target frame, target-side situation or model-use boundary only when its defining rule is current, 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. U.PresentationCarrier is the publication-side carrier kind used under E.17 and E.24.PUB; ordinary carrier wording names the 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, name that exact carrier or relation.

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. For physical raw material, name the relevant constituent, affected-referent, resource-use, supply, transfer, or transformation relation and use the pattern that defines it.

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 subject pattern or relation declaration; only a genuinely absent predicate, condition, or defining pattern or declaration names the affected receiving use and future subject pattern or relation declaration. 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 identified 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 defining rule are named by value. Retain ordinary input, output, result, outcome, or deliverable only while the exact defining relation rule 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 the pattern that defines that candidate. Do not invent either one inside pattern prose or replace it with a universal kind or relation.

#record

Use record only when an FPF pattern or project practice defines 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 defining record rule 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.SystemRoleAssignment, or a status-register entry under its named status 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 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 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- or reliance-guiding appearance whose missing prerequisite is recovered under A.15.4.

Keep the ordinary example word only after the actual 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 after the claim is recovered: it may name an admitted system classified under an exact local OperatorSystemRole, a process or mathematical operator, an organizational or interface position, an ordinary title, or another direct relation; the word alone selects none;

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.

Keep owner as ordinary architectural, organizational, policy, source-maintenance, or stewardship wording when the sentence already makes the precise ownership or responsibility relation and its participants clear. Otherwise name that direct relation. Owner does not mean a system-role kind, U.SystemRoleAssignment, authority, or Work by default, and it is not a substitute for pattern, DRR, selected U.Episteme, exact EpistemePublicationRelation occurrence, publication form, publication unit, file carrier, or project record.

Split the actual claim into the smallest applicable value:

• exact architectural, organizational, policy, source-maintenance, stewardship, ownership, or responsibility relation and participants;
• relation to an FPF pattern or an authority-reference relation;
• named source set used as authority for the claim;
• file carrying FPF pattern text, file carrier, or publication unit;
• evidence record or evidence source;
• FPF pattern or project target;
• support root; or
• ordinary or quoted non-use when owner is only title-like wording; otherwise use the result selected through E.10.ROLE—for example, a local system-role kind and classification, a named U.SystemRoleAssignment occurrence, or another relation.

Never use owner to avoid deciding which of those claims the sentence makes.

#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 another 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 values defined or constrained separately are being used—for example an exact local system-role kind or U.SystemRoleAssignment occurrence, U.Method, U.WorkPlan, and actual U.Work.

#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, separate assertion or occurrence-description episteme about one exact U.SystemRoleAssignment, 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 defining rule 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 concrete pattern and what it contributes. 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: FPF pattern, pattern section, accepted DRR, FPF publication, FPF view, record kind with its defining rule, 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 the different 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 as its own assertion or representation rather than as the relation itself;
• if the sentence is not making one relation claim, unpack the wording and claim under repair into an 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 with a named kind and defining rule 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, repair the 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. Apply the rule that defines or constrains 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 defines or constrains 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, the separate evidence/identification/estimate/sampling/simulation components actually used, a C.28 support result, 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 selecting a predicate or pattern locator. Test T supports claim C becomes Test T is evidence for claim C; use A.10 for that evidence relation. 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 the pattern that defines that relation. If its relation or a participant is unclear, use A.6.P; if both are clear but no current pattern contains the defining content for the predicate, use A.6.RCD and return the established missing-governor result.

For a common alternative, use the applicable pattern 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 relevant 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 use A.6.P to choose one of these common lexical alternatives 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 the specific object under the pattern that defines the recovered claim: 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 defines the basedness construction 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 already requires an F.18 naming decision 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 defines or constrains that predicate.

#Applying patterns versus procedural calls

FPF patterns provide reusable guidance for recognizable problem situations. In ordinary prose, apply pattern P is acceptable metonymy for a person or system using the method, rule, test, constraint, or lookup described by P; the pattern itself does not perform the project action.

Ordinary application. Name the recognizable problem, state the concrete contribution taken from the pattern, and state the resulting user action or judgement. An ordinary PatternID citation is enough when the reader only needs to find that contribution. Do not require an ontology, conformance claim or section, exact assertion, ClaimGraph, or formal application record merely to use the guidance.

Identity-sensitive application. Open this branch only when a named live alternative or receiving use changes truth, action, stop, interpretation, migration, publication, reuse, or reliance. Name that dependency first, then add only the identity it needs: for example, the exact pattern edition, ontology, conformance claim or section, governed object, claim-bearing episteme, obtaining relation and participants, current declaration, or representation and correspondence.

Use apply pattern, use the pattern guidance, the pattern applies to this problem situation, or the case falls under this pattern for the ordinary FPF-side use. These expressions do not assert that the pattern acts.

Do not leave project action as final wording when it hides a distinction that changes the current claim or use. For ordinary project-side activity, say plainly who does what and what result or judgement follows. When a current claim or receiving use depends on formal classification, choose exactly one applicable kind or relation: 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.

Keep route, path, branch, handoff, trajectory, move, or flow as ordinary navigation wording when no FPF movement, control, or temporal claim depends on it. When such a claim is current, name the relevant movement, control, and temporal relations and use the pattern that defines them.

#FPF-side and project-side epistemes and publications

Semioarchitecture often talks about two different groups of epistemes, publications, records, and uses:

• FPF-side material: 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 material: 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 sides 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 side 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 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 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 value under the pattern that defines it. 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; local system-role-kind classification under A.2; U.SystemRoleAssignment occurrences under A.2.1; Method under A.3; planned work and WorkPlan under A.15.2; dated Work occurrences under A.15.1; actual launch or performed values under obtaining direct relations or A.6.1 bindings; separate performed-work, finalization, result, telemetry, and gate records under the patterns that define them; 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 performed work goes to F.18 only after A.13 and A.15.1 independently admit the Work occurrence from its actual performer basis, time, Method, and containing System. If the reusable account also needs precise assignment-bound attribution, establish F.6 afterward through the same obtaining assignment. Keep the affected referent, application bindings, resource use, and other direct facts separately recoverable. Add a continuity policy only when occurrence identity matters. Keep production, measurement, evaluation, delivery, acceptance, and downstream-effect claims under their direct patterns.

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, separate 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 the FPF rule actually applied, or relation to an accepted DRR.

#basis, context, scope, frame

These words can hide different subject questions; they do not name one common kind.

• For basis, name the source or direct relation actually used by the sentence—for example, a decision, evidence, comparison, threshold, grounding, or admissibility relation.
• For context, apply E.10.D1 and recover the subject-defined content that changes the action—for example, a scheme, scope, model-use structure, situation, design-time or run-time referent, architecture, environment, domain subject, or local-practice use.
• For scope, use A.2.6 when an actual claim scope and its slice-membership facts are current; otherwise use the subject pattern for the stated extent or boundary.
• For frame, say what the word refers to—for example, a viewpoint, reference frame, comparison frame, state frame, or ordinary narrative framing.

If a basis changes what may be done, state the admissible use. State a relation claim or project-side FPF reference only when the sentence actually makes that claim. If context hides the EntityOfConcern, recover that entity and the subject relation before any Bridge, parity, or identity claim.

#translation and multilingual heads

A bilingual alias is not a Bridge by itself and does not create equivalence, substitution, UTS admission, or a cross-local 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-local naming, a UTS row, a Core-facing term, or a reusable FPF head is intended.

#state, status, posture, readiness

E.10 only recognizes the wording problem; it does not duplicate the recovery procedure. If readiness or ready still hides which governed value is meant, use E.10.MOVE. It exits to A.19.SPR only for a hidden bearer and state frame, to A.2.5 for an assignment-state condition, to A.15.5 for work-entry readiness, to A.21 for a distinct gate decision, or to another direct pattern for the recovered claim.

For other state-family wording, use the direct pattern when the exact object and claim are already clear. Use A.19.SPR only while the object, state frame, or value remains hidden. Close with an ordinary statement of the recovered object and claim under that pattern; introduce a predicate only when the pattern defines or needs one. Otherwise keep ordinary prose, quote-only wording, a reduced-use cue, or a blocker.

#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 readiness or ready still hides which governed value is meant, use E.10.MOVE; use A.19.SPR only if that recovery leaves a hidden bearer and state frame. For source currentness, another state or status, publication-use disposition, quality result, admission state, campaign state, or process state, use C.2.P, E.9.DA, E.21, E.19, the release or process carrier, A.19.SPR while its object or state frame remains hidden, or the direct pattern for the recovered value.
• If it means a claim, question, use, or relation is currently asserted, relied on, or action-bearing in the described situation, keep the modifier only when the sentence also names the claim or claim-bearing episteme, obtaining relation or source/use relation, admissible use, and—when needed—the pattern that defines it, 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 governing rule; a temporal qualifier of a 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 FPF pattern for that stronger claim 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:

• the beneficiary System or reference required by the selected predicate; if source wording says role, apply E.10.ROLE and cite a local system-role kind and classification or an obtaining U.SystemRoleAssignment occurrence only when that permission or authority predicate actually uses it;
• 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 A.2.9 granting or delegating speech-act occurrence and, only when the current policy validly institutes one, the resulting A.2.8.PER GrantedPermissionRelation@Context. Keep the grantor System, any grantor U.SystemRoleAssignment occurrence used by the predicate, the beneficiary System or reference, policy and currentness basis, scope and window, and any separate on-behalf-of or Work relation distinct. The cue mints neither DelegatedPermissionRelation nor another generic delegation or authorization kind; if the pattern that defines the permission claim cannot be recovered, block operative use of the wording rather than naming a relation without a governor;
• 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 an 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 its own claim-bearing episteme or C.29 representation.

Split:

• review profile;
• review harness;
• source map;
• navigation index;
• registry record;
• catalog publication;
• benchmark harness;
• entry aid or discoverability aid;
• FPF 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;
• FPF pattern applicable to 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 patterns involved by value; if an actual relation between patterns is being claimed, name the exact direct relation, its actual pattern participants, and the pattern that defines it.

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 packet with its exact question, scope, and source set;
• 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 how E.21 or another named quality pattern is applied.

#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 relevant 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 selected U.Episteme, exact publication occurrence when availability is material, publication form, PublicationUnit, file, source note, and 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 what the sentence actually names: an FPF pattern; pattern section; accepted DRR; FPF publication; FPF view; document with a named source-basis, evidence-basis, architecture-basis, or review-basis relation or use; file carrier; review target; record kind and the pattern that defines it; obtaining relation and participants; receiver-needed relation occurrence; claim-bearing episteme; reusable A.6.5 declaration; or C.29 representation with 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: distinguish the FPF pattern or section that supplies the rule, 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 using the exact source or practice boundary and effective scheme that supply the intended meaning;
• unpack FPF-side umbrellas such as generic FPF-side object wording, generic named-target wording, locus, row, host, and source by naming what the sentence means: an FPF pattern; pattern section; DRR; FPF publication; U.View; document with a named source-basis, evidence-basis, architecture-basis, or review-basis relation or use; file carrier; record kind and the pattern that defines it; obtaining relation and participants; receiver-needed relation occurrence; claim-bearing episteme; reusable A.6.5 declaration; C.29 representation with explicit correspondence; or another 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 by naming the entity and relation they hide: a publication or carrier use; a project-side FPF kind and reference named by value; a direct relation claim with its participants or an A.6.1 operation-application binding; a local A.15.PROD or A.6.RCD claim; an 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 MethodDescription as defined by the relevant pattern; or an A.6.P.WMR non-assertability result independently reasoned as factually unsupported, missing-information, or missing-governor. Only missing-governor also names the affected receiving use and future subject pattern or relation declaration. 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. For relation-like wording, use A.6.P or its retained specialization; use A.6.RCD only for the exact residual claim whose participants are known and which no current direct relation closes. For episteme, publication, or source-use wording, use C.2.P. For durable reusable naming, use F.18 after recovering the kind and use. 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 pattern that defines or constrains the recovered claim, 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 concrete 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 repaired claim or result, 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 material for selected lexical, register, naming, morphology, and local rewrite problems. They are not a second ontology, wording-recognition table, or pattern head, and do not replace E.10.ARCH, a selected precision-restoration pattern, the concrete pattern for the recovered claim, or F.18. When 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 another named pattern, the current applicability table and the pattern that defines the claim control the repair.

Intent. Provide one normative trigger-and-repair rule set that makes FPF language unambiguous, composable across sources and uses, 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 ↔ Extension patterns ↔ Local use ↔ 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) Extension pattern specifications (CAL, LOG, and CHR), (c) local source or practice 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-local collision. A label such as Owner is assumed to have one global meaning even though distinct sources, practices, or schemes use it differently.
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 when they agree with the current applicability table and the pattern that defines or constrains the recovered claim.

#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, and invariants (for example U.Holon, U.SystemRoleAssignment, U.Method, U.Work, and 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. Local use — the exact source or practice boundary, effective scheme, local meaning statements, aliases, local kind distinctions and classification rules that the use actually needs; cite an F.9 Bridge only when an exact relation between distinct local senses obtains.
4. Instance — concrete identifiers for admitted holder Systems, exact U.SystemRoleAssignment occurrences, Work occurrences, and carriers.

V‑1 (Unidirectional meaning). Meaning is constrained from Kernel to extension patterns to local use to Instance. A local source, practice, or scheme may add a narrower designation or distinction, but it does not silently redefine a higher stratum's term; any actual relation between distinct local senses is stated separately.

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

V-3 (Citation style). When a local Tech designation changes interpretation or action, its first use names the source or practice provenance and effective scheme needed to read that use—for example, ReviewerSystemRole under the JournalReview-2026 definition. Reuse under another local meaning first compares the exact governed values; use F.9 only if a direct Bridge between distinct exact cells actually obtains. A suffix may serve as a locator, but it establishes neither kind identity, admission, nor assignment.

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 boundaries, specification-use morphology, guarded use of bare role, exact SystemRole compounds, and subject-specific recovery of Domain wording. It aligns with E.10.D1, F.4 SystemRoleKindDescription, A.2.5 SystemRoleAssignmentStateRelation, A.2.7 SystemRoleKindRelationStructure, F.11 Method Quartet Harmonisation, and F.17 UTS. Scope: Guidance is register-agnostic and applies across the FPF; illustrative examples pass Minimal Generality and Domain Anchoring (MG-DA) and the other rules of E.10.

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, Work, Episteme, Tradition, Lineage, Characteristic, Method, Profile, Description, Spec, TransformationFlowStructure, Card, Pack, Dashboard, …). SystemRole is allowed only as the common compound inside one concrete local system-role-kind designation such as ReviewerSystemRole; bare role remains a recovery trigger rather than a kind head.
• 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 the pattern defining that episteme kind. 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 — System-role kinds, assignments, and carrier-relation separation (ref. E.10.ROLE, A.2, A.2.1, F.4, F.5, C.2.1, C.2.P, E.17, E.24.PUB, A.10, and C.35)
• Positive distinction: A system role is an exact local kind for entities already admitted under A.1 as U.System. C.3 recovers it through the candidate domain, operative work-facing membership condition, intended member/non-member boundary, and continuity rule. A practice or source reference locates the definition or signals a comparison; it does not identify the kind. Its Tech designation ends in ...SystemRole, for example ReviewerSystemRole. The name creates no admission, assignment, agency, capability, or Work.
• Assignment rule: A system-role assignment is an obtaining occurrence of one directly declared species under U.SystemRoleAssignment. The species declaration defines HolderSystemSlot, the exact local system-role-kind domain of AssignedSystemRoleKindSlot, any other participant meanings, its predicate, applicability, and occurrence-identity rule. The occurrence supplies the actual holder System, assigned-kind value, any other participant values, and extent. A source, interpretation, taxonomy, scheme, description, or display is not automatically an assignment participant; name it separately only when the assignment claim actually depends on it.
• Readable example: Under the JournalReview practice, TeamAlpha is classified under ReviewerSystemRole because it can supply the substantive review judgment required by that practice. Add ReviewAssignment-42 only when the assignment itself matters and both its directly declared species and obtaining occurrence are recoverable. If performed Work is current, point first to its independently complete A.15.1 occurrence basis. Add F.6 only for a separately claimed precise assignment-bound attribution. A short attribution sentence may omit only an assignment identifier unused by the receiving claim; it does not omit a performer, Method, time, containing System, assignment occurrence, or F.6 attribution from the recoverable attribution basis.
• Carrier rule: Carrier is not a free holon or system kind. Recover the direct carrier relation: use U.PresentationCarrier only under E.17 and E.24.PUB 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; evidence or source-currentness carriage under A.10 or G.11; generated or produced carriage under C.35; or a named episteme-symbol carrier relation independent of any system-role assignment.
• Source-word rule: Job titles such as reviewer, owner, and lead remain Plain or quoted wording until the current claim is recovered. Use E.10.ROLE for an ambiguous claim-bearing role. Use ...SystemRole only for an exact local system-role kind, and preserve owner when an actual architectural, organizational, policy, source, or responsibility ownership relation is what the sentence states.
• Do: ReviewerSystemRole; ReviewAssignment-42 : U.SystemRoleAssignment; LeanTraditionCarrier only when its direct episteme-symbol carrier relation is declared.
• Don’t: Reviewer as a U-kind, ReviewerCarrier for an assigned system, an unqualified ...Role Tech head, or Carrier as an unstated system kind. Onto4 — Recover what domain means in this use (ref. E.10.D1 and F.17)
• Rule: The word domain does not create a kernel kind, catalogue mark, family, bundle, or inheritance relation by spelling. Recover what domain names in the current claim—for example, a DPF subject, discipline, source-defined field, model domain, market, physical region, or policy extent—or keep it as ordinary prose when it carries no FPF-governed use.
• Local-meaning rule. When a durable domain expression carries source-local meaning, identify its exact source edition, effective ReferenceScheme, local expression, local-sense claim, and any obtaining basis relation. Create an F.17 SchemeSenseCell only when a named receiver needs a stable address. Use F.9 only for an independently obtaining Bridge between distinct exact cells; state any proposed use separately.
• Discipline boundary. Use U.Discipline only when the claim satisfies the pattern that defines that kind. A domain label, shared vocabulary, or UTS row does not establish discipline identity.
• DPF boundary. A DPF states its domain subject, intended audience and use, source basis, scope, and qualification window under E.4.DPF; it need not invent DomainFamily, DomainBundle, or a list of Context identifiers.
• Do: “The Clinical Safety DPF addresses adverse-event analysis and device-labelling decisions for the stated audience and scope.”
• Don’t: infer ClinicalSafetyDomain, DomainFamily, or DomainBundle as a kind from that wording.

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—for example, a U.Holon, U.System, U.Episteme, Tradition, Lineage, Profile, exact local system-role kind, U.Work as the admitted kind or a Work occurrence admitted under it, Characteristic, or direct carrier relation.
• Do: “Kind named: ReviewerSystemRole — the exact local kind whose admitted-system candidates satisfy the current substantive-review condition. Its member/non-member boundary and continuity rule are recoverable under C.3; the named review practice locates that definition. A concrete assignment names its directly declared species and one separately obtaining occurrence under U.SystemRoleAssignment.”
• Don’t: “Reviewer — a person who …” (blurs the kind named).

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

• process, procedure, workflow, function, or activity -> first recover the wording family: change-situation wording applies A.3.4.P; function-like wording applies A.6.F. Possible recovered values include U.Method, U.MethodDescription, U.WorkPlan, one dated Work occurrence admitted under U.Work, a separate episteme about it, U.Transformation, and TransformationFlowStructure. Choose among them only after naming the object, any obtaining method-side or other relation and its participants, the relevant declaration or representation use, or the claim kind and the pattern that defines it.
• Tradition → Tradition (Tech); leave “Tradition” only as a Plain twin with an adjacent Tech label.
• domain -> apply Onto4: name the actual domain subject, source or practice boundary, effective scheme, discipline claim, DPF scope, or ordinary use that matters here. Do not infer DomainFamily, DomainBundle, ContextId, or a UTS row from the word.
• …CarrierRole used for an assigned System -> start with E.10.ROLE; recover the holder System, local ...SystemRole kind, A.2.1 assignment occurrence, and its declared species only when the passage asserts those facts. Recover carrier, source relation or source-local meaning, interpretation, publication, evidence-use, and Work claims through their own relations.
• ambiguous owner wording -> recover the precise relation or other claim being made—for example, an architectural, organizational, policy, source-maintenance, responsibility, authority, commitment, or work-facing claim. Keep owner when that precise ownership relation is current; use a ...SystemRole designation only when the recovered object is an exact local system-role kind.
• job titles (owner, lead, champion) in the Kernel -> keep them in Plain or quoted wording until the claim is recovered; use exact ...SystemRole designations only for admitted local system-role kinds.
• Do: ReturnsTransformationFlowStructureDescription, Tradition: Test-Driven; LedgerTeam is classified under LedgerCustodianSystemRole, with any exact assignment, responsibility, authority, source-maintenance, or interpretation relation stated separately when current.
• 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 bounded distinction and assignment example. The twelve rows below are morphology cues, not classification or assignment assertions. Read each candidate System label and candidate local system-role-kind label separately. Before asserting classification, pass C.3 and A.2; before saying an assignment obtains, admit the holder System and establish both the A.2.1 occurrence and its declared species. A schedule, place, office, desk, title, source or practice cue, taxonomy, scheme, or interpretation episteme supplies none of those facts by wording.

Checklist before minting a KernelToken

• Head noun signals kind (Onto1).
• EntityOfConcern and Description-episteme boundary and specification-use morphology correct (Onto2).
• If system-role-related or carrier-related: local system-role kind, direct assignment species, and carrier relation remain separate; holder-system admission is explicit and the direct carrier-relation pattern is named (Onto3).
• Any action-changing Domain wording recovers its subject, use, and applicable pattern; a durable local expression uses F.17 only when its source-local meaning or public term row is current (Onto4, Onto6).
• Object‑of‑talk declared (Onto5).
• SCR-LEX rewrites checked for current system-role-kind, direct assignment-species, 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. 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 concerning things such as holons, interfaces, and ports, name the exact invariant, compatibility condition, compliance profile, acceptance specification, or interoperability profile by value—for example InterfaceCompatibilityCondition, ComplianceProfile, AcceptanceSpec, or InteropProfile. State any promise or commitment separately; naming does not make it a property of the thing.

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 designation with a display-only Plain designation for one named value under one stated local meaning and effective ReferenceScheme: an admitted durable U-kind, C.3 U.Kind, Concept-Set row, imported signature symbol, or another value whose kind and definition are already known. The LEX registry checks the pairing under PTG (Plain Twin Governance) and identifies it by Twin-Map ID (LEX). Create an F.17 SchemeSenseCell only when stable reuse or another named receiver needs an exact address. “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 designation used in testable semantic clauses and may have one Plain designation for a stated didactic use. The Plain designation is admitted only when it names the same value under the stated local meaning and effective scheme; it does not create another value, cell, kind, or relation.

#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.

A source or practice may use local aliases in its glossary. Each alias points to one Tech designation under an effective scheme and an explicit local meaning claim. Create a SchemeSenseCell only when a named receiver needs a stable address; use F.9 only when an actual relation between distinct exact cells is current.

Make “plain twins” (reader-friendly labels) safe by construction, not just style. The plain twin preserves the named value, local meaning, scope, and reader expectations of the Tech designation; it is display-only and local to the stated source, practice, scheme, and use.

• Tech name (tech) — the canonical, kernel-conformant label used in normative clauses (for example U.SystemRoleAssignment, TransformerSystemRole).
• Plain twin (plain) — a didactic display alias permitted in expository prose and UI display only for the stated local meaning and use.

Principle: The Tech designation names the value; a Plain twin may not change that value or its stated local meaning. Locality comes from the named source, practice, effective scheme, and use. A Bridge is added only when its own F.9 predicate obtains.

#Plain Twin Safety constraints (normative)

CC‑TWIN‑1 - One‑to‑one and local. Each Tech designation has at most one plain twin for one stated local meaning and didactic use; that plain twin points to at most one Tech designation in the same use.

CC‑TWIN‑2 - Sense‑equivalence proof. A plain twin names the same value under the same local meaning claim and effective scheme as its Tech designation. When an F.17 SchemeSenseCell exists for that use, both expressions resolve to that exact cell. The registry notes include at least one counterexample showing how the twin could be misread and why the stated use still passes.

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:

• A Plain twin for one exact local system-role kind keeps “(system role)” and names its Tech designation on first use. Bare role is not a Plain twin for a universal kind. When service or access still hides its object or relation, follow L-SERV and A.6.P:4.11a; after recovery, keep that object's or relation's 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: TransformerSystemRole → “Transformer (system 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 its everyday interpretation can denote a different kind—for example, Tradition as organization, corpus, or field—it is admitted only with a bracketed head and a first-use local gloss (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 first-use local gloss (CC-TWIN-7). (This list may be extended in the registry.)

CC‑TWIN‑6 - No cross-local relation by label. Plain twins are not portable by spelling. Reuse under another local meaning first recovers that exact value, scheme, expression, and local-sense claim. Cite an F.9 Bridge only when its direct relation between distinct exact cells actually obtains; names alone carry no authority, equivalence, or substitution.

CC‑TWIN‑7 - First‑use gloss. At first occurrence in a document or screen, show a plain twin as “Plain twin [Tech designation] — local gloss”, for example: “Transformer (system role) [TransformerSystemRole] — one local kind for systems already admitted under A.1 and eligible for the stated transformer assignments in OR_2025; classification creates neither an assignment nor Work. An assignment claim names both an A.2.1 occurrence and its declared U.SystemRoleAssignment species”.

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 designation for one stated local meaning and didactic use. 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 recording tech, plain, referenceScheme, localSenseClaim, sourceOrPracticeBoundary, didacticUse, 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, same value and local meaning, Stop-list compliance, and First-use gloss. When a SchemeSenseCell is current, the harness also checks the exact cell.

#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 itself using LEX.TokenClass, then apply the guardrails corresponding to that class: kernel tokens unify across domains; discriminator tokens and existing ContextToken values make one recovered local source, practice, scheme, subject, or use legible from the name itself. ContextToken is the existing token-class identifier; it denotes no Context object. 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, for example manufacturing, healthcare, and cloud operations. Otherwise reject or narrow the KernelToken candidate and recover each word or qualifier under the object and rule that define it. Use a ContextToken only after the exact local source, practice, scheme, meaning, and receiving use are recovered. Use an A.19 CharacteristicSpace only when one named U.Characteristic, one declared CSLC scale, and the exact receiving use make that construction current; an assignment-state relation remains under A.2.5. MG-K2 (No parochial nouns). Kernel names contain no domain nouns such as Ticket, Microservice, Patient, or Developer. Domain-looking wording is a recovery trigger, not a destination: it may denote a C.3 local kind, exact system-role kind, system-role assignment, system or architecture object, episteme or record kind, declared Characteristic and scale, source wording, ordinary qualifier, recovered local-use ContextToken, or another value whose kind and use are already defined. Bare role has no default Tech reading. SystemRole appears only inside a concrete local kind designation admitted through C.3 and A.2; lexical shape alone creates neither that kind nor an assignment. 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 labels for an exact local system-role kind or its F.4 SystemRoleKindDescription 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 U.Method, qualifying U.MethodDescription, U.Capability, U.Mechanism, system or architecture object, A.19 CharacteristicSpace, A.2.5 SystemRoleAssignmentStateRelation, C.29 representation, formal substrate, source wording, or another value only when the predicate for that value is satisfied. Do not use Capability, CharacteristicSpace, assignment-state relation, or mechanism as disposal bins for 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 local-use ContextToken — Domain Anchoring (DA-D)

DA-D1 (kind anchoring). The head noun names the FPF kind or exact local construction being classified—for example Sense, Bridge, Characteristic, SystemRole, or another subject-specific head. A concrete local system-role-kind designation may use the SystemRole compound, for example ReviewerSystemRole; bare Role fails this test because it does not reveal whether the claim concerns classification, assignment, participation, declaration, representation, episteme use, or ordinary wording. Readers can answer “X of what?” without relying on an unstated container. DA-D2 (Enumeration rule, 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 closed value set, classified kind, local classifier, state/status frame, source wording, C.29 representation, example or alternative set, or another construction defined for that value. 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). A cross-local relation is not inferred from similar labels or token classes. Use F.9 only when its direct Bridge predicate obtains between exact distinct cells; 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, explicit classified kind, and closed-value interpretation under its classification rule. 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 object and rule; 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, A.19 CharacteristicSpace, A.2.5 SystemRoleAssignmentStateRelation, C.29 representation, formal substrate, source wording, or another value only when its predicate is satisfied. MG-DA‑T4 (Enum clarity). For an enumeration, list the closed value set, the kind being classified, and the rule that classifies it. 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) (for example, KernelToken use in normative kernel constraints is admitted; Plain-register use outside a glossary is restricted; a locally scoped use under another scheme requires its own valid designation rule and does not gain a Bridge by alias alone).

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

#Lexical prerequisites for a durable token

Mentioning LEX.TokenClass, LEX.Reserved-Names, or LEX.AllowedScopes does not create the values needed to admit a durable token. Before a NameCard can become current, the selected FPFCoreReferenceScheme must resolve four things: (1) the U.NameToken; (2) its current TokenClass classification assertion; (3) the current reserved-name or other authoritative collision-set value and the collision result; and (4) the current allowed-scope policy and a passing use-scope assertion. A prose example, full-text absence, heading, registry-shaped table, or intended policy supplies none of them by implication.

Worked near-miss. Suppose SelectedRuleContentSubgraphDesignation, derivedUsingRuleContent, and evaluatedAgainstRuleContent are proposed as KernelToken candidates. They can pass the tri-domain and object-of-talk tests through assembly-rule content selected in manufacturing derivation, protocol content used in healthcare derivation while evidence separately warrants case facts, and deployment-policy content selected for cloud release evaluation while service-provision Work and operational support remain separate. Even if their spellings do not collide in the inspected corpus, corpus absence is not a reserved-name or allowed-scope result. Do not publish their F.18 NameCards or F.17 rows until all four prerequisites resolve; a placeholder card or row closes none of them.

Using these names as candidate designators in declaration content changes no predicate semantics and does not admit them as public names, enumerations, Characteristics, CharacteristicSpace values, relation kinds, or U-kinds.

#Role-Precision Token Classes and Allowed Uses

The eight selected names below are KernelToken values under FPFCoreReferenceScheme. Each names one value already defined or constrained by its subject pattern; the lexical rule admits no kind, relation occurrence, declaration, judgment, description, structure, NameCard, row, or publication occurrence.

For all eight names, Plain wording that silently turns the token into a neighboring object is prohibited. Reuse under another local practice, source, scheme, or meaning uses that value's own identity and designation rules; when two exact cells are compared, any Bridge and use claim remain separately admitted. A change to the named value, TokenClass classification, or stable allowed-use rule reopens only the affected NameCard and row. A collision or conformance result for one dated corpus or candidate is evidence for its publication decision; it is not a reusable lexical rule or a currentness participant in the public pattern.

SystemRole alone is not a universal token with its own FPF kind or a NameCard subject. It is common morphology inside a concrete local designation such as ReviewerSystemRole. C.3 and A.2 recover that kind through its system-candidate domain, operative work-facing membership condition, intended member/non-member boundary, and continuity rule; practice or source provenance only locates or prompts comparison of the definition. AssignedSystemRoleKindSlot, SystemRoleAssignmentSlot, and fields ending in ...SystemRoleKindRef or ...SystemRoleAssignmentRef remain declaration-local ContextToken uses; the token-class name adds no Context object, and the fields are typed by existing U.KindRef or U.RelationRef, not by newly minted RefKinds. J_kindUse remains local notation. None receives a public row merely because the spelling recurs.

#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 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 schedule representation, planning cue, or other recovered construction. Do not mint ETLService at kernel level. Recover the ETL claim first: the way of doing may be one U.Method; a separately identified claim-bearing episteme may be U.MethodDescription only when that method is its 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 name the recovered claim; 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 rule gate). Every enumeration names its closed value set, classified kind, and classification rule. Require a CharacteristicSpace only when one named U.Characteristic is bound to one declared CSLC scale; otherwise retain the local classifier, state/status value set, source wording or C.29 representation, example or alternative set, local kind, or another construction defined for that classification. 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 pattern 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 the patterns that define them, such as its own A.6.5 relation-participant SlotKinds and RefKinds whose direct reference patterns admit them. A RefKind defined elsewhere remains defined there, and membership in an A.6.1 operation-argument or result declaration list does not transfer its definition 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. Recover the subject first: use a lens, flow, or composition inside G.5 when that is the actual construction, or use a subject-specific …Description or …Spec under the exact project profile and effective scheme when that construction's own admission gate passes. (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 exact local system-role-kind labels: UpperCamelCase (IncisionOperatorSystemRole, MethodDescription). Relations and verbs: lowerCamelCase (performedUnderAssignment, isExecutionOf, bindsMethod). IDs and instances: flat with delimiters chosen by the exact local naming scheme or project profile, but never colliding with kind-name or system-role-kind-label forms (e.g., W#Seam134, ctx:Hospital.OR_2025). Register discipline: normative tokens use the Technical register; Plain synonyms are allowed in prose only, never in constraints.

#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 classification rule; use CharacteristicSpace only when that enumeration is the declared CSLC scale of the named Characteristic (see § 7).

Not only suffix guard

• Suffixes are closely related to kinds and should be clearly guarded by MG-DA.
• Other morphemes, not only suffixes, also respect kinds. 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. U.EpistemePublication is a rejected kind name: when the selected edition is available as a published episteme, name or make recoverable its exact EpistemePublicationRelation occurrence, publication form, bounded use, and carrier under E.24.PUB. The rejected spelling may remain only in an explicit rejection explanation or a negative test, never as a positive object, kind, reference, or field.
• Name the publication form separately from the episteme: for example U.PreArticulationCuePack, U.AbductivePrompt, typed bounded projection, partial normal form, endpoint-specific publication form, or another declared form. A publication form is not itself the governing FPF source.
• Name U.View and MVPK face separately from the publication form. A PlainView, TechCard, InteropCard, or AssuranceLane is an episteme-level view or publication face, not the source claim, not the publication form itself, and not the SCR or RSCR carrier.
• Name the carrier or rendering relation separately. Documents, dashboards, generated screens, trace files, cards, and transport formats hold or render a publication; they are not the U.Episteme, not the claim or effect being relied on, and do not supply the rule for that claim.
• Name source-finding cues separately from source epistemes. A cue, badge, credential view, dashboard tile, heading, signature-looking mark, or generated explanation may help find a source; it does not by itself create an authoritySourceRef target, evidence relation, gate decision, assurance claim, exact U.SystemRoleAssignment occurrence, status assertion, Work occurrence, deontic permission, or Work authorization.
• Use an ordinary PatternID reference when a reader only needs to find the rule. Add relationFunctionClaimRef and the defining or constraining ClaimGraph only when admissible interpretation, comparison, migration, publication, or reuse depends on that exact rule identity. Use authoritySourceRef when a non-pattern target such as an external standard, editioned register, DRR, gate decision, policy record, system-role-assignment register, or status register carries the relevant authority. Do not use generic sign, source, project-work, or container-placement wording as solution terms.
• When a published episteme is used for work, name the P2W chain element being used: intended method family, selected method or method of work, one exact U.WorkPlan baseline, planned work, or one actual Work occurrence admitted under U.Work. Then name any separate claim-bearing episteme about that occurrence and any separately current direct resource-use, affected-referent, operation-application, measurement, evaluation, decision, delivery, acceptance, or receiving-use relation under the pattern that defines it; when a production-work, entity-inception, or production-completion claim is current, name one local A.15.PROD claim instead of implying a universal production relation. Apply A.6.P.WMR only while one such Work-to-Method boundary relation remains hidden after generic relation recovery. Do not let generic action, use, material, work result, or result measurement hide that distinction.
• Use C.2.P when episteme-publication-heavy wording carries an episteme, publication, view, carrier, relation, admissibility, evidence, work, gate, decision, method, or pattern-use claim. E.10 keeps the lexical and naming discipline; C.2.P recovers the FPF kind; obtaining relation and participants; receiver-needed occurrence; reusable A.6.5 declaration; claim-bearing episteme and participant designations; C.29 representation and correspondence; project-side FPF kind and reference; or a not-triggered disposition before the 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 — guarded recovery from role

• Bare claim-bearing role is a lexical trigger with no default Tech reading. Apply E.10.ROLE, write the ordinary sentence with its recognizable object and action or relation, and stop as soon as one exact object or relation and its direct pattern are clear.
• Use SystemRole only as the common compound inside one concrete local system-role-kind designation such as ReviewerSystemRole. Recover the kind through C.3's candidate domain, operative membership distinction, member/non-member boundary, and continuity rule. Practice or source provenance is a locator and comparison cue; the spelling creates no system admission, assignment, agency, capability, responsibility, participation, Work, evidence use, or status.
• A participant meaning or actual participant remains under its direct relation; a reusable declaration place remains an A.6.5 SlotKind or A.6.1 declaration; a tuple, table, formula, graph, diagram, schema, or call position remains under its representation pattern and explicit correspondence. None becomes a system-role kind by wording.
• Preserve ordinary or quoted role when no FPF claim relies on it. Preserve owner when a precise ownership relation is current—for example, an architectural, organizational, policy, source, or responsibility relation. This rule forbids lexical cleansing as well as default formalization.

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

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

M-FW (Tool and file markers). Tooling and file suffixes (...API, ...JSON, ...YAML, ...CI, ...Kafka, ...Postgres) are not part of conceptual names. Place them in local source or practice glossaries or operational configurations (DevOps Lexical Firewall). Kernel names never carry tool, format, or notation marks. This is conceptual discipline, not a data-management ontology.

#Prefix discipline

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

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

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

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

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

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

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

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

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

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

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

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

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

#Alias hygiene

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

#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 Contents query rows,
• or one bounded lexical-query record governed by F.17, UTS, or F.18.

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

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

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

canonical
noncanonical_visible
domain_query_examples
forbidden_aliases

Ordinary lexical-query support should stay compact:

• ordinary Table of Contents rows: prefer 2-5 query phrases;
• ordinary README scenario or [E.11](/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 an accepted F.18 naming settlement admits that use; otherwise keep the phrase as ordinary local query wording. Such a practitioner phrase may help recover a canonical FPF pattern while remaining lexical-query support only.

#Compatibility with USM (acts and tokens)

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

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

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

#Acceptance and regression checks (LEX and USM)

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

#Autonomy lexicon (L‑AUTO )

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

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

Notes.

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

#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, SystemRoleAssignmentStateRelation occurrences or assertions, deontic statuses, and epistemic statuses are not Characteristics by label alone; each remains governed by its direct pattern. Rule L-CHR-S4 (Lexical classifiers). Keep a lexical classifier or tag under its classification rule: a local classification function and value set, source wording, C.29 representation element, example or alternative set, status or state-frame value set, local kind or classifier, or another construction defined for that classifier. Call it a U.Characteristic only when that characteristic and one CSLC scale are declared. Do not default the residue to Facet, attribute, or another umbrella kind. Checks.

• CC-L-CHR-1. scope characteristic(s) is banned in Kernel and local-use Tech wording.
• CC-L-CHR-2. CharacteristicSpace near Scope — 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 mechanism references, control presences, certification states, or other status values admitted by their specific patterns; they are not generic governance records or measurements. Claim scope, work scope, CHR measures, qualification window, mechanisms, status values, and evidence keep their own kinds even when one Q-Bundle authoring structure coordinates them. (A.2.6 § 6.2; A.6.1; C.16, A.18, and C.25).

#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 local uses 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 keeps the EntityOfConcern, an episteme that describes it, and specification use of that episteme distinct; 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 value whose kind and definition are already known. 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 as a recovery guide. “Ban” means the listed phrase is not accepted as an unexplained Tech term in Core prose, identifiers, or diagrams. It may remain as ordinary, quoted, or source-local wording when its use is clear; otherwise name the recovered value or relation. EntityOfConcern and Description-episteme boundaries, specification-use gates, and token gates prevent object, description, 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 EntityOfConcern is M_quality and whose claims state the method's steps and applicability. Evaluate dated Work against the applicable acceptance condition, constraint, or commitment."

#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. Action-changing use recovered. Each use of context that changes interpretation or action names the exact source, scheme, scope, model-use structure, situation, frame, referent, or practice that matters. Ordinary, quoted, and already defined uses remain available.
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. A performed occurrence is admitted as dated U.Work from its independent A.13/A.15.1 basis. A complete A.13/A.15.1/F.6 basis is required only when the receiving use additionally claims precise assignment-bound attribution; missing F.6 does not revoke Work. Other direct facts, including affected referent, bindings, and resource use, remain separate. A short attribution sentence may omit only an assignment identifier unused by its receiving claim; the underlying occurrence and attribution remain recoverable. An assertion, description, log, or record about the Work is a separate episteme, not the occurrence.
6. Cross-local relation. When the text relates two different local senses, it identifies the exact F.17 cells and cites an F.9 Bridge only if that direct relation obtains under the applicable F.9 relation profile. When a receiving use is current, a separate C.2.1 claim says what action is proposed, its use direction, correspondence rule, tolerated loss, and polarity. That claim does not show that the action occurred. Use A.10 or B.3 only when reliance or assurance is actually current. Apply A.6.9 (RPR-XCTX) when published wording such as “same”, “equivalent”, “align”, or “map” still hides the relation.
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 classification rule; use U.Characteristic and CharacteristicSpace only when the enumeration is the declared CSLC scale of that exact Characteristic).
8. Morphology ok. Suffix, compound, prefix, and casing respect § 8 LEX.Morph (for example, concrete …SystemRole kind designations, MethodDescription, Work, and reserved prefixes); bare ...Role is not a default Tech form.
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 relevant pattern) and names the recovered value by value; no tooling or file suffixes in Kernel tokens.
10. State gating present (when needed). Readiness of an assignment to a system role is expressed through SystemRoleAssignmentStateRelation plus a separate SystemRoleAssignmentStateAssertion when an assertion is needed, not through vague “approved” or “ready” wording.

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

• With E.10.D1 — Recovering What “Context” Means in Use. E10-CTX-1: When context changes the statement or next action, recover what supplies the boundary—for example, a value, relation, scope, scheme, situation, or use defined by the relevant pattern. E10-CTX-2: For source-local meaning, state the exact source, expression, effective scheme, and local sense. Create F.17 cells when stable addresses are needed; use F.9 only for an obtaining direct Bridge between two exact cells, and keep every proposed use and reliance claim separate.

• 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 E.10.ROLE, A.2, A.2.1, and A.15 (system-role-kind, assignment, Method, and Work alignment). Bare role has no default Tech reading. A local system-role kind classifies independently admitted systems; classification, assignment, and Work remain separate. U.Method is a way of doing; U.MethodDescription is a claim-bearing episteme about one admitted method that passes A.3.2. A performed occurrence is dated U.Work: A.15.1 admits it first from its actual performer basis, Method, time, and containing System; F.6 follows only for precise assignment-bound attribution. A compact attribution account keeps the Work basis and all performers named or recoverable and may omit only an assignment identifier unused by the receiving claim after attribution is established. Assertions, descriptions, logs, and records about the occurrence are separate epistemes.

• With F‑cluster (Unification) and UTS (F.17). Recover each source-local cell under its effective scheme. A comparison row may cite direct Bridges, losses, contrasts, and separately warranted use claims; the row creates none of them. UTS is the human-readable term publication.

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 (Triggered use, not spelling ban). A listed word opens repair only when its FPF-governed use hides a kind, relation, claim, or action; quoted, ordinary, and already precise uses remain available.
2. LEX‑CC‑2 (Context wording). After E.10.D1, each action-changing use of context names what supplies the relevant boundary, interpretation, or situation and makes the next action or stop clear.
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). A positive cross-local relation cites an obtaining direct F.9 Bridge between identified cells; any proposed use and reliance remain separate. Shared spelling alone establishes none of them.
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 evaluation or acceptance Work that applied it, the returned value or result episteme, and the acceptance predicate with its participants under the applicable acceptance pattern; 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 under the evidence 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 applicable local repair pattern. If cleanup yields one durable reusable name, the text first records the applicable F.8 decision for the already identified value, then completes an F.18 NameCard; public, Core-facing, durable, or cross-local 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 quoted source cues only. Start with E.10.ROLE; they are neither system-role-kind designations nor assignment occurrences. PLC_17, ChangeControlBoardSystem, and OpsBot are independently admitted systems. Use ObserverSystemRole, ApproverSystemRole, and DeployerSystemRole only where those classifications matter. For each precise dated Work occurrence, recover the exact actual performer through A.13 and let A.15.1 independently admit the occurrence. Add F.6 only when the example or receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. Omit only assignment identifiers that the receiving example does not use. Source suffixes and interpretation epistemes remain separate. The exact dated Work occurrences remain separate from covering assignments and F.6 attributions, and all three remain separate from the log episteme, approval speech-act content, and fulfillment claim. Assignment and F.6 references appear only in an expressly consumed attribution branch. 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 quoted cues. Recover ProductLeadershipSystem and sCGSpecCIBot independently; use AuthorizerSystemRole and DeployerSystemRole only for exact local classification claims. For RolloutApprovalWork-F123 and DeployWork-F123, recover each exact actual performer through A.13 and let A.15.1 independently admit each dated Work occurrence. Add F.6 only when this account or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. Omit only assignment identifiers that the receiving account does not use. Keep source titles, source or scheme cues, approval content, deployment results, and telemetry separate, and identify each through the rule for that value or relation. 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 under A.10, B.3, G.6, F.10, or the applicable evidence pattern; replication is recorded through evidence-use, source-use, status-use, or reproducibility-status relations under their respective patterns; 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 the value and use that need a name, 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 rule gate; U.Characteristic and CharacteristicSpace only when one 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 define or constrain 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 value and its kind and record the applicable F.8 decision, then use F.18 for the NameCard and F.17 when public, Core-facing, durable, or cross-local 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 global or cross-local 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.

Bare claim-bearing role is another guarded head and has no default Tech reading. Use E.10.ROLE to recover the current object or relation; use SystemRole only inside a concrete local system-role-kind designation after that kind is independently admitted.

#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 only the local facts that matter here: the exact source or practice, effective scheme, scope, model-use structure, working situation, frame, or referent when it changes interpretation or action. Do not create a generic Context card. 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 classification rule; declare a CharacteristicSpace only when the enumeration is the declared CSLC scale of one 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 — Inspect the selected span

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 shared labels whose local senses may differ; do not infer a relation from the label.

#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 object, applicable rule, admissible use, and scope. Compare the same object and claim 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 relevant pattern, or leave blocking. Name an exact predicate, assertion, ClaimGraph, Method, actor, assignment, or Work only when the current claim or a named later use depends on that identity. Proportional naming never makes F.6 a Work-admission premise: A.15.1 closes Work membership first, while a precise assignment-bound claim must still establish its separate F.6 relation. A replacement phrase is admissible only when it remains recoverable and 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 applicable rule  • 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  • For actor or doer wording, identify the entity that acts and admit it as U.System only when A.1 passes. Ordinary actor wording need not become a precise agency claim. When performed Work is current, apply the A.13 core and independently admit the occurrence through A.15.1; only afterward add F.6 if precise assignment-bound attribution is current. Add an A.13 characteristic profile only when conditionally consumed.  • 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 its evidence, source, status, constraint, commitment, gate, or publication pattern 2.2 Apply LEX.Morph (§ 8): compound and suffix gates such as concrete ...SystemRole kind designations, ...Work, MethodDescription, service-description episteme, service-access publication, or service-offer record labels, casing, and reserved prefixes. Bare ...Role remains a trigger, not an accepted default form. 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 On first use, state the exact source or practice and effective scheme when they change meaning. Add a Tech-and-Plain twin pair in the local glossary only when a one-to-one didactic mapping is useful. 2.5 Perform one local KindRestorationCheck for each changed FPF-governed phrase. Write the full form below only when the repair needs a separately inspectable result; otherwise the repaired sentence and its kind-preservation check are enough. Keep any written result with the bounded repair instead of 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, applicable pattern contribution, admissible use, and scope on both sides; add only the distinctions required by the selected branch.
• Visible result and stop: give the accepted wording, concrete result obtained by applying the selected rule, or 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 concrete pattern for any current relation, declaration, representation, bare-role recovery, exact local system-role kind or assignment, Method, Work, evidence, assurance, gate, or decision use, and state what it contributes; 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 or mapping between two exact local senses is being claimed, identify both senses and create their F.17 cells when stable addresses are needed. Cite an F.9 Bridge only if its direct relation actually obtains under the applicable F.9 relation profile. When a receiving use is current, state a separate C.2.1 claim with the proposed action, use direction, correspondence rule, tolerated loss, and polarity. Use A.10 or B.3 only when reliance or assurance is actually current, and recover any action that occurred under its own pattern. Apply A.6.9 (RPR-XCTX) when quoted or imported wording such as “same”, “equivalent”, “align”, or “map” still hides the relation. 3.3 Publish an F.17 row or compact UTS only when readers need a durable term address. State the value it names, effective scheme, source expression, local sense, Tech and Plain designations when both exist, and warnings. The row creates no Bridge, equivalence, use, or reliance. 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. Local-use prompt. When context changes interpretation or the next action, has E.10.D1 recovered the exact source, scheme, scope, model-use structure, situation, frame, referent, or practice that matters?
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 the phrase is actually about—for example, a Method, Work, Characteristic, Capability, constraint claim, commitment, publication form, service-access relation, service-offer record, interpretation, local kind, U.Transformation, TransformationFlowStructure, authority use, source or practice boundary, or another exact object? If bare role is claim-bearing, use E.10.ROLE; a concrete ...SystemRole compound is admissible only for an exact local system-role kind. 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 the pattern for that branch and preserve only the objects it needs. If no branch fits, state the other governed object or ordinary non-use. If the sentence still mixes branches or only lists possible patterns, rewrite it before applying E.10.ARCH or another pattern.
7. Support interpretation prompt. If support, supported, supporting, or a support-headed compound appears, 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 domain fact. If so, name the things and relation and use the pattern that defines that relation; apply A.6.P only when the predicate or a participant is unclear, and A.6.RCD only when both are clear but no current pattern defines or constrains the predicate. If it is not a direct relation, choose the matching common alternative in E.10:0.2, write the concrete sentence, and use the pattern for that alternative. 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, compound, prefix, and casing pass LEX.Morph gates (for example, concrete …SystemRole kind designations, MethodDescription, and Work), with no default bare-Role Tech reading?
10. Promise, ability, access, and performance split. Are service promise or acceptance content, service-access relation, Capability (ability), and Work (performance) distinct and defined by their patterns?
11. Plan and execution split. Are planning cues and U.WorkPlan kept separate from performed U.Work? For each actual performer, does A.13 supply the local kind and criterion, classification, same obtaining assignment, scope, working situation, window, and adequate core evidence, with a profile only when conditionally consumed? Does A.15.1 then independently admit the Work from its performance history, Method, time, and containing System? When precise assignment-bound attribution is claimed, does F.6 separately relate that already admitted Work through the same assignment? Do affected-referent, binding, resource-use, assertion, and description claims remain separate?
12. Evidence prompt. Do documents, epistemes, and publications stay in source-use, evidence-use, specification-use, or publication-use relations? When precise agency or performed Work is current, is the actor an admitted U.System with the A.13 core, is the Work independently admitted by A.15.1, and is any precise assignment-bound attribution separately established by F.6 through the same obtaining assignment? Does any bare role wording first pass E.10.ROLE rather than assigning the episteme?
13. Bridge prompt. If the text asserts a relation between two local senses, are the exact cells identified, and does the F.9 Bridge actually obtain under its applicable relation profile? When a receiving use is current, does a separate C.2.1 claim state the proposed action, use direction, correspondence rule, tolerated loss, and polarity? Are reliance, assurance, and any action that occurred kept separate and opened only when current?
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, fit with the rule governing the claim, and local action guidance? If not, narrow the repair, keep ordinary wording with a recovery note naming the 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 (operating-room planning and work)

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, a PlanItem substantively coordinates the intended surgeon classification and assignment conditions, operating-room resource reservation, planned start of 08:00, IncisionMethod, the 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 edition identity needed by the plan is selected through a separate U.EpistemeRef whose subject pattern supplies its rule; 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. For ApprovalSpeechActWork-221, recover QAApprovalSystem as exact actual performer through A.13 and let A.15.1 independently admit the dated Work. Add F.6 only when this account or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. Add ApproverSystemRole only when that classification matters. Approval speech-act content and the resulting GateDecision remain separate, 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, recover Robot_SN789 as exact actual performer through A.13 and let A.15.1 independently admit WeldWork-SN789-4711 from its performer, time, Method, and containing-System facts. Add F.6 only when this account or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. Add WelderSystemRole only when that classification matters. Each bounded change of the workpiece joint is identified under A.3.4 before stating a work-to-change fact. If the Work first constitutes a distinct seam entity, A.15.PROD supplies its identity specification and inception boundary. Measurement-result epistemes remain separate evidence for acceptance and duration claims. Treat source string WeldingCellContext as a quoted recovery cue. If it changes the claim, recover the exact source edition, plant practice, effective scheme, scope, or working situation that it denotes. Any assignment interval is described outside the four participant designations.”

#Cloud and SRE (production deployment and work)

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 quoted recovery cue, not a performer or assignment. Recover sCGSpecCIBot as exact actual performer through A.13 and let A.15.1 independently admit DeployWork-r4711 from its performer, time, Method, and containing-System facts. Add F.6 only when this account or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. Use DeployerSystemRole only when that classification matters. The 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. LogWriterSystem is recovered as exact actual performer through A.13, and A.15.1 independently admits LogWritingWork-r4711 from its performer, time, Method, and containing-System facts. Add F.6 only when this account or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. Use TransformerSystemRole only when that classification matters. The service promise remains separate and does 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 applicable pattern 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 pattern and admissible use. A different governed object, source-use relation, explicit non-use, or blocker is named instead when no branch applies.
4. Applicable rule identified. If the issue is no longer lexical, name the pattern or precision-restoration realization pattern and its concrete contribution.
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 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 produce one A.6.P.WMR result family. 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 the patterns that define their claims.
• 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 relevant rule, 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, relation and participants, declaration slot, participant designation, representation correspondence, source-use relation, admissible-use boundary, or applicable pattern. A synonym replacement can make the sentence smoother while changing the claim. E.10 therefore starts with a cheap trigger scan; the practitioner then uses only the smallest pattern contribution needed for the recovered object.

The lexical rule content 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, apply the relevant pattern or continue the ordinary task. Name an exact subject assertion or ClaimGraph only when truth, action, comparison, publication, reuse, or reliance depends on that identity; a PatternID may remain an ordinary citation. The fuller form System S used Method M while performing Work W remains correct when actor, Method, and Work identity are themselves part of the claim, but it is not the default paraphrase of apply pattern P.

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, an appropriate pattern use, 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:

• A source edition, effective scheme, or local meaning changes → re-affirm any Tech-and-Plain twin mapping and first-use gloss; recheck an F.9 Bridge, use claim, reliance claim, or acceptance wording only when that exact changed value participates.
• A system-role-kind or other kind name grows (“and”, “plus”, or “--”) -> apply MG-DA: recover the one kind, explicit alternatives, relation, or bundle before renaming. Bare role first uses E.10.ROLE.
• 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 hidden subject, relation, and receiving use. Update only that recovered claim; 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 the pattern for that representation or publication unless claim content actually changes. Never move the change into service labels or system-role-kind 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.
• Wording about a way of doing or one of its neighboring objects changes—for example, wording with method, practice, technique, algorithm, program, proof, solver, workflow, process, procedure, access path, query plan, control strategy, method algebra, method graph, or selector calculus → recover the method-side object or relation before rewriting. The result may be U.Method; an exact composition, substitution, iteration, fallback, selection, family-membership, or other direct method-side relation; an A.22-selected MethodRelationStructure only when a named use depends on their organization; 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; exact system-role assignment or relation among system-role kinds; A.1.1 BoundedModelUseStructure; an exact source, practice, scope, situation, discipline, or cultural-evolution 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 concrete 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 classification rule; add a CharacteristicSpace only when the enumeration is the declared CSLC scale of one named U.Characteristic.
• Suffix drift (e.g., …Work on a plan) → fix via LEX.Morph.
• A label is reused across local sources, practices, or schemes → recover each local meaning. Keep them distinct unless an F.9 Bridge actually obtains between exact cells; state any proposed use and reliance separately.
• 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 value and its use, 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

Say it cleanly, once (memorise): A system role is one exact local kind for entities already admitted under A.1 as U.System. C.3 recovers it through the candidate domain, operative work-facing membership condition, member/non-member boundary, and continuity rule; source or practice provenance only locates the definition. A person, team, organization, or non-human technical object may qualify. A system-role assignment is one exact occurrence under U.SystemRoleAssignment. Bare role identifies neither and has no default Tech reading. 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 subject or relation through L-SERV and A.6.P:4.11a, then use the pattern for that recovered claim; 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. Source-local meaning is stated under the exact source or practice and effective scheme. An F.9 Bridge is asserted only for an actual relation between identified cells under the applicable F.9 relation profile. When a receiving use is current, a separate C.2.1 claim states the proposed action, use direction, correspondence rule, tolerated loss, and polarity; reliance, assurance, and any action that occurred remain separate.

Name forms (allowed morphology):

• System-role kinds and other local kinds: use <Noun>SystemRole only for a local system-role kind admitted under A.2 and C.3, and <Noun><Kind> for another local kind (IncidentCommanderSystemRole, ShiftOperatorSystemRole, WorkItemKind). Standards, evidence, requirements, statuses, relation participants, declaration places, and representation positions do not become system roles by suffix.

• Statuses: name them only under the exact state or status pattern (ApprovedStatus when that pattern admits it); a status is not a system-role kind and is not enactable by label.
• No suitcase nouns: avoid and, plus, and & in names; recover one kind, explicit alternatives, relation, or bundle instead of creating a composite system-role-kind name.
• 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, E.10.LRN, E.10.ROLE, 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 applicable to the current trigger; use A.15.PROD for local production-work, entity-inception, and production-completion claims when that result family is current.
• Coordinates with E.10.D1: use it when context hides subject-defined content that changes the next action—for example, a scheme, scope, model-use boundary, situation, design-time or run-time referent, architecture, environment, domain subject, or local-practice use.
• Coordinates with patterns for these objects: architecture, transformation, Work, evidence, assurance, gate, publication, source use, mathematical lens, Characteristic, temporal claim, exact local system-role kind and classification, U.SystemRoleAssignment, Method, and direct relation when those claims are current.
• Use: the concrete pattern for the recovered object, relation, evidence, authority, work, publication, or admissible-use claim whenever the issue is no longer wording precision.

#E.10:End

Last Updated: 2026-08-30 — upstream FPF commit e400eab3 (github.com/ailev/FPF)