#Part C — Kernel Extension Specifications

Preface node heading:part-c-kernel-extension-specifications:40684

#What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

#Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

#Content

#Epistemic holon composition (KD-CAL)

Scope & exports. A substrate‑neutral calculus for composing epistemic holons (U.Episteme) and reasoning about their motion and equivalence. Exports: (i) three point‑characteristics—Formality F, ClaimScope G, Reliability R—that locate a single episteme; (ii) a pairwise ladder of Congruence Levels (CL 0…3); (iii) four Δ‑moves (Formalise, Generalise/Specialise, Calibrate/Validate, Congrue); (iv) composition rules (Γ_epist) for aggregates; (v) propagation laws for CL through mappings and notation bridges. KD‑CAL is typed by U.EpistemeSlotRelation and never confuses ClaimGraph, EntityOfConcernSlot, GroundingHolonSlot, Viewpoint, View, ReferenceScheme, notation, publication form, or carrier. All F–G–R computations are context‑local; Cross‑context traversals require an explicit Bridge with CL and apply the B.3 congruence penalty Φ(CL) to R. // Contexts ≡ U.BoundedContext; substitution is plane‑preserving only.

Formality F is the rigor characteristic defined normatively in C.2.3. All KD‑CAL computations and guards SHALL use U.Formality (F0…F9) as specified there; no parallel “mode” ladders are allowed.

#Problem Frame

FPF fixes two archetypal sub‑holons: U.System (physical/operational) and U.Episteme (knowledge holon). KD‑CAL is the primary composition pattern for U.Episteme, giving engineers a compact, testable way to say (a) how strictly an episteme is written (F), (b) how much structure it manages (G), (c) how well it is warranted by evidence or severe tests (R), and (d) how closely two epistemes coincide (CL). KD‑CAL is built atop C.2.1 U.Episteme — Epistemes and their slot relation, which reifies every episteme through U.EpistemeSlotRelation: ClaimGraph, EntityOfConcernSlot, GroundingHolonSlot, Viewpoint, View, and ReferenceScheme. Notation, publication forms, carriers, and work occurrences remain outside episteme content and are linked by their own FPF relations.

#Problem

Teams routinely entangle programs, specifications, proofs, and datasets; a “proof” is treated as a tested routine, a “program” is cited as if it entailed a theorem. Trust decays because justification and evidence freshness are not explicit. Epistemes are anthropomorphised as actors (“the standard enforces…”), producing category errors at execution. Without a shared composition and equivalence calculus, aggregates hide weakest links and analogies harden into overclaims. KD‑CAL must stop these failure modes with a single constitution and scale‑set.

#Forces

• Universality vs domain idioms. One calculus must cover physics theories, legal codes, safety specs, algorithms, and formal proofs without flattening their differences.
• Meaning vs materiality. Meaning must be independent of carrier, yet accountable to it historically.
• Deductive vs empirical. Axiomatic certainty and empirical trust have different evidence-continuity profiles; both must compose.
• Abstraction vs enactment. Epistemes constrain action; systems act. The calculus must keep the roles distinct.

#Solution

#Coordinates and the episteme slot relation

KD‑CAL characteristics (single‑episteme, point‑values).

• Formality F. From free prose to machine‑checkable proof/specification. Litmus: would a machine reject it if wrong?
• Claim scope (G), a set‑valued applicability over U.ContextSlice, with ∩/SpanUnion/translate algebra; CL penalties apply to R, not to F/G. Litmus: how wide is the declared scope, and under what minimal assumptions does the claim hold?
• Reliability R. From untested idea to continuously validated claim. Litmus: where is the last successful severe test? R‑claims MUST bind to evidence and declare relevance windows; stale bindings degrade R or require waiver per ESG policy.

Congruence Level (CL), pairwise ladder. CL‑0 Opposed/Disjoint (contrastive; no substitution); CL‑1 Comparable / Naming‑only (label similarity; no substitution); CL‑2 Translatable / RoleAssignment‑eligible (structure‑preserving mapping in a declared fragment with stated loss; theorems may transport); CL‑3 Near‑identity / Type‑structure‑safe (invariants match; type‑structure substitution allowed). CL is a characteristic of a relation between two epistemes; it is not a fourth member of the F–G–R assurance tuple and it is not a characteristic space of its own. Norm: substitution is permitted only if plane‑preserving and CL ≥ 2; substituting type‑structure requires CL = 3.

Slot-relation link. The assurance components are stated over U.EpistemeSlotRelation: F by the internal ClaimGraph and formal substrate, G by the ClaimScope attached to the EntityOfConcern and assumptions, and R by evaluation templates and evidence bindings. Notation belongs to representation and reference-scheme structure; carriers remain outside the episteme and link through SCR/RSCR or other exact carrier relations. Multiple notations are allowed only when their relation is explicit; authors SHOULD register NotationBridge(n₁,n₂) with an associated CL to make conversion loss explicit.

#Four Δ‑moves (epistemic motion)

• ΔF — Formalise. Rewrite for stricter calculi/grammars; raise proof obligations.
• ΔG — Generalise / Specialise. Widen or narrow the claim scope (assumptions & scope). Changes to decomposition granularity are an orthogonal view and do not change G unless they alter the envelope.
• ΔR — Calibrate / Validate. Strengthen severe tests or add live monitoring; update evidence bindings.
• ΔCL — Congrue. Establish and record the sameness relation between two epistemes (ladder 0→3). Moves compose into paths; CL along a path is the minimum of its links.

#Composition (Γ_epist) and propagation

Let Γ_epist combine epistemes {Eᵢ} into a composite episteme Γ that makes a joint claim (AND‑style) or exposes an interface (series composition). KD‑CAL imposes safe defaults:

• R (Reliability). Along any justification path P, compute R_eff(P) = max(0, min_i R_i − Φ(CL_min(P))) (weakest‑link with congruence penalty). For series composition (claims needed conjunctively), the path‑wise weakest‑link applies; for parallel support (independent lines to the same claim), use R(Γ) = max_P R_eff(P) (annotate independence); never exceed the best attested line. Cross‑context steps and NotationBridge traversals contribute to CL_min(P).

• F (Formality). F(Γ) = minᵢ F(Eᵢ) (monotone non‑increasing along used paths). To raise F, apply ΔF to the weakest parts.

• G (ClaimScope). On any dependency path, take the intersection of claim scopes (the narrowest overlapping scope). Across independent support paths to the same claim, set G(Γ) = SpanUnion({G_path}) constrained by support (drop unsupported regions). Widening/narrowing the scope is an explicit ΔG± operation.

• CL (Congruence). For a chain of mappings E₀ ~ E₁ ~ … ~ Eₖ, the path congruence is min CL(Eⱼ,Eⱼ₊₁). Passing through a NotationBridge sets CL to the bridge’s declared level; the Φ(CL) penalty is applied in the R fold for any path that traverses it.

These rules keep Γ aligned with the holonic kernel: Γ is only defined on holons and respects identity/boundary discipline from the core.

#What must not be conflated (normative guards)

• Representation structure ≠ carrier. Files, PDFs, or repositories are carriers outside the episteme; they never count as parts of U.Episteme (see C.2.1 EP‑1; CC‑EPI‑2/3).
• Epistemes do not act. Only systems perform work; epistemes carry constraints and evaluation criteria through their ClaimGraph, EntityOfConcern, grounding holon, scope, and evidence bindings (per Core A.15 / CC‑EPI‑3).
• CL is not a score. It is a qualitative ladder of preservation classes; do not average it.

#✱ Archetypal Grounding (Tell–Show–Show)

Universal rule (tell). Compose knowledge by Γ_epist with weakest‑link R, monotone F, and explicit CL on every bridge; keep ClaimGraph, EntityOfConcern, grounding holon, viewpoint, view, reference scheme, notation, publication form, and carrier in their FPF relation named by values.

System (show, Sys‑CAL lens). Consider a battery‑pack thermal subsystem integrating a physics model of heat flow and an operating envelope for fast‑charge. As a system, it composes pumps, sensors, and controllers by physical Γ with conservation constraints (Sys‑CAL). The assurance story depends on epistemes about the model and envelope; the system acts, epistemes constrain. (Archetypes and boundary discipline per core.)

Episteme (show, KD‑CAL lens). Consider a CMIP‑class climate projection episteme (post‑2015 generation): its ClaimGraph covers PDEs and parameterisations; its EntityOfConcern and grounding holon identify what projection claim is about and how it is grounded; its ClaimScope names historical forcings, resolution, and assumptions; its representation may include domain equations and a tabular schema linked by a NotationBridge with an explicit CL. Compose sub‑epistemes for radiation, clouds, and ocean mixing: R = min across the critical path; an independent hindcast line can raise R only up to its own level; F is bounded by the least‑formal sub‑claim unless the composition adds formal invariants.

#Bias‑Annotation

• Metric worship. Treating [F,G,R] as ends rather than means; mitigation: require evidence bindings and narrative of limits in the claim scope and grounding envelope.
• Category slip. Equating a notation or carrier with ClaimGraph, EntityOfConcern, or grounding holon; mitigation: slot-relation and carrier separation under C.2.1.
• Analogy inflation. Presenting CL‑0/1 as identity; mitigation: always name the CL rung for cross‑mappings.

#Conformance Checklist

1. C2‑1 (Slot relation). Every U.Episteme MUST satisfy C.2.1 slot discipline for ClaimGraph, EntityOfConcernSlot, GroundingHolonSlot, Viewpoint, View, and ReferenceScheme; carriers link through SCR/RSCR or other exact carrier relations and are never parts of the episteme.
2. C2‑2 (Coordinates). Each episteme SHALL declare [F,G,R] with a brief rationale; F is U.Formality ∈ {F0…F9} per C.2.3, exactly one episteme‑level F computed as the min over essential parts. CL is declared for pairs only. Sub‑anchors: ** Contexts MAY mint named sub‑anchors (e.g., F4[OCL], F7[HOL]), which MUST preserve the global order and map to their parent anchor from C.2.3.
3. C2‑3 (Composition). Authors SHALL choose Γ_mode (series vs parallel). For any justification path use R_eff(P) = max(0, min_i R_i − Φ(CL_min(P))); for parallel independent lines to the same claim, take R(Γ) = max_P R_eff(P) (never exceeding the highest-R support line). Compute F(Γ) = min along the used paths. For G, use path‑wise intersections and then SpanUnion({G_path}) constrained by support. Cross‑context traversals MUST use a Bridge with CL and apply Φ(CL) to R.
4. C2‑4 (NotationBridge). Multi‑notation representation components SHOULD register NotationBridge edges with CL and loss note; any cross‑notation reasoning MUST cite the bridge’s CL.
5. C2‑5 (No action). Epistemes MUST NOT be assigned actions; work is executed by systems in role.

#Consequences

Benefits. A single, compact map for all knowledge epistemes or publications; fast detection of weakest‑link R in aggregates; disciplined reuse across domains with explicit CL; consistent separation of meaning from material carriers. Trade‑offs. Authors must learn to declare Γ‑mode and CL explicitly; multi‑notation work requires bridge bookkeeping; mitigation: the episteme slot relation and CL scale keep the discipline brief and repeatable.

#Rationale

KD‑CAL turns the coarse legacy semiotic picture into holonic composition over U.EpistemeSlotRelation, where formal structure and claim scope (F,G), evidence (R), and cross‑mapping congruence (CL) are visible and composable. The explicit C.2.1 slot relation prevents carrier confusion; the characteristics provide a manager‑readable yet formalisation‑ready scale (with G grounded in scope/envelope, not part‑count); the CL scale replaces overloaded “alignment” with a typed sameness relation.

#Relations

• Depends on: U.Episteme — Epistemes and their slot relation (C.2.1): identity invariants, slot definitions, carrier separation, and evidence bindings.
• Peers: Sys‑CAL (C.1), which composes systems; KD‑CAL composes epistemes and feeds assurance lenses in Part B.
• Constrained by authoring: Architectural patterns must include Tell–Show–Show with Archetypal Grounding (this section).

#Worked mini‑examples (post‑2015 flavours)

• Formal lift (ΔF). Recasting a 2019 variational free‑energy narrative into a typed calculus raises F, clarifies scope, and enables CL‑2 bridges between biological and ML formulations—without claiming empirical gain (R unchanged).
• Parallel evidence (R, max). Two independent hindcast lines (circa CMIP6, 2019) supporting the same forecast allow R(Γ)=max(R₁,R₂); if one line drifts, the composite is bounded by the higher-R support line until series constraints apply.
• Notation bridge (CL drop). A 2021 type‑theoretic specification rendered in a semi‑formal DSL requires a NotationBridge with a CL<3 note; any theorem transported across must respect the bridge’s declared preservation.

(No tooling is implied; these are conceptual moves within the calculus.)

#C.2:End

#U.Episteme: Constitution, Empirical Grounding, and Edition Relations

Type: Pattern Status: Stable Normativity: Normative except where a section is explicitly marked informative

Plain name. Episteme constitution.

Mint or reuse. This pattern reuses U.Episteme, U.ClaimGraph, U.Entity, U.ReferenceScheme, U.Holon, U.Signature, RelationSignature, and SlotSpec. It introduces the direct relation names EpistemeConstitutionRelation, EpistemeEmpiricalGroundingRelation, and EpistemeEditionRelation; it introduces no U-kind. Each named ...RelationSignature below is the relation-facing use of one declaration episteme for which the A.6.0 membership predicate obtains; A.6.0 therefore recognizes that same individual as a U.Signature, not as another identity. The signature-local SlotKinds named below identify participant meanings only inside their stated signatures. An episteme itself has no slots, and repeated slot spelling in another signature establishes no shared SlotKind by spelling alone.

One-line summary. A U.Episteme is a knowledge holon identified by exact claim content, one exact EntityOfConcern, and the effective U.ReferenceScheme that makes those claims interpretable as claims about that entity. EpistemeConstitutionRelation is the core direct relation of the episteme ontic. Empirical grounding, viewpoint, view, scope, model use, edition succession, description, publication, carrier, and mathematical representation remain neighboring objects and relations.

Use this pattern when. Use C.2.1 when one body of claims about one exact subject, interpreted under one effective reference scheme, must be identified or compared. In ordinary words, identify what this body of knowledge says, what it says about, and which shared rules make that saying interpretable.

Changed claims, a changed subject, or a changed interpretation identify another episteme. Changed empirical grounding, viewpoint or view use, publication, form, carrier, or representation can leave the episteme unchanged; update the neighboring object or relation that actually changed.

A theory, model, specification, proof, or diagnosis can therefore be an episteme when the selected object is that claim-bearing whole. A diagram or dashboard has two branches: use C.2.1 when the selected claim-bearing whole satisfies the constitution test above; when the current object is instead its layout, file, display, or correspondence to something else, treat it as a publication form, carrier, or C.29 representation rather than as the episteme.

Primary working reader. An engineer or researcher who needs to identify a knowledge object and use it without mistaking its subject, file, view, evidence, or publication for that knowledge object.

Primary working concern. Keep one claim-bearing object reidentifiable through empirical grounding, viewing, revision, and publication, and detect when changed claims, subject, or interpretation identify another episteme.

Primary viewpoint. The practitioner using, comparing, revising, or publishing that knowledge object while keeping its identity and neighboring relations distinct.

Primary governed object. One U.Episteme: the claim-bearing knowledge holon being identified or compared.

Architecture in scope. C.2.1 also governs that episteme's EpistemeConstitutionRelation, EpistemeEmpiricalGroundingRelation, and EpistemeEditionRelation; it coordinates with the direct owners of viewpoint, view, scope, model use, description, publication, form, carrier, and representation.

Terminology guard. The EntityOfConcern of an episteme is the exact entity its claims concern. It is not the same field as the primary governed object of this pattern.

First useful move. Ask three ordinary questions: what is claimed, what exact entity are the claims about, and what designation and interpretation rules make those claims readable about that entity? Where the claims use measurement, comparison, or evaluation rules, name those applicable rules too. Those answers identify the episteme. If identity is all the task needs, stop there. Otherwise name the concrete receiving use—such as comparison, preservation, teaching, publication, inquiry, or decision—and add only the neighboring object or direct relation needed for its next visible sentence or action. Name an unresolved uncertainty or choice only when a real inquiry or decision has one.

What goes wrong if missed. A file or diagram becomes "the model"; a subject label drifts while the same episteme name is retained; the holon through which claims are empirically inspected, or the viewpoint from which claims are selected, is copied into episteme identity without justification; or a revised publication is mistaken for a changed knowledge object.

What this buys. Epistemes can be compared, revised, grounded, viewed, published, and used recursively while ordinary prose stays short. The complete distinction among the episteme, its direct relations, and their assertion, publication, and representation objects remains recoverable without making users restate every object for every claim.

Not this pattern when. Use the direct subject pattern when the current question concerns the system, work, method, relation occurrence, or other entity described by an episteme. Use A.1 for constructive recognition of a candidate under an admitted holon kind, C.3.2 for a local-kind membership judgment, and E.24.UK for FPF U-kind admission. Use E.17 and E.24.PUB for publication, A.10 and B.3 for evidence or assurance, C.29 for a mathematical representation, and E.10, C.2.P, or F.18 for precision restoration or naming. C.2.1 governs episteme identity, including the identity of a separately current classification assertion.

#Problem Frame

FPF treats an episteme as a holon, not as a document class or a filled record. A pump-maintenance specification, a clinical model, a theorem, a learned classifier description, and a curriculum model can all be epistemes when each is a claim-bearing whole about an exact EntityOfConcern under an effective reference scheme. Their carriers, notations, and admissible operations differ, but that difference does not remove the shared ontology question: what makes this one episteme, and what changes its identity?

The episteme ontic coordinates these distinct objects without collapsing them:

1. the U.Episteme knowledge holon;
2. direct relation occurrences that constitute, ground, or connect editions of that holon;
3. declaration epistemes whose C.2.1 identity is fixed independently, whose same individual has U.Signature membership under A.6.0, and whose relation-facing RelationSignature use declares reusable participant SlotSpecs for one exact relation kind;
4. assertion epistemes that claim a direct relation predicate obtains and description epistemes whose EntityOfConcern is one explicitly individuated occurrence;
5. publication occurrences that make one selected episteme edition available for a bounded audience and use;
6. publication forms that express the selected edition for that publication use;
7. U.PresentationCarrier entities that bear those forms;
8. C.29 mathematical representations that correspond to independently recovered objects for an explicit modeling or reasoning use.

The core constructive question is not which fields a card contains. It is whether an exact U.ClaimGraph, exact U.Entity, and effective U.ReferenceScheme stand in the relation that makes the claim content interpretable and evaluable as claims about that entity. When they do, their selected organization yields a whole-level epistemic characteristic: the resulting holon can be used as one defeasible or deductive body of knowledge. That characteristic is not supplied by any one participant alone.

Any exact U.Entity can participate as the EntityOfConcern. An episteme can therefore concern a system, work, method, relation occurrence, another episteme, or itself without changing the constitution relation. Episteme recursion does not introduce a second meta-episteme ontology.

Contemporary work on formal languages as cognitive tools, material and diagrammatic reasoning, distributed representations, and tool-assisted reasoning explains why representation regimes matter. C.2.1 preserves that insight by keeping representation and admitted operations explicit when current. It does not let notation, latent geometry, tool output, or a publication form determine episteme identity.

#Problem

Without one direct episteme ontology, several practical failures recur.

1. Carrier and episteme collapse. A PDF, database row, proof script, dashboard, or neural-model file is treated as the knowledge holon. File replacement is then reported as epistemic change even when claim content, EntityOfConcern, and interpretation are unchanged.
2. Subject drift. A specification or model keeps one label while the entity it concerns changes. Comparison and evidence use then combine claims about different entities.
3. Interpretation drift. The same tokens or graph are read under different designation, measurement, or evaluation rules while users assume one unchanged episteme.
4. Neighboring-relation collapse. Grounding holon, viewpoint, view, claim scope, model-use structure, evidence, edition, and publication become optional fields of one omnibus record. Their different obtaining and identity rules disappear.
5. Representation-first ontology. Tuple components, graph nodes, schema fields, and database keys are treated as actual relation participants or subject identity discriminators merely because a tool exposes them.
6. Agency leakage. A standard, model, method description, or claim graph is said to perform work. Systems perform work; epistemes participate in use, description, evidence, decision, and publication relations.
7. Dependent-kind identity fork. A method description or view is assigned another identity merely because its direct pattern supplies a membership condition. The same episteme can then appear twice, and a viewpoint or method-description use can be mistaken for a change of knowledge object.

The familiar Symbol-Concept-Object triangle can still introduce the difference among expression, meaning, and subject. It cannot serve as the ontology because it suppresses reference scheme, grounding, viewpoint, evidence, and the distinction between a relation and a representation of that relation.

#Forces

#Solution

Identify each U.Episteme through EpistemeConstitutionRelation: first state what it says, what exact entity it concerns, and the scheme under which those claims are read. Then name what the reader will do with that episteme. Add a neighboring relation only when the reader's next sentence or action requires it. Keep declaration epistemes, assertions, descriptions, names, references, publication occurrences, publication forms, carriers, and representations distinct under their direct patterns.

Local episteme mantra. Name the claims, what they concern, and the scheme that gives those claims their reference. Stop if identity is all the task needs. Otherwise name the concrete receiving use and add only the neighboring object or relation needed for its next sentence or action. Ask for an unresolved question only in a real inquiry or decision. Update episteme identity only when claim content, EntityOfConcern, or effective reference scheme changes; otherwise update the affected neighboring relation, publication occurrence, publication form, or carrier under its direct pattern.

The mantra is a recall aid, not a work plan. The application method and stop conditions are carried by sections 4.1-4.9; section 4.10 is a later reference for relation and neighboring-object distinctions.

#First-use completeness questions

Begin with the three questions that identify the episteme. They are identity questions, not fields to fill.

If the task needs only the episteme's identity—for example, to cite, catalogue, compare, teach, or reconstruct it—stop after the three answers. Otherwise state the concrete receiving use. Ask for an unresolved uncertainty or choice only when that use is a real inquiry or decision; comparison, preservation, teaching, and publication need no invented decision question.

Open a row below only when its first column names the reader's next sentence or action. Each positive answer adds an independently governed object or direct relation; none adds another slot or identity discriminator to the episteme.

Stop when no row describes the next sentence or action. A readable sentence naming the claims, EntityOfConcern, and effective reference scheme is then enough. Do not complete the table as a record. Use section 4.10 only when a later sentence or action actually needs the full relation and neighboring-object reference.

#Identify the episteme by its constitution

The shared C.2.1 identity of one U.Episteme is:

<claim content, exact EntityOfConcern, effective ReferenceScheme>

claim content is the identity-bearing U.ClaimGraph carried as the episteme's constitutive claim structure. Each episteme selects one exact U.Entity as the EntityOfConcern of the current claim-bearing whole. Its ClaimGraph may also designate other independently governed entities as participants in relational, comparative, negative, counterfactual, or modal claims.

When the subject really is an admitted relation kind, an already individuated obtaining relation occurrence, an admitted collection-as-whole, or another independently identified joint entity, that object may be the EntityOfConcern. Several participant designations do not by themselves constitute such an object. A negative or counterfactual relation claim can designate the relation kind and its participants in the ClaimGraph without requiring an obtaining world-side occurrence.

Split the ClaimGraph only when it combines independent subjects in a way that makes the selected EntityOfConcern untruthful or breaks the intended identity or comparison use; do not split merely because one predicate connects several participants. The reusable predicate-definition boundary is stricter: before publication, name one truthful exact EntityOfConcern and state what the definition claims about it. If no such single concern can be selected, remain at local compound-claim level.

The effective U.ReferenceScheme supplies the designation and interpretation rules needed to read this ClaimGraph as claims about this EntityOfConcern. Add measurement, comparison, or evaluation rules only when the claims' meaning uses them. The corresponding measurement or evaluation entities and relation occurrences remain under their direct patterns.

Formal near-miss: a theorem read under a formal vocabulary and calculus needs designation and interpretation rules, but it does not acquire ceremonial measurement or evaluation rules. Empirical contrast: a pump-tolerance episteme uses the applicable units, measurement procedure, and pass/fail criterion to make its claim meaningful; the actual measurement and evaluation occurrences remain neighboring objects rather than episteme constituents.

Changing any identity discriminator yields another episteme. Changing a carrier, layout, rendering, publication occurrence, evidence item, viewpoint assignment, or model-use setting does not by itself yield another episteme. A direct pattern may recognize the same individual as a dependent episteme kind through its stable membership condition, but it does not add another identity discriminator. [A.3.2](/generated/patterns/A.3.2) governs U.MethodDescription membership; [E.17.0](/generated/patterns/E.17.0) governs U.Viewpoint and U.View membership through fixed predicates over already identified epistemes. [A.6.3](/generated/patterns/A.6.3) governs an optional viewing construction between source and receiving epistemes, not view membership. If any work or construction changes claim content, EntityOfConcern, or effective reference scheme, those changed C.2.1 discriminators identify the resulting episteme, not the dependent-kind label.

This identity is constructive. The claim graph and reference scheme are epistemic constituents; the EntityOfConcern remains an independently governed entity related through aboutness and reference. When EpistemeConstitutionRelation obtains, their organization yields the whole-level characteristic of being one interpretable claim-bearing whole. The relation occurrence and the resulting episteme are distinct but reidentified from the same three discriminators.

#Govern the core direct relation

Tech name: EpistemeConstitutionRelation.

Plain reading: these claims, under this reference scheme, are claims about this exact entity and together constitute one episteme.

#Participants and the shared reusable-declaration rule

Before using any signature-local table, identify the declaration itself. Each of EpistemeConstitutionRelationSignature, EpistemeEmpiricalGroundingRelationSignature, and EpistemeEditionRelationSignature is first one exact C.2.1 episteme: its own U.ClaimGraph carries the declaration claims, its exact EntityOfConcern is the direct relation kind, and its effective U.ReferenceScheme makes those claims interpretable. For each of these three declarations the fixed A.6.0 membership predicate obtains, so A.6.0 independently recognizes that same episteme individual as a U.Signature. RelationSignature names the relation-facing use of that same individual; it is neither another U-kind nor another identity.

A complete declaration claim names the direct relation-kind designator, the exact A.6.5 SlotSpecs needed by reusable typed uses, the obtaining predicate, the occurrence-identity rule, applicability, and only the dependencies and provided names that are actually current. The direct relation kind, its actual participants, an obtaining occurrence, an assertion about it, a relation-occurrence description episteme, the declaration episteme, its publication, and a representation of any of these remain distinct. A receiving need may justify typed reuse but does not identify the declaration. One readable assertion needs no signature or manifest. An A.6.0 manifest is optional and is used only when actual dependencies or provided names must be exposed; a manifest row, list, citation, identifier, or edition marker creates neither episteme identity nor dependency.

Applying that shared rule locally, typed reuse of EpistemeConstitutionRelation uses the one declaration episteme EpistemeConstitutionRelationSignature, whose exact EntityOfConcern is EpistemeConstitutionRelation and whose declaration includes these SlotSpecs:

The SlotKinds belong only to this declaration. An actual claim graph, EntityOfConcern, or reference scheme is an actual relation participant under its independently governed kind. A card field or assertion designation corresponds to a SlotKind but does not become the participant.

#Obtaining and occurrence identity

EpistemeConstitutionRelation obtains exactly when the effective reference scheme supplies a coherent designation and interpretation of the claim graph as claims about the exact EntityOfConcern, and the three participants are constitutively organized as one claim-bearing whole whose claims can in principle be evaluated under that scheme. Merely placing three designations in a card does not make the relation obtain.

The relation occurrence is participant-determined by the exact <ClaimGraph, EntityOfConcern, ReferenceScheme> triple. The same triple cannot constitute two distinct U.Episteme instances under the shared C.2.1 identity rule. Recognition of that individual as a dependent episteme kind adds a membership judgment under the dependent kind's governing pattern, not another constitution occurrence or discriminator. A tuple may represent the triple under C.29, but tuple order and storage keys contribute nothing to identity.

The episteme and the relation occurrence are not identical. The relation is the obtaining organization among the three participants. The episteme is the knowledge holon constructively identified through that organization and its whole-level claim-bearing characteristic.

#Ordinary assertion, classification assertion, and explicit occurrence use

An ordinary assertion can state that claim content concerns an entity under a scheme without explicitly naming a relation occurrence. For every direct predicate, keep four jobs separate: the direct pattern defines participant meanings, the obtaining predicate, applicability, and the occurrence-identity rule; the current case supplies the facts that satisfy or fail that predicate; the assertion carries affirmative or negative polarity; and a separately governed evaluation or evidence-use relation states supported, refuted, or unresolved reliance when the receiving use needs it. When a receiving relation or claim needs the exact constitution occurrence, inspect the current ClaimGraph, EntityOfConcern, and ReferenceScheme facts against C.2.1's predicate. Only after those facts satisfy the predicate may the participant-determined identity rule individuate the occurrence for designation. The assertion, designation, occurrence, case facts, and reliance judgment remain different objects.

