FPF Reference

    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 governance. F.19 owns the common whole-span precise-language repair; E.10:0.2 supplies compact cues and routes only a genuinely unresolved FPF wording use. E.10.D1, E.10.LRN, E.10.DEV, E.10.ROLE, E.10.MOVE, E.10.ARCH, the precision-restoration patterns, and F.18 retain their exact subject work. Sections 5–9 below are optional register, naming, morphology, and overloaded-head references, not a second general language method.

    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.

    Use E.10 when a word, head, or short phrase in FPF-governed text still hides its kind, register, morphology, reusable name, or exact FPF relation after the surrounding sentence has been read in ordinary language.

    Relations

    E.10builds onStrict Distinction (Clarity Lattice)
    E.10builds onFour Guard-Rails of FPF
    E.10builds onNaming Discipline for U-kind Names and SystemRoleKindDescription Labels
    E.10builds onLocal-First Unification Naming Protocol
    E.10coordinates withWording-Use Ontological Precision Restoration Architecture
    E.10coordinates withRecovering What “Learning” Means in the Current Claim
    E.10coordinates withRecovering What Development or Evolution Means in the Current Claim
    E.10coordinates withMove and Readiness Wording Precision Restoration
    E.10coordinates withRelational Precision Restoration — Recovering Direct Relations from Under-Specified Claims
    E.10coordinates withExact Relation Recovery for Method and Work Claims
    E.10coordinates withNeeded Relation Claim Derivation and Relation-Kind Admission
    E.10coordinates withRelation-Declaration Slot Discipline - SlotKind, ValueKind, RefKind, and participant-designation discipline
    E.10coordinates withU.Episteme: Constitution, Empirical Grounding, and Edition Relations
    E.10coordinates withMathematical Lens Use
    E.10coordinates withU.MethodDescription: Description Episteme for a Way of Doing
    E.10coordinates withU.WorkPlan: The Schedule of Intent
    E.10coordinates withProduction Work, Entity-Identity Inception, and Production Completion Recovery
    E.10coordinates withEpistemic Precision Restoration
    E.10coordinates withState-Family Precision Restoration
    E.10coordinates withBase Declaration Discipline - Direct relation first; reusable declaration only when needed
    E.10coordinates withEvidence Graph Referring (C-4)
    E.10coordinates withTrust and Assurance Calculus
    E.10coordinates withU.Commitment (Deontic Commitment Relation)
    E.10coordinates withGranted Permission, Exercise, and Non-Prohibition
    E.10coordinates withU.SpeechAct (Communicative Work Kind, Occurrences, and Records)
    E.10coordinates withOntic Candidate Detection and First-Use Disposition
    E.10coordinates withOntic Description and Publication Discipline
    E.10coordinates withOntology-First Plain Technical Rewriting
    E.10builds onOntology-First Plain Technical Rewriting
    E.10builds onU.Episteme: Constitution, Empirical Grounding, and Edition Relations
    E.10builds onMulti‑View Publication Kit
    E.10builds onU.Ontic and Ontic Introduction Discipline
    E.10builds onU.Signature - Reusable Law-Governed Declaration Episteme
    E.10builds onRelation-Declaration Slot Discipline - SlotKind, ValueKind, RefKind, and participant-designation discipline
    E.10builds onWording-Use Ontological Precision Restoration Architecture
    E.10builds onRecovering What Development or Evolution Means in the Current Claim
    E.10builds onRecovering What “Learning” Means in the Current Claim
    E.10builds onRecovering What “Role” Means in the Current Claim
    E.10builds onRelational Precision Restoration — Recovering Direct Relations from Under-Specified Claims
    E.10builds onExact Relation Recovery for Method and Work Claims
    E.10builds onNeeded Relation Claim Derivation and Relation-Kind Admission
    E.10builds onEpistemic Precision Restoration
    E.10builds onState-Family Precision Restoration
    E.10builds onMove and Readiness Wording Precision Restoration
    E.10builds onProduction Work, Entity-Identity Inception, and Production Completion Recovery
    E.10builds onRecovering What “Context” Means in Use
    E.10outline childRecovering What “Learning” Means in the Current Claim
    E.10outline childRecovering What Development or Evolution Means in the Current Claim
    E.10outline childMove and Readiness Wording Precision Restoration
    E.10outline childWording-Use Ontological Precision Restoration Architecture
    E.10outline childRecovering What “Role” Means in the Current Claim
    E.10outline childConceptual Prefixes (policy & registry)
    E.10outline childRecovering What “Context” Means in Use
    E.10outline childEntityOfConcern, Description Episteme, and Specification-Use Discipline
    E.10explicit referenceRecovering What “Context” Means in Use
    E.10explicit referenceRecovering What “Learning” Means in the Current Claim
    E.10explicit referenceRecovering What Development or Evolution Means in the Current Claim
    E.10explicit referenceRecovering What “Role” Means in the Current Claim
    E.10explicit referenceMove and Readiness Wording Precision Restoration
    E.10explicit referenceWording-Use Ontological Precision Restoration Architecture
    E.10explicit referenceLocal-First Unification Naming Protocol
    E.10explicit referenceStrict Distinction (Clarity Lattice)
    E.10explicit referenceFour Guard-Rails of FPF
    E.10explicit referenceNaming Discipline for U-kind Names and SystemRoleKindDescription Labels
    E.10explicit referenceSystem-Role Kinds and Assignments
    E.10explicit referenceU.SystemRoleAssignment - Contextual System-Role Assignment
    E.10explicit referenceSystem-Role–Method–Work Alignment
    E.10explicit referenceSystemRoleAssignment and Performed-Work Attribution Check
    E.10explicit referenceEvidence Graph Referring (C-4)
    E.10explicit referenceHolon Aggregation and Part-Whole Construction
    E.10explicit referenceTrust and Assurance Calculus
    E.10explicit referenceUnified Term Sheet
    E.10explicit referenceAlignment and Bridge across Contexts
    E.10explicit referenceEpistemic Precision Restoration
    E.10explicit referenceRelational Precision Restoration — Recovering Direct Relations from Under-Specified Claims
    E.10explicit referenceBase Declaration Discipline - Direct relation first; reusable declaration only when needed
    E.10explicit referenceFunction and Functional Precision Restoration (RPR-FUNCTION)
    E.10explicit referenceState-Family Precision Restoration
    E.10explicit referenceCharacteristic and Scale Precision Restoration
    E.10explicit referenceNeeded Relation Claim Derivation and Relation-Kind Admission
    E.10explicit referenceControlled Semantic Coarsening
    E.10explicit referenceMulti‑View Publication Kit
    E.10explicit referenceRepresentation-Scheme Transition: EntityOfConcern-Preserving Representation-Scheme Transition
    E.10explicit referenceMathematical Lens Use
    E.10explicit referenceHolon Ontic Foundation (U.Holon and Admitted Holon Kinds)
    E.10explicit referenceU.Episteme: Constitution, Empirical Grounding, and Edition Relations
    E.10explicit referenceTransformation Ontic Precision Restoration
    E.10explicit referenceRelation, Signature, Interface, Role, and Slot Precision Restoration
    E.10explicit referenceU.Signature - Reusable Law-Governed Declaration Episteme
    E.10explicit referenceRelation-Declaration Slot Discipline - SlotKind, ValueKind, RefKind, and participant-designation discipline
    E.10explicit referenceModule Relation Repair
    E.10explicit referenceContract Unpacking for Boundaries
    E.10explicit referenceStructure and Structural Views (STRUCT-CAL)
    E.10explicit referenceArchitecture Structural View Adequacy (ASV)
    E.10explicit referenceArchitecture Description Adequacy
    E.10explicit referenceBoundary Norm Square (Laws / Admissibility / Deontics / Work-Effects)
    E.10explicit referencePublicationUnit Stability Discipline
    E.10explicit referencePublicationUnit Primary-Subject Discipline
    E.10explicit referenceConstraint Validity for Transformation Steps
    E.10explicit referenceGate Decisions from Independent Check Results
    E.10explicit referenceU.Commitment (Deontic Commitment Relation)
    E.10explicit referenceGranted Permission, Exercise, and Non-Prohibition
    E.10explicit referenceDecision Theory (Decsn-CAL)
    E.10explicit referenceAction-Invitation Precision Restoration (ACT-INV)
    E.10explicit referenceU.Work: Dated Performed Work Occurrence
    E.10explicit referenceOntic Description and Publication Discipline
    E.10explicit referenceU.Mechanism - Reusable Law-Governed Operation Declaration
    E.10explicit referenceProduction Work, Entity-Identity Inception, and Production Completion Recovery
    E.10explicit referenceU.SpeechAct (Communicative Work Kind, Occurrences, and Records)
    E.10explicit referencePattern Quality Gates: Review and Refresh Profiles
    E.10explicit referenceExplanationFaithfulnessProfile — bounded explanation-use discipline
    E.10explicit referenceWork-Relevant Appearance-Based Reliance Repair
    E.10explicit referenceLanguage-State Move Coordination
    E.10explicit referenceU.LanguageStateMoveTrajectory - Optional trajectory-account normal form over the language-state U.CharacteristicSpace
    E.10explicit referenceCharacteristicSpace & Dynamics Hook (A.CHR‑SPACE)
    E.10explicit referenceU.LanguageStateSpace - Language-state chart over U.CharacteristicSpace
    E.10explicit referenceSupervisor-Subholon Feedback Relation
    E.10explicit referenceControl Structure View Adequacy (LCA)
    E.10explicit referenceTransformation Flow Structure
    E.10explicit referenceEpisteme viewing - EntityOfConcern-preserving episteme construction
    E.10explicit referenceEntityOfConcern retargeting
    E.10explicit referenceExact Relation Recovery for Method and Work Claims
    E.10explicit referenceTransformer Constitution (Quartet)
    E.10explicit referenceU.WorkPlan: The Schedule of Intent
    E.10explicit referenceThe Agential Role & Agency Spectrum
    E.10explicit referencePublicationUnit Stability Discipline and Local Head Restoration
    E.10explicit referenceSystemRoleAssignmentStateRelation - Assignment-State Recognition and Work Admission
    E.10explicit referenceWork-Entry Readiness and Full-Kit Preparation
    E.10explicit referenceDRR Decision-Adequacy Evaluation CharacteristicSpace
    E.10explicit referenceFPF Pattern-Quality Evaluation CharacteristicSpace
    E.10explicit referenceOntology-First Plain Technical Rewriting
    E.10explicit referenceU.Ontic and Ontic Introduction Discipline
    E.10explicit referenceSystemRoleKindDescription — Describing an Exact System-Role Kind
    E.10explicit referenceSystemRoleKindRelationStructure - Relations among System-Role Kinds
    E.10explicit referenceMethod Quartet Harmonisation
    E.10explicit referenceU.MethodDescription: Description Episteme for a Way of Doing
    E.10explicit referenceEntityOfConcern, Description Episteme, and Specification-Use Discipline
    E.10explicit referenceStructural Synthesis and Discovery Adequacy
    E.10explicit referenceTelemetry-Driven Refresh & Decay Orchestrator
    E.10explicit referenceKinds, Intent and Extent, and Typed Reasoning
    E.10explicit referenceAnti-Explosion Control for System-Role and Status Name Families
    E.10explicit referenceStatic and Regression Conformance Harness for Unification
    E.10explicit referenceKindUseAdaptationDeclaration — Contextual Adaptation of Kinds without Cloning
    E.10explicit referenceAdvanced Mereology: Components, Portions, Aspects & Phases
    E.10explicit referenceFirst-Practical Entry and Pattern-Use Discoverability Discipline
    E.10explicit referenceExpanded Entry Disambiguation Cases
    E.10explicit referenceMeasurement & Metrics Characterization (MM‑CHR)
    E.10explicit referenceA.CHR-NORM — Canonical “Characteristic” & rename (Dimension/Axis → Characteristic)
    E.10explicit referenceA.CSLC-KERNEL — Minimal CSLC in Kernel (Characteristic/Scale/Level/Coordinate)
    E.10explicit referenceQ-Bundle: Authoring "-ilities" as Structured Quality Bundles
    E.10explicit referenceUnified Scope Mechanism (USM): Context Slices & Scopes
    E.10explicit referenceBounded Model-Use Structure and DDD Bounded-Context Recovery
    E.10explicit referenceGrounded Architecture and Selected-Structure Adequacy
    E.10explicit referenceFinding the Acting or Changed System
    E.10explicit referenceStatus Families Mapping (Evidence • Standard • Requirement)
    E.10explicit referenceEvidence Graph & Provenance Ledger
    E.10explicit referenceCausalUse-CAL: Causal-Use Questions, Identification, and Realizability
    E.10explicit referenceCultural-Evolution Wording-Use Precision Restoration
    E.10explicit referenceMint-or-Reuse Decision
    E.10explicit referenceBridge Stance Note
    E.10explicit referenceOntic Candidate Detection and First-Use Disposition
    E.10explicit referenceDeclarative Representation Precision Restoration

    Content

    Use this when

    Use E.10 when a word, head, or short phrase in FPF-governed text still hides its kind, register, morphology, reusable name, or exact FPF relation after the surrounding sentence has been read in ordinary language.

    What goes wrong if missed. An author replaces one broad word with another or imports a technical-looking classification without recovering the object, relation, or use that made the wording matter.

    What this buys. E.10 supplies cheap cues and the shortest exact route to an existing FPF rule. It does not turn ordinary prose into a lexical record or make every candidate word open an ontology exercise.

    First useful move. Read the complete natural span with F.19. If its object, predicate, participants, referents, contribution, and list meaning are clear, make the plain repair and stop. Use the cue surface below only to locate an unresolved FPF wording use; then open the smallest applicable lexical or subject pattern.

    Not this pattern when. Use F.19 for general plain-language repair, missing operands, predicate compatibility, grounded contrasts, referents, coordination, list load, and information order. Use the subject pattern directly when its governed object and contribution are already clear. For non-FPF source prose, use C.2.P source-expression unpacking mode and borrow an E.10 cue only when preparing a possible FPF use.

    A cue is neither a ban nor a verdict. Its absence is not semantic clearance, and its presence is not an instruction to formalize the sentence.

    One-screen cue and route

    1. Read one complete sentence, row, paragraph, list, or small coherent section rather than classifying a word in isolation.
    2. Apply the connected F.19 reading. If ordinary meaning settles the issue, write the repaired text and reread the changed sentence with only its meaning-dependent neighbors.
    3. If an FPF wording question remains, name that one question: head or kind, register, morphology, durable name, direct relation and participant, reusable declaration, claim or report, representation, source or publication use, or another exact governed object.
    4. Use the applicable subject pattern directly when the object and claim are already recoverable. Use the detailed E.10 rows only for the selected lexical question. Open E.10.ARCH when the distinction among a world-side fact, reusable declaration, claim or report, and representation is itself unresolved.
    5. Check the replacement for another umbrella head, an unintended kind or scope change, and a newly introduced relation. If one remains unresolved, state the blocker instead of filling the sentence with possible interpretations.

    The ordinary result is repaired text or a blocker. E.10 requires no per-correction card, field set, concordance row, or classification receipt. A using environment may manage attention over a large text, but that mechanism is outside this language pattern.

    Common prose can often remain ordinary after the relation is stated: Test T is evidence for claim C; Index I helps readers find section S; Column C bears roof R's load. These sentences reach different subject patterns and do not need a common SupportRelation.

    Local patterns may cite a useful recognition row. They do not copy the trigger inventory or create a local lexical registry unless a stable local vocabulary is itself the governed product. Self-application remains bounded: use E.21 for pattern-quality evaluation and the exact subject pattern for any non-lexical claim.

    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.

    Compact cue and routing surface

    Keep these cues available while applying F.19. They help find candidate spans; they do not replace the whole-span judgement.

    Cue familyInspect in the complete natural spanContinue beyond F.19 only when
    Broad or overloaded heads such as support, basis, context, role, process, method, route, record, result, or statusWhat recognizable object, relation, source, use, or state does the sentence actually mean?An FPF kind, register, relation, source use, or governed value remains unclear.
    Development- or evolution-family wording such as development, evolution, progress, growth, adaptation, or lineageWhat changed or is represented, what continuity or membership matters, what posture or value claim is current, and which direct owner receives it?Those values remain action-changing and unresolved; use E.10.DEV, then E.10.MOVE only for a separate remaining path or trajectory ambiguity.
    Agentive or causal predicates attached to evidence, documents, patterns, representations, methods, or other doubtful subjectsCan the grammatical subject bear the asserted predicate under the intended literal or ordinary metonymic reading? Check inside negation, modality, and examples.Precise systemhood, agency, Work, attribution, evidence, or causal use is itself part of the claim.
    Negative and contrastive forms such as not, rather than, does not mean, does not turn, warnings, and non-use guardsDoes a plausible intended reader have an independent local reason to construct the rejected reading, and does the distinction change truth, understanding, or use?The guard carries an exact FPF admissibility, safety, source-use, or claim boundary.
    Verbs with uncertain objects or destinations; relational nouns such as bearer, boundary, basis, readiness, or condition; vague pronouns and demonstrativesCan one intended operand, other participant, or referent be recovered cheaply and uniquely?The missing value is an exact FPF participant, relation position, state bearer, or source reference.
    Grouping marks, repeated coordination at several grammatical levels, comma or semicolon chains, nested lists, stacked modifiers before the governing clause, and coverage heads such as examples, variants, forms, activities, or continuationsDoes the reader need a series at all? If so, what proposition it serves, what its membership semantics are, and which members change use?A closed FPF value set, kind, declaration, relation set, or representation remains unresolved.
    Qualifiers such as exact, direct, current, supported, valid, ready, stronger, or safeWhat live alternative, bearer, scale, criterion, time, or bounded use does the qualifier distinguish?The qualifier carries a governed identity, state, characteristic, decision, or admissible-use claim.
    New tokens, suffixes, compounds, acronyms, paired registers, and reusable labelsIs this a local wording choice or a durable FPF name, and does its form expose the settled kind?Register, morphology, token class, collision, or durable naming is current.
    Source, publication, carrier, field, table, graph, dashboard, or model wordingIs the sentence about the represented object, a claim-bearing episteme, publication or carrier use, or the representation and its correspondence?The source-use, publication, declaration, or representation boundary is still hidden.

    Semantic-area cues: classify FPF-governed trigger wording before acceptance by semantic area, not by a local forbidden-word list. Typical classes include admissibility/deontic terms, evidence and review-check terms, action-invitation terms, characteristic/scale and stratification source labels, state-family terms, lifecycle/process terms, pattern-application wording, publication-form terms, and local equivalents.

    Package-form and relation cues: primary carrier, specialization, profile, overlay, family, bundle, cluster, suite, pack, kit, record, umbrella, and local equivalents.

    Item count is only a cue. Two coordinated members may already form a needless catalogue; a long legal set, signature, inventory, or checklist may be required. Matching kinds do not earn a series by themselves: the receiving use must require readers to distinguish or retain the members together.

    exact is not a general precision marker. Keep it for literal or bounded source identity, or when it distinguishes a live alternative that changes truth, action, publication, reuse, or reliance. An ordinary PatternID citation needs no formal expansion merely because it is exact.

    Exact routing boundary

    If the applicable pattern and the current object, direct relation and participants, declaration, claim-bearing episteme, representation and correspondence, or source use are already recoverable, use that pattern directly and state its concrete contribution—for example, a definition, constraint, test, method, or lookup.

    Remaining unresolved questionSmallest next route
    Local head, register, morphology, or already-settled token useThe applicable detailed E.10 section.
    Meaning of context, learning-family wording, bare role, move or readiness wording, function-like wording, state-family wording, or characteristic wordingE.10.D1, E.10.LRN, E.10.ROLE, E.10.MOVE, A.6.F, A.19.SPR, or C.16.P respectively.
    Development or evolution wording still hides the changed or represented subject, continuity or membership, posture, direction or value basis, direct owner, or receiving useE.10.DEV; continue to E.10.MOVE only when an independent trajectory, route, path, ordering, posture, or representation ambiguity remains.
    Direct predicate or actual participant remains unclearA.6.P; use A.6.RCD only after both are clear and no current pattern defines or constrains the predicate.
    Fact, reusable relation declaration, claim or report, and representation are still being confusedE.10.ARCH, followed by the exact subject pattern.
    Episteme, publication, carrier, source-reference target, or source-use relation remains hiddenC.2.P and then the exact publication, source, evidence, or use pattern.
    Intentional loss of precision for a narrower admissible useApply the controlled precision-reduction pattern, normally A.6.3.CSC, with E.17.*, A.6.3.RT, F.9, or C.29 when that relation is being made. Recover the source-bearing side, declared loss, narrower admissible use, blocked downstream use, and reopen condition.
    One durable reusable name is needed after its value and use are settledF.18; one-off wording remains local.
    Meaning cannot yet be recoveredLeave a plain blocker or retain bounded quote-only or source-only wording.

    The result is the repaired wording, the concrete result of the selected pattern, or the blocker. Do not require a rejected neighboring interpretation, a field schema, or a complete catalogue of possible routes when the current sentence needs only one.

    Optional trigger index

    The compact surface above is the normal entry. The detailed rules in E.10:0.2c and the L-rules in section 9 are optional references after one cue has selected a real FPF wording problem.

    Frequent search terms include broad heads (support, basis, context, role, method, process, result, record), state and authority-looking words (current, ready, valid, approved, required), source and representation words (source, publication, carrier, field, map, dashboard), and grouping or coverage language (and, plus, slashes, examples, variants, forms). They are examples, not a closed lexicon. Search can increase recall; only the natural-span reading can decide whether a defect exists.

    Use a detailed row only when its exact distinction changes the repair. Otherwise write the ordinary sentence and return to the domain task.

    requirement and required recovery

    Treat requirement and required as cues, not as a shared engineering kind or durable suffix. Read the complete span through F.19; when an ordinary sentence can state the condition or action directly, repair it and stop.

    When the wording still carries an FPF-governed claim, recover the bearer, the exact claim or relation kind, the governing pattern when its identity changes use, and the practical consequence. Write that construction directly and reread the changed sentence. The result is the repaired text or a blocker, not a separate record.

    Current claim behind the wordingExact recovery and practical consequence
    An accountable subject undertakes a duty, accepts a recommendation-as-duty, or is prohibited under an issuing or authority relation.A.2.8 -> U.Commitment; the commitment changes the accountable subject's declared duty, recommendation-as-duty, or prohibition stance for the stated scope and validity window.
    A valid grant permits a beneficiary, no prohibition is found in a current sufficiently complete frame, dated work exercises a grant, actual dated work is found not to violate any applicable prohibition in a current sufficiently complete frame, or a same-scope permission conflict is found.A.2.8.PER -> the exact GrantedPermissionRelation@Context, NonProhibitionFinding@Context, PermissionExerciseRelation@Context, NonViolationFinding@Context, or PermissionNormConflictFinding@Context; do not route it through U.Commitment.
    A subject structure, value, or use must remain inside a stated engineering boundary.The constraint claim under the pattern that defines it; the constraint blocks or admits the named use and does not create a commitment without an accountable subject and authority relation.
    A public pattern-use template says which candidate-basis positions must have current fillers.E.11 CandidatePatternUseBasisCompletenessCondition@FPFReadme; it describes positive completeness and does not order a participant to fill a form.
    One candidate pattern use can precede another only because the first candidate's result is its basis.E.11.PUR precedence with prerequisiteResult and the prerequisite candidate's exact PatternUseResultExpectation@Context; no duplicate result-kind field is created.
    One transformation-flow position depends on another.E.18.3 basisDependency with its exact supporting relation; dependency is not obligation.
    An improvement loop cannot continue until missing information positions become sufficient.E.23 holdUntilInformationBasisSufficient with non-empty unfilled-position descriptions and one sufficiency condition.
    A framework-authoring dependency is absent or not current for the next use.E.4.DPF separates availability from relevance; only a missing dependency carries an acquisition-condition description, and only missing + currentForNextAuthoringUse blocks the next authoring use.
    A candidate framework organization must cover declared relation families for a stated use.One E.4.DPF constraint claim node with covered family ref-kind pairs, admitted-use description, and coverage-criterion description; any WorkPlan acceptance target remains separate basis.

    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.

    External holon and graph-expression source wording

    Cue. External holon-class or Holon Graph Architecture (HGA) graph-expression wording such as AgentHolon, OrganisationHolon, DataHolon, ProcessHolon, Portal, Projection, event envelope, provenance, target holon, projection envelope, projected content, envelope, payload, RDF graph, node, edge, traversal, or boundary-governed payload whose FPF object is hidden.

    Recover the claim before importing the source label. Use A.1 for admitted system or holon claims; C.2.1, E.17, architecture-description, publication, source-relation, or evidence patterns for data, document, projected content, description, publication, view, or evidence claims; A.10, source-relation, evidence-relation, dated-work, or publication patterns for event and provenance claims; and A.3.4.P, method, work-plan, or Work patterns for process-like wording. Portal, access, traversal, service-access, protocol, and agreement-like words do not select peer routers. While their object remains hidden, use A.6.RSIR; after recovery, use E.17 or the pattern for the publication claim, C.29 or the pattern for the representation and correspondence, A.6.0 plus A.6.5 for a reusable signature and its slots, A.6.M for a module-interface claim, the pattern for the policy claim, and A.10 or the pattern for the evidence claim. Use A.6.P:4.11a only when a relied-on service or access phrase hides its concrete subject or direct relation; use A.6.C only when recovered service-term, SLA, protocol, or agreement-like wording bundles promise, utterance or publication, governance, Work or consequence, or evidence claims; use general A.6.P only for another under-specified direct relation. For graph, RDF, node, edge, or traversal expression claims, use C.29, A.22, C.30.ASV, C.30.AD, E.17, or the pattern for the recovered source or publication relation; use A.6.B only for L, A, D, or E statement classification inside a boundary package.

    W3C Community Group Holon Graph Architecture (HGA) vocabulary is retained as a serious source-finding cue or comparison term only after the recovered FPF object is named and differences from FPF are explicit. Do not mint source-class U-kinds such as U.AgentHolon, U.DataHolon, U.ProcessHolon, U.Portal, U.Projection, U.Envelope, or U.Payload; do not turn semantic-web class names or graph-expression vocabulary into FPF ontology.

    Lexical Trigger Rewrite Rules

    EntityOfConcern, primary entity of concern, and local topic wording

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

    If local wording meant...Rewrite as...
    the EntityOfConcern named by a claim-bearing episteme or episteme-lane U.Viewthe actual EntityOfConcern participant under C.2.1; use EntityOfConcernRef or entityOfConcernRef only when the applicable reference rule requires it, and keep the episteme or U.View separate
    the admissible class constraint on actual EntityOfConcern participants corresponding to one current episteme-constitution declarationEntityOfConcernClass only where that declaration or an EntityOfConcern-preserving law is being applied
    what one bounded PublicationUnit is mainly aboutpublicationUnitPrimaryEntityOfConcern under C.2.P and E.17.AUD, with its carried-EntityOfConcern or non-claim-bearing kind/topic/subject meaning; publicationUnitPrimarySubject for E.17.AUD.OOTD's separate primary-subject question, with C.2.1 projection only under that pattern's equality condition; otherwise the non-claim-bearing kind or reference named by value, or plain topic or subject only when no claim-bearing episteme participant, current A.6.5 declaration, or direct reference use is current
    wording such as describedEntity, DescribedEntityRef, primary described entity, EntityOfInterest, or EoIClassrecover the actual EntityOfConcern participant under C.2.1, the publication-unit primary-EntityOfConcern or ordinary primary-subject use, or the local FPF kind; use EntityOfConcernSlot only as an A.6.5 SlotSpec inside a current reusable constitution RelationSignature; keep entityOfConcernRef and EntityOfConcernRef under their applicable reference rules; and rewrite to the exact current value among those, EntityOfConcernChangeMode, EntityOfConcernClass, publicationUnitPrimaryEntityOfConcern, publicationUnitPrimarySubject only for the E.17.AUD.OOTD primary-subject use, or the local FPF kind named by value. For the non-claim-bearing case, use the kind named by value or plain topic or subject without inventing an EntityOfConcernRef. If no use can be recovered by value, keep the old wording only as quoted source or trigger wording and block reliance.
    a review targetreview target, review-facing target packet named by value, FPF pattern, pattern section, or file-carrier set only when the file-carrier interpretation is being made
    a local table or paragraph topic with no claim-bearing episteme, C.2.1 participant, current declaration, or reference usetopic, subject, or direct noun
    an FPF-side pattern, pattern section, accepted DRR, FPF publication, FPF view, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation or use, or companion or projection material being improvedFPF pattern, pattern section, accepted DRR, FPF publication, FPF view, document with named source-basis, evidence-basis, architecture-basis, or review-basis relation or use, or companion or projection material
    a project-side episteme, publication, record, carrier, or activity under workproject episteme, view, or publication named by value, A.10 evidence relation, typed evidence record, A.20 constraint or adjudication decision record, A.21 GateDecision, A.21 DecisionLogRef, B.3 assurance or engineering-justification record, typed status record whose FPF status pattern is named, A.2.8 U.Commitment, exact A.2.8.PER permission result, C.11 ChoiceResult, C.11 decision record, A.6.A action invitation, one A.15.1 dated Work occurrence admitted under U.Work, a separate episteme about that occurrence, A.15 U.WorkPlan, U.Method, U.MethodDescription, carrier relation, or front-end relation

    Use the selected row only when the EntityOfConcern distinction changes the sentence. State the recovered participant, publication-unit use, review target, or ordinary topic directly; preserve any claim-bearing episteme, declaration, representation, source wording, and reader use that actually remains current. The ordinary result is the repaired sentence or a blocker, followed by the local F.19 reread.

    publication-unit wording that implies authoring or interpretation work

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

    If local wording meant...Rewrite as...
    bounded human-inspected unit inside a publicationPublicationUnit
    the act of writing or editingauthoring or editing Work when one dated occurrence is current; otherwise a planning cue or content inside an already admitted U.WorkPlan when only intended work is current. An exact episteme is U.WorkPlan only after A.15.2 recovers one present EntityOfConcern, one horizon, at least one PlanItem, and substantive coordination claims about possible future performed work. When the sentence instead concerns the authored object, use a separately identified claim-bearing episteme under its own exact kind. Any production or change relation between the Work and that episteme needs its own defining rule or pattern. The authored episteme is U.MethodDescription only if its exact EntityOfConcern is one admitted U.Method and its claims independently pass A.3.2; the writing or editing act is never the MethodDescription.
    a pattern body or sectionFPF pattern body, pattern section, or PublicationUnit of that pattern
    a file or rendered mediumcarrier, front-end, rendering, or document with named source-basis, evidence-basis, architecture-basis, or review-basis relation or use
    a publication formpublication form
    a generic publication facegeneric publication face, or U.View only when the relevant view pattern states that relation
    a declared MVPK facedeclared MVPK face, and U.EpistemeView only under MVPK constraints
    a claim-bearing episteme or episteme species named by valueselected U.Episteme, episteme-lane U.View with explicit episteme tether, or episteme species named by value; when current availability matters, name the exact EpistemePublicationRelation occurrence separately

    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, make the basis explicit: state the relation when a relation claim is being made, state the admissible-use boundary when a boundary-use claim is being made, and name the exact project-side kind and reference 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. Record those values in relationClaimSlice, admissibleUse, and projectSideFPFRef, respectively, only when the receiving claim needs the named fields.

    surface, view, face

    Do not treat these as synonyms.

    WordFirst split
    viewU.View, U.EpistemeView, reader viewpoint, UI view, declared-substrate interpretive view, or review view
    facegeneric publication face, declared MVPK face, UI face, or public-facing companion publication
    surfaceTreat as trigger wording, not as an accepted Tech head. Recover one of: publication face, publication form, publication unit, carrier, rendering, UI or front-end face, physical or geometric surface, companion publication, companion or projection material, carrier relation, or another FPF object named by value.

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

    source, target

    These are relation words, not final kinds.

    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:

    Problem wordingRecovery needed
    target version in improvement proseObjectVersionUnderImprovement or ObjectVersionUnderQualityEvaluation, unless target is quoted source wording
    pattern carrierFPF pattern publication form when the pattern is the publication form; file carrier or rendering only when the system-side bearer is being claimed
    object evaluation when the evaluated kind is knownobject-under-improvement evaluation name, such as PatternQualityQBundle, DRRDecisionAdequacyEvaluationCharacteristicSpace, FPFPillarAdequacyEvaluationCharacteristicSpace, or declared local evaluation
    thing, object, target, artifact, or material as final headFPF kind named by value, project-side FPF kind, or blocker

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

    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 for a two-sided supervisor-subholon feedback relation; use the direct subject pattern for any other control or control-layer relation and C.30.LCA for a control-structure view;
    • 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

    These words are cues when the sentence hides who or what uses what, for which claim or action, and what changes as a result. State that ordinary sentence first. Pattern application can usually be written as Use P to ...; publication use, reliance, evidence, Work, gate, decision, and other governed uses go directly to their subject patterns once the object and relation are clear.

    For a bounded or supported-use claim, name the admissible action and its basis. State an excluded adjacent or stronger use only when it satisfies the grounded-guard test in F.19:4. Do not turn a document into a generic capability or replace the sentence with an inventory of every nearby FPF kind.

    Use C.2.P when a source or publication use remains hidden, A.6.P when a direct predicate or participant remains unclear, and E.10.ARCH when fact, declaration, report, and representation are still confused. Name relationClaimSlice or projectSideFPFRef only when the receiving claim actually consumes that identity.

    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.

    Coordination and FPF-governed lists

    Apply F.19 first: ask whether the receiving use needs a series at all. If one governing claim, relation, or representative case would do, write it and remove the catalogue. A broader umbrella head is not a repair.

    When a series is needed and its FPF meaning remains unresolved, distinguish the current use:

    • a closed set, with its classified kind, membership rule, and closure;
    • illustrative examples, with the proposition or kind first and a non-exhaustive cue when completeness is plausibly ambiguous;
    • explicit alternatives or a sequence;
    • several obtaining direct relations, each with its actual participants;
    • a reusable relation declaration, with its RelationSignature and A.6.5 SlotSpec values; or
    • a C.29 representation, with its elements, represented objects, and correspondences.

    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 none fits, leave the ontology or architecture question blocking instead of making the list itself a new kind. Even when one case fits, keep only members whose distinction changes the receiving use.

    strong, stronger, weak, weaker, support

    Use strength wording only when the sentence makes the comparison dimension clear. Examples of more precise wording:

    • 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;

    A named scale, evidence class, threshold, or CharacteristicSpace supplies the comparison when that is the dimension used.

    Treat support as a cue to write the concrete subject, predicate, object, and use. If that sentence states a clear direct relation, use the pattern that defines or constrains it. If the predicate or a participant remains unclear, use A.6.P; if both are clear and no current pattern supplies the rule, use A.6.RCD. Use A.6.6 when the claim is specifically basedness.

    When the phrase carries a bounded-use claim, state the admissible action. Add a stronger or adjacent non-use only when it satisfies the grounded-guard test in F.19:4. A support-headed durable name reaches F.18 only after the governed object and use are settled; otherwise replace the head locally or leave the meaning blocked.

    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 to make the relation explicit when a relation claim is being made, the admissible-use boundary when a boundary-use claim is being made, and the project-side FPF kind and reference named by value when that side is being used. Record the corresponding values in relationClaimSlice, admissibleUse, and projectSideFPFRef, respectively, only when the receiving claim needs those named fields. For an unused side, record absence only when a named receiving use must distinguish it from missing information.

    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 perform a global string replacement. Use search only to locate candidates; read each natural span through F.19, preserve accepted FPF names unless a separate naming decision changes them, and let the selected review or campaign carry corpus coverage.

    case, scenario, example, pilot, anti-case

    Use F.19 to decide whether the text needs several cases, whether each changes recognition or action, and whether an illustrative series could plausibly be mistaken for a complete classification. State the proposition or kind first and mark examples as non-exhaustive when that ambiguity is live.

    If the word also carries an exact FPF use, name that use directly—for example a project situation, worked example, pilot, negative control, evidence case, comparison case, or source example—and apply its subject pattern. Do not reproduce this menu in the repaired prose.

    A case may illustrate or test a pattern. It becomes evidence, a decision basis, a source basis, or another governed object only through the relation and rule that establish that use, not through the label case itself.

    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 its primary subject 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.

    Deleting live or replacing it with another status word is useful only when the changed sentence now states the ordinary bearer and claim. Otherwise recover the governed state, currentness, temporal, source-use, or relation value, or leave the meaning blocked; then rerun the local F.19 reading.

    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.

    Using the cue surface

    During normal reading, keep the compact cue surface available rather than loading every detailed lexical table. A search term or grouping mark can locate a candidate span, but absence of a cue is not clearance and presence is not a defect. Read the complete natural span through F.19; open one detailed E.10 row only if an FPF wording question survives that reading.

    Multi-span and corpus use

    For a document or corpus, the selected review or editing method defines coverage and manages attention. Search may group likely candidates, but each accepted change comes from reading its natural span and produces repaired text or a blocker; E.10 adds no separate coverage or progress inventory.

    Compare recurring FPF-governed heads across the bounded object, especially a selected name, heading, table column, schema field, coordinate name, status value, or reusable authoring term. Also compare a head that carries the local architecture across substantive claims, replaces another broad head, or carries a finding or accepted basis into the final wording. If the repeated head conceals different governed objects or relations, split or rename those uses and reread the affected spans. Ordinary polysemy remains acceptable when each local meaning is clear; repetition alone is not a defect. Check the replacement head as well, so that a new umbrella does not merely preserve the old ambiguity.

    If the declared scope is the whole document or corpus, representative examples do not establish coverage. That coverage obligation belongs to the review or campaign that selected the scope; it does not turn E.10 into an inventory format.

    Recovery and disposition

    What remains after F.19Disposition
    Ordinary meaning is clearRepair locally, reread the changed sentence, and stop.
    One lexical, register, morphology, or token question remainsUse only the applicable detailed E.10 rule.
    A governed relation, kind, source use, declaration, report, representation, state, characteristic, or durable name remains unclearUse the exact route in E.10:0.2a; return the selected pattern's concrete result to the sentence.
    Meaning cannot yet be recoveredLeave the wording quote-only or source-only where appropriate, or state the blocker.

    Closure rules

    Closure is the repaired text, the concrete result of the one selected subject pattern, or a blocker. A pattern citation or trigger label alone is not closure.

    After any wording or syntax change, rerun F.19 on the changed sentence and only the neighboring text needed to settle its meaning. Check that the replacement preserves the intended kind, relation, scope, and action without introducing another umbrella or unsupported branch.

    When the positive sentence settles the use, close with that sentence and return to the domain task. Additional evidence belongs only to a receiving review or decision that actually needs it.

    Optional wording-repair note

    Use these fields only when a receiving review or decision needs an inspectable wording-repair note:

    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.

    SelectedInterpretation retains that closed value set. If none of its classifications fits the current subject-specific repair, use the selected subject pattern's own result instead of silently extending the lexical form.

    When a wording-repair note needs formal fields, record one plainIntent before the technical fields. Use E.10.ARCH for the fact, declaration, report, or representation branch only while that distinction remains unresolved. 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.

    Problem frame

    Current name set. F.19 owns the common semantic and pragmatic reading of the natural span. E.10 supplies the compact cue surface and detailed lexical, register, naming, and morphology rules for one unresolved FPF wording use. E.10.ARCH and the subject patterns own deeper recovery; later lexical material does not reopen a second general prose method.

    Intent. Provide a normative lexical cue and repair rule set that keeps FPF wording composable across sources and uses. Authors, reviewers, and tooling use the subordinate material only after E.10:0.2 has selected one unresolved lexical question:

    • 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

    ForceTension to resolve
    Universality and local fitKernel stays universal while exact sources, practices, schemes, and uses retain their needed local distinctions.
    Brevity and clarityShort names help, but only if morphology signals the right governed kind.
    Stability and evolutionNames should survive refactors while accommodating new roles and kinds without explosion.
    Pedagogy and precisionPlain words aid learners; Tech labels anchor formal checks.

    Solution - compact cues with exact lexical routes

    Apply the connected F.19 reading to the complete natural span. If ordinary meaning settles the issue, repair the text and stop. Only a surviving FPF lexical question opens the subordinate LEX-BUNDLE or ULR material.

    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. The retained detail covers vertical register stratification, Tech and Plain pairs, token generality, naming morphology, overloaded FPF heads, and conformance of durable lexical choices. Use only the detail needed for the selected problem.

    This subordinate material does not replace F.19, E.10.ARCH, a selected precision-restoration pattern, the concrete pattern for the recovered claim, or F.18. F.19 governs the ordinary semantic and pragmatic reading. 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.

    Use the exact subject pattern as soon as the governed object and claim become clear. After the lexical repair, reread the changed sentence through F.19 and return to the substantive task.

    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.

    ArenaMorphology examplesCandidate system labelCandidate local system-role kindSeparate source cue or ambiguityAvoid
    Software engineeringBuildTransformationFlowStructureDescription, CIHarnessSpecRepoTeamMaintainerSystemRoleRepoX is a repository or source cue; name the exact maintenance practice or source edition only when it changes the claimBuild Process, Repo Owner
    Applied research and experimentationSamplingMethodSpec, CalibrationLineageCarrierReviewPanelReviewerSystemRoleGrantCallY is a source cue; name its edition and review practice when they matterSampling Algorithm (if prose), Lab Owner
    Production and service managementShiftWork, SafetyOfficerSystemRoleTeamAlphaSafetyOfficerSystemRolename the exact plant-operations practice, source, or working situation if it changes the claimSafety Officer as a U-kind, SafetyDomain Governance
    Operations research and optimisationRoutingMethodDescription, CostCharacteristicAnalysisGroupModelStewardSystemRoleORProgram is a source or practice cue; recover the exact use that changes the claimRouting Function, Model Owner
    Healthcare and clinical opsCarePathwayTransformationFlowStructureDescription, MedicationAdministrationWorkDrKAttendingPhysicianSystemRolename the exact ward practice, source, or clinical situation if it changes the claimCare Process, Ward Owner
    Finance and accountingReconciliationMethodSpec, JournalPostingWorkTreasuryTeamTreasuryStewardSystemRolename the exact book, source edition, or treasury practice if it changes the claimReconciliation Process, Account Owner (underspecified)
    Legal and complianceRetentionPolicySpec, InvestigationWorkPrivacyOfficeDataProtectionOfficerSystemRolename the exact policy source, organization practice, scope, and edition when they matterCompliance Function, Data Owner (underspecified)
    Cloud and IT operationsIncidentTransformationFlowStructureDescription, RunbookMethodSpecOnCallEngineerTeamSystemOnCallEngineerSystemRoleOnCallRotation is schedule or roster wording under L-SCHED, not a holder; name the exact service source, operating practice, or situation if it mattersIncident Process, Service Owner (underspecified)
    Logistics and supply chainPickingWork, RoutingMethodSpecDispatchTeamSystemDispatcherSystemRoleDispatchDesk is an ambiguous desk label, not a holder; name the exact hub practice or scope if it mattersPicking Process, Fleet Owner
    Construction and civil engineeringPermitAcquisitionTransformationFlowStructureDescription, InspectionMethodSpecSiteInspectionTeamSystemSiteStewardSystemRoleSiteOffice is an ambiguous place or office label, not a holder; name the exact project lot or site practice if it mattersInspection Process, Site Owner
    Emergency responseTriageMethodDescription, EvacuationTransformationFlowStructureDescriptionResponderSystem-17IncidentCommanderSystemRoleIncidentLead is title-like role wording, not a holder; name the exact incident situation or response practice if it mattersTriage Function, Incident Owner
    AgricultureIrrigationTransformationFlowStructureDescription, SoilSamplingMethodSpecFieldTeamFieldStewardSystemRolename the exact plot, source, or field practice if it changes the claimIrrigation Process, Field Owner

    Checklist before minting a KernelToken

    • Head noun signals kind (Onto1).
    • EntityOfConcern and Description-episteme boundary and specification-use morphology correct (Onto2).
    • If 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)

    Tech (authoritative)Plain (didactic)Notes and guards
    U.Systemsystem, machine, teamBare “service” is never a safe Plain twin for U.System. Apply L-SERV only when a relied-on use hides the concrete subject or next route, then use A.6.P:4.11a; quoted, historical, illustrative, and harmless ordinary wording stays outside. Avoid “service-instance”; after recovery use “system instance”, “service access point”, “service offering”, or another head phrase supplied by the pattern for the recovered claim.
    U.Epistemebody of knowledge, document, dataset, modelThe pair preserves the Carrier and Content distinction (A.7).
    U.Methodhow‑to, procedure (abstract)Do not call this “process” (L‑PROC).
    U.MethodDescriptionaccount of how one identified method is donerecipe, SOP, playbook, code, and spec-text are recognition cues, not automatic twins. Use this pair only after the claim-bearing episteme has one admitted U.Method as its exact EntityOfConcern and passes A.3.2's substantive-description threshold; call out Spec separately only after the E.10.D2 gate.
    U.Workwork (work kind)This plain twin names the admitted kind only. A run, execution, activity, job, or case can name one Work individual only after A.15.1 grounds that occurrence; show an explicit occurrence name and the head work occurrence rather than reusing the kind twin.
    one exact local ...SystemRole kindreviewer (system role), maintainer (system role)Local kind for entities independently admitted as U.System. On first use, say which systems can count, what work-facing condition separates members from relevant non-members, and what changes preserve that distinction. A practice or source reference may help readers find or compare the definition; it does not identify the kind. The Plain wording creates no system admission or assignment.
    U.PromiseContentpromise, offering, service offeringNever equate to provider system or API (L‑SERV).
    U.Capabilityability, capacity (within bounds)Separate from a system-role kind, system-role assignment, Method, and Work; carries its own envelope and measures.
    U.Dynamicslaw of change, model of evolutionNot a capability or a method.

    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 and didactic placement. Use Tech names in Conformance Checklists, predicates, type signatures, and acceptance clauses. Reserve Plain twins for didactic use.

    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.

    U.NameTokenLEX.TokenClassNamed value and subject patternStable admitted use
    U.SystemRoleAssignmentKernelTokendirect assignment family under A.2.1exact Core definition, directly declared species, typed reference constraint, conformance check, worked case for the same family, F.18 NameCard, or F.17 row
    KindUseAdaptationDeclarationKernelTokenC.3.4 declaration-episteme familyexact Core definition, typed declaration or constraint, conformance check, worked case for the same family, F.18 NameCard, or F.17 row
    KindUseAdaptationCorrespondenceDeclarationKernelTokenC.3.4 correspondence-declaration familyexact Core definition, typed declaration or constraint, conformance check, worked case for the same family, F.18 NameCard, or F.17 row
    KindUseAdaptationJudgmentKernelTokenC.3.4 three-valued judgment familyexact Core definition, typed judgment or constraint, conformance check, worked case for the same family, F.18 NameCard, or F.17 row
    SystemRoleKindDescriptionKernelTokenF.4 description-episteme constructionexact Core definition, typed description or constraint, conformance check, worked case for the same construction, F.18 NameCard, or F.17 row
    SystemRoleAssignmentStateRelationKernelTokenA.2.5 direct relation kindexact Core definition, directly declared relation use or typed constraint, conformance check, worked case for the same relation, F.18 NameCard, or F.17 row
    SystemRoleAssignmentStatePredicateKernelTokenA.2.5 predicate-value familyexact Core definition, directly declared predicate use or typed constraint, conformance check, worked case for the same family, F.18 NameCard, or F.17 row
    SystemRoleKindRelationStructureKernelTokenA.2.7 selected-structure constructionexact Core definition, typed structure use or constraint, conformance check, worked case for the same construction, F.18 NameCard, or F.17 row

    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)

    For BusinessService wording, use U.PromiseContent when the recovered claim concerns promised content; for Function wording, use U.Capability when it concerns a system's ability; for NaturalProcess wording, use U.Dynamics when it concerns a law of change. Each recovered claim must satisfy its subject pattern. 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.

    SuffixKind named by suffixEntityOfConcern and Description-episteme boundary and specification-use gateLEX.TokenClass gateExamplesTypical inadmissible uses
    SystemRole (compound ending)One exact local system-role kindThe kind is independently admitted under C.3 and A.2 through its U.System candidate domain, operative work-facing membership condition, member/non-member boundary, and continuity rule. Practice or source provenance only locates or prompts comparison of the definition. The name supplies no assignment, agency, capability, or Work.ContextTokenTransformerSystemRole, ApproverSystemRoleBare ...Role; participant, declaration, representation, evidence, status, standard, source, constraint, commitment, or publication-use readings.
    MethodOne semantic way of doingEntityOfConcern sideKernelToken or ContextTokenSteriliseInstrumentMethodAttaching an episteme edition or carrier version to the Method. When one exact method-description edition matters, use a separate governed U.EpistemeRef and only the narrow edition selector defined by A.3.2; keep tooling and carrier versions separate.
    MethodDescriptionClaim-bearing episteme about one exact admitted methodDescription episteme only when its claims make at least one substantive statement about that method as a way of doingKernelToken or ContextTokenSteriliseInstrumentMethodDescriptionAdmission by recipe, procedure, algorithm, code, diagram, document form, or label; calling it "process"; encoding runtime actuals; embedding an edition or carrier version in the conceptual name.
    ...SpecTestable specification (acceptance-bound)Description episteme admitted for specification useKernelToken or ContextTokenMethodSpec, TransformationFlowStructureSpec, SystemSpecUsing “Spec” without acceptance tests or harness; treating formal notation alone as specification; putting runtime actuals here.
    WorkWork occurrence kind or an occurrence classified under itU.Work is the admitted world-side kind; one Work individual is a dated occurrence. A run log, ticket, assertion, description, or record about it is a separate U.Episteme.KernelToken for the kind; ContextToken for an individual or record with an explicit distinguishing headU.Work; W#Seam134WorkOccurrence; W#Seam134WorkRecordPlans and schedules; design-time recipes; using a run record as the occurrence; defining a Work subkind by an act label; storing actual relations as occurrence fields.
    WorkPlanClaim-bearing episteme coordinating possible future performed workSame-individual dependent kind of U.Episteme only when A.15.2 recovers one present EntityOfConcern, one horizon, at least one PlanItem, and substantive coordination claimsContextToken after membershipMaintenanceWorkPlan_Q3 only after the A.15.2 gateAdmission by schedule, window, planned item, ticket, calendar, or plan-record form alone; logging actuals; claiming execution.
    Service (recovery trigger only)No kind is named by this suffix before recovery; afterward use the head that names the recovered object or relationApply L-SERV and A.6.P:4.11a to recover the promise content, commitment, bearer, Method, Work, acceptance, publication or API description, or direct relation actually used; preserve the EntityOfConcern/Description-episteme boundary and specification-use gate under the pattern for that claim.Trigger wording only; any retained ContextToken must already name the recovered object or relation and its useobject-storage service promise; passport-issuance service-access claimUsing Service as a final durable head-kind; naming teams or APIs as Service; treating the possible readings as one bundle.
    CapabilitySystem abilityEntityOfConcern sideKernelToken or ContextTokenScheduleGenerationCapabilityMislabeling system-role kinds, assignments, or methods as capabilities.
    DynamicsLaw or model of changeEntityOfConcern sideKernelToken or ContextTokenLotkaVolterraDynamicsUsing for abilities (Capability) or recipes (Method).
    ObservationObservation record or kind(run record; not EntityOfConcern and Description-episteme or specification use)ContextToken or DiscriminatorTokenVibrationObservationMixing with MethodDescription or Evaluation.
    EvaluationEvaluation episteme or evaluation recordDescription episteme or Description episteme admitted for specification useContextToken or DiscriminatorTokenCalibrationEvaluationUsing to name system-role kinds, assignments, or methods.
    EvidenceRole (retired trigger only)Source evidence-role wording; recover evidence-use, source-use, status-use, assurance-use, gate-use, or publication-use relation.Trigger wording, not a system-role kindTrigger wordingevidence-use, status-use, source-use, or publication-use relation named by its direct patternUsing as a system-role kind, U.SystemRoleAssignment, or generic evidence.
    EpistemeEpistemic knowledge unit (structural)Description episteme or Description episteme admitted for specification useKernelToken or ContextTokenTraceabilityEpistemeColliding with CHR ReferencePlane (never suffix “Plane”).
    System or HolonSubstantial entityEntityOfConcern sideKernelToken or ContextTokenAnesthesiaSystem, OrderFulfillmentHolonUsing to denote a source, scheme, local-use qualifier, or run record.
    BoundarySystem boundaryEntityOfConcern sideKernelToken or ContextTokenSterileFieldBoundaryUsing as a system-role kind or method.
    ObjectiveTarget stateEntityOfConcern side or Description episteme side, depending on formalizationKernelToken or ContextTokenHemostasisObjectiveEncoding acceptance tests in the objective. Put tests in the specification governed by their actual subject; use MethodDescription or MethodSpec only when that subject is one admitted U.Method, A.3.2 membership holds, and the specification-use gate is present.
    Requirement (trigger only)No FPF-wide suffix meaning. Recover the constraint, commitment, completeness condition, result expectation, dependency, sufficiency condition, availability or relevance state, or coverage constraint.Trigger wording; a durable local-use token exists only after its lexical admission rule is satisfied.Trigger wording or a ContextToken named for the recovered constructionlatency constraint under its constraint pattern; U.Commitment when accountable undertaking is currentPublishing Requirement as a general head or suffix; treating unlike constructions as one kind.
    Context or BoundedContext (trigger or established source term only)No FPF-wide kind or card is named by this suffixApply E.10.D1. For the established DDD term, use A.1.1 and name the exact model-use relations or selected BoundedModelUseStructure; for another use, name the actual source, scheme, scope, situation, frame, or local practice that changes the action.Trigger wording or an already admitted local-use tokenquoted DDD bounded context; source label retained as source wordingMinting U.BoundedContext, a mandatory Context Card, or a generic identity container.
    surface (trigger only)Not a durable Tech head by itself; recover publication face, form, unit, carrier, rendering, UI face, physical surface, geometric surface, or another FPF object named by value.publication availability or ordinary source wordingTrigger wordingpublication face, interop publication form, carrier relationStructureSurface, MechanismSurface, PortfolioSurface
    CardUTS or record unit (episteme)Description episteme, Description episteme admitted for specification use, or publication-unit use, depending on FPF kind named by valueContextTokenMethodCard, ExternalIndexCardEncoding runtime actuals; using as a ‘Service’

    Suffix conventions and retained-family boundaries

    SuffixLexical classMeaning and ontologyWhere it livesExamples and notes
    SpaceEntityOfConcern-side kindA typed state space (finite product of declared Characteristic×Scale components); no proceduresKernel A.19; CHR and space consumersCharacteristicSpace, CreativitySpace. Any episteme that defines or describes the Space remains separately identified. A selected definition edition is itself one exact U.Episteme; the Space is not editioned.
    SpaceRefPointerGoverned reference to one exact SpaceDirect reference pattern; data fields and UTSCharacteristicSpaceRef resolves to the exact Space. When a use depends on one exact Space-definition episteme, carry a separate governed field typed by U.EpistemeRef whose referent is that episteme; only its direct reference pattern may define a narrow edition selector.
    MapEntityOfConcern-side kind (method)One exact mapping U.Method from subjects to coordinates in a declared SpaceA.3.1 and the method-family pattern; Description epistemes remain separateDescriptorMap names the method only after A.3.1 admission. A claim-bearing episteme about that exact method may separately qualify as U.MethodDescription; a representation, record, or file does not.
    MapRefPointerGoverned reference to one exact mapping U.MethodDirect method-reference pattern; data fields and UTSDescriptorMapRef resolves to the method. If the use depends on one exact method-description episteme, carry a separate governed field typed by U.EpistemeRef; do not attach an edition selector to the method reference.
    DefRegistry-local alternate tokenA direct CG-Spec registry may use ...Def for one exact governed definition or specification item; the suffix alone does not decide whether that item is an episteme, formal object, method, formula, or publication formExact CG-Spec registryDistanceDef is admissible only inside the registry that defines its referent kind and use. Prefer ...Spec in new normative prose when an exact Description episteme has actually been admitted for specification use; do not generalize ...Def as an FPF-wide suffix.
    DefRefPointerRegistry-local reference whose exact referent kind and RefKind are defined by the direct CG-Spec registryExact CG-Spec reference pattern; data fields and UTSDistanceDefRef is admissible only when that registry says what it resolves to. If a use must pin one exact CG-Spec episteme, carry a separate governed field typed by U.EpistemeRef and use only a selector defined by that registry's direct reference pattern for that episteme edition. Do not treat ...DefRef as a global synonym for ...SpecRef.
    SpecDescription episteme admitted for specification useTestable invariants bound to acceptance harnessesE.10 and A.21Stable, testable definitions; normative by default; admitted for specification use. Use for normative calculi plus scoring and normalization specifications.
    SlotRelation-declaration suffixDeclaration-local SlotKind inside one exact A.6.5 SlotSpec of a reusable RelationSignature; it distinguishes one relation-participant meaning and is neither the actual participant nor a representation placeA.6.0 RelationSignature; A.6.5 SlotSpec declarationEntityOfConcernSlot, GroundingHolonSlot. A mathematical operand or argument place remains a C.29 representation element until explicit correspondence; operation argument and result declarations remain under A.6.1. Position and place are not alternate FPF names for a declaration slot.
    RefPointerReference or identifier whose RefKind is admitted by its direct reference pattern; a receiving assertion or relation-occurrence-description episteme may carry a field typed by that RefKind to designate an actual participant, but the reference, field, and participant remain distinctDirect reference pattern; receiving episteme fields and UTSU.EntityRef, U.HolonRef; episteme fields …Ref : U.EntityRef. …Ref never carries content and is never a ValueKind, SlotKind, or actual participant.
    SeriesConditional collection or structure labelNot an edition mechanism. Several exact EpistemeEditionRelation occurrences may be selected as a lineage structure only when one named receiving use depends on their organization; any selected edition collection and its membership remain separateC.2.1 with A.22 for the selected structure and A.14 for any collectionDo not mint U.EditionSeries; order, shared title, or collection membership establishes no edition continuity.
    edition selectorReference selector defined by its direct patternOptional only on a governed reference whose referent is one exact U.Episteme and whose direct reference pattern defines the selector; it selects an already recoverable edition and establishes neither episteme identity nor historical continuityDirect reference pattern and C.2.1signatureRef.edition is admissible where A.6.0 defines that narrow selector. Do not infer a universal <Thing>Ref.edition property.

    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; or project-side FPF kind and reference. Ordinary wording may close locally when it carries no such FPF claim.

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

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

    L-Space - Disciplined use of Space

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

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

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

    L‑ruleAmbiguous or low-precision word (Ban)Canonical FPF target(s)EntityOfConcern and Description-episteme boundary and specification-use gateTokenClass gateNotes
    L-PROCprocess, practice, procedure, workflow, activity, a process-like function step, or method-structure wordingFirst decide what the sentence is about. Use A.3.4.P for a change situation and U.Method for one way of doing. Name composition, substitution, iteration, fallback, selection, family membership, or another method-side relation under the rule that defines it. Only when a named use depends on how several such relations are organized should the practitioner use A.22's criterion to select a structure, locally called MethodRelationStructure. Use U.MethodDescription only for an episteme whose EntityOfConcern is one admitted Method and whose claims substantially describe how to perform it. Keep a planning cue or schedule representation as such until A.15.2 admits a U.WorkPlan; use U.Work only for dated performance, and a separate episteme for its record. After E.10.ROLE, recover a local system-role kind and classification, an obtaining U.SystemRoleAssignment, or an A.2.7 relation only when work-facing wording actually states it. Other branches include an A.1.1 BoundedModelUseStructure when model-use organization changes the answer, an exact source, practice, scope, situation, discipline or cultural-evolution use, U.Transformation, TransformationFlowStructure, and C.29 notation.Method, direct method-side relation, optional A.22-selected method relation structure, one-method Description episteme, other subject-description episteme, planning cue or WorkPlan, Work occurrence or Work record, system-role kind and classification, assignment, relation among system-role kinds, model-use structure, source or practice boundary, discipline or source label, Transformation or transformation-flow structure, or selected lensKernelToken for admitted kinds; ContextToken for admitted local-use designations, occurrences, and records; lens or register when representation is currentA phrase such as “industrial process as line role” first uses E.10.ROLE; it creates neither a system nor a ...SystemRole kind. Chemistry enters U.Transformation, U.Dynamics, or Method only after the claim is recovered. Practice is not a root kind, and procedural, planning, or document form establishes neither U.Method, U.MethodDescription, nor U.WorkPlan.
    L-FUNCfunction, functional, functionality, effectApply A.6.F first when kind or relation is hidden. Possible recovered values include U.Capability, U.PromiseContent, U.Method, one dated Work occurrence admitted under U.Work, mathematical function or operator under C.29, and functional-architecture or architecture-to-TransformationFlowStructure relation under C.30, C.30.ASV, or C.30.TFS-REL.EntityOfConcern side for Capability, PromiseContent, Method, Work occurrence, mathematical object, architecture relation, or transformation-flow relation; any record about Work remains a separate Description epistemeKernelToken or ContextToken according to the recovered value and useNever use function as a Core kind name or as default architecture meaning.
    L-SERVservice or access-like wording used for provision, a team, software process, deployed component, endpoint, application, host, cluster, access point, offering, ticket, case, Method, or WorkApply this row only when relied-on FPF wording hides the concrete subject, participant, predicate, kind, permission, Work occurrence, or next question. Bare service has no default system reading: ordinary wording may name service-provision Work, a Method, PromiseContent, participation, or another direct claim, while software wording may be metonymic for a process, deployed component, endpoint, application, host, or cluster. Apply E.10 and A.6.P:4.11a to recover the hidden choice. Quoted, historical, illustrative, or harmless prose remains outside.Carry the original wording and relied-on use into A.6.P:4.11a. The recovered object and relation establish what the claim is about; the applicable pattern supplies any EntityOfConcern/Description-episteme boundary or specification-use gate. Use A.1.SCR only after A.6.P has named a bearer claim and the decision depends on systemhood; E.10 supplies neither classification nor a new kind.Keep the source token's register and class until the claim is recovered; no TokenClass choice admits a kind.Ask what stopped, what is provided, how it is provided, or which bearer must be restarted. Do not normalize service to server/system, Method, Work, PromiseContent, permission, or fulfilment. If the concrete subject, relation, or dependent use still cannot be named, stop the relied-on use. Record missing-governor[...] only after participants, needed predicate sentence, and dependent use are named but no current pattern supplies that predicate.
    L-SLASLA or service level agreement used for an SLO, accountable undertaking, published terms, or a documentUnpack acceptance thresholds into U.PromiseContent.acceptanceSpec; accountable obligations or penalties into U.Commitment; the packaged SLA through A.6.C into its separate promise, utterance or publication, commitment, Work or consequence, and evidence claims; and published terms into a speech act plus clause episteme. Keep Work, measurement, evidence, and acceptance verdicts separate.EntityOfConcern side for PromiseContent, Commitment, and any actual Work; episteme side for clauses, specifications, measurements, evidence, records, and verdictsKernelToken, ContextToken, or DiscriminatorToken according to the recovered value and useTreat SLA as polysemic shorthand, never one kind or Work record.
    L-SCHEDschedule, plan, or calendar as executionKeep a schedule, planned window, or calendar as source wording, a planning cue, or a representation until one exact episteme passes A.15.2's present-EntityOfConcern, horizon, PlanItem, and substantive-coordination predicate; only then use U.WorkPlan. For actual performance, identify one Work individual independently under A.15.1; telemetry, actuals assertions, and run records remain separate epistemes about obtaining facts.Source or representation until the gate; Description episteme for an admitted WorkPlan and for records versus world-side Work occurrenceContextToken only after the local-use designation or record is admittedNever infer U.WorkPlan from an intent window or schedule label, attach actuals to a plan, treat telemetry as Work, or store actual relations as occurrence fields.
    L-ACTactivity, action, task, or step as typeRecover the actual object before choosing the value: one dated U.Work occurrence; a separate work-record episteme when only a record is current; U.Method only for an independently recovered submethod of a composite Method; a C.29 representation element or claim-content constituent when the step appears only in code, diagram, recipe, or procedure; U.MethodDescription only when the claim-bearing episteme has one exact U.Method as EntityOfConcern and passes A.3.2; or a planning cue or PlanItem inside an admitted U.WorkPlan. If only order, fallback, substitution, or dispatch is current, name that direct method-side relation; use an A.22-selected MethodRelationStructure only when the receiving use depends on how several such relations are organized.Work occurrence, record episteme, Method, direct method-side relation, representation or claim-content constituent, MethodDescription, planning content, or optional selected method relation structureContextToken for an admitted local-use designation, occurrence, or record; otherwise the token class of the recovered valueReserve assign for an exact system-role assignment, satisfy for the A.2.5 assignment-state predicate, perform for Work, actuate for a System, and approve for the exact speech-act use. A verb, visible step, or planned-item label defines none of those objects by form.
    L‑AGENTagent, actor, or doer (bare)Recover the acting entity and admit it as U.System only when A.1 passes. Ordinary actor wording may stay ordinary when no precise agency or Work claim is consumed. For a precise Agent claim, apply A.13: exact local agential system-role kind and criterion, classification, obtaining assignment, scope, working situation, window, and adequate core evidence; add a characteristic profile only for a consumed Grade, autonomy or profile result, criterion-dependent characteristic, or assurance use. For performed Work, A.15.1 then independently admits the dated occurrence from its actual performer basis, Method, time, and containment. Only afterward does F.6 establish any precise assignment-bound attribution through the same obtaining assignment. A compact attribution rewrite keeps the combined basis recoverable and may omit only an unused assignment identifier after attribution is established.Acting entity or admitted System; optional A.13 local-kind/classification/assignment claim; independently admitted Work; separate F.6 relation when precise assignment-bound attribution is current; separate assertion or description episteme when currentKernelToken or ContextToken according to the recovered value and useA title, source or scheme cue, capability, evidence item, declaration place, assignment, or actor-like label establishes none of systemhood, classification, agency, profile, Work, or attribution.
    L‑OWNERowner of XRecover what ownership wording says in this claim. Keep owner when an actual architectural, organizational, policy, source-maintenance, responsibility, authority, or commitment relation is current. If the claim is instead a work-facing system classification or assignment, start with E.10.ROLE and use A.2 or A.2.1.Exact ownership or responsibility relation, exact local system-role kind, exact direct assignment species, ordinary wording, or blockerContextToken only when an admitted local-use designation is actually currentNo global owner property; no lexical replacement of a precise architectural owner; no assignment inferred from a title.
    L-CAPcapability for assignment, recipe, run, or promiseU.Capability means ability within an envelope. Keep an exact system-role kind, direct U.SystemRoleAssignment species, U.Method, dated U.Work, Work record, and U.PromiseContent separate under their patterns.EntityOfConcern side for capability, method, system-role kind, assignment, and Work occurrence; one-method Description episteme only after membership; separate run-record epistemeKernelToken or ContextToken according to the recovered value and useA system-role kind or assignment establishes no capability; a recipe form or record establishes neither MethodDescription membership nor Work.
    L‑DYNprocess of diffusion, growth, or learningU.Dynamics (law or model of change)EntityOfConcern sideKernelToken or ContextToken according to the recovered value and useReserve for uncaused change models.
    L‑EVID“paper or dataset proves or ensures”Recover the evidence-use, source-use, status-use, assurance-use, gate-use, or publication-use relation under A.10, B.3, F.10, G.6, E.17, C.28, or the rule that defines the recovered use relation. Use U.SystemRoleAssignment only for a separate exact assignment that currently obtains, whose holder is an admitted system and whose assigned participant is one exact local system-role kind.Episteme with exact claim target and direct use relation; any system-role assignment remains separateContextToken or DiscriminatorToken according to the recovered value and useEvidence use is a relation over an episteme and a claim or use; the episteme is not a system-role holder.
    L‑CTXcontext wording whose action-changing content is hiddenApply E.10.D1; recover the subject-defined value or relation that changes the action—for example, a scheme, scope, model-use boundary, situation, design-time or run-time referent, architecture, environment, domain subject, or local-practice use.Apply the pattern for the recovered subject and name its EntityOfConcern and any claim-bearing episteme; introduce no generic Context participant or card.Keep the recovered subject's token class; the spelling context selects none.Keep quoted and ordinary uses, and established uses already defined by a pattern. Rewrite only the use that hides the next action or stop.
    L-BRIDGEsameness, equivalence, alignment, or mapping inferred from a shared labelIdentify the two exact local senses first. If the F.9 predicate is being asserted, address each sense as an exact F.17 SchemeSenseCell and apply F.9 only when the direct Bridge relation actually obtains; state any bounded use and any A.10 or B.3 reliance separately.The Bridge relates the two exact cells. A card, row, label, score, or publication is a separate episteme or representation and makes no relation obtain.Keep each source expression under its effective scheme.A shared label creates neither a Bridge nor substitution, merge, admission, authorization, or performed use.

    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 only after the compact cue surface selects the named lexical problem. Accept a repaired sentence when its object, head kind, relation or claim, use, and scope are preserved, the applicable § 7 or § 8 rule passes, and the changed sentence passes the local F.19 reread. If an example would change the kind in the current sentence, split the claim or leave a blocker; do not copy it as a ready-made rewrite.

    Trigger symptomRecovered ontology example
    “the process owner approves”Start with E.10.ROLE for the title-like wording. If owner names an architectural or responsibility relation, keep that relation instead of forcing a system-role reading. State ApproverSystemRole separately only when the classification matters. If approval is precise performed Work, recover ApprovalSystem through A.13 and let A.15.1 independently admit the dated Work. Add F.6 only when the sentence 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. Keep the approval speech act, authority, and decision separate.
    “the document enforces policy”Policy_vN states the policy used by the applicable gate, constraint, commitment, or evidence relation. When enforcement Work is current, name its actual performer, admit the dated Work through A.13 and A.15.1, and add F.6 only for a precise assignment-bound attribution. Add PolicyEnforcementSystemRole only when that classification changes the claim.
    “our service runs nightly jobs”Apply L-SERV and A.6.P:4.11a first. If the sentence means dated service-provision Work performed by a scheduler system, recover that exact actual performer through A.13 and let A.15.1 independently admit the Work. Add F.6 only when the sentence 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. Add SchedulerSystemRole only when that classification matters. Promise content remains separate.
    "the API is the service"Apply L-SERV and A.6.P:4.11a. A reusable way of access may be API_Access_Method : U.Method; a claim-bearing interface specification is an episteme and becomes U.MethodDescription only under A.3.2; an addressable endpoint is a separate bearer; use A.1.SCR for it only when the claim depends on systemhood. Any API publication form/carrier remains separate, and promise content states the promised result and acceptance criteria. The source wording chooses none of these by itself.
    “capability assigned to team Y”Split the claims. TeamY may be an admitted System that has Capability C within envelope E. If the wording also means a work-facing classification, name its local system-role kind; if it means an assignment, name the occurrence with TeamY as holder and its declared U.SystemRoleAssignment species. Capability, classification, and assignment do not establish one another.
    “process health green”Apply A.19.SPR: name the bearer, state frame, value green, criteria or evidence, admissible use, and change condition; the color alone does not establish health or acceptance.
    “function of component A fails”Apply A.6.F. If the recovered claim is behavior performed as Work, recover the exact actual performer system through A.13 and let A.15.1 independently admit the dated Work. Add F.6 only when the sentence 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. Add ServiceOperatorSystemRole only when that classification matters. The evaluation result separately records failed acceptance on the cited observations.
    “context is unclear here”Apply E.10.D1 and name what changes the interpretation or next action: the exact source and edition, effective scheme, claim scope, model-use structure, working situation, frame, referent, or local practice. If two local senses are compared, identify them; assert an F.9 Bridge only when its direct relation between exact cells actually obtains.

    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. Agentive predicates and metonymy. A doubtful agentive or causal predicate—including a negated one—calls for the whole-span F.19 check. Retain ordinary, unambiguous metonymy; otherwise state the capable participant or the exact non-agentive relation. Add a denial only for a grounded plausible misreading whose correction matters.
    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.

    Optional detailed lexical checks (informative)

    Use this section only after F.19 and the compact cue surface have selected a lexical, register, morphology, or naming question.

    • Sections 5 and 6 distinguish lexical strata and Tech/Plain register use.
    • Section 7 tests token generality, domain anchoring, local source meaning, and acronym use.
    • Section 8 governs morphology, suffixes, compounds, aliases, and entry lexemes.
    • Section 9 contains deep recovery rows for an already-selected overloaded FPF head.
    • F.18 governs a durable reusable name after the value and use are settled.

    Open only the subsection that can change the sentence. Repaired text or a blocker, followed by the local F.19 reread, is sufficient. Create a DRR or other preservation evidence only when a separate receiving decision requires it.

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

    Use only the prompt selected by the compact route. Do not answer all prompts for every wording repair; § 7 and § 8 retain their own exact conformance uses.

    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. Relation and representation prompt. Does the sentence state its ordinary relation and participants? If the distinction among an obtaining fact, reusable declaration, claim or report, and representation remains unresolved, use E.10.ARCH; if it is already clear, use the exact subject pattern without inventorying the other branches.
    7. Support interpretation prompt. Write the concrete relation first. Keep ordinary or quoted support; otherwise use the direct subject pattern, A.6.P only for an unclear predicate or participant, A.6.RCD only after both are clear but no current pattern supplies the rule, and A.6.6 for basedness. Section E.10:0.2c.18 carries the examples; do not recreate its alternatives in the repaired sentence.
    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. Predicate-compatibility cue. When evidence, a document, publication, pattern, representation, or method is the grammatical subject of an agentive or causal predicate, read the complete span through F.19, including negation and modality. Retain clear ordinary metonymy; otherwise state the capable participant's action or the exact non-agentive relation positively. Open A.1, A.13, A.15.1, or F.6 only when precise agency, Work, or attribution is part of the claim.
    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. Use the precision-before-coarsening rule in F.19:4; the selected lexical prompts here locate the unresolved head, qualifier, or comparison question.

    Archetypal grounding: three concise examples (informative)

    These examples show the repaired claim first. Open the exact Work, attribution, publication, or naming apparatus only where the receiving use needs it.

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

    Repair, taking service here to mean the ward team: “Schedule Incision_221 in OR_Case_221_WorkPlan for 08:00, using IncisionMethod. SOP_OR_v4 states the incision-readiness constraint. QAApprovalSystem performs the approval; record its speech-act content and the resulting GateDecision separately; that decision admits the planned run. The ward team records Patient_221's recovery in RecoveryRecord_221.”

    Formal plan membership. 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.

    Actual approval Work. 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.

    Separate source claims. If the source also specifies a monitoring promise or an access method, recover those additional claims separately: 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. These are additional claims, not replacements for recording recovery.

    Manufacturing (assembly line)

    Messy: “The welding function provides air-tight seams; the process costs 3 min.”

    Repair: “Robot_SN789 can execute Weld_MIG_v3 within envelope E at measures M. The run WeldWork-SN789-4711 lasts three minutes and changes the workpiece joint. Use the recorded measurements to check the duration and the seam's air-tightness acceptance criterion.”

    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

    Messy: “The storage service wrote logs and the deployment process failed after 2 min.”

    Repair: “sCGSpecCIBot performed DeployWork-r4711, which failed after 120 seconds. LogWriterSystem performed LogWritingWork-r4711.”

    Admit each Work occurrence through A.13 and A.15.1; add F.6 only for a current assignment-bound attribution. Treat sCG-Spec_ci_bot#DeployerRole:CD_v7 as a source expression and recover CD_v7 separately. Use DeployerSystemRole or TransformerSystemRole only when the classification changes the claim.

    Separate source claims. If the source also specifies durability and availability targets as a storage promise, recover them in ObjectStoragePromiseContent. If it supplies an access-method description, identify that separate episteme as S3_API_Spec_vX and preserve the method it describes.

    Bias-Annotation

    Scope: FPF-governed wording-use repair; ordinary ungoverned language remains outside this pattern.

    BiasHow E.10 prevents it
    Lexical-substitution biasE.10 starts with trigger scan and governed-object recovery, not synonym replacement.
    Umbrella-to-umbrella biasRecover the recognizable object and relation, then name only the exact FPF value or pattern contribution that changes the sentence.
    Semio-biasWording-use repair does not displace the EntityOfConcern; descriptions, publications, and source-use relations stay separate from the object or claim under concern.
    Misallocated activityAssign action to the capable participant, or state the pattern's defining, constraining, guiding, or descriptive relation positively.
    Source-provenance-as-prose biasSource wording can be quoted or bounded as source-only, but live FPF prose states the current norm rather than narrating where a term came from.

    Conformance checklist

    Use this checklist when changing an E.10 rule, a governed token, or a durable lexical decision. Ordinary sentence correction returns repaired text and needs no recorded checklist.

    1. The cue is treated as a locator, not a ban or verdict.
    2. The complete natural span has been read through F.19; an ordinary repair stops there.
    3. Any deeper route is the smallest pattern that owns the unresolved FPF kind, relation, source use, register, morphology, or name.
    4. The replacement preserves the intended object, kind, relation, scope, and action and does not substitute another umbrella head.
    5. The accepted text contains the concrete sentence or selected pattern result, not a menu of possible interpretations or a mandatory rejected overread.
    6. The changed sentence and its meaning-dependent neighbors pass the local F.19 reread.

    Common anti-patterns and how to avoid them

    Anti-patternSymptomCorrection
    Umbrella replacementsupport becomes basis, route becomes path, or posture becomes status without a clearer claim.State the ordinary object and relation; use one exact route only if an FPF question remains.
    Cue as verdictA listed word is automatically banned, formalized, or counted as a defect.Read the complete span through F.19; retain ordinary and already precise uses.
    Activity assigned for grammatical symmetryA pattern, document, evidence item, or representation receives an agentive predicate because the sentence needs a subject.State the capable participant's action or the exact non-agentive relation positively. Keep ordinary metonymy when it is established and clear.
    Mandatory neighboring overreadEvery positive claim is followed by an imaginable but ungrounded non-use or stronger conclusion.Keep a guard only when a plausible intended reader has independent local grounds for that reading and the correction changes use.
    Catalogue instead of resultThe repair lists every possible kind, pattern, or interpretation without selecting the current one.Write the governing sentence, select the one applicable route, or leave the unresolved meaning blocking.

    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

    Practice question. When wording carries an FPF-governed claim, what is the least costly authoring discipline that either closes one local repair or reaches the rule for the exact object, relation, claim, or use without turning a glossary into a second ontology?

    Selected best-known line. Use one cheap trigger scan, recover the governed object or relation before renaming, apply the direct defining or testing rule, preserve the remaining reader use, and stop. This line combines the current FPF precision-restoration patterns with established terminology and controlled-vocabulary practice only for the objects those sources actually govern.

    Serious alternative or default. Synonym substitution, a central preferred-word list, and copied local warning catalogues are cheaper to start. They fail here because they can leave the obtaining relation, participant, claim-bearing episteme, admissible use, or direct owner hidden while making the sentence look more precise.

    Defect overcome and comparable effort. Clear ordinary wording exits after one scan. A load-bearing phrase takes one bounded recovery and one direct-pattern use; that is no more work than searching several local glossaries and is better because it returns an actionable claim or an explicit blocker. The deliberate cost is an honest reduced-use or blocked result when the object cannot be recovered.

    Mutation and source roles. The internal FPF row supplies the governing local architecture; ISO and W3C terminology or vocabulary sources constrain object, concept, designation, label, and publication uses; language-scent and accessibility sources inform cue preservation and discoverability. None of the external sources assigns FPF kinds or relation truth. The exact mutations are the trigger registry, direct-owner exits, phrase-level rewrite rules, entry projections, and Relations named in the rows below.

    Practice sourceUse of source and source-currentness claimWhat E.10 adoptsWhat E.10 rejects
    Current FPF precision-restoration pattern-set edition used here on 2026-07-20, especially A.6.P, A.6.RCD, C.2.P, E.24.CD, E.24.PUB, F.18, and F.19.Current problem-solving basis for FPF wording repair: F.19 owns the whole-span semantic and pragmatic reading; A.6.P recovers an unclear direct predicate or actual participant and tests the existing direct relation; A.6.RCD handles only the residual relation-bearing claim. Each other named pattern contributes only its kind, relation, publication boundary, naming use, or phrase repair.Keeps the compact cue and routing surface aligned with the deep relation, episteme, publication, ontic, and naming patterns without copying their apparatus into ordinary prose repair.Do not turn E.10 into a second relation, episteme, publication, ontic, naming, or general-language ontology.
    ISO 704:2022, Terminology work — Principles and methods, edition 4, 2022-07.Current external terminology-work source for links among objects, concepts, definitions, and designations and for term formation after those distinctions are recovered.Mutates the object-first scan and durable-name boundary: recover the governed object, relation, or claim before forming or preferring a designation.Do not treat terminology work as proof that a project relation obtains, as a substitute for the direct FPF rule, or as a central word list that assigns FPF kinds.
    Zhu, Reinecke, and Mitra, Language Scent: Exploring Cross-Language Information Navigation, arXiv:2604.03604, 2026.Current preprint extending information-scent work to cross-language navigation; its formative and laboratory evidence is promising but small and does not establish universal label equivalence.Mutates E.10:0.2b, E.10:8.5a, and F.17 coordination: admit compact in-situ entry cues when they preserve the named value and help a reader choose the right local interpretation; when a claim relates two local senses, identify them and use F.9 only if its direct Bridge predicate actually obtains.Do not infer global synonyms, a universal multilingual term registry, or cross-local equivalence from similar labels or a small study.
    W3C SKOS Reference for controlled structured vocabularies and lexical labels, with heavier OWL and RDF ontology practice used only by ontology-bearing patterns named by value.Current reference source for controlled-vocabulary publication and label relations; not current-best source for every FPF wording repair.Mutates E.10:0.2b, E.10:0.2c.18, and E.10:0.2c.28: keep vocabulary labels, concept-like heads, registries, maps, and reusable names recoverable as publication or naming objects named by value before reuse; F.18 defines durable naming, while relation, source, or domain ontology remains with the pattern that defines or constrains that claim.Do not make OWL-style term-to-class modeling the default answer to every vague term. Do not let a controlled vocabulary become a second FPF ontology or replacement wording-recognition table.
    W3C WCAG 2.2 headings and labels guidance plus consistent-identification guidance, with FPF-internal E.11, README, ToC, and I.2 entry-distribution practice.Current reference source for discoverability and label consistency; FPF entry projection remains the governing local architecture.Mutates E.10:0.2b, E.10:0.2c.29, E.10:19, and E.11 coordination: keep trigger wording discoverable enough for first repair, but make final wording, appropriate pattern use, and entry projection govern the result.Do not turn wording-recognition lists into local lexical registries, front-door taxonomies, or accepted replacement vocabulary. Do not let search convenience select ontology.

    The practical result is lexical governance that improves action guidance and semantic composability. Reopen only the internal rows whose defining pattern changes its kind, authority boundary, or recovery result; reopen the in-situ-cue choice only if stronger language-scent evidence changes cue usefulness for the intended readers; reopen the terminology, vocabulary-publication, or discoverability rows only if the cited standard changes the object, designation, label, publication, or navigation contribution used here. A source locator, publication-status, popularity, or unused-example change alone does not reopen E.10.

    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 governed name grows through coordination → use F.19 to ask whether a series is needed, then apply MG-DA only if the name still hides one kind, alternatives, a relation, or a bundle. Two members may already be excessive; a long required designation may be sound. Bare role first uses E.10.ROLE.
    • A slash, and, plus, &, repeated pair, nested list, or modifier chain appears in FPF-governed wording → read the natural span through F.19 before editing the mark. Retain conventional notation and required sets. If an FPF kind, alternative, direct relation, declaration, or representation remains hidden, use the selected E.10 or subject route; do not infer the defect from the character or item count alone.
    • 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.
    • An agentive or causal predicate is attached to a doubtful subject → read the whole span through F.19, including negation and modality; retain established metonymy or state the capable participant or exact non-agentive relation positively.
    • A verb or relational noun loses a needed participant → restore the object, destination, source, bearer, or other operand when one value is not cheaply and uniquely recoverable; open a deeper FPF route only if that participant is itself governed.
    • A generic head or support-headed compound acquires an FPF claim or bounded use → restore the head kind first. If support still hides a direct predicate or participant, use the selected E.10 route; otherwise state the concrete sentence and apply its subject pattern.
    • Wording about a way of doing or a neighboring object changes → use the selected method-side rule in E.10:0.2c or section 9 to recover the exact object or relation. Do not replace one umbrella with method, practice, mechanism, algorithm, or workflow.
    • A declarative representation starts to sound imperative → recover the represented object and correspondence through C.2.P.DR, C.29, or the exact subject pattern. Treat a path, table, dashboard, formula, or pattern relation as action only when an action claim is actually established.
    • 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.

    Quick card

    Read the complete natural span with F.19. Use E.10 cues to notice an overloaded head, doubtful agentive or causal predicate, ungrounded contrast, missing operand or referent, grouping or list pressure, loaded qualifier, or source/representation ambiguity. If ordinary meaning settles it, repair the text and stop. Otherwise open one exact lexical or subject route. The result is repaired text or a blocker, never a mandatory form or catalogue of possible meanings.

    • Use sections 5–9 only for the selected register, token, morphology, or overloaded-head problem.
    • Use E.10.ARCH only while fact, declaration, report, and representation remain confused; use the subject pattern directly once the claim is clear.
    • Use F.18 only for a durable reusable name after its value and use are settled.
    • Treat every trigger as a cue rather than a spelling ban. Two coordinated members may already be needless; a long required set may be sound.

    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: “F.19 reads the claim; E.10 opens only the unresolved lexical branch.”

    Relations

    • Builds on: F.19 for whole-span semantic and pragmatic repair; A.7, C.2.1, E.17, E.24, A.6.0, A.6.5, and F.18 for the exact distinction or durable name that remains after that repair.
    • Coordinates with precision-restoration patterns: E.10.ARCH, E.10.DEV for unresolved development or evolution wording, 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-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)