Each classification judgment has one pattern governing its criterion. A.1 governs constructive recognition of a candidate as an instance of an already admitted holon kind. C.3.2 governs a local-kind membership judgment. E.24.UK governs the ontology-level decision that admits a public U-kind; it does not classify a project candidate. None of these judgments is a direct admission relation created by C.2.1.

When project work needs a classification judgment as a separately reviewable claim, identify one claim-bearing episteme whose exact EntityOfConcern is the candidate entity. For an admitted holon kind, its claim content states affirmative or negative polarity for the exact classification predicate, names the kind, cites the A.1 constructive criterion and any kind-specific criterion, designates the direct part-relation occurrences used in the assessment, and cites any evidence-use relations that make supported, refuted, or unresolved reliance inspectable for the declared use. For a local kind, its claim content states the same polarity distinction for the candidate, local kind, selected KindSignature edition, context slice, and judgment governed by C.3.2; its reliance posture remains separate. A value classification inside another claim can remain claim content of that episteme instead of fabricating a value-shaped EntityOfConcern.

The assertion does not create the candidate, admit a U-kind, or make the candidate change kind when an FPF host is renamed or republished. For example, the assertion that Pump #37 satisfies the constructive U.System criterion may be revised when evidence changes, while Pump #37 and the criterion it satisfies retain their independently governed identities.

A card that calls a listed collection a holon is still only a classification assertion episteme. Its assertion polarity is affirmative, but the card alone leaves reliance unresolved for any use that requires A.1 to recover the exact constituents and grounded part relations, their constructive assembly, the whole's reidentification rule, actual compatibility with a governed larger-assembly construction, a composition-grounded whole-level characteristic, and the already admitted holon kind with its kind-specific criterion. The card form supplies none of those facts and does not make the classification predicate true.

The same constitution rule applies when a reader proposes to use an obtaining F.9 Bridge. Say first in ordinary words what the reader proposes to compare, substitute, translate, publish, or otherwise do; name the direction d, use-specific correspondence rule r, tolerated semantic loss t, and affirmative or negative polarity for named use u. Identify that statement as one ordinary C.2.1 assertion episteme: the exact Bridge b is its EntityOfConcern, its ClaimGraph designates <u,d,r,t> and polarity, and its effective ReferenceScheme makes those designations, the rule, and the tolerance interpretable. The exact <ClaimGraph, b, effective ReferenceScheme> triple identifies the assertion. Changing u, d, r, t, or polarity changes the claim content and therefore the assertion episteme, not fixed Bridge b. Keep this local claim form in ordinary wording: it introduces no public U-kind, universal use relation, or durable CamelCase claim name. Reopen F.18 only if an independent later use actually needs a reusable name.

An affirmative bounded-use assertion is one premise for that use; it is neither permission nor proof that the use occurred. A negative assertion leaves an otherwise obtaining Bridge in place. For ordinary bounded reliance below B.3's material-reliance threshold and with no assurance claim, A.10 separately governs the exact evidence-provenance graph relation and local RelianceDisposition: only pass supports this exact use, degrade supports only its named narrower use, and any other non-passing result supplies no support or routes the case to B.3 exactly as A.10 declares. When an assurance claim is made or the threshold is met, B.3 first decides whether a current assurance claim exists: the threshold requires the minimum reliance safety assurance record but creates no positive claim; use either a positive claim carrying the named use with its sufficient record or an exact no-assurance-claim or insufficient-record disposition that stops or narrows it. Neither branch authorizes the use. If the use actually happened, recover the actual Work under A.15.1, assertion episteme under C.2.1, publication occurrence under E.17, direct relation under its domain pattern, operation application under A.6.1, or another receiving object under its current owner.

#Add empirical grounding through its own relation

Tech name: EpistemeEmpiricalGroundingRelation.

Plain reading: these designated empirical claims of this episteme are inspectable through exact observation, intervention, measurement, or test relations involving this grounding holon.

C.2.1 uses explicitly designated partial coverage. For one candidate grounding occurrence, select one exact nonempty claim subgraph C from the episteme's already constitutive ClaimGraph. The occurrence says that every empirical claim in C is grounded; it says nothing about empirical claims outside C. To claim full empirical grounding for the episteme, C must contain every empirical claim in that episteme. Purely formal epistemes need no grounding occurrence merely to fill a record.

For every claim in C, state a concrete claim-to-world mapping under the episteme's effective ReferenceScheme to independently governed direct observation, intervention, measurement, or test relation occurrences involving the exact grounding holon. The mapping names what observation, intervention outcome, measured characteristic, or test result bears on that claim. One measurement involving the same holon cannot ground an unrelated claim.

The selected claim subgraph is by-value predicate content drawn from the episteme's ClaimGraph; it is not a third world-side relation participant, another episteme constituent, or a new U-kind. An assertion about grounding designates that subgraph and the claim-to-world mappings but creates none of the mapped occurrences.

Applying the shared declaration rule in 4.2.1, EpistemeEmpiricalGroundingRelationSignature is one declaration episteme whose exact EntityOfConcern is EpistemeEmpiricalGroundingRelation; the same individual has U.Signature membership and relation-facing RelationSignature use only under A.6.0. Its complete declaration includes the covered-claim-subgraph rule, obtaining predicate, maximal-continuous-interval identity rule, applicability, actual dependencies and provided names, and these participant SlotSpecs:

EpistemeEmpiricalGroundingRelation over participants (E,H), with covered=C, obtains exactly while every empirical claim in exact covered claim subgraph C has a current claim-to-world mapping to the required independently governed direct observation, intervention, measurement, or test relation structure involving H under E's effective ReferenceScheme. Every mapped relation required by that coverage must obtain. An exact direct evaluation relation counts as part of the empirical test only when the mapping states its concrete test role; otherwise evaluation and evidence can support or challenge an assertion about grounding but are not its world-side base.

One occurrence is identified by <episteme, exact covered claim subgraph, grounding holon, maximal continuous interval during which the complete coverage predicate is true>. Closing the open end of that interval refines the description of the same occurrence. Demonstrated failure of any required mapping followed by restored complete coverage yields another occurrence. Evidence or evaluation availability alone establishes neither obtaining nor nonobtaining and proves no temporal gap. If the complete coverage predicate is known to obtain, grounding continues without a stored report or work log. If it is known not to obtain, the relation does not obtain. If its truth is unknown, an affirmative grounding assertion has unresolved reliance for the declared use; that posture is not a third world-side grounding state.

The grounding holon need not be identical to the EntityOfConcern. One method-description episteme may have one grounding occurrence for a claim subgraph mapped to exact enactment work and another for a different claim subgraph mapped to the system whose behavior was observed. Each occurrence names its own C, H, and mappings. Sharing one grounding holon makes comparison inspectable but proves neither the same subject, the same claim content, nor coverage of any unlisted claim.

#Keep neighboring uses under their direct relations

Names ending in Slot are admissible here only as SlotKinds inside the exact RelationSignature governed by the neighboring direct relation pattern. A card or other episteme form carries participant designations in ordinary fields; it does not acquire SlotKinds by using similar field labels. None of those neighboring SlotSpecs belongs to EpistemeConstitutionRelationSignature.

#Relate distinct episteme editions explicitly

Tech name: EpistemeEditionRelation.

Plain reading: this later episteme continues this earlier episteme as a revision, refinement, or superseding edition.

EpistemeEditionRelation has exactly two direct participants. Applying the shared declaration rule in 4.2.1, EpistemeEditionRelationSignature is one declaration episteme whose exact EntityOfConcern is EpistemeEditionRelation; the same individual has U.Signature membership and relation-facing RelationSignature use only under A.6.0. Its complete declaration includes the direct predicate, participant-determined identity, applicability, actual dependencies and provided names, and these SlotSpecs:

The relation obtains when the two epistemes have different C.2.1 identities and one exact system performed revision, refinement, or supersession work under a method whose semantics establish historical continuation. C.2.P recovers the exact source expression and the source-to-revision-use relation by which the earlier episteme participates. Exact change facts already governed by their current patterns contribute to evaluating the edition-continuity predicate. If the edition claim also consumes the separate fact that the work first brought the later entity into existence, apply the shared boundary in 4.9; a missing inception governor blocks only that dependency. Once the required case facts satisfy the predicate, evaluation and evidence make an assertion about it inspectable. The system, work, method, source-use relation, change facts, any separate inception fact, evaluation, and evidence are not participants of EpistemeEditionRelation.

One occurrence is participant-determined by the exact <earlier episteme, later episteme> pair. Two work occurrences that establish the same historical continuation do not create two edition-relation occurrences. The relation is acyclic in its earlier-to-later direction. A renamed file, later publication, shared title, or bare provenance edge establishes no occurrence. Loss of a work log can lower confidence in an assertion about the relation, but it does not turn the work log into a third participant.

Several edition-relation occurrences may be selected as a lineage structure only when a receiving use depends on their organization. If that use also selects an edition collection, A.14 governs membership in that separately identified collection; collection membership does not establish edition continuity. PhaseOf may describe one unchanged episteme over a proper time interval, but it does not connect two different C.2.1 identities.

When claim content, EntityOfConcern, or effective reference scheme changes, the later object is another episteme. Apply EpistemeEditionRelation only when its historical-continuation predicate above obtains, whether the continuation is revision, refinement, or supersession. Apply A.6.4 separately only when the current claim is an effect-free retargeting between epistemes with different but bridge-related EntitiesOfConcern under its invariant; retargeting does not by itself establish edition continuity. A changed publication form alone identifies neither another episteme nor an edition relation.

#Keep descriptions, cards, publications, and representations downstream

A claim-bearing filled card can itself be an episteme when its claim content, EntityOfConcern, and effective reference scheme are recoverable. The reusable arrangement of that card can instead be a publication form, and a selected graphical or tabular element can participate in a C.29 representation. Identify each object through its own constitution and the direct relation in which it participates; visible shape does not determine its kind.

When a card or other form designates the participants of one direct relation, its field labels may correspond to SlotKinds in that relation's RelationSignature, and its field values may be by-value designations or references of the declared refModes. The form is not a filled direct relation occurrence; supplying fields does not make the predicate obtain or provide occurrence identity.

In a relational assertion, the claim graph designates the actual participants and states affirmative or negative polarity for the direct predicate. The direct pattern defines that predicate and the occurrence-identity rule; current case facts determine whether the predicate is satisfied or failed. A forecast, scenario, counterfactual, permission, or another claim family names its exact direct governor rather than using one common catch-all field. Only when an explicit reliance judgment is current for the declared use does A.10 or the receiving evaluation separately state supported, refuted, or unresolved reliance. An affirmative assertion may designate an occurrence only after the case facts satisfy the predicate and the direct identity rule individuates that occurrence; a negative assertion creates no failed world-side occurrence. In a relation-occurrence description episteme, the EntityOfConcern is that exact already individuated occurrence. The assertion and description retain their own C.2.1 identities; neither supplies case facts, obtaining, or the occurrence-identity rule.

Keep the direct verbs with their objects. A designator designates an already recoverable referent. A governed reference resolves to that referent under an effective reference scheme. An assertion or description episteme carries claims and participant designations. A C.29 representation stands in an explicit correspondence to what it represents. A publication occurrence makes a selected episteme edition available; a publication form expresses that edition for the use; a presentation carrier bears the form.

Plain published episteme means one already identified U.Episteme that currently participates as the selected edition in an exact publication occurrence. It is a contingent publication use, not a durable U.EpistemePublication kind and not a second identity for the episteme. The episteme keeps the same C.2.1 identity before, during, and after that availability relation.

A publication occurrence makes one selected episteme edition available to a declared audience for a declared bounded use. A publication form expresses that edition for the publication use. A U.PresentationCarrier bears the form. These are three different direct relations governed by E.17 and E.24.PUB; an assertion that any one obtains is a separate episteme. C.2.1 governs the identity of the selected U.Episteme; it does not replace the participants, predicates, or occurrence rules of those publication relations.

One completed inspection card shows why the distinctions matter. Its filled claims can identify one episteme; its reusable layout can be a publication form; its paper sheet or file can be a presentation carrier; and a publication occurrence can make the selected card episteme edition available to the maintenance team. None of those uses makes the others identical.

When rendering is current, a system performs rendering work and the exact work-participation, transformation, or A.6.1 binding current in that case relates the work to its affected entities. Rendering work, rendered entity, publication occurrence, form, carrier, and episteme retain their own identities. Republishing unchanged claims with another form or carrier creates no new episteme edition; changed claim content, subject, or effective scheme identifies another episteme without requiring a claim about when any entity first existed.

Under C.29, a tuple can represent the identity triple and a graph or hypergraph can represent claim, justification, dependency, or relation structure. U.ClaimGraph and JustificationGraph remain graph-valued epistemic structures. Their nodes and edges remain representation elements. An explicit correspondence can relate one selected representation element to an independently recovered object, but it neither identifies the two nor makes the representation element a participant of the represented direct relation.

#Preserve description and meta-description recursion

If episteme E1 describes pump P, P is the EntityOfConcern participant in the constitution relation that identifies E1. If review episteme E2 describes E1, then E1 is the EntityOfConcern participant for E2. The two relations have different triples and therefore identify different epistemes.

An episteme may describe itself when its own identity remains recoverable. Self-reference never closes an assurance argument by itself. Each justification or evaluation path terminates in independently governed evidence, observation, or formal derivation rather than in a cycle of claims that cite one another.

Description and specification use remain distinct. A Description episteme is admitted for specification use only when the E.10.D2 conditions are satisfied: checkable claims, a preserved or explicitly updated DescriptionContext, and a named harness or validation relation. Formal notation alone does not grant specification use or change the episteme's kind.

#Locate the change before updating episteme identity

#Hand episteme transformations to their governing patterns

Shared identity-inception boundary. Work or transformation can explain how an entity came about, but C.2.1 by itself establishes neither when that entity first existed nor that the work caused its inception. Open this boundary only when a current receiving claim asks whether a new entity began. Then use the subject's direct inception governor: that pattern defines the predicate and identity rule, and current case facts must satisfy it. If no such governor exists, return one missing-governor blocker naming the entity, work and change facts, required inception predicate, and receiving use. When the current question is only changed episteme identity, form, representation, view, or publication, do not open this boundary.

A.6.2-A.6.4 govern episteme-to-episteme morphing, source-to-receiving viewing construction, and retargeting. Identify every source and receiving episteme independently under C.2.1 before testing the exact transformation relation. Each transformation pattern states which identity discriminator is preserved or changed and names the exact correspondence, reinterpretation, or retargeting relation on which it relies. When local senses cross contexts, F.9 separately governs whether an exact Bridge obtains. If the morphism relies on that Bridge for a proposed use, state a separate C.2.1 assertion with the Bridge as EntityOfConcern and <u,d,r,t> plus polarity in its ClaimGraph, then recover current A.10 or B.3 reliance; none of those facts makes the morphism application occur. Categorical function, mapping, or tuple notation creates no direct relation occurrence.

For an A.6.3 source-to-receiving viewing construction, the two identified epistemes may retain the same EntityOfConcern while claim content or effective scheme is restricted. E.17.0 alone judges whether the receiving episteme conforms to an exact viewpoint and therefore has dependent U.View membership. Direct authoring or query generation can yield a candidate episteme without an A.6.3 construction, and neither route creates a multi-view family. For retargeting, the EntityOfConcern changes under an explicit bridge or correspondence. For a representation transition, the represented episteme may remain unchanged while the C.29 representation scheme and admitted operations change.

#Relation and neighboring-object reference

This reference table keeps the neighboring objects and relations visible after the application method. Ordinary prose names only the current object and its direct relation. A sentence such as “Model M concerns Pump P under Scheme S” is sufficient until another use needs explicit empirical grounding, a classification assertion, occurrence identity, edition continuity, publication, or representation correspondence.

#Semantic triangle as a didactic projection (informative)

The Symbol-Concept-Object triangle is a teaching projection, not the episteme ontology.

A triangle diagram may be used to introduce expression, meaning, and subject if its caption says that it compresses the C.2.1 episteme ontic. Its corners and arrows are representation elements. They supply no SlotKinds, direct relation occurrences, or identity rules.

This limitation matters in practice. A proof-assistant term, wiring diagram, clinical chart, learned embedding, or verbal explanation can all occupy the Symbol corner while supporting different operations and different losses. Those questions belong to the representation-scheme and transition patterns; one geometric picture does not answer them.

#Description and specification-use boundary (normative)

A Description episteme is a U.Episteme whose exact EntityOfConcern is the entity being described. Description does not create a second kind beside ordinary epistemes; it names the current relation and use of one episteme.

For a description use, keep these values recoverable:

When a filled card used to describe the entity has recoverable claim content, EntityOfConcern, and effective reference scheme, it is one episteme carrying these values. Its reusable layout can be a publication form, and the exact sheet or file that bears that layout can be a U.PresentationCarrier. The episteme, form, and carrier are not direct relation occurrences, and none makes a viewpoint, scope, or model-use relation obtain.

E.10.D2 governs the distinction among the EntityOfConcern, its Description episteme, and specification use. A Description episteme is admitted for specification use only when E.10.D2 checkability, DescriptionContext, and harness or validation conditions are satisfied. The suffix Spec, formal notation, approval appearance, or publication in a repository does not grant that use.

Self-description uses the same rule. If an episteme describes itself, its EntityOfConcern designation resolves to that episteme. If a review episteme describes it, the review episteme has the first episteme as EntityOfConcern and its own claim content and reference scheme.

#Episteme morphing, viewing, and retargeting (normative)

C.2.1 governs episteme identity discriminators and neighboring relations. A.6.2-A.6.4 govern transformations between epistemes.

#Effect-free episteme morphing

For a morphism from episteme X to episteme Y, state by value:

1. which of claim content, EntityOfConcern, and effective reference scheme are preserved, restricted, bridged, or changed;
2. which viewpoint, empirical-grounding, claim-scope, model-use, evidence, or representation relations are read or changed;
3. which claims in Y are preserved from or supported by X under the named morphism, the exact correspondence or retargeting relation governed by that morphism pattern, and any F.9 Bridge that governs cross-context sense use when current;
4. whether the operation changes only epistemes or also entails separately governed work or transformation.

The morphism declaration and any categorical notation are epistemic or mathematical objects. Only systems perform exact authoring, query, translation, or other work. A.6.1 declares typed argument and result positions. When an exact operation application is current, each application binding relates one exact entity to its declared argument or result position; every bound entity retains its independently governed kind, identity, and any domain-result algebra. Identify the affected or newly constituted entity, the actual change facts, and the C.2.1 discriminators independently. No bare A.6.1 result, generic work result, universal work-result relation, or universal production relation is inferred from a morphism arrow, declaration, or application.

#Epistemic viewing

A.6.3 governs an exact source-to-receiving viewing construction when one separately identified receiving episteme is constructed from one separately identified source episteme. That construction may preserve the exact EntityOfConcern while restricting claim content or specializing the effective reference scheme. It neither grants U.View membership nor performs work. Direct authoring and query generation can identify receiving epistemes without this construction relation.

E.17.0 independently judges EpistemeViewpointConformanceRelation(E,P) for one fixed receiving episteme E and one fixed viewpoint episteme P; only that obtaining relation gives the same E dependent U.View membership. A system may perform viewing, query, authoring, or rendering work, but neither that work nor an A.6.1 result position grants U.View membership or supplies C.2.1 identity.

Empirical grounding continues only while every mapped direct relation required by the receiving episteme's exact covered claim subgraph obtains. Changing publication, current use, evaluator, or evidence alone changes neither fixed E/P conformance nor grounding. Several source or receiving epistemes do not automatically form a multi-view family; identify any current collection under C.13 and any selected organization under A.22.

#Epistemic retargeting

U.EpistemicRetargeting is an effect-free morphism relating epistemes with different exact EntitiesOfConcern. A.6.4 governs the exact correspondence, reinterpretation, or retargeting relation that states what is preserved across the change. When the move also crosses context-local senses, F.9 governs the exact Bridge occurrence and does not replace the subject-side retargeting relation. A separate C.2.1 assertion says whether that Bridge is suitable for the retargeting use in direction d, under rule r, within tolerance t, with explicit polarity; A.10 or B.3 separately governs reliance. A system may perform exact retargeting work; identify its enacted method, any exact A.6.1 operation application and binding, affected or newly constituted entity, and actual change facts separately. The retargeting morphism itself performs no work, and no bare A.6.1 result, generic work result, or universal production relation is inferred.

Examples include retargeting from a module to a function it realizes, from observations to a learned model, or from one holon to a meta-holon or subholon with a different EntityOfConcern. A Fourier representation change is not automatically retargeting: use C.29 first to decide whether the signal remains the EntityOfConcern and only its representation changes. This test prevents mathematical notation from deciding ontology.

#Multi-view description and publication (normative)

C.2.1 identifies every candidate episteme and every viewpoint episteme separately. E.17.0 alone judges each exact EpistemeViewpointConformanceRelation(E,P) and the resulting same-individual U.View membership. DescriptionContext = <EntityOfConcernRef, BoundedContextRef, ViewpointRef> qualifies one describing use: its singular viewpointRef resolves one exact viewpoint episteme, it has no viewRef, and it selects no view. If another exact receiving-use qualification selects an already identified view, name that use and its exact governor separately. Neither qualification enters episteme identity or establishes conformance.

Several conforming views remain a plurality. Recover an exact C.13 collection only when a receiving use depends on that plurality as a collection. Recover an exact A.22 U.Structure only when the use additionally depends on organization among those views, and state the exact direct organizing relations. A shared EntityOfConcern, package, table, heading set, diagram, or carrier creates neither a view family, a collection, nor that structure.

A.6.3 governs only an obtaining source-to-receiving viewing construction when that history is current; direct authoring and query generation require no such relation. A system performs any viewing, authoring, query, comparison, or repair work. Neither that work route nor an A.6.1 result position grants U.View membership or identifies a multi-view family.

E.17 governs multi-view publication forms and uses, while E.24.PUB governs publication occurrences, forms, and carriers. The same recognized view can participate as the selected episteme in several publication occurrences without changing identity or conformance. Publication establishes no view membership and no cross-view subject relation.

When cross-view correspondence, consistency, realization, trace, or change impact matters, name the exact participants and apply the exact direct subject-relation governor. A C.2.1 assertion or description episteme may carry that claim; it does not make the relation obtain. If no direct governor is recoverable, return an exact missing-relation blocker naming the participants, required predicate and use, and missing governor; do not invent a relation. E.17, a matching heading, graph edge, diagram position, or shared carrier invents no correspondence relation.

#Archetypal Grounding — Worked Cases

These cases ground the pattern in practice; only a case that names an obtaining EpistemeEmpiricalGroundingRelation asserts empirical grounding.

#Physical engineering

A pump-maintenance specification has a claim graph about exact pump P under a reference scheme that resolves part names, states, units, and measurement procedures. Those three participants identify the episteme. For test bench B, exact covered claim subgraph C_B contains the discharge-pressure-tolerance and leakage claims. Its claim-to-world mapping names the direct pressure-measurement and leakage-inspection relations involving B; a maintenance-interval claim outside C_B is not grounded by those measurements. The grounding relation over (E,B), with covered=C_B, continues for the maximal interval during which every required mapping obtains. If that coverage continues while an evidence archive or inspection-work log becomes unavailable, only a separately governed support, warrant, confidence, or evidence-use assertion may change. A publication occurrence makes the episteme available through a rendered checklist form borne by an exact carrier; systems assigned the relevant roles perform the maintenance or inspection work recorded by checklist marks. A separately current assertion that P satisfies the constructive U.System criterion is another episteme about P; renaming or republishing the governing FPF pattern does not change P or create its systemhood.

The classification assertion changes only when its own claim content or reference scheme changes. Pump continuity is judged instead under the A.1 reidentification rule; a changed or unchanged assertion does not establish that continuity.

#Medicine

A diagnostic model concerns one patient-state entity or one admitted patient cohort under a scheme that defines observations, measurements, and diagnostic interpretations. Systems and role assignments participating in clinical work retain their own direct relations; they are not absorbed into the model's EntityOfConcern. Each EpistemeEmpiricalGroundingRelation identifies the exact covered diagnostic-claim subgraph, grounding holon, mapping to the required current observation, measurement, or test relations, and maximal continuous interval of complete coverage; it grounds no unlisted claim. If a threshold revision changes claim content or the effective reference scheme, that changed discriminator identifies another episteme; moving the unchanged model to another screen changes only the exact publication or representation object that actually changed.

#Learning

A curriculum model concerns an exact competence structure under a scheme that relates learning evidence and performance observations to competence claims. One exact admitted course-cohort holon or one exact admitted learning-environment holon may participate in a separate grounding occurrence without becoming the competence structure. A learner-facing episteme is a U.View when it conforms to an exact learner-facing viewpoint under E.17.0. If it was constructed from the source curriculum-model episteme, A.6.3 governs that separate viewing relation; systems in roles perform the lesson-session or receiving-episteme authoring or construction work. None of those facts is required merely to identify the learner-facing episteme from its claims, exact subject, and effective scheme.

#Episteme about an episteme

Simulation model M is one episteme. Review R concerns M, so the EntityOfConcern in R is the episteme M, not the physical system modeled by M. Claims in either episteme may cite separately governed evidence-use relations concerning the simulated or physical system. Publishing R does not revise M.

A theory episteme is recognized through its claim-bearing constitution and whole-level inferential characteristics. A textbook publication can make one edition of that theory available, but the publication occurrence, form, and carrier are not constituents of the theory and do not establish its holonhood.

#Edition succession

Episteme E1 participates in revision work W2 through the exact source-to-revision-use relation recovered by C.2.P; E2 has changed claim content and a separately recovered C.2.1 identity. C.2.1 defines the edition-continuity predicate and pair-based occurrence-identity rule. The enacted revision method, source-to-revision use, and actual change facts supply the current case basis. Inception contrast: in the positive branch, the direct subject owner already defines a first-existence predicate and the exact W2 change facts satisfy it, so that separately governed fact may enter the edition assessment. In the blocked branch, no such governor exists; return the shared 4.9 missing-governor result and do not use first constitution as an edition premise. In either branch, changed C.2.1 discriminators identify E2 independently. The edition assertion states polarity, separately governed evaluation or evidence use states reliance, and only positive case facts that satisfy the edition predicate let the pair rule individuate its occurrence. W2 is not a third participant. Later repackaging or publication establishes neither another episteme nor edition continuity.

#Grounded identity across two observations

A morning-observation episteme concerns observed object M under one reference scheme; an evening-observation episteme concerns observed object E under another. The exact direct identity or reidentification pattern for the observed entity must define the predicate and identity rule. The physically testable trajectory and observations supply the current case facts; they may satisfy or fail that predicate but the pattern itself establishes neither result. A separate identity-assertion episteme states affirmative or negative polarity, and exact evaluation or evidence-use relations make supported, refuted, or unresolved reliance inspectable. Only after positive case facts satisfy the predicate may its identity rule individuate an occurrence for designation. If no current direct governor is recoverable, keep reliance unresolved and return an exact missing-relation blocker naming M, E, the required predicate and use, and the missing governor. Even after both designations resolve to the same exact entity, the two observation epistemes need not merge: their claim graphs or effective reference schemes can keep their C.2.1 identities different. A shared label or grounding holon alone establishes neither world-side identity nor episteme identity.

#Readable wiring diagram as a proxy

Wiring-model episteme E1 concerns exact harness H under reference scheme S1, which resolves connector designators, pin identities, and connection predicates. A system performs exact diagram-redrawing work; any operation application, binding, or declared result position is governed separately by A.6.1. If only layout changes in a C.29 wiring-diagram representation, identify the exact representation transition and preserved connector, pin, and connection correspondence; E1 remains the same. If instead only an exact publication form, carrier, or rendering changes, identify that E.17/E.24.PUB object and relation; E1 again remains the same. If a connection claim is omitted or the legend changes the effective reference scheme, the changed claim graph or scheme identifies episteme E2. These three branches are settled by the changed object and C.2.1 discriminators; diagram-redrawing work and an A.6.1 result position establish none of them by themselves.

For the C.29 lens-use statement, the target phenomenon is the connectivity of H; the candidate mathematical object is the wiring-diagram representation under its stated diagram scheme; the mapping resolves connector marks and pin marks to the independently identified connectors and pins. A layout-only transition preserves connector identity, pin identity, and connection predicates. An omitted connection loses one predicate, while a changed legend loses the earlier mark-to-connector reference. The diagram remains admissible for maintenance diagnosis only while the connections on which that diagnosis depends are preserved and recoverable; stop that use or return to the source relation structure when they are not. This representation statement does not prove that the diagram is the harness, that visual similarity preserves claims, or that a higher readability score preserves episteme identity.

A readability score can therefore improve while diagnosable connectivity becomes worse. When that score is used as the practical value, apply E.13: name the intended diagnostic value, the readability proxy, and what became worse. C.29 and A.6.3.RT govern the representation transition and its preserved or lost structure; C.2.1 decides whether the changed claim graph or effective reference scheme identifies another episteme.

#Learned representation and tool-using inference

A language-model system performs one inference-work occurrence and may perform tool-call work during it. First recover a distributed activation pattern as an exact system-side phenomenon observed during that work. A probe's learned representation or decoded rendering may represent that phenomenon for a declared use under C.29 and A.6.3.RT; causal influence, decodability, or a readable label does not by itself make the activation pattern or its representation a U.Episteme. A probe result or decoded rendering is admitted as an episteme only when recoverable claim content concerns an exact EntityOfConcern under an effective reference scheme.

Keep the other entities and claims separate through their exact direct relations. A tool-call trace may fill an exact A.6.1 result position or another declared participant position for the call work. If a receiving claim additionally asks when that trace first existed, apply the shared 4.9 boundary; otherwise its result position and work history add no inception claim. If the trace itself carries claims about that work, it may also be identified as another episteme through the C.2.1 triple. An answer entity identified at an exact declared result position and a separately identified evaluation-report episteme can have different kinds and EntitiesOfConcern; neither is a generic work result by wording alone. Tool availability, a successful call, or a high evaluation score establishes neither claim truth nor empirical grounding. When tool integration changes or degrades reasoning, locate the change in the enacted method, inference work, call work, operation binding, representation use, evidence relation, or empirical-grounding occurrence. Reidentify an episteme only when its claim content, EntityOfConcern, or effective reference scheme changed.

#Bias-Annotation (informative)

C.2.1 deliberately favors explicit aboutness and interpretation because claims without an exact EntityOfConcern and effective reference scheme are difficult to compare or test. The mitigation is the A.6.REL minimum-current-object rule: ordinary use adds another object only when the reader's next sentence or action requires it, and states that object's direct relation to an already recoverable object.

The pattern also resists representation bias. Formal calculi, diagrams, learned representations, and interactive tools can materially change available reasoning operations, but their convenience or geometry cannot establish subject identity. C.29 and the selected transition pattern govern those differences.

Finally, the pattern has a claim-bearing-holon bias. Decodability alone does not make the decoded entity an episteme. The decoded entity is admitted as an episteme only when claim content, an exact EntityOfConcern, and an effective reference scheme are recoverable and together satisfy the constitution relation.

#Conformance Checklist (normative)

1. Episteme identity. Claim content, exact EntityOfConcern, and effective U.ReferenceScheme are recoverable, and the text states what changes each discriminator. A dependent episteme kind such as U.MethodDescription or U.View adds a governed membership judgment for the same individual, not another identity discriminator.
2. Direct constitution and case judgment. EpistemeConstitutionRelation has its three identified participants, obtaining predicate, and participant-determined occurrence-identity rule. C.2.1 defines that rule; current case facts satisfy or fail the predicate; an assertion states affirmative or negative polarity; and evaluation or evidence use states reliance only when needed. Designate an occurrence only after positive case facts and the identity rule individuate it.
3. Declaration identity and Slot discipline. Each of the three named relation declarations is first a C.2.1 episteme whose exact EntityOfConcern is its direct relation kind; the fixed A.6.0 predicate gives that same individual U.Signature membership and RelationSignature is its relation-facing use. Its complete declaration carries the direct predicate, occurrence identity, applicability, exact A.6.5 SlotSpecs, and only actual dependencies and provided names. Signature-local SlotKinds never become participants, and a one-off assertion needs no signature or manifest.
4. Classification discipline. A.1 governs recognition under an admitted holon kind, C.3.2 governs local-kind membership, and E.24.UK governs public U-kind admission. A separately current classification assertion is a C.2.1 episteme about the exact candidate; it states affirmative or negative polarity for the exact classification predicate and keeps supported, refuted, or unresolved reliance separately governed. It neither creates the candidate nor changes the kind's admission.
5. Empirical-grounding discipline. GroundingHolonSlot occurs only inside EpistemeEmpiricalGroundingRelationSignature. Each occurrence names one exact nonempty covered claim subgraph and maps every empirical claim in it to the required current direct observation, intervention, measurement, or test relations involving the grounding holon. Unlisted claims receive no grounding from that occurrence. One occurrence is reidentified from the episteme, covered claim subgraph, grounding holon, and maximal continuous interval during which the complete coverage predicate is true; demonstrated coverage failure followed by restoration yields another occurrence. Evaluation counts in the empirical base only when its exact direct relation and test role are stated; otherwise evaluation and evidence support or challenge an assertion. Availability or loss of a report, store, or work log alone neither makes nor unmakes grounding.
6. Edition discipline. EpistemeEditionRelation has exactly the earlier and later epistemes as participants and is acyclic in that direction. Identified edition work, exact source-to-revision use, enacted-method semantics, and actual change facts make the obtaining judgment inspectable without entering occurrence identity. Apply the shared 4.9 boundary only when the edition claim separately consumes a fact about when the later entity first existed.
7. View and neighboring-relation discipline. C.2.1 owns episteme identity; E.17.0 alone owns fixed E/P conformance and same-individual U.View membership; DescriptionContext resolves exactly one viewpointRef, selects no view, and remains separate from A.6.3 source-to-receiving construction. Several views remain a plurality. Recover an exact C.13 collection only when a receiving use depends on that plurality as a collection, and recover an A.22 structure only when the use additionally depends on their organization. Cross-view claims use their exact direct subject-relation governor or return an exact blocker naming the participants, required predicate and use, and missing governor. E.17 and E.24.PUB own publication, not view membership or correspondence.
8. Description boundary. The EntityOfConcern and any Description episteme about it remain distinct, including self-description and episteme-about-episteme cases.
9. Specification use. Specification force is admitted only when the E.10.D2 conditions obtain: checkable claims, a preserved or updated DescriptionContext, and a named harness or validation relation. Naming and appearance do not grant it.
10. Agency, work-result, and identity-inception boundary. Only systems perform authoring, evaluation, revision, publication, viewing, query, redrawing, and use work. A.6.1 declares typed argument and result positions; neither a position nor its binding says when the bound entity first existed. When a current claim asks that question, the subject's direct inception pattern must define the predicate and identity rule, and the exact work and change facts must satisfy them. If no such governor exists, return one missing-governor blocker naming the entity, facts, required predicate, and receiving use. Otherwise do not open the inception boundary. No morphism, heading, representation, form, bare A.6.1 result, generic work result, or universal production relation supplies that fact.
11. Publication boundary. Episteme, publication occurrence, publication form, view, and carrier keep separate identities. Plain published episteme names a contingent relation use, not another durable kind.
12. Representation boundary. Tuple components, graph elements, schema fields, and notation tokens remain representation elements. An explicit correspondence may relate one to an independently recovered object without identifying the two or changing the represented direct relation's participants.
13. Transformation and Bridge-use boundary. A morphing, viewing, or retargeting declaration states which C.2.1 identity discriminators are preserved or changed and names the exact correspondence or retargeting relation used. For cross-context sense use, F.9 separately establishes the exact Bridge; one C.2.1 assertion about that Bridge carries <u,d,r,t> and polarity; A.10 or B.3 separately governs reliance; and the direct receiver governs any actual Work, assertion, publication, relation, or operation application. The mathematical morphism performs no work, and none of these objects authorizes another.
14. Recursive assurance. Self-reference and meta-description do not form a minimal justification cycle; assurance terminates in independently governed evidence, observation, or formal derivation.
15. Minimum current object. Readable prose adds no object beyond the current use's dependency and states the direct relation to an already recoverable object.

#Common Anti-Patterns and How to Avoid Them

#Consequences (informative)

Benefits. Episteme identity becomes stable across carrier and publication changes. Description, empirical grounding, viewing, edition, and representation questions can be repaired locally because each has a direct relation. Self-description and multi-view use need no second ontology. The same pattern works for physical engineering, medicine, learning, formal work, and computational modeling.

Costs. A load-bearing episteme use has a recoverable exact EntityOfConcern and effective reference scheme rather than relying on a title or file. Empirical-grounding and edition claims depend on their own obtaining and identity evidence. Existing record-shaped schemas sometimes need to distinguish their fields from actual relation participants.

Limits. C.2.1 does not decide whether an epistemic claim is true, sufficient, current, or authoritative. It does not prescribe a file format, graph database, proof calculus, or publication layout. Those questions remain with evidence, evaluation, temporal, representation, and publication patterns.

#Rationale

Adding empirical grounding, viewpoint, scope, edition, and publication to every identity would instead collapse distinct relations and make ordinary use needlessly heavy.

Separating the episteme from its constitution relation is equally important. The direct relation explains how the identity-bearing participants are organized. The episteme is the resulting holon with a whole-level capacity to carry interpretable claims. A relation declaration is first its own C.2.1 episteme; A.6.0 independently recognizes that same individual as a U.Signature, and RelationSignature names its relation-facing use. Its claims declare the direct relation for typed reuse; an assertion claims that the relation obtains, and a publication occurrence makes a selected episteme edition available. None replaces another.

#SoTA-Echoing

These sources discipline different parts of the same working problem; they do not jointly define U.Episteme. Constructional ontology disciplines the separation among accepted constituents, constitutive organization, and resulting identity without turning the relation into work. Rodin disciplines evidence-backed identity across different observations, while the bounded BORO comparison stresses temporal recurrence without supplying FPF construction rules. Formal-language and material-engagement work explains why representation and grounding matter. RDF 1.2 remains a representation standard, while gUFO remains an ontology comparator for relational aspects; neither graph terms nor reifiers establish the direct relation occurrence. PROV-O motivates keeping the earlier episteme, revision work, exact source-to-revision use, actual change or local inception claim, and later episteme distinct while C.2.1 keeps only the two epistemes as participants of the edition relation. Current learned-representation and tool-integration research makes the same separations necessary for computational epistemes. In every case, C.2.1 retains the minimum-current-object rule: add only the object and direct relation needed by the receiving use, without collapsing either into the episteme or its carrier.

#Relations (overview)

• Builds on: A.1 for holon recognition, A.6.REL for direct relation occurrences, A.6.0 for independent same-individual U.Signature membership and relation-facing RelationSignature use, A.6.5 for declaration-local SlotSpecs and participant designations, A.7 for entity-description distinction, and C.29 for mathematical representation.
• Coordinates with: A.3.2 for U.MethodDescription membership without a second episteme identity; C.3.2 for local-kind membership judgments; E.24.UK for ontology-level U-kind admission; E.10.D2 for Description and specification-use discipline, including selection that creates neither conformance nor membership; A.6.1 for typed operation positions and exact current application bindings; A.6.2, A.6.3, and A.6.4 for morphing, source-to-receiving viewing construction, and retargeting; A.6.3.RT for representation transitions; E.17.0 for fixed E/P conformance and U.View membership; C.13 and A.22 for separately current multi-view collections and structures; the exact direct subject-relation pattern, or an exact missing-relation blocker naming the participants, required predicate and use, and missing governor; F.9 for exact Bridge semantics when a claim concerns a bounded cross-context use; E.13 when a visible representation-quality proxy is used as practical epistemic value; A.2.6 for claim scope; A.1.1 for bounded model-use structure; A.10 and B.3 for evidence and assurance; A.14 only when a phase or separately selected edition collection is current; C.2.P, A.3.1, and A.3.4 when source use, revision method, or actual change is current in edition-continuity evaluation; C.2.1:4.9 only when a local claim separately asks when a new entity began; E.17 for multi-view publication forms and uses; E.24.PUB for publication occurrences, forms, and carriers; and G.11 for currentness.
• Used by: every pattern that identifies, describes, classifies through an explicit assertion, compares, grounds, transforms, views, publishes, or refers to a U.Episteme.

#C.2.1:End

#Epistemic Precision Restoration

Type: C.2 precision-restoration pattern for episteme, publication, source wording, and source-relation wording Status: Stable Normativity: Normative unless a section is explicitly informative

#Use this when

First useful move. Decide whether the wording is source-expression clarification or FPF-governed use. Then write the smallest sufficient output: repaired sentence, candidate-set note, compact epistemic precision-restoration row, full epistemic precision-restoration check, or explicit non-use disposition.

Source-expression clarification. Use this mode when ordinary non-FPF prose needs precise interpretation. The aim is source-local clarification: recover what the sentence may mean, identify candidate kinds and relations, preserve important wording when needed, and produce one clarified phrase, candidate-set note, epistemic precision-restoration note, or use disposition. This mode may apply E.10, A.6.P, A.6.6, F.18, A.7, E.17, or another governing FPF pattern as a repair lens, but it does not require the source expression itself to use FPF vocabulary.

FPF-governed use. Use this mode when wording has FPF-governed use and hides one of this pattern's recovery fields. The field may be an episteme or episteme-side view field; a publication, publication form, generic publication face, MVPK face under E.17 constraints, or bounded publication unit field; a carrier or rendering relation; a relation or declared-use-boundary field; or a pattern-application wording field. The wording states the recovered FPF kind named by value, relation record, relation phrase, tuple-like record, project-side FPF kind and reference named by value, or explicit non-use disposition.

Use C.2.P as epistemic precision restoration for wording whose hidden field belongs to one of these field families, not to one new umbrella kind:

• source-expression fields: source wording and source-local meaning;
• episteme fields: claim-bearing episteme, episteme-side view, EntityOfConcern, and grounding relation;
• publication fields: publication, face, publication unit, publication-form relation, carrier relation, and rendering relation;
• project-side-use fields: pattern-application wording, project-side reliance wording, and the disposition by which source expression has or lacks FPF-governed use.

E.10 governs lexical and wording-use precision. C.2.P governs epistemic precision restoration across episteme, publication, carrier-relation, and view distinctions. Its recovery fields are source expression, source-local meaning, recovered FPF kind and relation set, publication construction, carrier relation construction, view construction, EntityOfConcern or grounding relation, reader use, and use or non-use disposition. These are fields of one recovery pass, not sibling kinds.

The practical partition is episteme-slot or publication-construction use, but it is not limited to named C.2.1 slots. It also handles source expression selected for FPF-governed use and pattern-application wording when those phrases are used as claim-bearing or use-boundary-bearing signs. Apply this pattern from E.10 only when the governing pattern cannot yet be selected directly because one recovery field is still unresolved: source wording, claim-bearing episteme, publication construction, carrier-relation construction, project-side reliance, pattern-application wording, or use or non-use disposition. The pattern-local decision selects source-expression clarification or FPF-governed use, recovers the current episteme-publication relation set, chooses recovered-by-value, reduced-use-cue, extension-candidate, blocked-use, rewrite-incomplete, or not-triggered disposition, and preserves the remaining reader use before any neighboring pattern governs its own invariant.

For source-wording restoration, C.2.P stops at recovery. It names the recovered FPF kind, relation, projectSideFPFRef, declaredUseBoundary, relationClaimSlice, remaining reader use, or explicit non-use disposition. When one of those recovered fields belongs to another FPF pattern, C.2.P names that governing pattern and leaves the object under that pattern's ontology. It does not turn source wording into a standalone kind or keep authority, evidence, gate, work, assurance, or readiness inside source wording.

Source-use wording guard. Do not read source-use as ordinary work with primary sources or citations. In this pattern, the compact phrase only flags that source wording, a source-bearing relation, a source-ref marker with its referenced object kind or relation slot named, or a source-finding cue is being asked to support FPF-governed use. The actual recovered field must be named through this pattern's fields: source expression, publication relation, carrier relation, relation slice, declared-use boundary, project-side FPF reference, or explicit non-use disposition. If that field is not recoverable, write the more specific phrase - source wording, source-bearing relation, unresolved source-finding cue, quote-only wording, or no FPF-governed use - instead of closing on source-use.

Source-to-use continuity rule. A source-wording repair is not closed merely because the broad word source was replaced by a more precise object name. The repaired wording must preserve the relation that made source wording useful. First name the current source expression or source-bearing position by its governing kind when it is live: source U.Episteme, source U.EpistemePublication, publication face, carrier relation, source-ref marker whose referenced object kind or relation slot is named, source-currentness relation, source-bearing relation, relation-claim slice, project-side FPF kind and reference, declared-use boundary, or explicit non-use disposition. Then state which named input is used now, what transformation, rendering, or use path carries it forward, what admissible use is allowed now, and what reopen condition or governing-pattern handoff applies when the use escalates. Do not close on value unless the governing pattern actually has a value slot. If those answers cannot be stated, lower the wording to source-finding only, reduced-use cue, blocked use, or incomplete rewrite.

Source-return boundary. Do not use source-return as the generic name for source-wording repair. In current FPF corpus, source-return condition is admissible only for the reverse or escalation edge in a derivative, coarsened, extracted, compressed, rendered, or reused carrier: the reader has already moved away from a named source expression, source U.EpistemePublication, source-bearing relation, transform record, evidence relation, or governing pattern position, and a stronger use, dispute, freshness change, hidden loss, or missing distinction requires return to that named endpoint or handoff to the governing pattern. If the sentence is naming the ordinary movement from a source expression, source publication, or source-bearing relation into current use, say source-to-use path, source relation, source-bearing relation, source expression, or the direct governing relation instead.

Work-reliance boundary. C.2.P does not decide whether work may proceed. It exits to A.15.4 only after the wording repair has recovered that a reliance appearance is being used as a reason for intended work or reliance and the governing pattern slot, relation, or project-side reference is still unnamed. If the direct governing pattern is already recoverable, use that governing pattern directly rather than making A.15.4 an intermediate repair.

Precision-restoration pattern note. A precision-restoration pattern is an architectural pattern for a recurring complex precision problem whose wording routinely hides several current distinctions. A.6.P is relation precision restoration; C.2.P is epistemic precision restoration. C.30.P is the selected architecture and structure precision-restoration pattern when architecture or structure wording hides the architecture claim being made, structure kind, structure relation, view, publication relation, or source relation selected for the current architecture claim. C.16.P is the selected characteristic and scale precision-restoration pattern when characteristic, scale, metric, score, indicator, coordinate, threshold, or comparison construction is hidden. C.16.Q is the selected quality-term precision-restoration pattern when quality-term or evaluative characterization is current and the found problem is not relation construction. E.10 detects the wording problem and selects the applicable recovery pattern; E.10.ARCH carries the shared recovery algorithm and applicability-row architecture; neither replaces this pattern's episteme, publication, and source-relation ontology.

Ordinary-language survival. Ordinary words can stay ordinary until the sentence gives them FPF-kind, relation, authority, evidence, use-boundary, work, gate, decision, bridge, or reliance claim. Source may stay ordinary when it only means where a quote came from; view may stay ordinary when it means what the reader sees and not U.View; route may stay ordinary navigation prose; support may stay ordinary help. Repair by FPF-governed sentence function, not by trigger word alone.

Not this pattern when. C.2.P is not the governing pattern for every recovered construct. General FPF lexical conformance stays under E.10; stable reusable naming under F.18; relation precision under A.6.P; A.6.B law-, use-boundary-, deontic-, and effect-claim boundary splitting under A.6.B; EntityOfConcern, Description episteme, and carrier separation under A.7; view and publication discipline under E.17 and E.17.0; architecture and structural description adequacy under C.30, C.30.ASV, A.22, C.31, or the architecture and structure pattern governing the claim; project work, evidence, gate, decision, method, action-invitation, assurance, and engineering-justification claims under their governing FPF patterns. When one of those claims is current, this pattern supplies source-expression unpacking and rewrite disposition; the FPF pattern named by value supplies its invariant.

Do not punish clarity. Prefer the clearest ordinary head that preserves kind, relation, and declared use boundary. Do not replace a clear plain phrase with a technical phrase unless the technical phrase blocks a currently plausible false interpretation or is needed for accepted stable FPF naming. In an ordinary case, reader help, source-pointer-only, or comparison only may be better than a more technical phrase.

#What goes wrong if missed

Episteme-publication-heavy text starts to build a parallel ontology. A generic publication face becomes a U.View, a file becomes an episteme, a dashboard tile becomes evidence, a pattern name becomes a procedure, or a slash list becomes a group kind. A broad word such as source is especially dangerous because it can hide several different recovery fields: an FPF pattern or DRR; a publication field; a document named for source, evidence, architecture, or review use; a reviewed publication, review packet, review record, or review state; a project-side FPF kind and reference named by value; or a relation.

The immediate cost is not only ugly terminology. Engineers and FPF authors start making action, evidence, gate, decision, or engineering-justification claims from the wrong entity, publication, record, relation, or carrier.

#What this buys

C.2.P gives one small epistemic precision-restoration move: recover the FPF kind and relation set first, then write wording that preserves the needed distinction without adding another claim. It prevents string-replacement cleanup, keeps FPF-side and project-side episteme and publication work separate, and blocks unclear wording from having FPF-governed use by guesswork.

Successful repair condition. Epistemic precision restoration is not closed by type-correct wording alone. It is governed by E.2 Pillars, especially P-2 Didactic Primacy, together with E.12 and the register rule in E.10:6.2. It closes only when the repaired text preserves or restores one remaining reader use: a usable action, a recognition reason that tells the working reader why the distinction matters, or a named FPF pattern application that carries the claim being made. When both Tech and Plain registers are current, the Tech interpretation must remain recoverable and any Plain or didactic line must map back to that Tech interpretation. A Plain, more expressive line, or intentional didactic metaphor may stay ordinary when it carries no FPF-governed use; when it carries ontological, evidence, causal, assurance, bridge, gate, work, decision, or use-boundary claim, that claim being made must be recoverable through the Tech fields, FPF kind named by value, recovered relation, project-side FPF reference or relation, or disposition named by the repair. If a repair in a FPF-governed Problem frame, Problem section, recognition text, example, or worked slice makes the text more precise but less able to show the working situation, why it matters, or what action remains, the repair is incomplete unless the governing FPF pattern is named for that claim being made. Overread removal is only half of epistemic precision restoration; the other half is remaining action guidance under the Pillars.

Recovery focus in plain terms. The use being made is one episteme-publication-heavy wording use inside conformant text: the word or phrase, the sentence function it carries, the FPF kind or relation it must recover, and the remaining declared use boundary after recovery.

Primary working user. The first user is a practitioner maintaining conformant FPF-style or project text: an author, review role, or engineer-manager who must repair wording without losing ontology. The downstream user is the practitioner who will rely on the repaired pattern or project text in a working situation.

Anti-overread payoff question. A repair is useful only if the pattern text can answer three things in ordinary prose: what false downstream interpretation is blocked; what useful action remains under the named FPF pattern; and when the reader must apply the FPF governing pattern named by value because evidence, gate, decision, work, assurance, bridge, release, or reliance is current. If the repair blocks an overclaim but leaves no useful action, the text is probably becoming ceremony rather than guidance.

#Problem frame

FPF already has episteme, publication, view, carrier, presentation, relation, naming, and pattern-application concepts. FPF-governed project, review, draft, pattern, and architecture prose, plus source prose being unpacked for possible FPF use, can still introduce convenient intermediate words that survive into final guidance without their kind and relation set recovered.

The recurring situation is simple: a sentence is understandable enough to feel worth keeping, but its head kind is not recovered. If it is repaired by replacing one broad word with another broad word, the ontology gets worse while the text looks cleaner.

#Purpose and Scope

This pattern gives the current glossary and rewrite rules for terms around epistemes, publications, views, publication forms, generic publication faces, MVPK faces under E.17 constraints, carriers, records, and bounded publication units.

It exists because episteme-publication-heavy texts can use locally convenient heads that collapse EntityOfConcern, publication unit, publication face, carrier, record, source relation, and project-side FPF kind and reference. Those words may be useful recognition handles, but they are not safe FPF heads when they carry ontology, authority, or authority-changing meaning.

The rewrite discipline here is ontological and use-facing, not lexical; in this pattern the repair is bounded to episteme, publication, source wording, and source-relation precision:

• do not replace one broad token with one new broad token by string substitution;
• first recover the FPF kind and relation set, whether the wording carries a claim, the publication, view, carrier, or relation construction, and any work, action, or authority crossing;
• then choose the smallest wording that preserves the FPF-governed distinction without creating a second ontology.

This pattern uses the E.10 trigger result as its entry condition, then works in the C.2.1 and E.17 epistemic-publication ontology rather than in a lexical registry.

#Problem

Without an epistemic precision-restoration discipline for episteme-publication-heavy wording:

1. broad publication words hide which field family is current: episteme or view, publication form or face, bounded publication unit, carrier relation, named document use, review-state use, or project-side FPF reference;
2. FPF pattern-application claims and project-side fields for work occurrence, work plan, decision, action invitation, method, record, carrier relation, or front-end relation get mixed in one sentence;
3. slash lists and heterogeneous rows become false group kinds;
4. unclear source meaning is guessed into FPF-governed wording rather than blocked or assigned to an accepted FPF extension;
5. authors copy the same loose wording into DRRs, patterns, source-relation notes, source-ref target notes, or project texts.

#Forces

#Solution

Repair episteme-publication-heavy wording by epistemic precision restoration, not by dictionary replacement.

A successful rewrite satisfies these field-validity constraints:

1. the head kind and sentence function are recoverable under E.10;
2. a stable reusable name has an F.18 naming result;
3. a relation, comparison, dependency, support, sameness, grounding, mapping, or endpoint claim has A.6.P relation precision, with use-boundary and project-side reliance questions split into their own fields;
4. a claim-bearing episteme, episteme species named by value, episteme-lane view, or project-side FPF kind and reference named by value has the needed C.2.1 typing or named FPF claim or declared-use boundary named by value;
5. publication, view, face, and carrier distinctions satisfy E.17.0, E.17, and MVPK;
6. the repaired text satisfies E.2 Pillars, especially P-2 Didactic Primacy, by preserving or restoring one remaining reader use: a usable action, a recognition reason that tells the working reader why the distinction matters, or a named FPF pattern application that carries the claim being made; when both Tech and Plain registers are current, the Plain or didactic line maps back to the recovered Tech kind, relation, or FPF pattern application under E.10:6.2; ordinary Plain wording and intentional didactic metaphor stay light when they carry no FPF-governed use, but ontological, evidence, causal, assurance, bridge, gate, work, decision, or use-boundary claim in a more expressive Plain line must be recoverable through the repaired Tech fields; FPF-governed Problem frames, Problem sections, recognition texts, examples, and worked slices must still show the broad working situation and first useful move, or the rewrite is incomplete;
7. the final phrase preserves the distinction without adding another claim;
8. unrecoverable meaning, kind, register mapping, or remaining reader use fails closed.

The detailed solution below carries the glossary and rewrite rules as ordinary pattern subsections. It is not an external container: these subsections are the pattern's detailed epistemic precision-restoration guidance.

#EpistemicPrecisionRestorationRecord

For FPF-governed cases, the recovery product is a compact pattern-local EpistemicPrecisionRestorationRecord or an equivalent local rewrite note. Ordinary local phrase repair may end as the repaired sentence itself when kind, relation, and declared use boundary are now clear and no downstream reliance, cross-context reuse, grouped-kind risk, hidden authority claim, project-side overclaim, conflict among publication, EntityOfConcern, and project-side action claims, or contested source meaning remains current. Prefer the plain names epistemic precision-restoration note, compact epistemic precision-restoration row, or local rewrite note when durable inspection does not require the code-like field name. The recovery note is a lightweight pattern-local authoring or review product, not a new ontology, not a dispatch table, not a durable FPF record kind, and not a mandatory heavyweight project record. It becomes a durable FPF record only if another accepted pattern or accepted DRR explicitly admits it as one. It records only the trigger, the recovered FPF kind and relation set, the requirement from the governing FPF pattern, and the final rewrite disposition that must remain inspectable after the repair.

Minimum fields when FPF-governed:

Recover by sentence function and claim being made, not word form. For words such as source, support, status, valid, ready, approved, and used, first ask which consequence the sentence would allow for the reader: source-finding only, source availability, source relation named by its governing pattern, evidence relation, gate passage, decision status, readiness threshold, work permission, assurance, engineering justification, or ordinary orientation. Then fill only the field whose FPF kind named by value, relation, or project-side reference is current. This list names possible consequences of the sentence, not kinds in one ontology.

projectSideFPFRef distinguishes a user-project object, relation, record, or work-use reference from FPF-side pattern or publication text. It does not replace context: bounded context, scope, window, and viewpoint remain separate facets of the recovered use when those facets are current.

Use the short form when only one field is current. Use the full record when several fields are current or when the phrase might otherwise create a grouped kind, hidden authority claim, project-side overclaim, conflict among publication, EntityOfConcern, and project-side action claims, contested source-relation meaning, or procedure-like ordering of pattern applications.

Carrier-specific recovery. Trigger spans such as carrier, carried by, publication carrier, access carrier, framework carrier, front door, front-end, rendering, file, dashboard, screen, skill pack, or MCP route are only recognition phrases. First recover which carrier-related field is current: U.PresentationCarrier or another carrier relation; publication exposure or access exposure; source-finding cue; evidence carrier or provenance carrier; generated carrier or produced carrier; framework publication carrier or framework access carrier; or project-side intended work or reliance. After recovery, the governing pattern is selected by the recovered field: C.2.1 for episteme identity and slot discipline; E.17 or E.17.AUD for publication face, publication unit, and access or publication relation; A.10 and G.11 for evidence, source-currentness, and provenance; C.35 for generated or discovered produced carriers; E.4.FPF, E.4.DPF, E.4.PFR, or E.4.DPF.DA for framework package carriers; A.15 or A.15.4 for work or reliance cases; and C.30.P, C.33, or C.34 for architecture or structure use. Do not close with carrier alone: close with the exact recovered field and the governing pattern that governs it.

#General Recovery Check

Use this recovery check whenever text proposes a new term, repairs an episteme-publication-heavy term, asks for language precision, or relies on wording around PublicationUnit, EntityOfConcern, publication, view, face, carrier, source relation named by value, source-bearing relation, publication face, EntityOfConcern, or bounded publication-unit claim.

0. Mode selection. Decide whether the current use is source-expression clarification over non-FPF prose or FPF-governed use. In source-expression clarification, preserve source-local nuance and do not force the whole source into FPF vocabulary. In FPF-governed use, the wording must satisfy E.10 and the governing patterns named by the recovery.

1. E.10 trigger scan and head-kind recovery. Use E.10:0.2 as the shared trigger scan. Decide what the head noun names before accepting the phrase: EntityOfConcern, Description episteme, or Description episteme selected for specification use, U.Episteme, U.View, publication form, generic publication face, MVPK face under E.17 constraints, U.PresentationCarrier or another carrier or rendering relation, project-side FPF kind and reference named by value, A.15.1 dated U.Work occurrence, A.6.A action invitation, A.2.9 SpeechActRef, A.2.8 U.Commitment, U.Method, U.MethodDescription, document named for source, evidence, architecture, or review use, reviewed publication, review packet, review record, or review state, or source-local ordinary sense. Apply EntityOfConcern and Description-episteme boundary and specification use, Context, Tech, Plain, and carrier humility rules before treating a word as meaning-bearing.

2. F.18 naming pass when a stable term is being chosen. If the phrase is becoming a reusable head, fill at least the lightweight Name Card facts: Context, Kind, purpose and use-domain, local sense, candidate head families, NQD-front reasoning, sense-seed read-through, and the lexical Q tuple {SemanticFidelity, CognitiveErgonomics, MorphologicalActionFit, AliasRisk}. Do not pick a label only because it is intuitive. Do not accept a replacement label until it passes the E.10:0.2 replacement-candidate anti-umbrella rule.

3. A.6.P relation-precision pass when a phrase carries relation, comparison, or action-invitation claim. Restore generic head kind first, then endpoint facets and kinds, then relation kind, slots, qualifiers, scope, time, viewpoint, and hooks for use-boundary, evidence, and work. For support wording, do not stop at a substitute label: select the current support-like claim or relation under A.6.P first, including source-description relation, EntityOfConcern or grounding-holon grounding, base relation through A.6.6, evidence, assurance, causal-use, mathematical-lens, characteristic or measurement, declared-use-boundary, work or enablement, or publication-companion use. If ambiguity remains, write a local Candidate-Set Note rather than debating synonyms.

4. C.2.1 episteme-slot pass when the recovered value is claim-bearing. Name EntityOfConcern, grounding, ClaimGraph, viewpoint and view, reference scheme, representation scheme, and bounded context as far as the claim needs. Do not use PublicationUnit or a carrier word as a substitute episteme.

5. E.17.0, E.17, MVPK publication pass when the recovered value is published or reader-facing. Separate the underlying episteme or view, U.EpistemePublication, publication form, generic publication face, MVPK face under E.17 constraints, PublicationUnit, carrier or rendering, and the project-side FPF kind and reference named by value when a project-side claim is current. A face, card, screen, or explanation can guide interpretation or source-finding without becoming evidence, work, gate passage, authority, or release permission. If those claims are current, fill declaredUseBoundary and projectSideFPFRef instead of treating the generic publication face or MVPK face under E.17 constraints as the source value.

5a. Neighboring-pattern selection after source wording and current FPF wording recovery. If source wording and current FPF wording, publication, carrier, face, or PublicationUnit recovery exposes a neighboring pattern's field, fill recoveredGoverningPattern with that governing pattern. Do not keep the neighboring field inside C.2.P after this pattern has recovered the source wording, current FPF wording, and publication relation set.

6. Remaining reader use. After the kind, relation, publication, and project-side splits are recovered, state the remaining reader use in one short line: what the working reader can now do, why the distinction still matters, or which named FPF pattern governs the claim being made. If both Tech and Plain registers are current, keep the Tech interpretation recoverable and make the Plain or didactic line map back to the recovered Tech kind, relation, or named FPF pattern application under E.10:6.2. Do not make this a heavy form for ordinary prose: a Plain line that carries no FPF-governed use may stay ordinary; a Plain line that carries ontological, evidence, causal, assurance, bridge, gate, work, decision, or use-boundary claim must be recoverable through the repaired Tech fields. If the repaired wording only proves that an overclaim was removed, but leaves no usable action, recognition reason, or FPF pattern application for the claim being made, do not classify the repair as recovered by value.

7. Authority-changing rewrite boundary. If the result would rename an accepted FPF pattern, change an accepted FPF term, or mint a reusable FPF kind, this pattern only classifies the phrase as recovered by value or as an understandable FPF extension candidate. It does not make the authority change by itself. Use the accepted source that already carries the decision by value; do not add a second decision source merely to restate the same content.

Fail closed:

• if the kind and relation set cannot be recovered, keep the term as plain or informative prose;
• if the relation kind cannot be recovered, keep the statement as a cue or split alternatives;
• if the publication construction cannot be recovered, do not use that publication, generic publication face, MVPK face under E.17 constraints, form, carrier, or rendered unit for work, evidence, gate, or authority claims;
• fill relationClaimSlice only when a relation claim is current, and fill declaredUseBoundary plus projectSideFPFRef when an use-boundary or project-side reliance claim is current;
• if the recovered wording is type-correct but leaves no remaining reader use, recognition reason, Tech-to-Plain mapping when both registers are current, or FPF pattern application, or if a Plain or didactic line supplies practical guidance through unrecovered ontological, evidence, causal, assurance, bridge, gate, work, decision, or use-boundary claim, mark the rewrite incomplete or demote the phrase to reduced-use cue or blocked use before using it as claim-bearing FPF or project text.

#Slash Discipline

In conventional abbreviations, source titles, mathematical notations, standards, URLs, file paths, and ordinary notations, a slash can be part of an accepted designation rather than a hidden FPF kind. In FPF-facing episteme and publication ontology, a slash is still a recovery trigger before it is a synonym marker unless the mark is part of such accepted notation, carrier syntax, or conventional designation.

Before leaving a slash expression in current prose, classify the expression as one of these cases:

• accepted notation or conventional designation: a standard name, source name, discipline abbreviation, established compound name, formula, ratio, fraction, unit, path-like quoted source token, title, product name, file path, URL, or quoted source wording where the slash is part of the accepted designation or carrier syntax; keep ISO/IEC, ISO/IEC/IEEE, 1/2, URLs, conventional abbreviations, and similar forms when the sentence uses them as notation;
• a plain-language synonym pair with no ontology, authority, evidence, or use-boundary claim;
• a lazy and/or-style join that must be split or recovered before FPF-governed use;
• a composite-kind candidate that needs F.18 and A.6.P recovery;
• a relation claim that needs a RelationKind, a QualifiedRelationRecord, or a multi-term relation phrase with typed endpoints, slots, qualifiers, scope, time, and viewpoint;
• a tuple-like record that needs a named record kind and named slot semantics;
• a failed ontology signal where the sentence lists unlike values because the FPF kind under repair, relation record, relation phrase, tuple-like record, alternative-case disposition, or not-triggered disposition has not yet been recovered.

If the expression is not one of the safe notation, conventional-designation, carrier-syntax, quoted-source, or plain-language cases, do not keep the slash as final wording. Do not repair it by replacing the slash with one equally vague grouped word. Write the recovered FPF kind, relation record, relation phrase, tuple-like record, alternative-case disposition, or not-triggered disposition by value.

#Unclear Source Meaning and FPF Extension Candidates

Sometimes the problem is not a bad word but one of two different cases:

• the intended claim cannot be determined from the surrounding source, current FPF kinds, or current FPF episteme and publication ontology;
• the claim is understandable, but current FPF does not yet contain the kind, pattern, relation record, or method guidance needed to carry it.

Do not merge those cases. An unclear claim is not current architecture truth merely because deleting it feels risky, and it must not be rewritten by guessing a likely author intention. An understandable uncovered claim may be retained as a candidate FPF extension only when the problem situation, tempting overread, rejected current uses, current FPF gap, and the first user action that would improve are stated by value.

Classify the case explicitly:

• recovered by value: the text now names the current U.Episteme, selected EntityOfConcern, U.View, publication form, generic publication face, MVPK face under E.17 constraints, PublicationUnit, carrier relation, relation record, relation phrase, tuple-like record, FPF pattern, document named for source, evidence, architecture, or review use, reviewed publication, review packet, review record, or review state, project-side FPF kind and reference named by value when projectSideFPFRef is current. The selected value is one current value, not the list: C.11 ChoiceResult; C.11 decision record; A.6.A action invitation; A.15 U.WorkPlan; A.15.1 dated U.Work occurrence; U.Method; U.MethodDescription; A.20 constraint or adjudication decision record; A.21 GateDecision; A.21 DecisionLogRef; A.10 evidence path; typed evidence record; B.3 assurance or engineering-justification record; typed status record whose FPF status pattern is named; carrier relation; front-end relation; or not-triggered alternative;
• understandable FPF extension candidate: the thought is clear enough to state as a candidate new or amended FPF kind, pattern, relation record, method guidance, accepted DRR content decision, or campaign-scoped content question, but it does not carry current authority, evidence, or use-boundary claim until an accepted architecture decision, accepted DRR, or accepted FPF pattern supplies that authority;
• source wording without FPF-governed use: the phrase has no current authority, evidence, or use-boundary claim;
• reduced-use cue: the phrase is kept only as a recognition cue or anti-case, not as a claim-bearing architecture decision;
• blocked use: the phrase is blocked for claim-bearing architecture, pattern, or project text while the needed meaning, kind, or relation is missing.
• rewrite incomplete: the repaired wording may be kind-correct, but it does not yet state a remaining reader use, recognition reason, Tech-to-Plain mapping when both registers are current, or FPF pattern application, or a Plain or didactic line carries ontological, evidence, causal, assurance, bridge, gate, work, decision, or use-boundary claim that cannot be recovered from the Tech interpretation; continue repair or demote to a non-use disposition before the text has FPF-governed use.

These dispositions are recovery results, not a meta-governance authority over all of FPF. When recovery names another FPF kind named by value, that FPF pattern governs that kind, its declared use boundary, and its conformance checks. C.2.P may identify that A.10, A.15, A.15.4, A.20, A.21, B.3, C.11, F.9, E.17.EFP, E.17.ID.CR, or another governing FPF pattern is current. It does not govern the recovered kind after that identification. C.2.P only makes the kind under repair, relation, and use boundary explicit enough that the right governing pattern can be applied.

No other disposition is closed. In particular, "seems to mean", "probably about", a cleaner paraphrase, or a broad umbrella replacement is not a successful recovery.

#Core Glossary

#Cross-Side Fields That Must Stay Split

These fields are current episteme-publication precision vocabulary for DRR, architecture, and pattern-drafting work. They exist to prevent one sentence from mixing FPF-side use-boundary, project-side records, actual work or action, method selection, carrier access, and authority records. They are local recovery aids, not FPF kinds, not record kinds, and not a universal record ontology. Each field closes only by naming the FPF kind named by value, relation record, relation phrase, project-side FPF kind and reference named by value, or explicit non-use disposition that is current in the sentence. The same local-aid rule applies to neighboring field names such as sourceRelationClass, explanationSourceRelationClass, comparativeRelationClass, representationValidityUseBoundaryValue, allowedUse, misuseRisk, and worldContactPolicy: they help record a local recovery or reader-use boundary, but they do not become kinds. These local fields do not instantiate evidence, gate, assurance, work, commitment, speech act, decision, release, authority, representation kind, world-contact kind, or policy kind. Read allowedUse as a local reader-fit field under declaredUseBoundary, not as permission, evidence relation, or authority.

#Episteme, Publication, and Carrier Distinctions

#Trigger Boundary

Lexical trigger scanning and direct known governing-pattern selection are governed by E.10:0.2, E.10:0.2a, E.10:0.2b, E.10:0.2c, and E.10:0.2d.

This pattern is applicable after that scan only when the governing pattern cannot yet be selected directly because one recovery field is still confused: source wording, claim-bearing episteme, publication construction, carrier-relation construction, project-side reliance, pattern-application wording, or use or non-use disposition.

When this pattern is applicable, do not restart from word taste. Keep the E.10 trigger result as input and recover source-expression clarification, FPF-governed use, current episteme-publication relation set, use disposition, and remaining reader use.

#Current Preferred Vocabulary

Use PublicationUnit when the intended entity is a bounded, human-inspected unit inside a publication. Do not use it for UI behavior, carrier behavior, front-end behavior, file identity, dashboard behavior, or export behavior; use A.7, carrier wording, front-end wording, or the FPF governing pattern named by value instead.

Use the current cluster names directly: PublicationUnit Stability Discipline, Local Head Restoration, and PublicationUnit Primary EntityOfConcern Discipline. When the current entity is a bounded unit inside a publication, use PublicationUnit; when the current entity is authoring or editing work, name that work directly.

Use EntityOfConcern, EntityOfConcernRef, and publicationUnitPrimaryEntityOfConcern when local wording means the EntityOfConcern named by a claim-bearing episteme or episteme-lane view, or the primary entity of concern stabilized by one bounded publication unit over that carried value.

For describedEntity, DescribedEntityRef, primary described entity, EntityOfInterest, or EoIClass, use EntityOfConcernSlot, entityOfConcernRef, EntityOfConcernRef, EntityOfConcernChangeMode, EntityOfConcernClass, publicationUnitPrimaryEntityOfConcern, or the local FPF kind named by value. If no claim-bearing episteme or episteme-lane view is current, use a non-claim-bearing kind named by value or plain topic or subject instead of inventing an EntityOfConcernRef.

Use ordinary topic, subject, or local referent only in non-normative explanatory prose where no episteme slot, publication construction, or authority relation is being asserted.

Do not mint any other new reusable FPF name from this pattern alone. PublicationUnit is governed by the E.17.AUD cluster named PublicationUnit Stability Discipline; this pattern recovers bounded-publication-unit wording into that head when the entity is current and points to that cluster for governance. FPF-governed uses keep the nearby definition or explicit publication relation set.

#F.18 And A.6.P Naming And Relation Interpretation For PublicationUnit

This is the F.18 and A.6.P name interpretation that this pattern reflects from the selected E.17.AUD cluster correction. It records why PublicationUnit is the selected bounded publication-unit head for the E.17.AUD cluster, while C.2.P remains the epistemic precision-restoration pattern.

F.18 and A.6.P naming and relation interpretation:
  Context: conformant FPF authoring and review where bounded publication units must not be confused with epistemes, views, publication forms, generic publication faces, MVPK faces under E.17 constraints, carriers, authoring work, or review process.
  Kind: primary-entity or local-head field for a bounded unit inside one publication.
  Purpose and use-domain: keep one human-inspected publication unit distinct from episteme, view, publication form, generic publication face, MVPK face under E.17 constraints, carrier, authoring work, and review process.
  Selected Tech label: PublicationUnit.
  Plain interpretation: bounded unit inside a publication that a person inspects as one unit.
  Candidate head families considered:
    - authoring-centered unit labels
    - reader-action-centered unit labels
    - mixed authoring-and-reader-action unit labels
    - PublicationReadingUnit
    - PublicationAuthoringUnit
    - PublicationUnit
    - ContentSpan
    - DocumentUnit
  F.18 result:
    - `PublicationUnit` has better SemanticFidelity than authoring-centered unit labels because the unit belongs to the publication lane, not to the authoring process.
    - `PublicationUnit` has better MorphologicalActionFit than mixed authoring-and-reader-action unit labels because it does not mix author, reader, and unit-boundary roles in one head.
    - `PublicationUnit` has lower AliasRisk than `content span` and `document unit` because `content` and `document` blur episteme, publication form, and carrier.
    - `PublicationUnit` still has nonzero AliasRisk because `publication` itself splits into act or occurrence of publishing, episteme publication, form, generic face, MVPK face under E.17 constraints, unit, and carrier; therefore FPF-governed uses keep the nearby definition or explicit publication relation set.
  Current result: accepted reusable FPF head for conformant episteme-publication-heavy FPF text within the declared bounded-publication-unit repair scope; use a more specific already accepted head where one governs the text under repair.

#Epistemic Precision Restoration After E.10

Lexical trigger rewrite rules are governed by E.10:0.2b, E.10:0.2c, and E.10:0.2d.

Use this pattern after those rules only when one of these remains unresolved:

• source-expression clarification versus FPF-governed use;
• source-local meaning versus current FPF wording;
• claim-bearing episteme versus publication, view, face, carrier, or publication unit;
• EntityOfConcern, grounding relation, or source-finding cue versus project-side evidence, work, gate, decision, assurance, method, action, release, or engineering justification;
• declarative FPF pattern application versus project work or control flow;
• use disposition: recovered by value, reduced-use cue, understandable FPF extension candidate, blocked use, rewrite incomplete, or not triggered;
• remaining reader use or Tech-to-Plain mapping after epistemic precision repair.

When none of these remains unresolved, apply the governing pattern selected by E.10 directly.

#Rewrite Execution Modes

Use the smallest sufficient mode that preserves the distinction. The template is an epistemic precision device, not a form to fill for every ordinary wording cleanup.

#Local prose cleanup

Use this mode when the phrase under repair is non-normative local prose and does not carry ontology, authority, review scope, release state, use-boundary, or a reusable name.

Action: rewrite directly or leave it unchanged. No table row is required.

#Compact epistemic precision-restoration row

Use a compact row for ordinary architecture, source-ref target, or review-use document cleanup where a sufficient FPF kind, relation record, relation phrase, or tuple-like record can be recovered without minting a new FPF head.

Compact epistemic precision-restoration row:
  file path, if current:
  FPF pattern, if current:
  pattern section, if current:
  sentence reference:
  phrase under repair:
  current sentence function:
  selected FPF kind named by value or project-side FPF kind:
  `relationClaimSlice` triggered? yes or no
  relation problem, if triggered:
  declaredUseBoundary triggered? yes or no
  projectSideFPFRef triggered? yes or no
  relation claim? yes or no
  if relation claim:
    RelationKind:
    endpoint, slot, qualifier notes:
    useBoundaryTargetKind:
    useBoundaryTargetRef:
  if local current-context unpacking:
    FPF-side kind, reference, or relation:
    project-side FPF kind, if current:
    project-side reference named by value, if current:
    notTriggeredReason:
  replacement:
  remaining reader use:
  distinction disposition: preserved, split, intentionally retired, still missing

#Full epistemic precision-restoration check

Use the full check when the wording may change ontology, introduce or retire a reusable head, change a claim-bearing pattern or document named for source, evidence, architecture, or review use, reviewed publication, review packet, review record, or review state, or resolve a contested source-meaning problem.

Epistemic precision-restoration check:
  file path, if current:
  FPF pattern, if current:
  pattern section, if current:
  sentence reference:
  phrase under repair:
  sentence function:
  distinction carried:
  E.10 head kind and EntityOfConcern and Description-episteme boundary and specification use interpretation:
  F.18 naming result: no stable term, reuse, MintNew sketch, DocumentLegacy
  F.18 candidate head families, if naming is current:
  F.18 lexical Q result, if naming is current:
    SemanticFidelity:
    CognitiveErgonomics:
    MorphologicalActionFit:
    AliasRisk:
  A.6.P trigger? yes or no
  A.6.P selected relation kind, slots, qualifiers, if current:
  claim-bearing episteme current? yes or no
  FPF kind and relation set:
  EntityOfConcern, grounding, ClaimGraph, viewpoint slots triggered:
  E.17 and MVPK publication form, generic face, MVPK face under E.17 constraints, view, carrier split:
  PublicationUnit typing, if any:
  FPF-side or project-side sentence:
  `relationClaimSlice` triggered? yes or no
  relation problem, if triggered:
  declaredUseBoundary triggered? yes or no
  projectSideFPFRef triggered? yes or no
  relation claim? yes or no
  if relation claim:
    RelationKind:
    QualifiedRelationRecord slots:
    useBoundaryTargetKind:
    useBoundaryTargetRef:
  if local current-context unpacking:
    FPF-side kind, reference, or relation:
    project-side FPF kind, if current:
    project-side reference named by value, if current:
    notTriggeredReason:
  rejectedOverread, if current:
  project-side record, work, action, method, carrier crossing:
  heterogeneous-list classification: one kind under repair, relation set, tuple-like record, alternative cases, failed ontology, not triggered
  pattern application, project work, decision distinction:
  chosen rewrite:
  remaining reader use:
  distinction disposition: preserved, split, intentionally retired, still missing
  unrecovered wording retained? no, yes, with scope and reason:
  use disposition: recovered by value, extension candidate, reduced-use cue, blocked use, rewrite incomplete, not triggered

#Epistemic Precision-Restoration Note

Use an epistemic precision-restoration note only when wording carries ontology, authority, evidence, or use-boundary claim. The note records the original phrase, recovered FPF kind or relation, reference named by value when current, project-side FPF kind and reference when current, remaining reader use, and disposition: recovered by value, extension candidate, reduced-use cue, blocked use, rewrite incomplete, or not triggered.

#Ordinary Completion and Reopen Boundary

A C.2.P application is complete for ordinary pattern-authoring use when the smallest sufficient product is present:

1. E.10 trigger result is kept as input and the text does not restart from word taste;
2. the wording is either left ordinary, repaired locally, expressed as a compact epistemic precision-restoration row, or escalated to the full check because the claim being made requires it;
3. the recovered episteme, publication, view, face, carrier, publication unit, EntityOfConcern, grounding relation, project-side reference, or use disposition is named by value;
4. every relation-like slice that remains current is assigned to A.6.P or its retained specialization, rather than being hidden inside this pattern;
5. the remaining reader use survives in ordinary prose or the wording is explicitly demoted to reduced-use cue, blocked use, rewrite incomplete, or not triggered.

Use the lowest sufficient product. A clean sentence is enough when one sentence recovers the claim being made. Use a compact row when the reader must inspect one recovered kind, relation, or disposition later. Use the full check only when several fields are current, when source wording's FPF use is contested, when a durable name may be minted, or when a publication, carrier, or project-side overread would otherwise survive.

This pattern can be applied to its own wording at the same lowest sufficient mode. If C.2.P text itself blurs a source expression, publication construction, pattern application, relation slice, or project-side reliance claim, repair that local wording here; do not create a recursive pattern-quality apparatus.

Reopen or lower a prior C.2.P repair when one of these content discoveries appears:

• the replacement head is another umbrella word such as support, display, route, kind, object, record, map, or mapping without FPF kind named by value and boundary;
• the repaired wording is type-correct but no longer tells the working reader what action, non-use, or neighboring-pattern application remains;
• a neighboring pattern is now the true governing pattern for the current evidence, assurance, gate, work, decision, publication, architecture, structure, relation, or naming claim;
• an entry cue, ToC row, summary, dashboard, retrieval snippet, or source-relation note preserves the pre-repair broad interpretation after the pattern body was repaired;
• repeated use shows that authors are filling the full check where a local sentence or compact row would suffice.

The ordinary stop condition is local: once the current sentence or bounded publication unit preserves kind, relation, use disposition, and remaining reader use, stop. Do not keep improving wording merely because a more elaborate record could be filled.

#Archetypal Grounding

#Boundary and Anti-Cases

#Transfer Coverage

C.2.P is intentionally narrow but must transfer across three recurrent publication situations:

• FPF-side drafting: pattern text, DRR text, source-relation notes, review-use notes, and pattern draft prose;
• project-side publication: dashboards, explanations, cards, documents, front-ends, rendered files, and generated summaries used around evidence, work, gates, decisions, assurance, or methods;
• external source-expression clarification: seminar fragments, papers, reviews, standards, and tool outputs being clarified before possible FPF use.

In all three situations the same invariant holds: recover the distinction between source wording and current FPF wording, claim-bearing episteme, publication construction, carrier-relation construction, relation-like slice, the neighboring pattern governing any recovered non-C.2.P field, and remaining reader use before accepting the wording as current FPF text.

#Bias-Annotation

#Conformance Checklist

#Current Scan Boundary

Lexical trigger scanning is governed by E.10:0.2, E.10:0.2a, E.10:0.2b, E.10:0.2c, and E.10:0.2d.

C.2.P conformance begins only when the E.10 result is epistemic precision restoration required or combined precision restoration required, or when non-FPF source text is being unpacked before possible FPF transfer.

Do not copy the E.10 trigger list into this pattern as a second registry. Use the E.10 result as input and recover source-expression unpacking mode, FPF-governed use mode, current episteme-publication relation set, use disposition, and remaining reader use. When the relation-bearing slice is current, A.6.P remains a separate required precision-restoration pattern.

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Operating Consequence

For new episteme-publication precision prose:

• start from FPF kinds and relations, not from familiar publication nouns and document nouns;
• use PublicationUnit for bounded publication units;
• use EntityOfConcern and EntityOfConcernRef when the episteme slot is current, and translate describedEntity source wording to the adopted EntityOfConcern family before FPF-governed use closure;
• keep publication form, generic publication face, MVPK face under E.17 constraints, view, carrier, document named for source, evidence, architecture, or review use, reviewed publication, review packet, review record, or review state, and project-side FPF kind and reference named by value separate;
• name relationClaimSlice, declaredUseBoundary, and projectSideFPFRef separately when more than one is current;
• classify heterogeneous kind lists before writing a sentence that depends on them;
• say that FPF patterns are applied in problem situations, not called or routed as procedures;
• leave accepted FPF names untouched unless a separate accepted naming decision authorizes a rename.

Operationally, each rewrite should:

• separate FPF-side episteme and publication context from project-side episteme and publication context whenever both are present;
• name relationClaimSlice, declaredUseBoundary, and projectSideFPFRef separately when a publication, display, cue, or explanation is treated as evidence, gate, constraint, adjudication, decision-making reliance, work permission, assurance, or engineering justification;
• classify heterogeneous lists before naming them: one kind under repair, relation set, tuple-like record, alternative cases, not-triggered alternatives, or failed ontology;
• say that FPF patterns are applied in problem situations, while project records, publications, views, carriers, and actions are worked with in project practice;
• avoid strength metaphors unless the characteristic, scale, threshold, evidence class, or use-boundary relation is named.

For cleanup of existing conformant texts:

• do not do a global string replacement;
• classify each unclear term occurrence by the smallest sufficient rewrite mode;
• use the full epistemic precision-restoration check only when ontology, reusable naming, FPF pattern text, or source-bearing project text is current;
• do not rename accepted FPF patterns from this pattern alone.

#Rationale

FPF already contains the relevant ontology. The recurring defect was not lack of concepts but ad hoc wording that bypassed them: source, target, display, object, host, route, supported use, and similar trigger terms packed several FPF kinds and relations into one convenient phrase; they are examples of wording to unpack, not current replacement vocabulary.

The correct repair is therefore not a new umbrella. It is a disciplined recovery action: use E.2, E.10, F.18, A.6.P, A.7, C.2.1, E.17.0, E.17, and MVPK together until the sentence says which EntityOfConcern, relation, publication, view, carrier, record, work, action, or pattern application it means.

Because E.2 governs all normative FPF patterns, epistemic precision is not a value apart from P-2 Didactic Primacy. An epistemic precision restoration may be stricter than the original wording, but if it turns FPF-governed reader-facing problem text into a kind inventory with no working situation or first useful move, it has not landed the FPF repair. The remedy is not expressive license and not metaphor removal; the remedy is recognition wording with declared-use boundary whose claim being made remains recoverable through the Tech interpretation or a named FPF pattern application.

The detailed rules remain in ordinary pattern sections, so the pattern is usable as FPF guidance rather than as an external glossary container.

#SoTA-Echoing

C.2.P does not claim to replace semiotics, terminology science, document engineering, or ontology engineering. Its claim being made is narrower: episteme-publication-heavy conformant text must recover accepted FPF kinds and relations before it is rewritten, so that episteme, publication, view, carrier, naming, relation, and project-side records are not replaced by ad hoc words.

Full external SoTA comparison is therefore not the governing evidence mode for this architectural precision-restoration pattern. A reduced external practice set is still required because the pattern governs terminology drift and epistemic precision restoration. The reduced set is selected only for the recovery discipline; it does not create a new ontology and does not outrank the FPF patterns named below.

In this section, SoTA-Echoing means compatibility with current FPF ontology and selected external practice anchors, not a claim that those external anchors are sufficient SoTA for every field they come from. ISO terminology entries are current standards anchors for designation practice; SHACL-style validation is only a fail-closed constraint analogy; word-sense and ambiguity-resolution practice is used only for context-sensitive sense recovery. If one of those domains becomes the governed object of a future claim, its own current SoTA pattern or source review must govern that claim.

External-practice boundary. External traditions enter only through the local FPF invariant named by value they sharpen. Object-oriented modeling and OWL-style ontology modeling do not become the default repair for vague FPF wording. Architecture-description standards help keep views, viewpoints, concerns, and descriptions explicit. Explainability and NLP faithfulness work helps prevent explanation laundering. RAG evaluation helps separate retrieval evidence, source availability, and answer trust. Quality-diversity and multi-objective search help avoid premature scalarization in candidate selection. None of these traditions becomes FPF ontology, FPF authority, or a universal pattern-quality benchmark.

#Internal FPF Governing Patterns

The current FPF corpus already has explicit governing patterns for this discipline:

• E.10 supplies the head-kind, term, morphology, register, and forbidden-umbrella discipline.
• E.10.D2 gives the "thing vs words vs rules" discipline and the carrier humility rule.
• F.18 gives the local-first naming protocol: Context, Kind, purpose and use-domain, local sense, candidate head families, NQD-front, semantic read-through, and lexical Q components before one label becomes a reusable head.
• A.6.P gives the relation-precision restoration method: restore generic head kind, build candidate sets for endpoint kinds and relation kinds, select kind-explicit slots and qualifiers, then allow guardrailed wording.
• C.2.1 gives the episteme slot relation and selected EntityOfConcern discipline.
• A.7 keeps EntityOfConcern, Description episteme, and publication carrier distinct.
• E.17.0, E.17 distinguish views, viewpoints, MVPK faces, publication forms, and publication projections.
• A.15.4 is a good current pattern example of keeping encountered publication, display, or low-articulation cue items distinct from the project-side FPF kind and reference named by value that governs work or reliance.
• A.16, A.16.0, A.19, B.2.5, C.27, and A.3.3 provide the movement, control, and temporal machinery used when episteme-publication prose talks about route, trajectory, movement, cadence, or dynamics.
• E.19 already treats terminology and sentence-level precision restoration as required review checks, not editorial polish.
• A.6.A carries action-invitation discipline when a publication, representation, or cue invites an action without itself becoming authority, evidence, gate passage, or work completion.
• C.11 carries decision-making and decision-record discipline when the question under repair is a decision rather than generic action.
• A.15 and A.15.4 split role, method, work-plan, and actual-work alignment from appearance-based reliance repair, so episteme-publication prose must not let A.15 become a universal episteme-publication governing pattern.
• E.9 is the campaign DRR pattern for campaign-level content decisions; E.11 is only for entry-discoverability situations and must not organize an episteme and publication repair by default.

The internal FPF governing patterns remain primary:

This reduced external-practice set changes the Solution in one practical way: an epistemic precision restoration cannot close merely because the replacement wording sounds cleaner. It closes only when the FPF kind, relation, declared use boundary, and any governing-pattern application is recoverable by value; otherwise the wording is blocked or becomes a candidate for a separate FPF-kind decision.

#E.19 Review Profile Carry-Through

Run PCP-TERM when the repair changes episteme-publication-heavy naming, umbrella words, slash compounds, trigger-word replacements, or relation wording.

Run PCP-BRIDGE when the repair imports terms, claims, norms, or authority expectations across contexts, disciplines, reference schemes, publication forms, or project record kinds.

Run PCP-ENTRY only when the repair changes which FPF pattern a working reader should apply in a problem situation. Do not use PCP-ENTRY as a substitute for the epistemic precision restoration itself.

Run PCP-PRAG when the repair changes reader action, practical payoff, or what the working reader can safely do next. A type-correct but inert repair fails this line even when every recovered kind is technically right.

When the repair changes evidence, proof, witness, grounding, explanation, gate, release, or engineering-justification claims, apply the governing FPF pattern for that claim (A.10, E.17.EFP, A.20, A.21, B.3, or another governing pattern when current) and select the current E.19 profile by the changed pattern claim. Do not mint a local evidence-review profile inside C.2.P.

#Relations

• Builds on: E.2 Pillars, especially P-2 Didactic Primacy; E.10, E.10.ARCH, A.7, F.18, A.6.P, C.2.1, E.17.0, E.17, MVPK, and A.6.A.
• Coordinates with: E.6, E.7, E.8, E.9, E.12, E.19, A.10, A.15, A.15.4, B.3, A.20, A.21, A.6.F, A.6.3.CSC, A.6.3.CR, A.6.3.RT, C.30.P, C.16.P, C.16.Q, E.17.EFP, and E.17.ID.CR.
• Does not replace: E.10 general lexical rules, F.18 naming protocol, A.6.P relation precision, or local episteme and publication patterns. It says when those patterns must be applied to episteme-publication-heavy wording.

#C.2.P:End

#Reliability R in the F–G–R triad

Reliability (R) is a conservative, evidence-bound warrant signal for a typed claim under an explicit claim scope (G). Cross-context reuse is Bridge-only: scope may be re-expressed via translate(Bridge,·) (often narrowing), while congruence penalties route to R only.

Type: Architectural (A) Status: Stable

#Problem frame

KD‑CAL asks a simple operational question: “Where can I safely use this claim?” FPF answers with a minimal “epistemic location” built from three coordinates and one bridge qualifier:

• F (Formality) describes how the claim is expressed and how strongly it supports verification workflows (C.2.3).
• G (Claim scope) describes where the claim is asserted to apply as a set-like object (A.2.6).
• R (Reliability) describes how strongly the claim is warranted by linked evidence under that scope.
• CL / CL^k / CL^plane (Congruence Levels) describe lossy transport when claims are reused across contexts, kinds, or planes (B.3, C.3). CL values live on edges/bridges (not on the claim as a “4th coordinate”).

In practice, the triad is frequently used before it is made explicit:

• Authors implicitly “average” disparate evidence and report a single confidence.
• Teams treat higher formality (F) as if it automatically implies higher warrant (R).
• Scope growth is smuggled in through phrasing instead of explicit scope operators (A.2.6).
• Cross-context reuse occurs without explicit bridges and without routing congruence loss into R.

This pattern makes R explicit in KD‑CAL and fixes the triad discipline required by Kind‑CAL (C.3) and the Trust & Assurance calculus (B.3).

#Problem

FPF needs a reliability coordinate that is:

1. Auditable. A reader can trace R to concrete evidence and see how reuse penalties were applied.
2. Composable. R can be propagated through claim graphs conservatively, without illegal scale arithmetic.
3. Orthogonal. R is not conflated with F (expression) or G (scope).
4. Bridge-safe. Any loss from transport across contexts/kinds/planes is explicit and affects R only.
5. Minimal. The solution does not introduce new core types or new face-kinds.

#Forces

#Solution

#Canonical triad relation

Definition DEF‑C2.2‑1 (Epistemic location). An epistemic location for a claim c is the tuple:

Loc(c | K, S) = ⟨F(c), G(c), R_eff(c)⟩

where:

• F(c) is Formality (C.2.3), treated as an ordinal.
• G(c) is Claim scope (A.2.6), treated as a set-like scope object.
• R_eff(c) is Effective reliability for c, treated as a ratio-scale scalar in [0,1] (or an ordinal proxy at [M‑0/M‑1]; see §4.5.A). R_eff is computed pathwise (DEF‑C2.2‑3): when more than one admissible justification path exists, publish multiple path records (PathId rows) and cite which PathId(s) a guard/decision consumed (see §4.8.A / G.6). Any collapse to a single scalar is an explicitly declared Γ‑policy (no implicit averaging).

A location is always understood relative to a bounded context and the assurance carriers used elsewhere in FPF:

• K is the declared U.BoundedContext.
• S ∈ {design, run} is the claim’s stance carrier (no DesignRunTag chimeras).
• ReferencePlane is declared where applicable; plane crossings apply CL^plane and penalize R only.
• When the claim is published on the Working‑Model surface, the author also declares validationMode ∈ {postulate, inferential, axiomatic} (E.14 / B.3).

Mode-to-lane hint (informative). validationMode sets the default expectation for which assurance lane carries the initial support load (B.3.3 or B.3.5). It does not add a new characteristic and does not change the meaning of R:

• axiomatic → VA-dominant (constructive grounding or proof carriers); if ReferencePlane=world, LA may still be required.
• inferential → VA+TA-dominant (reasoned chain + typing/alignment assurance); LA is optional and scope-bound.
• postulate → LA-dominant (empirical validation with freshness/decay); VA is optional. In all modes, R remains warrant, not ontological truth; “proof ⇒ R=1 in the world” is a category error.

Profile note (informative; fold compatibility). Some profiles treat empirical R as N/A for strictly axiomatic lines and use a tagged proxy R_proxy := F (line=formal) for folding, as an explicit proxy rather than an implicit “F⇒R” rule (B.1.3).

⟨F,G,R⟩ is an assurance tuple, not a U.CharacteristicSpace; do not draw “trajectories” in ⟨F,G,R⟩.

#What Reliability R means in KD‑CAL

Definition DEF‑C2.2‑2 (Reliability as warrant). R is a conservative, evidence-bound indicator of how strongly the claim “holds as stated” under its declared scope and context. It is interpreted as a warrant strength, not as truth.

Prophylactic clarification.

• A higher R means “the evidence and its relevance supports relying on this claim under this scope.”
• A higher F means “the claim’s form is amenable to higher-formality checking and wider reuse,” but does not itself imply the claim is warranted.
• A larger G means “the claim applies to more cases,” but does not itself imply the claim is warranted in those cases.

#Pathwise weakest-link propagation (series vs parallel)

KD‑CAL’s default Γ‑fold is weakest‑link on the entailment spine (the premises/lemmas actually needed), computed per justification path. It is conservative, monotone, and auditable.

Definition DEF‑C2.2‑3 (Pathwise weakest-link fold). Let P be a justification path for claim c. Let SpineClaims(P) be the required supports on the entailment spine, and let SpineBridges(P) be the bridges actually traversed on that spine (scope bridges, kind bridges, plane/notation transports where applicable).

Define the raw warrant of the path as:

R_raw(P) = min_{i ∈ SpineClaims(P)} R_eff(i)

and compute the effective warrant of the path by applying congruence penalties (see §4.5 for policy shape):

R_eff(P) = Π(R_raw(P); Φ(CL_min(P)), Ψ(CL^k_min(P)), Φ_plane(CL^plane_min(P)))

Spine discipline. The min is taken over the entailment spine only (no satellites, no “nice-to-have” citations).

This matches the KD‑CAL propagation rule (C.2:4.3) and the Trust & Assurance skeleton (B.3): weakest-link on the spine, penalize only by the worst (lowest) congruence encountered on the path (no averaging).

Parallel support (optional, declared). If the same claim c has multiple independent justification paths {P_j} (OR‑style support), the default is:

R_eff(c) = max_j R_eff(P_j)

Independence is recorded as an explicit note (e.g., separate rigs/datasets/proof lines), per CC‑C.2.2‑10 and the KD‑CAL composition rule (C.2:4.3). If the “multiple paths” actually cover different scope slices, do not use max to hide weaker slices; instead publish distinct G_path (SpanUnion‑style coverage) and keep per‑path R_eff traceable (A.2.6 / C.2:4.3).

Conflict detection (no averaging). If the evidence graph supports both p and ¬p with overlapping scope, do not average. Separate by context/scope, or mark the claim provisional with explicit conflict edges until resolved.

#Congruence penalties route to R only (no silent widening)

Cross-context reuse and cross-kind reuse are treated as transport with loss, and loss is expressed as a penalty that reduces R.

Invariant INV‑C2.2‑1 (R-only penalty routing). For any transport step that uses a bridge with a declared congruence level, the transported claim preserves its F value, re-expresses its scope via an explicit scope translation (translate) when needed, and only its R value is decreased by congruence penalties:

F_out = F_in G_out = translate(Bridge, G_in) (identity only for within-context identity use; cross-context use is undefined without a Bridge) R_out ≤ R_in

Claim scope may be re-expressed by an explicit translation, but must not be silently widened:

G_out = translate(Bridge, G_in) (may narrow / drop unmappable slices; never widen without an explicit ΔG)

No implicit translation. Translation between contexts never occurs implicitly: if the target context differs, an explicit Bridge (with declared CL and loss note) is mandatory; otherwise the reuse is non-conformant. No implicit translation. Cross‑Context reuse is conformant only via an explicit Bridge (declared CL + loss note) and an explicit translate(Bridge,·); see CC‑C.2.2‑4.

This invariant is why KD‑CAL guard macros and crossing bundles can be simple: transport never silently widens a claim; it either (i) translates/narrows scope explicitly, and/or (ii) reduces warrant.

translate is the USM operator (A.2.6). It may drop unmappable slices and may include refit-like normalization; this is not a penalty. Any further narrowing is an explicit Δ‑move (ΔG−) under A.2.6. Congruence loss (CL/CL^k/CL^plane) still routes to R only.

Notation/plane transports. NotationBridge and plane transports contribute to the relevant CL*_min(P) bottlenecks for the path; they do not “lower F” by penalty. If an author actually rewrites a claim into a different formality level, that is a new episteme (ΔF), not “transport”.

#Worked micro-example: translate(G) + penalty (A.2.6:11.2)

Source context: MaterialsLab@2026. Claim:

c: “Adhesive X retains ≥85% tensile strength on Al6061 for 2 h at 120–150 °C.”

• G_src := {substrate=Al6061, temp∈[120,150]°C, dwell≤2h, Γ_time=window(1y), rig=Calib‑v3}
• Loc_src(c) = ⟨F_src, G_src, R_raw⟩

Target context: AssemblyFloor@EU‑PLANT‑B. Reuse requires a declared Bridge b:

• Bridge Bridge#MatLab_to_PlantB maps lab rig → plant rig and introduces a measurement correction; CL(Bridge#MatLab_to_PlantB)=2 with loss note “±2 °C bias.”
• Scope translation: G_tgt := translate(b, G_src) which (in this case) narrows the temperature span to [122,148]°C due to the correction.
• Penalty routing: using policy Φ=Φ_v1, compute R_eff := max(0, R_src − Φ_v1(CL(Bridge#MatLab_to_PlantB))).

Key point: G changed only because translate(b,·) explicitly re-expressed the same entitlement in the target Context’s slice vocabulary; the congruence loss still affects R only. If authors decide that only [125,145]°C is safe to claim on the floor, that is an explicit ΔG− decision (scope edit), not a congruence penalty.

#Effective reliability under transport (policy-defined, monotone, bounded)

When a claim is reused via bridges, R_eff is computed by applying penalties determined by congruence levels.

Definition DEF‑C2.2‑4 (Effective reliability under transport). Let:

• CL be the congruence level of a scope bridge (B.3).
• CL^k be the congruence level of a kind bridge (C.3).
• CL^plane be the congruence level of a plane transport bridge (B.3 / plane patterns).

Let Φ, Ψ, and Φ_plane be policy-defined, monotone, bounded, table-backed penalty policies applied on the relevant edges:

• Φ(CL) — scope/context Bridge penalty (CL).
• Ψ(CL^k) — KindBridge penalty (CL^k) when kinds are mapped.
• Φ_plane(CL^plane) — plane-crossing penalty when ReferencePlane differs.

Important (direction of monotonicity). Congruence ladders are “polarity up” (higher CL = better fit). Per CC‑G0‑Φ and the Trust & Assurance skeleton, penalty tables are monotone decreasing in their CL ladders (if CL1 < CL2 then Φ(CL1) ≥ Φ(CL2), analogously for Ψ and Φ_plane) and bounded so that R_eff remains within [0,1] after clipping. Penalty magnitudes are not required to lie in [0,1] (tables may exceed 1 to force R_eff → 0 under the subtractive default); what matters is monotonicity, boundedness, and published policy identifiers.

Define:

R_eff(P) = clip_0^1( Π(R_raw(P); Φ(CL_min(P)), Ψ(CL^k_min(P)), Φ_plane(CL^plane_min(P))) )

where each *_min(P) is the lowest congruence level encountered on the entailment spine of P for that dimension (a bottleneck; no averages), and clip_0^1(x) truncates to [0,1].

Default (safe) instantiation (subtractive). When policies are expressed as subtractive penalties, a safe default is:

R_eff(P) = max(0, R_raw(P) − Φ(CL_min(P)) − Ψ(CL^k_min(P)) − Φ_plane(CL^plane_min(P)) )

This generalises the B.3 skeleton to multiple congruence ladders (scope vs kind vs plane) without introducing new penalty characteristics. If a dimension is not present on the path, its penalty term is treated as neutral (0 in the subtractive default).

Provisional marking. Default admissibility thresholds for reuse are set by Bridge calibration profiles (e.g., G.7). Typically, CL=1 requires an explicit waiver to proceed and CL=0 is inadmissible; this pattern only specifies that such thresholds gate transport before any numeric penalty is meaningful.

#Math-by-level gating (B.1.3:4.3)

• [M‑0/M‑1] allow ordinal comparisons only (no arithmetic on R_eff); Φ/Ψ/Φ_plane may be qualitative (“low/med/high”). Publish evidence links + lane tags.
• [M‑2/L1] numeric R_eff requires referencing numeric, table-backed policy identifiers for Φ/Ψ/Φ_plane (and Π if not default), plus reproducibility tags for empirical legs; otherwise treat the claim as [M‑1] semantics.

#Evidence lanes are not new characteristics

KD‑CAL does not add new global coordinates beyond F–G–R. Instead, it requires that reliability be explainable via assurance lanes (B.3.3):

• TA (Typing assurance): semantic/type alignment sufficient for transport and composition.
• VA (Verification assurance): logical/algorithmic checking, proof, model checking, static guarantees.
• LA (Validation assurance): empirical adequacy under declared conditions, tests, benchmarks, telemetry.

Lane reporting is how KD-CAL supports the common research distinction between logical soundness and empirical adequacy without introducing new global characteristics. Lanes remain separable in SCR/Notes; they are not averaged into a “single tradition score”.

#Scope operations are kind-safe (and use the ClaimScope algebra)

Reliability is meaningless if scope operations are applied to ill-typed entities.

Well-formedness constraint WFC‑C2.2‑1 (Type before scope). Let G1 and G2 be claim scopes associated to described entities of kinds K1 and K2. A scope operation that combines them (e.g., G1 ∩ G2 for serial intersection, SpanUnion({G_i}) for parallel coverage, or translate(Bridge, G) for cross‑context reuse) is defined only if:

• K1 = K2, or
• (same U.BoundedContext) K1 ⊑ K2 or K2 ⊑ K1 (an explicit kind relation/cast is named), or
• (cross‑Context) there exists a declared KindBridge relating K1 and K2 with an explicit CL^k (C.3).

This constraint prevents “type-by-scope” anti-patterns where scope manipulation is used to hide type mismatch.

#Minimal authoring recipe

A minimal, conforming KD‑CAL authoring flow for reliability is:

1. Fix the typed claim. State the claim as a typed proposition about a EntityOfConcern (Kind‑CAL, C.3).

2. Declare claim scope. Write G explicitly using A.2.6 operators; avoid scope-by-wording.

3. Declare stance carriers. Declare K=U.BoundedContext, S ∈ {design, run}, and (where relevant on Working‑Model surfaces) validationMode ∈ {postulate, inferential, axiomatic}; declare ReferencePlane if crossings are in play.

4. Bind evidence. Attach evidence stubs and lane tags (TA/VA/LA) and validity windows / decay policy where applicable (B.3.3, B.3.4).

5. Choose Γ-mode. Declare whether the support is series (required) or parallel (independent lines to the same claim).

6. Compute R_raw. Use the weakest-link fold on the entailment spine; for parallel support, use max only with an explicit independence note.

7. Declare bridges on reuse. If you reuse across contexts/kinds/planes/notations, declare the bridge(s) (including NotationBridge where applicable) and their CLs. Cross‑Context reuse is conformant only when an explicit Bridge is declared; CL admissibility rules apply (waiver or forbid) before any numeric penalty is meaningful (see CC‑C.2.2‑4). Reuse note (FPF discipline). When this section refers to “reuse/portability across contexts or planes”, interpret it as Bridge-only reuse per §4.4: e.g., Bridge Bridge#MatLab_to_PlantB with CL=2 and an explicit loss note, applying policy ids Φ=Φ_v1 (and, where applicable, Ψ=Ψ_v2, Φ_plane=Φ_plane_v1) to reduce R_eff only.

8. Compute R_eff. Apply the declared penalty policies into R (never into F or G), and publish ⟨F,G,R_eff⟩ with traceable references and policy identifiers.

A reliable claim is not a loud claim; it is a claim that can be carried.

#Authoring template: Path summary row (copy/paste)

When publishing R_eff for a claim, authors SHOULD include a compact, claim-local path summary. This is intentionally shaped so it can be turned into tooling later (EvidenceGraph/PathId in G.6) without introducing new Core types or face-kinds.

Notes:

• CL_*_min values are bottlenecks on the relevant path/dimension (no averaging).
• valid_until is the earliest expiry across empirical legs (or — / “fenced to TheoryVersion” for non-decaying proof legs).
• If you publish multiple admissible paths, include multiple rows and cite which PathId(s) your decision/guard consumed.

#Archetypal Grounding

Informative; non-binding.

#System illustration

System. A brake controller S has a claim:

c1: “For road friction μ ∈ [0.2, 0.9] and vehicle mass m ∈ [900, 2200] kg, wheel slip stays in [0.05, 0.25] under ABS control.”

• F(c1)=F5 because the controller and constraints are expressed as a machine-checkable model plus executable test harness (C.2.3).

• G(c1) is the declared operating envelope (A.2.6) as a product set in (μ, m, speed, tire) space.

• Evidence:

  • VA: model-checking of a simplified plant/controller model (strong, but only for the simplified plant).
  • LA: HIL simulation + track tests under sampled conditions with recorded telemetry windows (freshness required).
  • TA: typed alignment between “μ” in simulations, “μ” in the estimation pipeline, and “μ” inferred from real-world sensors.

If telemetry is reused from the track context to the road context, a scope bridge is declared with CL=2. Using the default monotone penalty table (B.3), the LA contribution is reduced, and the derived R_eff(c1) drops accordingly. The claim’s envelope G(c1) does not change; only the warrant for transporting the evidence does.

#Episteme illustration

Episteme. A paper asserts two claims about an algorithm A:

• c2: “A terminates for all inputs in domain D.” (axiomatic / proof-carrying)
• c3: “A achieves ≥ 0.92 F1 on dataset family F under deployment preprocessing P.” (empirical)

c2 can achieve high VA with a proof carrier; its LA lane may be N/A, but its TA lane remains relevant because the intended meaning of “domain D” must align with the implementation’s input model. c3 requires LA evidence and a freshness/shift policy because dataset and preprocessing drift change the scope and the warrant. If c3 is reused from a lab dataset context to a production context, a bridge with explicit CL is required, and R_eff is reduced until new in-context evidence is attached.

#Bias-Annotation

Informative; non-binding.

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal.

• Onto/Epist bias: High formality is often mistaken for high warrant (“proof therefore true in the world”). This pattern mitigates by forcing LA/TA visibility and by routing transport loss into R rather than mutating the claim.
• Prag bias: Teams may Goodhart R by narrowing scope or selecting easy tests. This pattern mitigates by requiring explicit scope declaration and by making scope changes first-class (A.2.6).
• Gov bias: Overconfident reuse across contexts is a recurring failure mode in governance settings. This pattern mitigates by forcing explicit bridges and penalties for reuse.
• Did bias: A single scalar is seductive; it hides what kind of warrant exists. Lane reporting keeps the scalar honest.

#Conformance Checklist

Normative.

#Common Anti-Patterns and How to Avoid Them

Informative; non-binding.

#Consequences

Informative; non-binding.

#Rationale

A triad only works if each coordinate has a single job.

• G carries entitlement. It states where the claim is asserted to apply. If G is implicit, teams argue about “what was meant” instead of updating scope.
• F carries checkability. It states how much the claim’s form supports mechanised scrutiny and reuse. If F is conflated with R, formalisation becomes a rhetorical weapon.
• R carries warrant. It states how much evidence supports relying on the claim under G. If R is not conservative, evidence with a low R coordinate can be laundered into high confidence.

Routing congruence loss into R only prevents a subtle but pervasive failure mode: transport across contexts/kinds/planes does not silently rewrite the claim; it only reduces how confidently we should carry it.

Weakest-link propagation is chosen because it is the simplest rule that is monotone, conservative, and auditable. When better combination rules exist, they can be introduced as explicit Γ‑policies, but the default must be safe.

#SoTA-Echoing

Normative.

SoTA pack binding note. If a SoTA Synthesis Pack exists for KD‑CAL reliability / cross‑context warrant transport in your Context (G.2), cite its ClaimSheet IDs / CorpusLedger entries / BridgeMatrix rows here. Otherwise, record SoTA-Pack: TBD/none and treat this section as the seed (do not fork it silently elsewhere).

#Relations

Builds on: C.2 (KD‑CAL overview), A.2.6 (Claim scope and operators), C.2.3 (Formality F), B.3 (Trust & Assurance calculus), B.1.3 (Γ‑fold patterns), B.3.3 (assurance lanes), B.3.4 (refresh/decay), C.3 (Kind‑CAL and kind bridges), F.9 (Bridges & CL), G.6 (EvidenceGraph PathId discipline), G.7 (Bridge calibration / admissibility thresholds). Coordinates with: C.16 (MM‑CHR evidence discipline), E.14 (working-model assertions), E.18/F.9/F.17/E.17/A.21 where crossing bundles and gate checks are live, C.25 (Q‑Bundle, for avoiding confusion between epistemic reliability and system reliability). Used by: C.3.3 (cross-kind reuse discipline), guard macro bundles in C.3.A and C.21, and any acceptance/gating logic that consumes R_eff while preserving F and G. Clarifies: The KD‑CAL meaning of reliability implicit in C.2:4.1 and the transport clauses referenced across B.3 and C.3.

#C.2.2:End

#U.LanguageStateSpace - Language-state chart over U.CharacteristicSpace

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative

Plain-name. Language-state space.

Builds on. A.19, E.10, F.18.

Used by. C.2.LS, C.2.3, C.2.4, C.2.5, C.2.6, C.2.7, A.16.0, A.16, A.16.1, A.16.2, B.4.1, B.5.2.0, F.9.1, A.6.P, C.16.Q, A.6.A.

Use this pattern when. Use C.2.2a when a governed U.Episteme publication needs a language-state position before an endpoint pattern can honestly govern it.

What goes wrong if missed. Teams flatten articulation, closure, anchoring, representation factors, route-bearing publication forms, faces, and carriers into one vague maturity label such as early, ready, or settled.

What this buys. A slot-explicit chart position for the episteme publication, with threshold notes and role-lane distinctions kept visible before routing, prompt entry, bridge comparison, or endpoint use.

#Problem frame

In engineering, inquiry, operator, and management practice, teams often need to say where a governed U.Episteme publication currently stands before it has reached an endpoint governing pattern. That governed publication may appear through several cue-bearing, route-bearing, or endpoint-bound publication forms, but the chart claim remains about the governed U.Episteme publication rather than about a local alias or a carrier lane.

Cue packs, routed cue sets, abductive prompts, typed route-bounded projection publications, partial normal forms, and endpoint-bound records are not rival positioned items in the space. They are publication forms through which a current position claim is made visible. MVPK faces may render those forms, but faces are not themselves the forms. By contrast, a service disturbance, a model-vs-observation discrepancy, a bodily tension, a telemetry trace, a model output, or a carrier document may trigger, witness, or carry that episteme, but none of those is itself a coordinate in the space.

Practitioners, including engineers, operators, researchers, managers, and engineer-managers, still have to decide where such an episteme currently stands, which thresholds matter next, which publication form is admissible, and what must not yet be claimed. If this domain is described only with folk labels such as raw, early, settled, or ready, the real geometry disappears.

#Problem

Without an explicit language-state chart:

1. teams collapse several facets into one maturity story;
2. F is silently misused as a surrogate for articulation, closure, anchoring, and representation factors;
3. thresholds are published as vague readiness statements instead of explicit facet conditions;
4. source phenomena, governed epistemes, publication forms, publication faces, and carriers are conflated;
5. bridge and endpoint work inherit under-described upstream states.

#Forces

#Solution

U.LanguageStateSpace is the cluster-local name for the declared language-state chart over U.CharacteristicSpace as disciplined by A.19.

It is not a second kernel state-space apparatus beside A.19. It is the particular declared U.CharacteristicSpace whose basis slots are the language-state facets used in this cluster.

#Kind and chart boundary

U.LanguageStateSpace is a dependent durable chart value under U.CharacteristicSpace and the episteme language-state boundary, not a new root state-space U-kind. Its identity is the declared characteristic-space chart for governed episteme publication positions. Score tables, publication forms, local route maps, and carriers can publish or use the chart, but they are not the chart.

#Core role

U.LanguageStateSpace gives FPF one explicit declared chart for answering five questions:

• which basis slots define where the governed episteme stands;
• what a position claim in that chart means;
• which thresholds are locally declared over those slots;
• what comparisons are admissible without cross-facet collapse;
• and how the same position claim stays distinct from the publication form currently expressing it.

#Position reading under A.19

A language-state position is a partial, slot-explicit coordinate claim in the declared language-state U.CharacteristicSpace.

Each basis slot publishes a ValueSet(slot), interval, or other admissible set-valued claim. Early seam publications may leave some slots unknown or wide, but that uncertainty must be declared rather than hidden inside one stage word.

position language is therefore admissible here only as shorthand for such slot-explicit A.19 coordinate claims. It does not authorize a rival process-sequence or feature-vector story.

#Facet basis

The language-state chart is coordinated by explicit facet governing patterns rather than by an informal master progression. In the current cluster the basis is formed by:

• C.2.3 for F;
• C.2.4 for articulation explicitness;
• C.2.5 for language-state closure degree;
• C.2.6 for language-state anchoring mode;
• C.2.7 for the language-state representation-factor bundle.

C.2.2a states that these basis slots together define the chart. It does not govern the internal scale semantics of the individual facets.

#Ontological slot groups

Within this cluster, keep five slot groups distinct:

• positioned episteme publication - the governed U.Episteme publication whose current position is being claimed;
• grounds / witnesses - disturbances, discrepancies, traces, model outputs, bodily tensions, exemplars, or contrasts that justify the current reading;
• publication forms - cue packs, routed cue sets, prompt forms, typed route-bounded projection publications, partial normal forms, and endpoint-bound records through which the episteme is published;
• publication faces - the existing MVPK faces on which those publication forms are rendered when face typing matters;
• carriers - documents, console notes, cards, trace files, or model carriers that hold or render a publication.

U.LanguageStateSpace governs only the coordinate reading of the position claim. It does not collapse that claim into the grounds, publication form, publication face, or carrier.

#Position publication rule

A published position claim in U.LanguageStateSpace should normally make at least the following explicit:

• the positioned U.Episteme publication whose position is being described;
• the relevant slot values, ValueSet claims, or intervals;
• the current publication form and, when it matters, the MVPK face carrying it;
• the carrier or SCR/RSCR lane if physical or digital preservation/distribution matters;
• the grounds, witnesses, or inherited pins that justify the current reading;
• any local threshold note that makes one region, corridor, or endpoint claim admissible for the next position claim.

For this pattern, a position claim is reviewable when:

• the positioned U.Episteme publication is named or inherited by an already pinned upstream publication;
• the slot values, intervals, or ValueSet claims are explicit enough to show where the publication stands;
• the grounds, witnesses, or inherited pins that justify those values remain visible;
• any threshold-bearing use states the local threshold note or the pinned threshold source it inherits;
• and the text keeps the positioned episteme publication, publication form, publication face, and carrier in distinct slot groups. A polished note, a carrier with more preservation or distribution support, or a more formal face does not by itself prove a new position. The chart claim remains admissible only when those slot groups and slot claims stay visible.

#Non-substitution of F

F remains one basis slot in the chart, not the whole chart.

A conforming account shall not infer:

• closure from formality alone;
• anchoring from publication-face format alone;
• representation factors from articulation alone;
• or routing admissibility from a lone F statement.

Where operationally meaningful thresholds exist, they must publish on the relevant slots rather than being disguised as informal F sublevels.

#Position versus publication form

A position claim in U.LanguageStateSpace is distinct from:

• the underlying governed U.Episteme,
• the source disturbance, discrepancy, or witness,
• the current publication form,
• the MVPK face that renders that publication,
• the carrier that stores or displays it,
• or the endpoint-pattern-governed publication that may result from it.

Those roles are coupled but distinct. U.LanguageStateSpace keeps the position claim readable without collapsing it into any one bearer lane.

#Threshold publication discipline

If a threshold is used to justify a move or endpoint entry, that threshold shall be stated on explicit basis slots in the chart. Statements such as this is now ready, this has matured, or this is still too early are non-conformant when they substitute for undeclared slot conditions.

#Comparison and bridge note

Comparisons inside one context may use the shared chart and local thresholds. Comparisons across contexts require explicit bridge discipline. Label similarity or stage-language similarity does not establish sameness of charts, positions, or thresholds.

C.2.2a therefore supports bridge work, but does not grant cross-context identity by itself.

#Corridor reading note

The current Language-State & Semantic Routing Corridor in this cluster is a distributed overlay over:

• C.2.2a
• C.2.LS
• C.2.4–C.2.7
• A.16
• A.16.0–A.16.2
• B.4.1
• B.5.2.0

A.16.1 / U.PreArticulationCuePack remains the earliest durable seam publication form in that corridor. B.4.1 is the explicit route-bearing seam after cue preservation, not the first publication in the corridor. B.5.2.0 is typed prompt entry, not generic route governance.

C.16.Q, A.6.A, A.6.P, B.5.2, A.15, and C.25 are seam-coupled downstream governing patterns rather than members of this language-state governing-pattern set.

This note gives readers one corridor map only. It does not relocate articulation, closure, route, prompt, bridge, or endpoint semantics out of their current governing patterns.

#Archetypal Grounding

Tell. One note can have high operator-loop anchoring yet still low closure. Another can be document-mediated and symbol-heavy while still open on route choice. Both are positions in one language-state chart, but not on one maturity progression.

Show (System). A service disturbance is a system-side phenomenon. The positioned governed U.Episteme publication is the alerting episteme published from that disturbance; its position claim may be moderately formal, low-closure, high in operator-loop anchoring, and mixed in representation because terse codes and natural-language hints coexist.

Show (Episteme). A model-vs-observation discrepancy is a witness-level tension, not the positioned episteme publication itself. Once preserved as a cue pack, the resulting governed U.Episteme may be low in articulation, low in closure, trace-anchored, and only partly symbolic even when rendered into prose.

#Bias-Annotation

The pattern deliberately biases authors toward decomposable coordinate claims and away from folk stage vocabularies. That costs some brevity, but it prevents collapse of genuinely different state facets into one adjective.

#Conformance Checklist

• CC-C.2.2a-1 U.LanguageStateSpace SHALL be treated as the declared language-state chart over U.CharacteristicSpace, not as a rival kernel space and not as a disguised F progression.
• CC-C.2.2a-2 Published positions SHALL cite explicit facet governing patterns when those positions matter for movement, routing, or endpoint entry.
• CC-C.2.2a-3 Position claims SHALL use slot-explicit values, ValueSet claims, or intervals; uncertainty SHALL NOT be hidden inside stage words such as ready, early, or mature.
• CC-C.2.2a-4 A position claim in the chart MUST NOT be conflated with the current ground, witness, publication form, publication face, or carrier.
• CC-C.2.2a-5 Cross-context comparison of positions or threshold talk SHALL go through bridge discipline rather than label similarity.
• CC-C.2.2a-6 Corridor and navigation notes MUST NOT be read as relocation of facet, seam, bridge, or downstream governing-pattern semantics into the chart governing-pattern set.
• CC-C.2.2a-7 If a position claim is used for routing, endpoint entry, or gate-adjacent reasoning, the threshold note and the role-lane distinction between positioned episteme publication, publication form, face, and carrier SHALL remain explicit or explicitly inherited from a pinned upstream publication.

#Common Anti-Patterns and How to Avoid Them

• Maturity monism. Replace five facets with one stage word. Repair by publishing explicit slot placement.
• Formality capture. Use F to stand in for articulation, closure, or anchoring. Repair by naming the actual facet governing pattern.
• Carrier collapse. Treat a document, cue pack, or routed note as if it were the position itself. Repair by separating carrier lane, publication form, publication face, and position claim.
• Threshold folklore. Speak of readiness without any explicit threshold declaration. Repair by publishing relevant local threshold notes on explicit slots.
• Bridge by vibe. Treat similar stage language in two schools as equivalence. Repair by explicit F.9 bridge with loss notes.
• Corridor inflation. Treat the navigation cluster or corridor map as if it were the governing-pattern set for all downstream semantics. Repair by naming whether the current statement belongs to the chart governing-pattern set, a seam publication form, or a downstream governing pattern.

#Consequences

The benefit is that practitioners, including engineers, operators, researchers, managers, and engineer-managers, can speak about where a governed U.Episteme stands without hiding the reasons inside vague maturity language. The trade-off is that publication must carry explicit slot and threshold information when decisions depend on it.

#Rationale

Language-state work needs one explicit statement of what this chart is before individual facet, move, and endpoint patterns start using it. Without that statement, readers have to reconstruct the same geometry from scattered local rules and examples.

#SoTA-Echoing

SoTA note. This section does not mint a second rule source. It is a load-bearing alignment statement: the Solution, Conformance Checklist, and role-lane discipline of this pattern must match the stance stated here or explicitly justify divergence.

Traditions covered. This pattern binds itself to architecture-description governance, model-based systems engineering, and risk/governance profiling practice.

Architecture-description governance. C.2.2a adopts the discipline that positions, publication forms, faces, and carriers stay explicitly distinct, even when one local rendering makes them look aligned.

MBSE and profile discipline. C.2.2a adapts multi-property state publication into a chart over U.CharacteristicSpace whose basis facets remain decomposable and locally thresholded.

Local stance. The load-bearing SoTA claim for this pattern is narrow: best-known current practice treats governed language-state as a multi-facet chart with explicit thresholds and role-lane distinctions, not as one maturity progression or one polished publication face.

#Relations

• Builds on: A.19, E.10, F.18.
• Coordinates with: C.2.LS, C.2.3, C.2.4, C.2.5, C.2.6, C.2.7, A.16.0, A.16, F.9, F.9.1, E.17.1.
• Constrains: threshold publication, positional claims, and anti-collapse discipline across the language-state cluster.

#Worked Examples

#Inquiry cue before endpoint capture

A research cue note may occupy a position claim with:

• moderate F,
• low articulation explicitness,
• low closure,
• strong embodied or trace-based anchoring,
• and mixed representation factors.

That position explains why the note should remain upstream of A.6.P or C.25 even if its prose happens to look polished.

#Routed operator alert note

A routed operational alert may have:

• moderate formality,
• medium articulation,
• low closure because several responses remain live,
• high operator-loop anchoring,
• and mixed symbolic and natural-language representation.

That position explains why the alert belongs in a route-bearing seam publication before it hardens into an endpoint-pattern-governed work record or reliance record.

#Viewpoint-bound adequacy note

A document-mediated adequacy note about an architecture description may be relatively high in formality and articulation, mid-level in closure, document-mediated in anchoring, and symbolic in representation. That position remains within the same language-state chart even though its carrier lane differs from an embodied inquiry cue.

#Polished prose is not closure

A prose rewrite may look cleaner, more compact, or more manager-readable than the source cue and still remain low in closure or articulation explicitness. If the underlying slot values, uncertainty, and route plurality remain unchanged, then publication polish changes the rendering or carrier lane, not the chart position by itself.

#Position Publication Package Discipline

A publishable position claim should normally identify:

• the positioned U.Episteme publication whose position is being described;
• the relevant slot values, ValueSet claims, or intervals;
• the current publication form and, if relevant, the MVPK face and carrier;
• the grounds, witnesses, or inherited pins behind the current position;
• any threshold note or endpoint-readiness condition used by the next pattern.

Minimum self-check:

1. Is the author naming a position claim in the chart, or only a folk stage label?
2. Is F being used as a surrogate for another slot?
3. Are source phenomena, publication forms, publication faces, and carriers being confused with the positioned episteme publication?
4. Are threshold claims explicit enough for the next position claim or endpoint decision?
5. If the text compares two contexts, is there a real bridge or only a lexical resemblance?

#C.2.2a:End

#Unified Formality Characteristic F

Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative

Plain-name. Formality characteristic.

One-line summary. C.2.3 defines Formality (F) as one ordinal U.Characteristic with polarity up, anchored by the default ladder F0...F9, and declared as the F coordinate of the typed F-G-R assurance tuple.

#Problem frame

Transdisciplinary work needs one shared way to speak about rigor of expression. A research hypothesis in constrained natural language, a software interface specification with explicit invariants, a controller model checked against hybrid obligations, and a proof-bearing formal development are not comparable by domain lore alone. They are comparable by how strictly the content is expressed.

Historically, that distinction drifts. Teams mix editorial maturity, organizational status, notation choice, proof support, and scope narrowness into one vague story about something being more formal. C.2.3 removes that drift by giving FPF one explicit U.Characteristic for rigor of expression.

#Problem

Without one unified F characteristic:

1. Rigor is narrated inconsistently. Different contexts invent local mode/tier language with no shared comparability.
2. Status and rigor collapse. Something accepted, published, or approved is mistaken for something precisely expressed.
3. Expression changes are hidden. A move from sketch to predicates or from executable model to proof is not recorded as a distinct content change.
4. Composition becomes unsound. A composite episteme is treated as highly formal because one segment is highly formal, even when essential support still depends on less formal parts.
5. Other characteristics are misused as surrogates. Authors quietly use scope, evidence, or language-state facets as if they were part of one master formality characteristic.

#Forces

#Solution - U.Formality as one ordinal characteristic

C.2.3 defines U.Formality as the single governing characteristic for rigor of expression in FPF.

#Identity and typing

• Name: U.Formality (abbreviated F in the assurance tuple)
• Type: U.Characteristic
• Scale kind: ordinal
• Polarity: up
• Carrier: any U.Episteme
• Default value family: F0...F9

F states how strictly the content is expressed. It does not state whether the content is true, well evidenced, widely applicable, or organizationally accepted.

#Role in the typed F-G-R tuple

F is the formality coordinate in the assurance tuple. Its interaction rules are strict:

• F is not G; scope remains governed by U.ClaimScope and other USM structures.
• F is not R; evidence, warrant strength, and decay remain assurance concerns.
• CL and bridge losses affect R, not F.
• Changes in notation, carrier, or rendering form do not change F if the formal content is preserved.

#Extensibility and local anchors

FPF provides the default anchor ladder F0...F9. A context may define sub-anchors or intermediate anchors such as F4[OCL] or F6.5, but only if:

• global order is preserved,
• the local anchor is explicitly docked to a parent anchor,
• the context does not invent a rival ladder or proxy scale.

#Usage obligations

• Every normative episteme shall declare one F value.
• Thresholds that depend on rigor should be written explicitly as F >= Fk conditions.
• Any raise or lowering of F is a content change, not a status-only change.
• F remains declaration and reasoning infrastructure; it is not itself a governance process.

#Archetypal Grounding

Tell. F does not ask whether a claim is correct. It asks how strictly the claim is expressed.

Show (System). A system requirement written as controlled natural language with unambiguous acceptance conditions may be F3; the same requirement rewritten as explicit typed invariants may become F4; a machine-checked proof of a critical invariant may raise the relevant claim core to F7 or above.

Show (Episteme). A research conjecture can begin at F1-F3, then gain explicit predicates at F4, executable semantics at F5, and proof-bearing core content at F7-F8, while remaining recognizably the same evolving claim family.

#Bias-Annotation

The pattern biases FPF toward one explicit rigor characteristic and against stories that mix formality with status, publication quality, scope width, or evidence support. That bias is intentional. The price of explicit declaration is smaller than the cost of comparing rigor through folklore.

#Conformance Checklist

• CC-F-1 Every normative U.Episteme SHALL declare exactly one U.Formality value, either a default anchor or a local sub-anchor explicitly docked to one.
• CC-F-2 F SHALL be treated as an ordinal characteristic; arithmetic over F values is invalid.
• CC-F-3 Higher F SHALL mean greater or equal strictness of expression, not greater truth, trust, or scope.
• CC-F-4 Contexts MUST NOT publish alternative "formality modes" or "tiers" as surrogates for F.
• CC-F-5 Local sub-anchors SHALL preserve the global ordering and the parent anchor meaning.
• CC-F-6 The episteme-level F of a composite episteme SHALL be bounded by the least-formal essential support on the relevant support path.
• CC-F-7 Implementations MUST NOT average F values numerically.
• CC-F-8 Changes in G, R, or CL SHALL NOT change F unless the expression form itself changes.
• CC-F-9 Cross-context transport SHALL preserve the attributed F; if the receiving context rewrites the claim materially, it becomes a new episteme with its own F.
• CC-F-10 Translation loss, bridge loss, and plane crossings SHALL affect R rather than being hidden as F changes.
• CC-F-11 Assigned F values SHALL be justifiable by observable content such as explicit predicates, executable semantics, or machine-checked proofs.
• CC-F-12 Declaring a tool or notation SHALL NOT by itself justify a higher F unless the content satisfies the target anchor semantics.
• CC-F-13 Status labels such as Draft, Approved, or Published MUST NOT substitute for F.
• CC-F-14 A context that uses F in gates or policies SHALL write those thresholds explicitly.
• CC-F-15 Language-state facets such as articulation or closure MUST NOT be hidden as pseudo-levels of F.

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

FPF needs a rigor characteristic that is portable across mathematics, software, systems, policy, and research. The smallest stable answer is one ordinal characteristic with clear anchors and explicit composition rules. Anything more fragmented breaks comparability; anything more compressed hides the substantive differences between sketch, predicate, executable model, and machine-checked proof.

#SoTA-Echoing

Post-2015 practice across formal methods, software architecture, safety engineering, verification, computational science, and typed proof environments converges on one broad lesson: rigor is not binary. It rises through explicit structuring, predicate expression, executable semantics, and machine-checked obligations. C.2.3 adopts that gradient while keeping the characteristic notation-agnostic and transdisciplinary.

#Relations

• Defines: the F coordinate of the typed F-G-R assurance tuple.
• Builds on: characteristic machinery from A.18 / A.19 and episteme-level characteristic assignment from Part C.
• Coordinates with: C.2.2, B.3, F.9, C.2.LS, A.16, C.2.4, C.2.5, C.2.6, and C.2.7.
• Coordinates with: C.19.2 when a declared use asks whether increasing rigor of expression or selecting/configuring a formal apparatus repays application work. F measures expression rigor; it does not select the apparatus, plan the work, or establish the problem-facing result.
• Constrains: any pattern, gate, or editorial rule that speaks about rigor of expression.

#Canonical Anchors F0...F9

Reading rule. Anchors are ordinal. They say what is minimally true of the expression form, not what is true of the world.

#F0 - Unstructured prose

Free natural language with unstable vocabulary, implicit assumptions, and no stable internal structure.

#F1 - Scoped notes

Still informal, but with stable topic focus and more consistent terminology. Scope is named even though criteria are not yet operationalized.

#F2 - Structured outline

A recognizable template or full section shape exists. The expression is coherent end-to-end, but acceptance criteria are still largely placeholders or informal.

#F3 - Controlled narrative

Claims are expressed in constrained prose with stable interpretation. Acceptance or refusal conditions are visible in language, even if not yet fully predicate-like.

#F4 - First-order constraints

Critical claims can be rendered as explicit predicates or invariants over typed entities. Consistency and conflict are at least checkable in principle.

#F5 - Executable math / algorithmics

The expression has declared executable semantics. Running the model, algorithm, or simulation is part of its meaning.

#F6 - Hybrid formalism

Several formal layers are coordinated explicitly, typically discrete plus continuous or several tightly coupled formal subsystems, with declared obligations between them.

#F7 - Higher-order verified

Core claims are encoded in a proof-capable higher-order setting and machine-checked against that logic kernel.

#F8 - Dependent / constructive proofs

Programs-as-proofs or dependent-type expressions carry the relevant property in their types or proof terms.

#F9 - Univalent / higher foundations

Higher-equality foundations are load-bearing. The expression relies on a frontier-grade setting where equivalence is handled as structure-level identity.

#Cross-anchor cautions

• Execution is not proof.
• Surface structure is not yet semantics.
• Publishing or approval is not an anchor.
• A local sub-anchor does not erase its parent anchor's meaning.

#Assigning F in Practice

#First-pass questions

1. Can a competent reader misread the claim materially? If yes, the expression is likely at F0-F2; if not, it may be F3 or above.
2. Are the critical claims visible as explicit predicates or invariants? If yes, the expression is at least F4.
3. Does the expression have declared executable semantics? If yes, it is likely in the F5-F6 region.
4. Would a logic kernel or type checker reject an incorrect change to a core claim? If yes, the expression is likely F7-F8, or F9 if higher-equality machinery is essential.

#Quick rubric

• No full structure -> F0-F1
• Full structure but mostly placeholder criteria -> F2
• Controlled prose with one stable reading -> F3
• Explicit predicates / invariants -> F4
• Declared executable semantics -> F5
• Hybrid / layered formal obligations -> F6
• Machine-checked proof core -> F7
• Dependent proof-carrying core -> F8
• Higher-equality foundations are essential -> F9

#Typical delta-F moves

• F2 -> F3: replace loose prose with controlled phrasing and explicit acceptance statements.
• F3 -> F4: recast acceptance into typed predicates or invariants.
• F4 -> F5: give the expression declared executable semantics.
• F5 -> F6: make multi-layer obligations explicit.
• F6 -> F7/F8: move critical claims into machine-checked proof or dependent-type form.

#Composition and Interaction

#Weakest-essential-support rule

For a composite episteme, the effective F is bounded by the least-formal essential support on the relevant support path. A highly formal annex does not lift an informal essential claim core.

#Relation to G

F concerns expression form; G concerns applicability or claim scope. Tightening scope may accompany a raise in F, but it is a separate change and must remain visible as such.

#Relation to R

Higher F often makes evidence easier to formulate, test, or prove, but it does not create warrant strength by itself. Empirical freshness, corroboration, and bridge penalties remain R concerns.

#Relation to CL and Bridges

A bridge may expose loss or mismatch across contexts. Those losses affect R; they do not silently lower or raise the attributed F. If the receiving context must materially rewrite the claim, it should publish a new episteme with its own F.

#Worked Examples

#Research hypothesis

A short note proposing a new scaling law with one stable reading and explicit acceptance conditions in prose is typically F3. Rewriting the acceptance conditions as typed predicates would move it toward F4.

#Interface specification

An interface specification with explicit preconditions, postconditions, and invariants is typically F4. Adding declared executable semantics in a faithful reference model may move it toward F5.

#Safety controller

A controller coupled to a plant model with explicit hybrid obligations is typically F6. If key invariants are then machine-checked in a higher-order proof environment, those claims move toward F7.

#Decision policy

A decision policy with controlled prose may remain F3. If thresholds and conditions are published as typed predicates, it becomes F4.

#Proof-bearing algorithm

A dependent-typed algorithm whose central property is carried by the type itself is typically F8.

#Executable ML recipe

A fully explicit training-and-evaluation recipe with declared execution semantics is typically F5. It does not become F7 merely because the surrounding execution machinery is sophisticated.

#Authoring and Review Guidance

#For authors

Declare F honestly and early. A low F declaration is not a defect; it is often the correct statement about an early expression. Raise F by changing the expression form itself, not by applying prestige language or by pointing to surrounding machinery.

#For reviewers

Review the actual claim core. Ask whether the target anchor semantics are visibly satisfied, whether essential support contains segments with lower R, lower F, or missing witness coverage, and whether status or other characteristics have leaked into the F declaration.

#For integrators and assurance leads

Use F explicitly in gates and composition analysis, but do not let it absorb work that belongs to G, R, CL, or C.2.LS. Large F gaps across collaborating epistemes are signals for explicit formalization work, not excuses for wishful leveling.

#Glossary and Notation

• U.Formality / F. The rigor-of-expression characteristic governed by this pattern.
• Anchor. A named ordinal milestone on the F ladder.
• Sub-anchor. A context-local refinement docked to one parent anchor.
• Delta-F. A content change that alters expression rigor.
• Essential support. The support without which the central claim does not stand.
• Example notation. F = F4, F = F7[HOL], requires F >= F6.

#Change Log and Patch Notes

#Supersession of legacy ladder language

This pattern supersedes deprecated wording that speaks about alternate formality modes, tiers, or editorial ladders. Forward-looking use should speak in F directly.

#Migration guidance

When refreshing legacy material, assign an initial F from observable content, rewrite local maturity labels into explicit F declarations, and keep provenance notes only as historical annotations rather than live rigor surrogates.

#Boundary to language-state facets

For the language-space extension, F does not govern U.ArticulationExplicitness, U.LanguageStateClosureDegree, U.LanguageStateAnchoringMode, or U.LanguageStateRepresentationFactorBundle. Contexts MUST NOT hide thresholds for those facets as pseudo-levels or submodes of F; those facets remain explicitly governed by C.2.LS and its subordinate patterns.

#C.2.3:End

#U.LanguageStateFacetProfile - Thin profile bundle for language-state facets

Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative

Plain-name. Language-state facet profile.

Use this pattern when. Use C.2.LS when a governed U.Episteme publication needs one explicit profile that keeps formality, articulation, closure, anchoring, representation factors, and local thresholds visible together.

What goes wrong if missed. Teams replace the facet profile with a maturity adjective such as ready, raw, or stable, then route, reopen, bridge, or govern the publication from a label that hides the actual facet values.

What this buys. A thin, decomposable profile bundle: each facet stays governed by its own pattern, while the profile gives authors, assurance readers, and integrators one place to publish threshold-relevant language-state position.

#Problem frame

Once position claims in the declared language-state chart over U.CharacteristicSpace must be published and compared, teams need one thin profile bundle that keeps the relevant facets visible as one explicit facet profile without turning that profile into a second characteristic calculus or a surrogate maturity progression.

#Problem

Without a dedicated profile bundle, authors blur articulation, closure, anchoring, and representation into one vague maturity story, or they silently reuse F as a surrogate. That blocks admissible threshold publication, undercuts A.16 move guards, and makes school-to-school bridge work harder than it needs to be.

#Forces

#Solution

U.LanguageStateFacetProfile is a typed profile bundle that names the facets by which position claims in the declared language-state chart over U.CharacteristicSpace are published and interpreted:

• formalityRef -> U.Formality from C.2.3
• articulationExplicitnessRef -> U.ArticulationExplicitness from C.2.4
• languageStateClosureDegreeRef -> U.LanguageStateClosureDegree from C.2.5
• languageStateAnchoringModeRef -> U.LanguageStateAnchoringMode from C.2.6
• languageStateRepresentationFactorBundleRef -> U.LanguageStateRepresentationFactorBundle from C.2.7
• thresholdRefs? -> context-local threshold declarations over the governed facets
• routeNotes? -> informative notes that help interpret routing or reopening decisions

C.2.LS is therefore a profile-bundle governing pattern, not a characteristic governing pattern and not a trajectory governing pattern. Characteristic semantics remain with A.18/A.19; admissible moves remain with A.16; explicit transition-structure publication remains with E.18.

#Kind and profile-bundle boundary

U.LanguageStateFacetProfile is a dependent durable profile-bundle value under the declared U.LanguageStateSpace and U.CharacteristicSpace boundary, not a root U-kind. Its identity is the explicit bundle of language-state facet refs used for position reading and threshold publication. A local dashboard, table, route note, or maturity label is a publication or interpretation over the bundle, not the bundle itself.

#Governing boundary

C.2.LS governs only the profile composition and the rule that the language-state facets must remain explicit and non-collapsed. It does not:

• redefine F;
• invent a second formality progression;
• govern the scale semantics of AE, CD, LanguageStateAnchoringMode, or U.LanguageStateRepresentationFactorBundle;
• govern reopen/backoff moves;
• govern endpoint classification or bridge kinds.

#Threshold publication discipline

Any threshold used for routing, admissible move guards, or entry into A.6.P shall be published on explicit named facets within the profile. Contexts shall not speak of hidden sub-levels of F when what matters is really articulation, closure, anchoring, or the representation-factor bundle.

#Local profile-reading witness

For this pattern, a published facet profile is reviewable when:

• the facet refs are explicit or explicitly inherited from an already pinned upstream publication;
• any threshold-bearing use names the facet whose threshold is being invoked;
• route notes or local overlays remain informative and visibly docked to the explicit facet bundle;
• and the profile does not smuggle move rules, bridge rules, gate state, or downstream governing-pattern semantics into the bundle record.

A polished label, one strong facet, or one memorable route note does not by itself yield an admissible profile reading. The profile remains conformant only when the named facets stay explicit and decomposable.

#Composite readings

A language-state judgement may be composite, but the composite shall be decomposable. For example, a cue may be:

• low AE,
• medium CD,
• AM.TraceAnchored,
• and representation-wise mixed rather than purely symbolic.

A conforming profile makes this decomposition visible rather than hiding it under one poetic label such as "early" or "raw".

#Corridor map note

C.2.LS participates in the current Language-State & Semantic Routing Corridor, but only as the thin governing pattern of the facet-profile bundle. Readers who need one map of the full language-state governing-pattern set should read the corridor note in C.2.2a.

That map does not change the governing boundary here: C.2.LS still does not govern cue preservation, route-bearing publication, prompt entry, or downstream endpoint use.

#Archetypal Grounding

Tell. A team may say a draft is "still forming" for different reasons. U.LanguageStateFacetProfile forces the team to say whether the issue is low articulation, low candidate-space closure, an anchoring mismatch, or an unresolved representation-factor bundle.

Show (System). An operator alert note can be AM.OperatorLoop anchored and low-closure without being low-formality in every respect.

Show (Episteme). An inquiry note can be low articulation yet already tightly anchored to exemplars and traces.

#Bias-Annotation

The pattern biases authors toward explicit facet governance and away from master-scale stories. That cost is intentional: the goal is to prevent surrogate progressions from entering the Core.

#Conformance Checklist

• CC-C.2.LS-1 A language-state facet profile SHALL reference explicit facet governing patterns rather than invent local unnamed factors.
• CC-C.2.LS-2 C.2.LS MUST NOT redefine F or create a second formality progression.
• CC-C.2.LS-3 Thresholds that matter for routing, reopening, or lexical repair SHALL be published on explicit facets.
• CC-C.2.LS-4 Trajectory accounts that rely on facet profiles SHOULD reuse A.16 move kinds and E.18 transition-structure publication rules.
• CC-C.2.LS-5 Composite labels such as early, settled, or ready SHALL NOT stand in for the explicit facet bundle when those states matter operationally.
• CC-C.2.LS-6 Composite readings, overlays, and route notes SHALL remain decomposable into named facets and MUST NOT behave as hidden master factors.
• CC-C.2.LS-7 A profile bundle MUST NOT smuggle move rules, bridge rules, gate state, or downstream governing-pattern semantics into what should remain a thin facet-profile record.

#Common Anti-Patterns and How to Avoid Them

• Shadow progression. Treating early/late as a master scale. Split the judgement into the named facets.
• Formality capture. Letting F stand in for closure or articulation. Publish those facets explicitly.
• Bundle inflation. Turning U.LanguageStateFacetProfile into a second A.19. Keep it thin and referential.
• Opaque readiness. Using words such as ready or mature without naming which facet justifies the claim.
• Route-note capture. Letting an informative route note behave like move rule, gate state, or endpoint governance. Keep route notes informative and push operative authority back to A.16, downstream governing patterns, or gate/work governing FPF patterns or authoritySourceRef targets.

#Consequences

The benefit is authority-reference clarity: early cue work, bridge annotations, and reopen moves can all talk about one explicit facet profile. The trade-off is more explicit profile authoring and threshold publication.

#Rationale

The pattern gives the declared language-state chart over U.CharacteristicSpace one stable facet-profile record through which its facet bundle can be published together, while respecting the rest of FPF's governing boundaries.

#SoTA-Echoing

SoTA note. This section does not mint a second rule source. It is a load-bearing alignment statement: the Solution, Conformance Checklist, and boundary discipline of this pattern must match the stance stated here or explicitly justify divergence.

Traditions covered. This pattern binds itself to architecture-description governance, model-based systems engineering, and governance/profile discipline.

Architecture-description governance. C.2.LS adopts the discipline that useful state publication should keep the relevant profile elements explicit rather than hiding them inside one summary label.

MBSE and profile discipline. C.2.LS adapts typed multi-property state publication into a thin, decomposable language-state facet bundle rather than one master scale.

Local stance. The load-bearing SoTA claim for this pattern is narrow: best-known current practice treats language-state publication as a small explicit facet profile with local thresholds and decomposable readings, not as one maturity adjective or one route-coloured bundle label.

#Relations

• Builds on: A.18, A.19, C.2.2a, C.2.3.
• Coordinates with: C.2.4, C.2.5, C.2.6, C.2.7, A.16.0, A.16, A.16.1, A.16.2, B.4.1, B.5.2.0, E.18, F.9.1.
• Constrains: language-state threshold publication and profile composition.

#Worked Examples and Composition Notes

#Operator-facing early alert

A console alert note may be published with a language-state facet profile such as:

• F = F2/F3 because the note is structurally controlled but still lightweight;
• AE = AE2 because candidate anchors are visible but not yet fully relation-shaped;
• CD = CD1 because several routes remain live;
• LanguageStateAnchoringMode = AM.OperatorLoop because the note is directly anchored to operator intervention/work;
• RepresentationFactorBundle = {local, sparse, mixed-symbolic} because alert text and compact codes coexist.

This example shows why no one facet can replace the others. The note is not simply early; it is early in a specific, decomposable way.

#Research cue before lexical repair

A felt or trace-anchored mismatch cue in an inquiry note may be:

• low AE,
• very low CD,
• AM.EmbodiedFelt,
• and representation-wise mixed because the cue is partly verbal, partly kinesthetic, partly exemplar-based.

That profile explains why the cue should remain in A.16.1 rather than being forced into A.6.P or B.5.2 immediately.

#Architecture-description case

A viewpoint-bound note about the adequacy of an architecture description may be moderately high in F, moderately high in AE, still mid-level in CD, document-mediated in AM, and symbolic in its representation-factor bundle. The profile keeps description-side adequacy distinct from system-side engineering quality.

#Same F, different profile

Two notes may share the same rough F band and still differ sharply in articulation, closure, anchoring, and representation factors. One may be operator-loop anchored and low-closure; another may be document-mediated and comparatively closed. The profile bundle keeps that difference visible instead of letting F behave like a master factor.

#Authoring and Review Guidance

#For authors

When publishing a language-state facet profile:

1. start from the local authoring problem rather than from a memorized progression;
2. name the facet refs explicitly;
3. add threshold refs only when a threshold changes routing, repair, or governance;
4. avoid global labels such as "mature", "raw", or "ready" unless the profile decomposition is already visible.

#For assurance readers

An assurance reader should ask:

• is any facet silently replaced by F?
• is a threshold published on an explicit facet rather than on a poetic surrogate?
• do route or reopen claims actually match the published facet bundle?
• are profile notes genuinely informative, or are they smuggling governing semantics that belong elsewhere?

#For integrators

Integrators should preserve profile references rather than rephrasing them into local slang. A local alias is acceptable only if the underlying facet docking remains explicit and stable.

#Extension and Migration Notes

#Local extension rule

Contexts may extend the profile with local threshold refs, route notes, or additional descriptive aids, but they shall not add a new master facet that collapses the governed set into one summary factor.

#Migration from surrogate prose

Older prose often says:

• "the episteme is still early",
• "the issue is not mature enough",
• "the note is ready",
• "the cue is still raw".

A conforming migration rewrites such statements into explicit facet talk: which facet is low, which is high, which threshold is or is not met, and which move that fact justifies.

#Boundary reminder

U.LanguageStateFacetProfile is a coordination record. If authors find themselves putting move rules, bridge rules, scale rules, or bundle semantics into the profile itself, they are writing in the wrong governing pattern.

#Profile Publication Package Discipline

#Minimal publishable profile package

A publishable U.LanguageStateFacetProfile should normally carry:

• the declared facet refs for AE, CD, LanguageStateAnchoringMode, and LanguageStateRepresentationFactorBundle;
• any threshold refs that substantively affect routing, repair, bridge interpretation, or review load;
• the local relation to F when readers might otherwise treat F as a surrogate;
• any omission note when a facet is intentionally unpublished, unknown, or locally irrelevant.

One-line publication is admissible only if facet governance remains legible.

#Partial-profile rule

A partial profile is admissible only when omission is explicit. Publishing AE and CD while deferring LanguageStateAnchoringMode is acceptable; silently omitting it and then speaking in scalar prose such as "early" or "ready" is not.

If only one facet is published, either explain why the others are not governed in the current note or point to the note where they are already published.

#Overlay discipline

Local overlays such as "explicit-but-open", "trace-heavy", or "operator-tight" are admissible only when they dock to explicit facet refs. Overlays remain secondary to the governed profile and must not replace the facet bundle.

#Cross-Facet Reading Rule

#No master-facet reading

Do not infer the whole language-state profile from one facet. High AE does not entail high CD; strong AM.OperatorLoop does not fix AE or CD; symbolic representation does not entail high F; low CD does not imply low operational consequence.

#Threshold interaction rule

When a threshold is expressed over one facet, say whether the other facets are merely informative or also constraining. A Context may allow entry into B.5.2.0 once AE suffices for an explicit open question while still capping CD so rival answers remain live; it may allow entry into A.6.P at AE3+ while still capping CD so the move remains exploratory rather than endpoint-binding.

#Transition reading rule

Read profile transitions facetwise. A note may become more explicit without becoming more closed, more document-mediated without changing closure, or more symbolic without becoming more formal. A.16, A.16.1, A.16.2, B.4.1, and B.5.2.0 should therefore cite the facet transition that actually justifies the move.

#Review Matrix and Migration Tests

#Review matrix

An assurance reader should ask:

• is each published facet governed by its proper pattern rather than by surrogate prose;
• does any overlay smuggle a hidden scalar or gate decision;
• are threshold claims tied to the facet that really bears them;
• do cited moves in A.16, A.16.1, A.16.2, B.4.1, or B.5.2.0 actually match the facet bundle;
• if the profile crosses a bridge or viewpoint boundary, are stance and loss notes kept in F.9 or F.9.1 rather than imported as fake facets.

#Migration test for source prose

Source phrases such as "still immature", "not ready yet", or "already stable enough" should be unpacked into: which facet is claimed, which anchor or bundle member justifies it, which threshold or route consequence follows, and which governingPatternRef or authoritySourceRef carries that consequence.

#Comparative profile use

Compare profiles facetwise unless a Context has published an explicit local aggregation for reporting. Such an aggregation remains secondary and must not replace the profile in norms, thresholds, or bridge claims.

#C.2.LS:End

#U.ArticulationExplicitness

Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative

Plain-name. Articulation explicitness.

Use this pattern when. Use C.2.4 when a governed U.Episteme publication must say how explicit its semantic shape already is before routing, repair, prompt entry, or endpoint classification.

What goes wrong if missed. A formal-looking sentence is treated as semantically ready, a real early cue is discarded as too vague, or F is misused as a proxy for whether anchors, slots, and relation-like structure are explicit enough.

What this buys. A separate ordinal characteristic for articulation explicitness, so teams can publish early cues, threshold entry into A.6.P, and keep articulation distinct from formality, closure, trust, and endpoint authority.

#Problem frame

A governed U.Episteme can already matter while its semantic shape is not yet fully explicit. The declared language-state chart over U.CharacteristicSpace therefore needs one basis-slot governing pattern for how explicit that shape already is, without confusing articulation with rigor, truth, or closure.

#Problem

When articulation explicitness stays implicit, authors either overstate readiness for downstream repair or endpoint classification, or hide early cue structure entirely. Reusing F for this judgement creates a category error: formality is about rigor of expression, not about whether the semantic shape is already explicit enough for repair or endpoint classification.

#Forces

#Solution

U.ArticulationExplicitness is an ordinal characteristic over how explicit the semantic shape is in a published position claim in the declared language-state chart over U.CharacteristicSpace, for publication, route-governance claims, and repair.

#Kind and characteristic boundary

U.ArticulationExplicitness is a dependent durable characteristic value under the declared U.LanguageStateSpace / U.CharacteristicSpace boundary, not a root U-kind. Its identity is the articulation-explicitness basis slot and ordinal scale discipline for governed episteme publication positions. Local thresholds, route labels, and score-table columns may reference it, but they do not create a separate U-kind.

#Characteristic specification

• Kind: CHR characteristic.
• Scale discipline: ordinal.
• What rises: semantic shape becomes more explicit.
• What does not follow automatically: truth, trust, closure, admissibility, or formality.

AE is therefore independent from F, from LanguageStateClosureDegree, and from endpoint authority.

#Starter anchor set

The anchors are a starter set; a Context may refine them locally, but it shall keep the ordinal direction and the distinction from F intact.

#Use discipline

• AE may be used to state entry conditions for A.6.P.
• AE may be used to justify why an episteme remains in A.16.1 or B.4.1.
• AE shall not be used as a surrogate for closure, confidence, or truth.
• High F shall not be taken to imply high AE, and high AE shall not be taken to imply high F.

#Change discipline

Raising AE requires additional explicit anchors, slots, or normal-form structure. Lowering AE is admissible under A.16.2 when a prior articulation proves over-committed or misleading.

#Archetypal Grounding

Tell. "Something is off" may be a real cue even before role bearer, intended work occurrence, reliance use, or evaluator are explicit.

Show (System). An operator alert cue grounded in a disturbance trace may be stabilized as a candidate intervention cue before a full work relation or reliance relation specification exists.

Show (Episteme). A research note may name a contrast and exemplars before it has a clean proposition.

#Bias-Annotation

The pattern legitimizes early cues. The counter-bias is explicit: low AE never licenses hidden semantics or unreviewable leaps.

#Conformance Checklist

• CC-C.2.4-1 AE SHALL NOT be treated as a synonym for F.
• CC-C.2.4-2 Entry into A.6.P SHOULD require at least the Context's declared articulation threshold.
• CC-C.2.4-3 AE judgements that drive routing or repair SHALL cite the anchors, contrasts, or slots that justify the chosen level.
• CC-C.2.4-4 Raising AE SHALL NOT be described as if it automatically settled closure or authority.

#Common Anti-Patterns and How to Avoid Them

• Formal-looking but semantically thin. High F, low AE. Declare both.
• Mystical cue immunity. Low AE presented as exempt from authoring discipline. It is not.
• Ready-by-tone. A sentence sounds precise, so authors assume AE3+. Publish the actual anchors.

#Consequences

The benefit is admissible publication of early cues and clearer threshold setting for repair. The trade-off is that authors must distinguish "not yet explicit" from "already formal".

#Rationale

AE is one basis slot in the declared language-state chart over U.CharacteristicSpace. Without it, A.16.0, A.16.1, and B.4.1 cannot state crisp entry, seam, and completion conditions.

#SoTA-Echoing

The distinction echoes work on sketching, focusing/TAE, embodied cue capture, and representation probing: a cue can be real and operationally relevant before it becomes fully explicit.

#Relations

• Builds on: A.18, C.2.2a, C.2.LS.
• Coordinates with: C.2.5, A.16.0, A.16, A.16.1, A.16.2, A.6.P, B.4.1, B.5.2.0.
• Constrains: articulation thresholds for routing and repair.

#Worked Examples and Edge Cases

#High formality, low articulation

A template may be syntactically precise and therefore high in F, yet still low in AE because the actual role-bearer, relation, or intended-work-or-reliance-move slots remain unclear. This is the classic case where formal-looking language overstates semantic readiness.

#Low formality, high articulation

A short, plain note may be low in F yet already high in AE because the relation skeleton is explicit enough for A.6.P. This case matters because it shows that AE is not a stylistic measure.

#Threshold edge case

A cue with stable trigger span and candidate anchors may still sit between AE2 and AE3. A Context should then publish its local threshold rule explicitly rather than pretending that entry into A.6.P is obvious by tone.

#Authoring and Review Guidance

#Author prompt

To assign AE, ask:

• is the trigger span stable?
• are candidate anchors visible?
• is there already a minimally relation-like skeleton?
• is a normal form actually publishable, or only hinted?

#Review prompt

An assurance reader should reject AE claims that rely only on rhetorical confidence. The claimed level should be supported by anchors, slots, contrasts, exemplars, or explicit normal-form structure.

#Threshold publication reminder

If AE determines whether an episteme stays in A.16.1, passes through B.4.1, or enters A.6.P, that threshold should be published explicitly and locally.

#Extension and Migration Notes

#Local anchor refinement

Contexts may refine the starter anchor set with subanchors, but the refinement must preserve the ordinal direction and the distinction from F and CD.

#Migration from vague articulation prose

Statements such as "still vague", "more explicit now", or "ready for formalization" should be migrated into explicit AE claims plus the corresponding move or routing claim.

#Boundary reminder

AE does not govern closure, confidence, or warrant. If authors want those meanings, they must publish them through their own governing patterns.

#Articulation Publication Package Discipline

#Minimal articulation package

An AE claim that matters for routing or repair should normally publish more than a level token. The supporting package should indicate which of the following are present:

• stable trigger span;
• candidate anchors or contrasts;
• role-bearer / intended-work-or-reliance-move / evaluator slots where relevant;
• a minimally relation-like skeleton;
• a candidate normal form, or an explicit note that no such form is yet admissible.

A bare AE3 label is a publication with insufficient articulation support when the supporting articulation evidence is absent.

#Threshold package for route change

If entry from A.16.1 or B.4.1 into A.6.P depends on AE, publish the threshold together with the minimum articulation package required at crossing time.

#Evidence-limited rise rule

AE may rise only as far as the published anchors, slots, and contrasts warrant. Stylistic polish, templates, or rhetorical confidence do not raise AE on their own.

#Threshold Crossing and Split Handling

#Admissible entry into relational repair

Entry into A.6.P is admissible when the local articulation threshold is met and the note already exposes enough relation structure for precision restoration to operate on a real relation-like episteme. Entry into B.5.2.0 is admissible when the open question is explicit enough for prompt-species publication even if relation structure is still too thin for A.6.P. If the threshold is borderline, keep the episteme in B.4.1 or A.16.1 and state what anchor or slot is still missing.

#High-articulation, low-closure cases

A note may reach AE4+ while remaining low or mid in CD. In such cases state that articulation is sufficient for precise handling while closure still leaves rival routes or frames live.

#Split-publication rule

If one note contains a high-AE fragment and a low-AE remainder, split the publication rather than assigning one averaged level that hides the actual route structure.

#Review Matrix and Endpoint Boundary Tests

#Review matrix

An assurance reader should ask:

• are the named anchors genuinely present rather than merely presupposed;
• does the claimed articulation level rest on structure rather than tone;
• are role-bearer, intended-work-or-reliance-move, evaluator, or comparison slots still ghosted;
• if AE is used to justify a route-governance transfer, is the destination governing pattern actually ready to receive the publication.

#Endpoint-boundary test

High AE does not by itself authorize endpoint claims, gate claims, or quality ascriptions. If such consequences appear, show which downstream governing pattern takes over.

#Migration note for false precision

Rigid templates, capitalized labels, or tidy sentence rhythm can simulate articulation. Migration should therefore test whether anchors and slots are really present; if not, the articulation level should drop.

#C.2.4:End

#U.LanguageStateClosureDegree

Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative

Plain-name. Language-state closure degree.

Use this pattern when. Use C.2.5 when a governed U.Episteme publication must say how fixed its candidate space, route space, or frame space has become before endpoint use, reopening, or retreat.

What goes wrong if missed. A confident tone is mistaken for closure, closure is mistaken for truth or gate authority, or a closure drop leaves endpoint expectations and route commitments silently hanging.

What this buys. A separate ordinal characteristic for closure degree, so teams can distinguish exploration, stabilization, selected route, guarded fixation, and admissible retreat without collapsing closure into formality, articulation, warrant, or obligation.

#Problem frame

A governed U.Episteme may already be explicit enough for publication while its declared position claim remains intentionally open to rival routes or frames. The declared language-state chart over U.CharacteristicSpace therefore needs a separate basis-slot governing pattern for how fixed or closed the current candidate space has become.

#Problem

Closure is often hidden inside vague words such as "ready", "settled", or "open". When closure is not explicit, teams cannot reason cleanly about reopen, sketch-backoff, or the admissibility of endpoint docking.

#Forces

#Solution

U.LanguageStateClosureDegree is an ordinal characteristic over how fixed the current candidate set, framing, and admissible next moves are in a published position claim in the declared language-state chart over U.CharacteristicSpace.

#Kind and characteristic boundary

U.LanguageStateClosureDegree is a dependent durable characteristic value under the declared U.LanguageStateSpace / U.CharacteristicSpace boundary, not a root U-kind. Its identity is the closure-degree basis slot and ordinal scale discipline for governed episteme publication positions. Local route commitments, gate claims, or authority states remain neighboring claims unless their governing patterns make them current.

#Characteristic specification

• Kind: CHR characteristic.
• Scale discipline: ordinal.
• What rises: the local state becomes more fixed or more binding.
• What does not follow automatically: truth, trust, formality, or quality.

#Starter anchor set

#Non-collapse rules

LanguageStateClosureDegree is not:

• F;
• articulation explicitness;
• gate decision;
• evaluator confidence;
• warrant strength.

A text may be highly explicit but low-closure, or low-explicitness but already high-closure by policy. Those states shall not be collapsed.

#Change discipline

Increasing CD requires narrowing candidate space, route space, or frame space explicitly. Lowering CD is admissible only through a named move such as reopen, sketchBackoff, or respecify, with a retained-witness and discarded-assumption note.

#Archetypal Grounding

Tell. Two notes may look equally explicit, but one is still intentionally open while the other is already committed to a single route.

Show (System). An incident cue can be routed to rollback while remaining reopenable if new evidence arrives.

Show (Episteme). A hypothesis sketch can be highly articulated but still low closure because rival explanations remain live.

#Bias-Annotation

The pattern makes closure explicit, which resists hidden overconfidence but may feel heavy to authors who prefer implicit consensus.

#Conformance Checklist

• CC-C.2.5-1 Closure SHALL be declared independently from F and AE when it matters for routing, docking, or reopening.
• CC-C.2.5-2 Reopen/backoff moves SHALL cite the prior closure state they are relaxing.
• CC-C.2.5-3 Strong-closure states SHOULD name the guard, governingPatternRef, or authoritySourceRef that makes the closure binding.
• CC-C.2.5-4 Endpoint authority SHALL NOT survive a closure drop silently when the supporting route or publication form no longer holds.

#Common Anti-Patterns and How to Avoid Them

• Closure by mood. A sentence sounds decisive, so teams assume high closure. Publish CD explicitly.
• Irreversible drift. Closure rises informally but no reopening condition exists. Use A.16.2.
• Authority smuggling. High closure is treated as if it were automatically a gate or obligation. Route those consequences through the proper governing patterns.

#Consequences

The benefit is admissible handling of stabilization, commitment, and reopening. The trade-off is more explicit state declaration and more explicit retreat records.

#Rationale

Closure is the route-governance basis slot that complements articulation within the declared language-state chart over U.CharacteristicSpace. A.16.0 and its seam species need both.

#SoTA-Echoing

The facet aligns with iterative design, open-world reasoning, and exploratory search practices where closure is a governance choice rather than a hidden by-product.

#Relations

• Builds on: A.18, C.2.2a, C.2.LS.
• Coordinates with: C.2.4, A.16.0, A.16, A.16.1, A.16.2, B.4.1, B.5.2.0.
• Constrains: reopen, backoff, and endpoint docking guards.

#Worked Examples and Retreat Cases

#Explicit but still open

A note may sit at AE4 yet only CD1 because rival explanatory frames are still live. The important lesson is that explicit publication does not imply settled closure.

#Strong closure under policy guard

An operator rule may be only moderate in AE but high in CD because policy already fixes the next step under the current horizon. This shows why closure is governance-facing, not merely stylistic.

#Reopen case

A route may move from CD4 back to CD2 when counter-evidence appears. A conforming publication does not hide this as embarrassment; it records the retreat as an admissible A.16.2 move.

#Authoring and Review Guidance

#Author prompt

To assign CD, ask:

• how many rivals remain live?
• is one route merely preferred, or actually fixed?
• what guard, governingPatternRef, or authoritySourceRef makes the closure binding?
• what would count as an admissible reopen trigger?

#Review prompt

An assurance reader should ask whether closure is being inferred from tone, from hierarchy, or from social force rather than from an explicit narrowing of route or frame space.

#Governance note

Whenever CD substantively affects gates, commitments, or late endpoint authority, the supporting guard, governingPatternRef, or authoritySourceRef should be visible.

#Extension and Migration Notes

#Local anchor refinement

Contexts may refine the starter closure anchors, but shall keep the ordinal progression and the explicit link to reopen/backoff discipline.

#Migration from readiness language

Words such as "settled", "closed", "final", or "open" should be treated as migration prompts into explicit CD claims and, where needed, into named A.16.2 moves.

#Boundary reminder

CD is not warrant strength and not a gate decision. It speaks only about the local fixity of the current episteme or publication position and its candidate space.

#Closure Publication Package Discipline

#Minimal closure package

A publishable CD claim should name what has narrowed:

• the rival routes or frames that remain live;
• the route, frame, or interpretation that is currently privileged or fixed;
• the guard, governingPatternRef, authoritySourceRef, or policy that makes the narrowing binding;
• the condition under which an admissible reopen or backoff would occur.

A bare claim such as "now settled" is insufficient when closure affects routing or authority.

#Narrowing-source rule

Closure may rise because evidence eliminates rivals, governance temporarily binds a route, or protocol requires fixation under time pressure. State the source of narrowing because different sources imply different reopen expectations.

#Partial-closure rule

Closure may be local rather than global. A note can be closed enough for one route while remaining open about broader explanation or classification; a prompt may be fixed enough to hold one question steady while still open enough that rival answers remain live. Publish that locality explicitly.

#Continuing and Withdrawn Authority Handling

#Authority retention rule

If higher CD carried endpoint expectations, guard claims, or route commitments, a closure drop must say which consequences remain and which are withdrawn.

#Admissible retreat record

An admissible retreat through reopen, sketchBackoff, or respecify should retain:

• the prior closure state;
• the reason the prior fixation no longer holds;
• the assumption or route being relaxed;
• the still-binding remainder, if any.

This prevents false continuity after retreat.

#Closure versus obligation boundary

High CD may coexist with obligations, but CD is not itself an obligation-bearing governing FPF pattern or authoritySourceRef target. When prose treats "closed" as "must now be done", name the actual governingPatternRef or authoritySourceRef for that claim.

#Review Matrix and Reopen Tests

#Review matrix

An assurance reader should ask:

• what was narrowed;
• by what governingPatternRef, authoritySourceRef, or guard it was narrowed;
• what would reopen it;
• whether any gate, release, work, evidence, assurance, policy, or adjudication authority survives the claimed closure level;
• whether the publication distinguishes local closure from whole-context finality.

#False-finality test

Words such as "final", "settled", or "decided" should be challenged unless the route-governance and guard package is explicit. Final-sounding rhetoric often overstates actual closure.

#Cross-facet reminder

Low CD does not imply low articulation, low anchoring, or poor representation. Reviewers should not treat openness as low seriousness.

#Split-closure review case

A publication may be closed enough for immediate local work use or reliance use while remaining open about broader explanation, long-horizon consequences, or alternative classification. Allow the split when locality is explicit; reject prose that advertises whole-case finality when only one language-state segment is fixed.

#C.2.5:End

#U.LanguageStateAnchoringMode

Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative

Plain-name. Language-state anchoring mode.

Use this pattern when. Use C.2.6 when a governed U.Episteme publication needs to say whether its current position is anchored in bodily enactment, traces, model state, document mediation, operator loop, or an explicit mixed regime.

What goes wrong if missed. A prose note hides an embodied, trace-based, model-latent, or operator-loop cue; bridge-loss notes disappear; and the final publication face is mistaken for the original anchoring regime.

What this buys. A nominal anchoring-mode characteristic that keeps source anchoring, publication face, carrier, bridge loss, evidence, and reliance claims separate while still letting teams compare language-state positions.

#Problem frame

Published position claims in the declared language-state chart over U.CharacteristicSpace differ not only by articulation and closure, but by how the governed U.Episteme in that claim is anchored to bodies, traces, model states, documents, or operator loops.

#Problem

Without an explicit anchoring-mode declaration, embodiment and source anchoring are smuggled into informal prose or folded into representation terms. That undercuts cue comparison, undercuts bridge loss notes, and turns operator-facing language-state work into a special case with no explicit governing-pattern relation.

#Forces

#Solution

U.LanguageStateAnchoringMode is a nominal characteristic that states the primary anchoring regime of the governed U.Episteme named by the current position claim: bodily enactment, trace, model state, document, operator loop, or an explicit mixed regime. If source anchoring and current publication-face anchoring differ, both shall be distinguished rather than collapsed.

#Kind and characteristic boundary

U.LanguageStateAnchoringMode is a dependent durable characteristic value under the declared U.LanguageStateSpace / U.CharacteristicSpace boundary, not a root U-kind. Its identity is the anchoring-mode basis slot and nominal family for governed episteme publication positions. Evidence, source-currentness, publication face, carrier, work, gate, and reliance claims remain with their direct governing patterns.

#Starter family

#Governing boundary

U.LanguageStateAnchoringMode is an anchoring-mode characteristic for one governed U.Episteme claim. It is not a representation factor bundle, closure state, truth status, evidence relation, source-currentness relation, work claim, gate claim, or reliance permission by itself. Model-latent, operator-loop, embodied, trace, and document-mediated cases name where the episteme is anchored for the current claim; any publication face, carrier, source-currentness, bridge-loss, work, evidence, or gate claim stays with the direct governing pattern.

If embodiment matters, it shall be declared here or immediately beside this characteristic rather than being hidden inside representation talk.

#Mixed-mode rule

AM.Mixed is admissible only when the component modes are named explicitly. "Mixed" shall not be a lazy escape from deciding whether the key anchor is bodily, trace-based, model-latent, document-mediated, or operator-loop based.

#Bridge implications

Bridge work over governed U.Episteme publications in the declared language-state chart should pay attention to anchoring shifts. A translation from AM.EmbodiedFelt to AM.DocumentMediated, or from AM.ModelLatent to prose, often requires explicit loss notes in F.9 and may require a bridge-use note in F.9.1.

#Archetypal Grounding

Tell. A felt cue, a controller-side probe score, and a textual design note may all be early cues, but they are anchored differently.

Show (System). An alert tied to an operator console is AM.OperatorLoop, not just "text".

Show (Episteme). A model-probe cue grounded in latent state is AM.ModelLatent even when rendered into prose.

#Bias-Annotation

The pattern pushes authors to declare anchoring rather than hide it in metaphors such as "the system wants" or "the note suggests".

#Conformance Checklist

• CC-C.2.6-1 Anchoring mode SHALL NOT be inferred from publication phrasing alone when it matters for source use, reliance, or bridge interpretation.
• CC-C.2.6-2 Embodiment-sensitive or operator-loop cases SHOULD declare the embodiment or operator anchor explicitly.
• CC-C.2.6-3 U.LanguageStateAnchoringMode MUST NOT be collapsed into U.LanguageStateRepresentationFactorBundle.
• CC-C.2.6-4 Mixed-mode declarations SHALL list their component modes explicitly.

#Common Anti-Patterns and How to Avoid Them

• Text-only illusion. Treating every cue as document-mediated because it has been written down.
• Representation capture. Using symbolic/distributed labels to hide world-anchoring distinctions.
• Embodiment mystification. Treating bodily or operator-loop cues as beyond explicit publication.

#Consequences

The benefit is cleaner reasoning about embodied, operator-facing, trace-based, and model-latent cues. The trade-off is more explicit declaration work and more explicit bridge loss notes when modes shift.

#Rationale

The declared language-state chart over U.CharacteristicSpace needs one explicit anchoring basis slot so that A.16.0, A.16.1, B.4.1, and F.9.1 can refer to anchoring regime without redefining it.

#SoTA-Echoing

The facet is motivated by embodied cognition, operator-facing interaction practice, active inference, and modern model-probing practice, all of which distinguish cue content from anchoring regime.

#Relations

• Builds on: A.18, C.2.2a, C.2.LS.
• Coordinates with: A.7, A.16.0, A.16, A.16.1, B.4.1, B.5.2.0, C.2.7, F.9.1.
• Constrains: cue publication and bridge loss notes.

#Worked Examples and Bridge-Loss Cases

#Embodied-to-document shift

A bodily felt cue published as prose usually changes from AM.EmbodiedFelt toward AM.DocumentMediated. That shift is not harmless; it often introduces bridge loss and should be treated as such when cross-context equivalence is claimed.

#Model-latent to operator-loop case

A latent probe score may first be AM.ModelLatent, then feed an operator-facing alert face where the working publication becomes AM.OperatorLoop. A conforming account should keep both anchoring modes visible rather than pretending the downstream publication wording fully captures the model-side cue.

#Mixed-mode publication

An alert note may admissibly be AM.Mixed when it combines operator-loop anchoring, trace anchoring, and document mediation. But the mix must be named explicitly rather than used as a catch-all escape.

#Authoring and Review Guidance

#Author prompt

When declaring anchoring mode, ask:

• what is the primary anchor kind?
• does bodily or operator participation matter directly?
• is the key anchor trace-based, model-internal, or document-based?
• if multiple modes matter, which ones and why?

#Review prompt

An assurance reader should watch for the common mistake where prose formatting tricks authors into forgetting the original anchoring mode.

#Bridge note

If anchoring changes across publication or translation, F.9 and F.9.1 should often carry explicit loss or stance notes rather than silent equivalence language.

#Extension and Migration Notes

#Local extension rule

Contexts may add local anchoring modes, but they should do so by extension of the starter family rather than by collapsing the family into a text-vs-world binary.

#Migration from metaphorical prose

Statements like "the system wants", "the note suggests", or "the operator-facing publication says" should be repaired by naming the actual anchoring mode and the actual detector/enactor or witness structure.

#Boundary reminder

U.LanguageStateAnchoringMode does not decide representation, articulation, closure, or trust by itself. It only names how the episteme is anchored.

#Anchoring Publication Package Discipline

#Minimal anchoring package

A publishable U.LanguageStateAnchoringMode claim should normally identify:

• the primary anchor kind;
• any directly relevant embodiment, operator, trace, model, or document witness;
• the transformation chain if the current note is not at the original anchoring site;
• any secondary modes that remain load-bearing.

This is especially important when the final wording is prose, because prose often hides the anchoring regime.

#Source-versus-face rule

Distinguish the anchoring mode of the source cue from the anchoring mode of the current publication face. A bodily cue written into a document may still require AM.EmbodiedFelt as source mode and AM.DocumentMediated as publication face.

#Mixed-mode decomposition rule

AM.Mixed is admissible only when its component modes are named and the reason for the mixture is operationally real. It must not become a convenience label for an episteme that has not yet been analyzed.

#Anchoring Shift and Transport Discipline

#Shift declaration rule

When an episteme crosses from one anchoring mode to another, state whether the shift is merely publication-level or whether it changes what can be preserved, compared, or trusted. A move from operator-loop enactment to report prose, for example, often drops timing, bodily load, and enactment friction.

#Bridge-loss governing relation

If an anchoring shift matters across contexts, F.9 or F.9.1 should govern the loss or stance note. C.2.6 only requires the shift to be noticed and not misrepresented as lossless.

#Same-content illusion test

Two cues may be paraphrased into the same sentence while remaining differently anchored. If the anchoring regime differs, the cues are not automatically substitutable.

#Review Matrix and Extension Tests

#Review matrix

An assurance reader should ask:

• what the original anchoring regime was;
• what the current publication regime is;
• whether the transformation chain is explicit;
• whether any bridge loss or stance note is missing;
• whether a declared mixed mode is genuinely decomposed.

#Local extension test

A new local anchoring mode is justified only when it answers a distinct anchoring question that the starter family cannot express without distortion.

#Cross-facet reminder

Anchoring mode often correlates with representation and articulation changes, but it does not govern them. Reject prose that uses AM.ModelLatent, AM.EmbodiedFelt, or AM.OperatorLoop as shorthand for being vague, early, trustworthy, or closed.

#C.2.6:End

#U.LanguageStateRepresentationFactorBundle

Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative

Plain-name. Language-state representation-factor bundle.

Use this pattern when. Use C.2.7 when a governed U.Episteme publication needs to describe how its representation is organized through locality/distribution, sparsity/density, symbolicity/subsymbolicity, or an explicit local factor bundle.

What goes wrong if missed. One representation label such as symbolic, distributed, or encoding basis starts doing too much work: it hides articulation, closure, anchoring, bridge loss, or comparison assumptions.

What this buys. A factor-bundle account of representation that keeps representation organization separate from anchoring, articulation, closure, evidence, carrier, and admissible-use claims.

#Problem frame

Published position claims in the declared language-state chart over U.CharacteristicSpace must distinguish representation factors such as locality, sparsity, and symbolicity without pretending they form one master factor.

#Problem

Terms such as EncodingBasis collapse several independent choices. That makes comparison brittle and encourages one-factor stories such as distributed = informal or local = precise.

#Forces

#Solution

U.LanguageStateRepresentationFactorBundle is a factor bundle, not one scalar characteristic. The minimal core starter set is:

• U.LocalityDistribution
• U.Sparsity
• U.Symbolicity

A Context may publish a local alias such as EncodingBasis, but it shall dock back to the underlying factor bundle instead of replacing it.

#Kind and factor-bundle boundary

U.LanguageStateRepresentationFactorBundle is a dependent durable factor-bundle value under the declared U.LanguageStateSpace / U.CharacteristicSpace boundary, not a root U-kind. Its identity is the bundle of representation factors used for governed episteme publication positions. Individual factors, aliases, dashboards, model probes, or publication forms do not become separate U-kinds unless another governing pattern admits them.

#Minimal factor readings

#Non-collapse rules

LanguageStateRepresentationFactorBundle is not:

• LanguageStateAnchoringMode;
• ArticulationExplicitness;
• LanguageStateClosureDegree;
• evidence, source-currentness, publication authority, work permission, or gate readiness.

A representation may be distributed yet have high trace anchoring; symbolic yet low-articulation; sparse yet low-closure. Those combinations shall remain visible. A model-state, embedding, vector-store relation, or operator-facing publication face may fill one or more representation factors, but the factor bundle does not decide the episteme, carrier, evidence, bridge, work, or gate relation by itself.

#Extension rule

Contexts may add extra representation factors only if the extension is published as a factor addition rather than as a new master factor that erases the core factor bundle.

#Archetypal Grounding

Tell. A model-state cue can be highly distributed but still trace-anchored; a symbolic note can be low articulation if its semantics are still vague.

Show (System). An operator decision aid may mix sparse alert codes and symbolic method-description text.

Show (Episteme). A research probe can move from distributed activation patterns to sparse symbolic hypotheses without any one-step formality story.

#Bias-Annotation

The pattern resists folk theories that try to line up one representation factor with one stage or progression story.

#Conformance Checklist

• CC-C.2.7-1 LanguageStateRepresentationFactorBundle SHALL be published as a factor bundle, not as a hidden scalar.
• CC-C.2.7-2 Local aliases such as EncodingBasis MAY exist only with an explicit docking to the governed factors.
• CC-C.2.7-3 Representation factors MUST NOT silently replace LanguageStateAnchoringMode or LanguageStateClosureDegree.
• CC-C.2.7-4 New local factors SHALL preserve the factor-bundle discipline.

#Common Anti-Patterns and How to Avoid Them

• One-factor myth. Treating distributed/local or symbolic/subsymbolic as the whole story.
• Progression collapse. Equating representation shifts with formalization or closure.
• Alias capture. Letting EncodingBasis or a similar local alias erase the factor bundle.

#Consequences

The benefit is cleaner comparison across schools, substrates, and publication forms. The trade-off is that representation talk becomes more explicit and less slogan-friendly.

#Rationale

The factor-bundle design keeps the representation basis-slot family in the declared language-state chart over U.CharacteristicSpace orthogonal to articulation, closure, and anchoring.

#SoTA-Echoing

This factorization fits current work on sparse distributed representations, hybrid symbolic/neuro-symbolic representation practices, and interpretability practice.

#Relations

• Builds on: A.18, C.2.2a, C.2.LS.
• Coordinates with: C.2.6, A.16.0, A.16, A.16.1, B.4.1, B.5.2.0, F.9.1.
• Constrains: language-state position publication and bridge loss notes around representation shifts.

#Worked Examples and Factor Interaction Notes

#Distributed but explicit

A model-side summary may be representation-wise distributed and still highly explicit once published into a stable symbolic wrapper. This case matters because it blocks the folk myth that distributed implies vague.

#Symbolic but still low-articulation

A glossary-like note may be fully symbolic while still low in AE because the semantic anchors are not yet stabilized. This blocks the opposite myth: symbolic therefore explicit.

#Mixed representation publication

An operator-facing publication face may combine sparse alert codes, symbolic method-description text, and distributed back-end model summaries. The representation-factor bundle should make that mixture visible instead of compressing it into one label.

#Authoring and Review Guidance

#Author prompt

To publish a representation-factor bundle, ask separately:

• how local or distributed is the representation?
• how sparse or dense is it?
• how symbolic or subsymbolic is it?
• which additional factor, if any, genuinely matters enough to publish?

#Review prompt

An assurance reader should reject any attempt to use one factor as if it summarized the rest. The factor bundle exists precisely to block that reduction.

#Cross-facet reminder

Assurance readers should also watch for silent replacement of LanguageStateAnchoringMode, AE, or CD by representation talk.

#Extension and Migration Notes

#Local extension rule

Contexts may add extra factors, but each added factor should answer a distinct question rather than duplicating locality, sparsity, or symbolicity under another label.

#Migration from alias-heavy prose

Aliases such as EncodingBasis or similar should be unfolded into explicit factor dockings before they are relied upon for comparison, bridge claims, or downstream use.

#Boundary reminder

U.LanguageStateRepresentationFactorBundle describes representational organization only. It does not determine admissible use, closure, or anchoring by itself.

#Factor-Bundle Publication Discipline

#Minimal representation package

A publishable U.LanguageStateRepresentationFactorBundle should normally show the current factor settings for locality/distribution, sparsity/density, and symbolicity/subsymbolicity, together with any declared extra factor. If a factor is intentionally omitted, say so rather than hiding the omission under a compact alias.

#No hidden scalar rule

Compact overlays such as "sparse-symbolic" are admissible only when they dock to the underlying factor bundle. No compact label may behave as a hidden master score for comparison, bridge comparison, or stage/progression talk.

#Alias docking rule

Local aliases such as EncodingBasis are admissible only when their docking to the governed factors is explicit and stable. If an alias compresses several factors, the compression should remain visible.

#Factor Interaction and Cross-Facet Reading Rule

#Interaction rule

Representation factors may correlate, but they do not determine one another. Highly distributed cues can still be sparse; symbolic publications can still be locally dense; mixed symbolicity can coexist with either strong or weak articulation. Publish the actual factor bundle rather than narrating one factor as if it predicted the rest.

#Cross-facet non-substitution

Representation talk must not silently replace AE, CD, or LanguageStateAnchoringMode. A shift from distributed to symbolic publication may change readability while leaving articulation low, closure open, or anchoring heavily operator-bound.

#Bridge reminder

If a representation shift matters in transport across contexts, note that the shift may alter what is preserved or salient. The bridge itself remains governed by F.9 and F.9.1.

#Review Matrix and Extension Tests

#Review matrix

An assurance reader should ask:

• are all claimed factors visible in the publication or cited source;
• does any alias hide the factor bundle;
• is one factor being used as if it summarized the whole representation state;
• has representation talk started to replace articulation, closure, or anchoring claims.

#Local extension test

An additional factor is justified only if it captures a distinct representational question that cannot be reduced to locality, sparsity, or symbolicity. The extra factor should extend the bundle, not become a rival master factor.

#Migration test for source terminology

Source vocabularies often use "symbolic", "distributed", or "encoding basis" as if one term solved the whole classification problem. A conforming migration unpacks the term into explicit factor dockings and then checks whether any cross-facet claims were smuggled into the source label.

#Bundle-comparison reminder

Representation bundles may be compared across contexts only after the compared factors are explicit. If one context uses a compact local alias and another publishes the full factor bundle, require explicit docking before treating the two descriptions as commensurable.

#C.2.7:End

#Declarative Representation Precision Restoration

Type: C.2.P precision-restoration child pattern for declarative-representation overread Status: Stable Normativity: Normative unless a section is explicitly informative

#Use this when

Use this pattern when a declarative representation is about to guide action, reliance, gate, release, evidence, method, mechanism, work, or pattern-application claims by its shape alone.

First useful move. Fill one compact DeclarativeRepresentationRepair note: visible expression or artifact; exact current direct object or relation; exact representation or correspondence use, or none; current source or publication relation; tempting stronger action claim; recovered governing pattern; retained use; blocked stronger action claim; and stop or reopen condition.

Quick example. A heat-flow graph in a reactor-cooling review can show preserved and lost flow relations. It does not authorize a valve change by graph shape. The repair keeps the graph path as graph structure, returns release or gate reliance to the gate, source, and evidence patterns, and blocks the hidden work-permission claim.

Use this pattern especially when:

• a graph path, PathSlice, flow valuation, transformation-flow structure line, or graph expression over such a structure is overread as a prescribed work route or workflow;
• an A.10 evidence path is overread as approval, permission, release, gate passage, or assurance;
• a query, access path, query plan, table, dashboard, schema, checklist predicate, or API description is overread as method, work plan, performed work, gate, permission, or proof;
• a publication face, source-chain relation, carrier file path, mathematical representation, method-description representation, or FPF pattern relation is overread as call, dispatch, invocation, send, receive, route, or pattern application;
• method-like wording hides whether the current claim concerns U.Method, U.MethodDescription, formal substrate, mathematical-lens use, U.Mechanism, U.WorkPlan, dated U.Work, evidence relation, source relation, or quote-only source wording.

What goes wrong if missed. The representation appears to do work it cannot do. A path "routes" a decision, a query "calls" a pattern, a dashboard "authorizes" release, a checklist predicate "runs" a process, an evidence path "permits" action, or a program-looking text becomes "the method" without recovering method semantics, method description, formal substrate, mechanism, work plan, work, evidence, or source-use relation.

What this buys. The working reader keeps a visible expression useful without making it magical or hiding its direct owner. Graph paths and structures, evidence or provenance relations, queries and formal objects, publication faces, and pattern relations keep their own kinds. When a graph, file, tile, table, or face represents one of them, the exact representation or correspondence use is stated separately. For method-like wording, the reader identifies the direct object or relation, any represented object or claim, and the exact relation that gives the expression its current use before selecting method, method description, formal substrate, mechanism, plan, work, evidence, source, gate, or release guidance.

Not this pattern when.

• If the graph path, PathSlice, or flow valuation is already current as graph structure, use E.18 directly.
• If the evidence relation or provenance relation for a claim is already current, use A.10 directly.
• If the publication face or source-use relation is already current, use E.17, E.17.EFP, C.2.P, or the direct publication pattern.
• If the current claim concerns a semantic way of doing, use A.3.1; if it concerns the description of that way, use A.3.2.
• If the current claim concerns operation algebra, laws, admissibility predicates, transport, audit, or governing-definition assignment, use A.6.1 or E.20.
• If the current claim concerns planned work or dated work, use A.15.2 or A.15.1.
• If the word is only quoted source wording or ordinary navigation prose with no FPF-governed claim, keep it quote-only or ordinary.

#Problem frame

FPF work meets many declarative-looking expressions and many direct objects or relations: graph and table artifacts; paths and selected structures; state predicates and values; dashboard and publication faces; evidence, provenance, source, and pattern relations; formal substrates; and method descriptions. Some visible expressions represent a separately governed object or claim; other named items are themselves the current direct object or relation. Their common declarative appearance does not make them peers in one kind.

The recurring failure is a category shift. Because some representations look like paths, pipelines, calls, dispatches, states, gates, or control programs, the prose starts granting them operational effects. A representation then seems to authorize work, pass a gate, enact a method, prove a result, release a system, or select a pattern by its shape alone.

This pattern repairs that shift. It does not build a general theory of representation. It only restores the exact FPF-governed object, relation, or claim and its direct governing pattern when declarative-looking wording is overread as imperative or operational.

#Problem

Without this repair:

1. Graph path becomes work route. A path or path slice in E.18 is treated as an ordered work narrative, even when no work occurrence, work plan, or method description is current.
2. Evidence path becomes permission. An evidence relation or provenance relation is treated as approval, gate passage, release, safety, or authority rather than as evidence for a named claim or effect.
3. Query becomes method. A query, access path, query plan, or dashboard is treated as the semantic way of doing, rather than as a representation, method description, evidence relation, source relation, or ordinary source wording.
4. Pattern relation overread as dispatch. Pattern application prose starts saying that one pattern exits to, routes to, calls, invokes, receives, owns, or dispatches another, hiding declarative pattern relations and direct governing-pattern selection.
5. Programming-paradigm label becomes ontology. Imperative, functional, logical, constraint, object-centric event, effect-handler, pipeline, orchestration, or workflow wording is treated as the FPF kind rather than as one representation style or source label.
6. Mechanism, method, and work collapse. A method-like expression is repaired to method or mechanism by vocabulary rather than by the current claim: way of doing, description, formal substrate, law-governed mechanism, plan, occurrence, evidence, or quote-only wording.

#Forces

#Solution

Repair declarative-representation overread by separating the visible expression, the direct object or relation, and any representation use before naming the direct governing pattern for the current claim.

The repair order is:

1. Name the visible expression or artifact. Quote or identify the graph highlight, file, query text, predicate display, dashboard tile, table, publication face, path diagram, carrier path, mathematical expression, method-description expression, or pattern sentence that prompted the overread.
2. Recover the exact current direct object or relation. Name the graph structure, PathSlice, flow valuation, evidence or provenance relation, state predicate or value, query or formal object, publication face or occurrence, formal substrate, claim-bearing episteme, source relation, carrier-side object, pattern relation, or other direct outcome under its own governor. This is a list of alternative recovery outcomes, not representation kinds in one ontology.
3. State the representation or correspondence use, or write none. When the visible expression represents a separately identified object or claim, name the exact relation and target. When the direct object or relation itself is current and no separate representation claim is needed, write none; do not relabel the direct object as a representation kind.
4. Recover source or publication relation when current. If a face, source chain, generated explanation, copied text, dashboard, file path, or publication unit is current, use the publication pattern or source-use pattern governing that relation.
5. Name the tempting stronger action claim. Say what the visible expression is being asked to do by resemblance: route, call, dispatch, invoke, run, flow, send, receive, authorize, release, prove, prescribe, execute, select, pass a gate, or record work.
6. Select the governing pattern. Use the direct pattern when the object or relation is already recovered; otherwise use this pattern only long enough to recover the direct outcome, any representation use, and the blocked stronger claim.
7. State retained use. Keep the weaker useful use: graph structure, evidence relation, source-finding, state predicate, publication face, exact representation use, formal-substrate input, candidate method reading, or pattern relation.
8. State the blocked stronger action claim. Block only the stronger claim that is not recoverable.
9. Stop or reopen. Stop when the governing pattern can carry the next claim. Before stopping, ask what claim, evidence relation, gate relation, safety relation, method relation, work relation, or source relation would become less reviewable if the visible expression were accepted as the stronger claim. Reopen if a later source changes the visible expression, direct object or relation, representation relation or target, source currentness, governing pattern, or intended use.

#DeclarativeRepresentationRepair note

Use this compact note when the wording has FPF-governed use:

DeclarativeRepresentationRepair:
  VisibleExpressionOrArtifact:
  CurrentDirectObjectOrRelation:
  RepresentationOrCorrespondenceUse: <exact relation and represented target> | none
  SourceOrPublicationRelation:
  TemptingStrongerActionClaim:
  RecoveredGoverningPattern:
  RetainedUse:
  BlockedStrongerActionClaim:
  StopOrReopenCondition:

The note records the local repair long enough to make the next governing pattern selectable. If the direct governing pattern already supplies a better record, use that record and keep only the repaired wording, exact direct outcome, any representation use, retained use, blocked stronger claim, and stop or reopen condition here.

Use four plain questions before the owner table: What visible thing am I looking at? What direct object or relation is current? What, if anything, does it represent? What stronger action claim must remain blocked?

#Direct governing-pattern selection

#Legitimate path and route settlement

path is not banned.

A.10 evidence path for <claim, effect, or use> is legitimate when the evidence relation or provenance relation for the named claim, effect, or reliance use is current. E.18 graph path and PathSlice are legitimate when the graph object, path, slice, crossing, or flow valuation is current. Carrier file paths, URLs, mathematical paths, and quoted source paths are legitimate when their notation, source-use function, or use relation is current.

The defect is not the word. The defect is hidden ontology: the sentence treats a representation as if something literally ran, flowed, executed, authorized, released, proved, selected, or prescribed action without first naming the exact direct object or relation and its governing pattern.

When the representation is route-shaped, loop-shaped, graph-shaped, diffusion-like, or workflow-like, ask first which object is current:

Do not repair route-shaped wording by replacing it with another route-shaped word. Always recover the visible expression, exact direct object or relation, representation or correspondence use or none, retained use, blocked stronger action claim, direct governing pattern, and stop or reopen condition. When the representation use is none, that is enough to close the repair; do not require a represented target, preserved and lost structure, or a mathematical-lens admissible-use account. When an exact representation, mathematical-lens, or selected-structure use is current, also name its target, the preserved and lost structure, and the admitted and blocked uses required by C.29 or that structure's direct owner.

#Method, algorithm, mechanism, plan, and work settlement

Do not repair algorithm, program, solver, proof, recipe, method, workflow, process, procedure, access path, query plan, or control strategy by choosing one fashionable replacement.

Method-description membership guard. A code file, SOP, proof script, solver model, process model, protocol, recipe, diagram, or query plan is only a representation clue. First identify the claim-bearing episteme under C.2.1. Apply A.3.2 only when that same episteme has one admitted U.Method as its exact EntityOfConcern and at least one claim says how that method is done, such as its transformation or enactment concern, applicability, precondition, intended effect or preserved condition, bound, generic participant meaning, or internal method composition. A name, author, citation, approval, file form, runnable configuration, or representation correspondence alone is a near-miss. If the test fails, do not assign U.MethodDescription; keep the representation, publication, plan, dated work, result, formal substrate, mechanism declaration, evidence, or source use with its direct owner. A representation or publication change does not decide membership. If claim content, exact method, or effective reference scheme changes, C.2.1 first identifies the resulting episteme; then apply A.3.2 to that individual.

Recover what the source is actually about and what it asserts:

Cooling contrast. A reusable cooling procedure can be U.Method only after the context-local way of doing, its transformation or enactment kind, transformed referent or structure, preconditions, and intended effects are recovered. “Required cooling effect” alone is claim content, not a method. If a later cooling episode actually changes the governed loop state, that occurrence remains a separate A.3.4 U.Transformation and needs its own changed referent, boundary, conditions, actual facts, and continuity or reidentification basis.

When the source label hides method, mechanism, formal-substrate, work, evidence, gate, result, or temporal claims, use E.10.ARCH:3.1 to state the project concern in ordinary words, then identify each exact object and claim separately. For this host, repair only the representation overread and name the direct governing pattern for the current claim; linked values remain under their own governing patterns rather than becoming one representation-repair claim.

#Programming-paradigm and process-model settlement

Imperative, functional, logical, constraint, object-centric event, effect-handler, pipeline, orchestration, Declare-style, SQL-like, e-graph, hypergraph, or process-mining wording is a clue to identify the visible expression, direct object or relation, any representation use, and current claim. It is not a decision procedure by itself.

Current practice makes the old contrast between imperative and declarative labels too weak as a final ontology:

• constructor and process-theory lines keep computation, information, dynamics, and procedure close to possible or impossible transformations and compositional realization;
• scoped effects and handlers separate operation syntax, semantic handling, scopes, resources, equations, type information, and effect information;
• Declare-style process models and object-centric event logs distinguish constraints, events, objects, relations, ingestion, transformation, storage, and analysis;
• e-graph and monoidal-rewriting work shows that computation or process representation may be equivalence or composition structure rather than instruction order.

Use those lines as guardrails: recover the exact FPF-governed object, relation, claim, or representation use and its direct owner instead of replacing one programming-paradigm label with another.

#Worked slices

#Graph path in a transformation-flow structure

Wording: "The P2W path routes the team from principle to work."

Repair:

DeclarativeRepresentationRepair:
  VisibleExpressionOrArtifact: P2W graph expression with a highlighted path or path slice
  CurrentDirectObjectOrRelation: exact E.18 `PathSlice` and E.18.1 carry-through relation among the named records when those objects are current
  RepresentationOrCorrespondenceUse: C.29 correspondence from this P2W graph expression to the exact E.18 `PathSlice`
  SourceOrPublicationRelation: none
  TemptingStrongerActionClaim: ordered work route for the team
  RecoveredGoverningPattern: E.18.1, with A.15.2 or A.15.1 only if planned or dated work is current
  RetainedUse: selected graph path and carry-through relation for inspection
  BlockedStrongerActionClaim: no work route or prescribed workflow by path shape alone
  StopOrReopenCondition: reopen when path, source currentness, graph edition, or intended work relation changes

A graph publication or pattern publication remains a separately governed publication object. If one is current, state its exact source or publication relation and participants in the neighbouring claim; neither publication object belongs in SourceOrPublicationRelation by mention alone.

#Evidence path near release

Wording: "The evidence path authorizes release."

Repair: A.10 can state an evidence path for the claim or effect. Release, permission, or gate passage requires the authority, gate, or release pattern that governs that claim. This pattern is used only if path wording itself is causing the representation to be overread as a permission route.