#Part C — Kernel Extensions Specifications

Preface node heading:part-c-kernel-extensions-specifications:29111

#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 sits on the U.Episteme semantic triangle (Symbol–Concept–Object) and never confuses notation with 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 home pattern of 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 — Semantic Triangle via Components, which reifies every episteme as Concept (claim‑graph), Object (describedEntity & evaluation rules), and Symbol (notation)—not the file itself; carriers and work/executions remain outside and are linked via isCarriedBy / producedBy(U.Work).

#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 host 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 lifecycles; both must compose.
• Abstraction vs enactment. Epistemes constrain action; systems act. The calculus must keep the roles distinct.

#Solution

#Coordinates and the triangle

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.

Triangle link. The assurance components live on the Concept↔Object side: F by the internal claim‑graph structure, G by the ClaimScope (scope & assumptions) as a scope object, and R by evaluation templates and evidence bindings. The Symbol vertex hosts notation; carriers are outside the episteme and link via isCarriedBy. Multiple notations are allowed under a single Symbol component; 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)

• Symbol ≠ 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 constrain/evaluate via Object and Concept (per Core A.15 / CC‑EPI‑3).
• CL is not a score. It is a qualitative ladder of preservation strength; 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 Symbol–Concept–Object separate and never turn a carrier into a part.

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 Concept is a claim‑graph over PDEs and parameterisations; its Object defines an claim scope (historical forcings, resolution); its Symbol may include two notations (domain equations vs. 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 Object envelope.
• Category slip. Equating a notation or its carrier with the Concept; mitigation: Symbol–carrier separation and EP‑1 triangle cardinality.
• Analogy inflation. Presenting CL‑0/1 as identity; mitigation: always name the CL rung for cross‑mappings.

#Conformance Checklist

1. C2‑1 (Triangle). Every U.Episteme MUST occupy exactly one slot per {Symbol, Concept, Object}; carriers link via isCarriedBy and are never parts.
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 strongest 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 Symbol 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 artefacts; 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 triangle and ladder keep the discipline brief and repeatable.

#Rationale

KD‑CAL externalises a long‑standing semiotic insight (Sign–Meaning–Referent) into a holonic composition where syntax/structure (F,G), pragmatics/evidence (R), and cross‑mapping strength (CL) are visible and composable. The explicit triangle (C.2.1) prevents carrier confusion; the characteristic provide a manager‑readable yet formalisation‑ready scale (with G grounded in scope/envelope, not part‑count); the CL ladder replaces overloaded “alignment” with a graded sameness notion.

#Relations

• Depends on: U.Episteme — Semantic Triangle via Components (C.2.1): identity invariants EP‑1, Symbol–Concept–Object definitions, 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 stronger 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 — Epistemes and their slot graph

One-line summary. U.Episteme is the holon type for epistemes; its internal ontology is given by U.EpistemeSlotGraph, which replaces the legacy semantic triangle with a typed graph n-ary relation over DescribedEntity, GroundingHolon, ClaimGraph, Viewpoint, View, and ReferenceScheme, aligned with U.RelationSlotDiscipline and ready for both symbolic and distributed representations.

#Context

FPF’s kernel recognises two archetypal sub‑holons: System and Episteme. Systems are operational wholes; epistemes are knowledge holons—theories, models, specifications, standards, algorithms, proofs—whose reason for being is to say something defeasible or deductive about something and to be held to account by justification.

Readers. Engineering managers and lead designers who need a uniform way to reason about theories, specifications, algorithms, proofs—from charter memos up to formal axiomatics—without collapsing into tooling or discipline‑specific notations.

KD‑CAL (C.2) needs a precise notion of what an episteme is and how it mediates between:

• the thing(s) it is about,
• the contexts and systems that ground and test it, and
• the representational machinery (notations, carriers, operations) we use to work with it.

Contemporary work on formal languages as cognitive artifacts (Dutilh Novaes), operational iconicity of notations (Krӓmer), material engagement (Malafouris), distributed representations and latent‑space communication in ML, and tool‑augmented reasoning (ReAct‑style agent loops) shows that:

• the relation between an episteme and its DescribedEntitySlot is not a single “Object-vertex”: it involves explicit slots and morphisms (described-entity mapping, grounding, evaluation) typed by SlotKinds and contexts;
• representations come in heterogeneous forms (symbolic, diagrammatic, latent, interactive), with very different operational affordances;
• inference is often mixed‑mode: symbolic reasoning plus calls to tools, solvers, and learned models.

FPF therefore needs a more modular, graph‑shaped ontology for epistemes which:

• keeps KD‑CAL and I/D/S discipline intact,
• is compatible with A.6.0/A.6.5 signatures (SlotKind/ValueKind/RefKind),
• can be used uniformly by A.6.2–A.6.4 (epistemic morphisms) and E.17.* (views & publication),
• and demotes the old non-SoTA semanit triangle to a didactic projection, not the normative ontology.

In this pattern:+

• U.Episteme is the holon genus for epistemes (C.2), with components and identity governed by A.1/A.6.0/A.7.
• U.EpistemeSlotGraph names the internal ontology graph of U.Episteme: the small, typed n-ary relation over episteme positions (DescribedEntitySlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, ViewSlot, ReferenceSchemeSlot) on which KD-CAL, A.6.2–A.6.4 and E.17.* rely.
• Species such as U.EpistemeCard, U.EpistemeView, U.EpistemePublication are holonic realisations of U.Episteme whose component structure is constrained to be compatible with U.EpistemeSlotGraph.

#Problem

Without a shared episteme constitution, teams fall into recurring failure modes:

1. Object–Description–Carrier soup. Diagrams and files are treated as the theory itself. Changes to a PDF are confused with theoretical change.
2. DescribedObject blur. A spec seems to describe “everything in general”. The GroundingHolon—what exactly this knowledge is about—is implicit and drifts.
3. Proof vs program confusion. Algorithms, specifications, and proofs are mixed: a “proof” is used as if it were a tested routine; a “program” is cited as if it entailed a theorem (Curry–Howard misunderstood).
4. Unanchored trust. Claims accumulate with no explicit justification graph or evidence freshness, so assurance degrades invisibly.
5. Category errors at execution. Epistemes appear as actors (“the standard enforces…”) instead of systems acting with or on epistemes such as data sets or algorithms.

The legacy non-SoTA “Semantic Triangle” treated an episteme as a holon with three components: Concept (ClaimGraph), Object (Reference Map), and Symbol (notation).

This worked well for:

• separating meaning (Concept) from carriers, and
• integrating KD‑CAL’s F–G–R characteristics (Formality, ClaimScope, Reliability).

But for current use‑cases it has structural blind spots:

1. No explicit DescribedEntity slot. The “Object vertex” bundles together what the episteme is about with how we interpret and test it. There is no explicit slot for the entity‑of‑interest (U.Entity) and no clear separation between:

   • the thing described, and
   • the ReferenceScheme used to read claims as statements about that thing.

2. Grounding collapses into Object. Material and organisational contexts (labs, infrastructures, organisations) that ground an episteme (in Malafouris’ sense) are hidden in the Object/Reference Map. KD‑CAL and Bridges need explicit GroundingHolon positions.

3. Viewpoints are not first‑class. ISO‑style viewpoints (families of stakeholders, concerns, conformance rules) and their induced views appear only indirectly, via KD‑CAL or MVPK. There is no explicit U.Viewpoint / U.View pair at the episteme core, which makes it hard to:

   • connect to I/D/S DescriptionContext,
   • organize multi‑view descriptions (E.17.0), or
   • align publication viewpoints with engineering viewpoints.

4. Representations and operations are compressed into “Symbol”. Very different representational regimes are flattened into one Symbol vertex:

   • purely denotational notations (no internal inference calculus),
   • fully operational calculi (e.g., proof assistants),
   • interactive visualisations,
   • latent vectors and prompt‑programs for LLMs. There is no place to say “this representation admits syntactic inference of such‑and‑such kind” vs “this is just a passive label”.

5. No explicit signature discipline. The triangle speaks of “Object/Concept/Symbol” but not of slots and references in the sense of A.6.5 U.RelationSlotDiscipline. In episteme this leads to:

   • names where slot, value and ref are conflated (DescribedEntityRef used as if it were a slot),
   • ambiguity between “epistemic object” (what is talked about) and “episteme” (the description),
   • fragile interoperability with signatures for roles, methods, services.

Thus we have problems of:

• DescribedEntity drift. Specifications and models accumulate without a stable notion of which DescribedEntity they talk about; fields like SubjectRef are overloaded and resist safe refactoring.
• Viewpoint confusion. Engineering, publication and governance views are mixed, making it hard to maintain consistency across surfaces or to reason about conformity of descriptions under different viewpoints.
• Representation mismatches. Trade‑offs between neural vs symbolic, diagrammatic vs textual, or interactive vs batch representations cannot be expressed at the episteme level; they leak into ad‑hoc tool descriptions.
• Broken modularity. As soon as we add KD‑CAL, LOG‑CAL, MVPK, and E.TGA, multiple implicit triangles appear, each with slightly different semantics, instead of a single shared U.EpistemeSlotGraph.

We need a replacement for the triangle that keeps its didactic clarity but matches the graph‑ and morphism‑centric reality of contemporary epistemic work.

#Forces

#Solution — from outdated semantic triangle to U.EpistemeSlotGraph

#Overview

For U.Episteme, the legacy semantic triangle is replaced by U.EpistemeSlotGraph that is a small, typed ontology graph and an n-ary relation view over the core episteme positions:

Nodes / positions / slots. Minimal kernel SlotKinds (with their ValueKinds) that every episteme can refer to, following A.6.5:

• DescribedEntitySlot (ValueKind U.Entity or a declared subkind) → “what this episteme is about”;

• GroundingHolonSlot (ValueKind U.Holon) → “where/how this is grounded”;

• ClaimGraphSlot (ValueKind U.ClaimGraph) → “what is being said (intensional content)”;

• ReferenceSchemeSlot (ValueKind U.ReferenceScheme) → “how we read claims as statements about entities”;

• ViewpointSlot (ValueKind U.Viewpoint) → “under which viewpoint we read/validate this episteme”;

• ViewSlot (ValueKind U.View) → “a view‑episteme produced under a viewpoint”.

• Slots and signatures. These positions are realised as SlotKinds with associated ValueKinds and RefKinds under U.RelationSlotDiscipline (A.6.5). An episteme kind (U.EpistemeKind) is a signature over these slots.

• Episteme as n‑ary relation and as holon. Each concrete episteme instance can be seen both as:

  • a tuple filling these slots (U.EpistemeTuple), and
  • a holon with components (U.EpistemeCard, U.EpistemeView, U.EpistemePublication) whose fields correspond to those slots.

U.Episteme is thus the holon type whose components are disciplined by the U.EpistemeSlotGraph; C.2.1 fixes that discipline.

• Morphisms. Simple epistemic morphisms (described-entity mapping, grounding, encoding, evaluation) are expressed as ordinary relations/functions between these positions. A.6.2–A.6.4 then specify general laws for effect-free morphisms over U.Episteme.

• Legacy triangle as didactic projection. The classic Symbol–Concept–Object triangle becomes a didactic view of this graph, not the normative ontology; it is simply the projection to:

  • Symbol ≈ a subset of U.RepresentationScheme/U.RepresentationToken,
  • Concept ≈ U.ClaimGraph,
  • Object ≈ {DescribedEntity, ReferenceScheme}.

The rest of this pattern fixes the minimal core needed by KD‑CAL, A.6.2–A.6.4 and E.17.*. The representational nodes (U.RepresentationScheme, U.RepresentationToken, U.PresentationCarrier, U.RepresentationOperation) are introduced as an extension C.2.1+, preserving the interface defined here.

#Minimal epistemic positions (nodes & slots)

This section defines the minimal node set for U.EpistemeSlotGraph and the associated SlotKinds. These are the positions that A.6.2–A.6.4 and E.17.* can rely on.

#DescribedEntitySlot — “what this episteme is about”

Tech: DescribedEntitySlot (SlotKind), describedEntityRef : U.EntityRef (Ref slot in tuples/cards). Plain: described entity, entity‑of‑interest, object‑of‑talk.

Intent. Provide a single, explicit slot for the entity (or entities) that an episteme is about, avoiding the former conflation of Object/Reference/Context.

Normative definition.

1. DescribedEntitySlot is a SlotKind in the sense of A.6.5 U.RelationSlotDiscipline.

   • Its ValueKind is U.Entity.
   • Its RefKind is U.EntityRef (or a species thereof) and MUST be realised in data as a field named describedEntityRef : U.EntityRef (E.10 discipline).

2. Species of U.EpistemeKind MAY constrain the ValueKind to a subtype EoIClass ⊑ U.Entity (for example, “EoI is always a U.Holon and, more specifically, a U.System or U.Episteme”). The subtype MUST NOT be named U.DescribedEntity; “described entity” remains a role name, not a kernel type.

3. Wherever episteme previously used U.EpistemicObject as a separate type, it is re‑interpreted as “U.Entity in the role of filling DescribedEntitySlot” and is marked as legacy alias in LEX‑BUNDLE.

Didactic cue. “Ask: What, exactly, is this description about? That is the DescribedEntity.”

#GroundingHolonSlot — “where / in what holon this is grounded”

Tech: GroundingHolonSlot (SlotKind), groundingHolonRef : U.HolonRef?. Plain: grounding holon, holon‑of‑grounding, engagement context.

Intent. Capture the material–social holon (system, lab, infrastructure, organisation, runtime environment) with respect to which an episteme’s claims are tested, calibrated or validated.

Normative definition.

1. GroundingHolonSlot is a SlotKind with:

   • ValueKind U.Holon,
   • RefKind U.HolonRef (or a species thereof),
   • and recommended field name groundingHolonRef? : U.HolonRef in episteme cards/views.

2. GroundingHolonSlot is optional at the minimal core: an episteme may be un‑grounded at M‑mode (e.g., purely mathematical), but any episteme used for empirical evaluation or assurance under KD‑CAL SHALL either:

   • populate groundingHolonRef, or
   • declare explicitly that no such grounding is possible (e.g., counterfactuals, abstract logics), with consequences reflected in KD‑CAL R.

3. The phrase “grounding holon” is plain‑register; there is no kernel type U.GroundingHolon. It always means “the holon currently filling GroundingHolonSlot for this episteme.”

Didactic cue. “Ask: In which lab/organisation/world‑slice do we test or observe this? That is the GroundingHolon.”

#U.ClaimGraph and ClaimGraphSlot — intensional content

Tech: U.ClaimGraph (kernel type), ClaimGraphSlot (SlotKind). Plain: claim graph, intensional content.

Intent. Reuse the existing KD‑CAL notion of ClaimGraph as the episteme’s intensional body, but make its role as a slot value explicit.

Normative definition.

1. U.ClaimGraph is the ValueKind for ClaimGraphSlot:

   • nodes: typed claims (definitions, axioms, theorems, requirements, properties, assumptions);
   • edges: logical/derivational/refinement relations, as already defined in C.2.

2. ClaimGraphSlot is a SlotKind whose instances are always stored by value in core patterns:

   • content : U.ClaimGraph is the normative field in U.EpistemeCard / U.EpistemeView;
   • C.2.1 MUST NOT introduce U.ClaimGraphRef as a ValueKind. Any reference type for ClaimGraphs, if needed, is a RefKind defined by discipline packs on top of U.ClaimGraph.

3. ClaimGraphSlot is mandatory: every U.EpistemeKind that uses C.2.1 SHALL have exactly one ClaimGraphSlot.

Didactic cue. “Ask: What is actually being claimed, defined, required, proved? That is the ClaimGraph.”

#U.Viewpoint and ViewpointSlot — perspective of concerns and validators

Tech: U.Viewpoint (kernel type), ViewpointSlot (SlotKind), viewpointRef : U.ViewpointRef?. Plain: viewpoint, perspective, stakeholder perspective.

Intent. Provide a first‑class home for ISO‑style viewpoints and their generalisations, as used by E.17.0 U.MultiViewDescribing, MVPK, and TEVB.

Normative definition.

1. U.Viewpoint is the type of intensional viewpoint specifications:

   • families of RoleEnactors/stakeholder groups the viewpoint speaks for,
   • their concerns,
   • allowed kinds of descriptions/specifications,
   • and conformance rules for views under this viewpoint. (The internal structure of U.Viewpoint is fixed in E.17.0, not here.)

2. ViewpointSlot is a SlotKind with:

   • ValueKind U.Viewpoint,
   • RefKind U.ViewpointRef,
   • normative field name viewpointRef? : U.ViewpointRef on episteme cards/views.

3. For I/D/S descriptions/specs (E.10.D2), viewpointRef is a mandatory part of DescriptionContext; C.2.1 treats that as a species‑level constraint, not as a universal requirement for all epistemes.

4. ViewpointSlot may be unset in purely internal, pre‑viewpoint epistemes (e.g., raw formal developments), but any episteme that participates in MultiViewDescribing (E.17.0) MUST set it or be deterministically associated to it via a ViewpointBundle.

Didactic cue. “Ask: Who is this for, and what do they need to see to accept it? That is the Viewpoint.”

#U.EpistemeView / U.View and ViewSlot — episteme‑level views

Tech: U.EpistemeView (kernel species of U.Episteme), alias U.View; ViewSlot (SlotKind); viewRef : U.ViewRef. Plain: view, epistemic view.

Intent. Distinguish view‑epistemes (views of descriptions/specifications) from both:

• the underlying descriptions/specifications themselves, and
• the PublicationSurface carriers on which they are rendered (E.17, L‑SURF).

Normative definition.

1. U.EpistemeView is a species of U.Episteme whose episteme kind includes, at minimum:

   • one ClaimGraphSlot (typically a sliced or projected ClaimGraph),
   • one DescribedEntitySlot,
   • one ViewpointSlot,
   • and appropriate ReferenceSchemeSlot.

2. U.View is an alias for U.EpistemeView in E‑cluster patterns (especially E.17.*), used where the word “view” is conventional.

3. ViewSlot is a SlotKind whose:

   • ValueKind is U.View,
   • RefKind is U.ViewRef (or U.EpistemeViewRef species),
   • intended usage is in meta‑structures such as U.MultiViewDescribing families and MVPK.

4. ViewSlot MUST NOT be confused with carrier slots: Surfaces and faces are not values of ViewSlot; they are U.Surface artefacts in L‑SURF, related to views by MVPK.

Didactic cue. “Ask: Which particular slice of the description under this viewpoint are we talking about? That is the View.”

#U.ReferenceScheme and ReferenceSchemeSlot — reading ClaimGraph as claims about entities

Tech: U.ReferenceScheme (kernel type), ReferenceSchemeSlot (SlotKind); referenceScheme? : U.ReferenceScheme. Plain: reference scheme, interpretation scheme, description scheme.

Intent. Separate what is being said (ClaimGraph) from how claims are read as statements about entities and contexts (designation, measurement, evaluation envelopes), without reifying the referents themselves as a vertex.

Normative definition.

1. U.ReferenceScheme is a component type of epistemes, not an external object:

   • it determines how nodes of U.ClaimGraph are mapped to properties/relations over values of DescribedEntitySlot,
   • it specifies measurement/evaluation templates (how to test claims on GroundingHolon),
   • it fixes claim-scope predicates / admissible regions over declared U.ContextSlice selectors (and, where needed, references to domain spaces used inside those selectors).

2. ReferenceSchemeSlot is a SlotKind with:

   • ValueKind U.ReferenceScheme,
   • no RefKind in the minimal core (ReferenceSchemes are stored by value as referenceScheme? : U.ReferenceScheme fields on episteme cards/views). Discipline packs may introduce U.ReferenceSchemeRef as a RefKind, but must not repurpose it as a new ValueKind.

3. ReferenceScheme is the place where the legacy “Object‑vertex” semantics now live:

   • it does not “contain” the real‑world object,
   • it hosts the rules that tie claims to entities and groundings.

Didactic cue. “Ask: Given this ClaimGraph, how exactly do we treat it as talking about these entities in these contexts, and how do we test it? That is the ReferenceScheme.”

#Minimal node set and extension C.2.1+

The minimal U.EpistemeSlotGraph core for C.2.1 consists of positions (the episteme core SlotKinds of A.6.5 CC‑A.6.5‑5):

• DescribedEntitySlot (ValueKind U.Entity),
• GroundingHolonSlot (ValueKind U.Holon),
• ClaimGraphSlot (ValueKind U.ClaimGraph),
• ViewpointSlot (ValueKind U.Viewpoint),
• ViewSlot (ValueKind U.View),
• ReferenceSchemeSlot (ValueKind U.ReferenceScheme).

This pattern only fixes these positions. The extension C.2.1+ (second step of the refactor) adds:

• U.RepresentationScheme and RepresentationSchemeSlot,
• U.RepresentationToken and RepresentationTokenSlot,
• U.PresentationCarrier and PresentationCarrierSlot,
• U.RepresentationOperation and RepresentationOperationSlot (with inference regime annotations),

without changing:

• the definition of U.EpistemeKind,
• the minimal U.EpistemeCard interface,
• or the assumptions A.6.2–A.6.4 / E.17.* make about episteme components.

In C.2.1+ carriers remain structural publication artefacts, not semantic parts of the episteme: U.PresentationCarrier values are linked to U.Episteme / U.View via MVPK / L‑SURF relations (e.g. isCarriedBy / faces) and MUST NOT be counted as components when reasoning about episteme identity, DescribedEntity/grounding, or KD‑CAL morphisms. Changing carriers or surfaces alone never changes the U.Episteme instance determined by C.2.1; it only produces new U.Work / publication events.

#Attached epistemic structures (non-slot components)

U.EpistemeSlotGraph deliberately does not reify every epistemic artefact as a node. Several key structures remain attached, non-slot components of U.Episteme:

• JustificationGraph — the argument/evidence graph for nodes of U.ClaimGraph (A.10/B.3).
• EvidenceBindings — per-claim U.EvidenceRole assignments that connect claims to external U.Work and carriers.
• EditionSeries — the PhaseOf chain of episteme editions (A.14) with change-class annotations (symbol-only vs ClaimGraph vs ReferenceScheme changes).
• ScopeCard / U.ClaimScope — USM scope objects (A.2.6) describing where the episteme’s claims hold.

These attached structures are not extra positions of U.EpistemeSlotGraph; they hang off the U.ClaimGraph/U.ReferenceScheme pair and are governed by KD-CAL (C.2), A.10 and B.3. C.2.1 only requires that an episteme which participates in KD-CAL exposes them in a way that keeps ClaimGraph / ReferenceScheme / Evidence / EditionSeries / ClaimScope clearly distinguishable.

#Episteme as n‑ary relation and as holon

To prevent confusion between objects‑of‑talk, their descriptions, and the places they occupy in an episteme, C.2.1 explicitly treats epistemes both as:

1. n‑ary relations with a signature (slots & values), and
2. holons with components (fields & parts).

#U.EpistemeKind — episteme as a typed n‑ary relation

Tech: U.EpistemeKind (kernel type).

Intent. Provide a signature‑level description of an episteme as an n‑ary relation whose arguments are governed by SlotKind/ValueKind/RefKind triples per A.6.5.

Normative definition.

1. Every episteme that participates in KD‑CAL belongs to some U.EpistemeKind. The kind determines:

   • which SlotKinds appear (DescribedEntitySlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, ViewSlot, ReferenceSchemeSlot, …),
   • the ValueKind for each slot (always a subtype of U.Type),
   • the RefKind used to store it in episteme (when applicable).

2. U.EpistemeKind is a special case of U.Signature (A.6.0), with its slots governed by U.RelationSlotDiscipline (A.6.5). C.2.1 MUST NOT define an alternative slot discipline.

3. For the minimal core, every U.EpistemeKind MUST include:

   • exactly one ClaimGraphSlot,
   • at least one DescribedEntitySlot,
   • and at least one ReferenceSchemeSlot. Inclusion of GroundingHolonSlot, ViewpointSlot, ViewSlot MAY be species‑level constraints (mandatory for D/S‑epistemes, optional for others).

Didactic cue. “An EpistemeKind is the type of episteme: which positions it has and what can go into them.”

#U.EpistemeTuple — episteme as filled n‑ary relation

Tech: U.EpistemeTuple (kernel species).

Intent. Model filled instances of an episteme’s signature, separating the n‑ary relation from any particular holonic packaging or publication.

Normative definition.

1. U.EpistemeTuple is a species whose instances are pure value tuples:
   • for each SlotKind in the associated U.EpistemeKind, a value of the slot’s ValueKind (or a reference value of RefKind, if the kind is configured as such).
2. U.EpistemeTuple is notation‑agnostic and carrier‑agnostic: it does not know about files, formats, or surfaces. It exists to give A.6.2–A.6.4 a minimal notion of “episteme as a point in Ep”.
3. In episteme, U.EpistemeTuple rarely appears directly; it is typically induced by U.EpistemeCard and U.EpistemeView (which add component structure and meta‑information).

Didactic cue. “An EpistemeTuple is the abstract record of what fills which slots — nothing more.”

#U.EpistemeCard, U.EpistemePublication, U.EpistemeView — holonic realisations

Tech: U.EpistemeCard, U.EpistemePublication, U.EpistemeView (species of U.Episteme).

Intent. Provide holon‑level structures that engineers can work with (components, mereology, provenance), while keeping them aligned with U.EpistemeKind and U.EpistemeTuple.

Normative definition.

1. U.EpistemeCard. A species of U.Episteme whose components correspond one‑to‑one to slots of some U.EpistemeKind:
   • content : U.ClaimGraph (for ClaimGraphSlot),
   • describedEntityRef : U.EntityRef (for DescribedEntitySlot),
   • groundingHolonRef? : U.HolonRef (for GroundingHolonSlot),
   • viewpointRef? : U.ViewpointRef (for ViewpointSlot),
   • referenceScheme? : U.ReferenceScheme (for ReferenceSchemeSlot),
   • optionally representationSchemeRef? : U.RepresentationSchemeRef (C.2.1+),
   • meta : Edition/Provenance/Status…. Minimal episteme identity is the pair ⟨content, describedEntityRef⟩ within a U.BoundedContext; all other fields are optional at the genus level but may be mandatory in species. Changes that alter content or the effective referenceScheme (or that intentionally re‑identify describedEntityRef) SHALL be realised as new phases in an U.EditionSeries (PhaseOf chain) under A.14/A.7. Changes confined to U.PresentationCarrier / surfaces or other publication artefacts do not create a new episteme; they are captured as U.Work / publication events over the same U.Episteme.
2. U.EpistemePublication. A species representing epistemes that have been published onto surfaces (MVPK). It:
   • has at least the components of U.EpistemeCard,
   • plus references to U.Surface / U.Face artefacts (E.17, L‑SURF),
   • but does not re‑interpret these surfaces as parts of the episteme; carriers remain external.
3. U.EpistemeView. As defined in §4.1.5, a species of U.Episteme representing a view under a specific U.Viewpoint. Its components are a specialisation of U.EpistemeCard:
   • ClaimGraph often restricted/projection of a base description/specification,
   • Viewpoint fixed,
   • ReferenceScheme tailored to that viewpoint.

Alignment requirement. For any of these species, the pattern MUST state explicitly:

• which U.EpistemeKind it realises, and
• how each component maps to a SlotKind/RefKind under U.RelationSlotDiscipline.

This ensures that A.6.2–A.6.4 can treat any U.Episteme* uniformly as both:

• an object in the category Ep, and
• a structured holon with components.

#SlotKind / ValueKind / RefKind discipline for DescribedEntity & GroundingHolon

C.2.1 adopts A.6.5 U.RelationSlotDiscipline wholesale. For the two key positions:

1. DescribedEntitySlot.
   • SlotKind = DescribedEntitySlot;
   • ValueKind = U.Entity (species may constrain to EoIClass ⊑ U.Entity);
   • RefKind = U.EntityRef (or a species thereof);
   • normative field name in episteme cards: describedEntityRef : U.EntityRef. No kernel type named U.DescribedEntity is introduced; the phrase “described entity” always means “an instance of U.Entity in the role filling DescribedEntitySlot”.
2. GroundingHolonSlot.
   • SlotKind = GroundingHolonSlot;
   • ValueKind = U.Holon;
   • RefKind = U.HolonRef;
   • normative field name: groundingHolonRef? : U.HolonRef. There is no kernel type U.GroundingHolon; “grounding holon” is a slot occupant name. Any episteme that previously mixed slot/value/ref concepts (e.g., using DescribedEntityRef as if it were a type) MUST be migrated to this discipline over time; C.2.1 provides the normative anchor, and F.18 / discipline packs provide the migration guide.

#Minimal epistemic morphisms (informal schema)

Note. The full mathematical treatment (categories Ep and Ref, describedEntity functor α : Ep → Ref, and effect‑free morphisms) lives in A.6.2–A.6.4. Here we fix only the object‑level relations that C.2.1 expects to exist between its positions.

At the level of U.EpistemeCard components and SlotKinds, we assume the following primitive relations (not all are functions):

1. describedEntitySet : U.Episteme → P(U.Entity) derivable from DescribedEntitySlot and ReferenceScheme

   • For an episteme E, describedEntitySet(E) is (at least) the singleton containing the entity referenced by describedEntityRef(E); in more complex cases, it may be a finite set or bundle of entities, determined by ReferenceScheme.
   • The functorial DescribedEntity mapping δ_E : Ep → Ref used in A.6.2–A.6.4 is the categorical lift of this relation: it forgets episteme internals and keeps only the object in the ReferencePlane determined by the pair <DescribedEntitySlot, GroundingHolonSlot>.

2. grounds : (U.Entity, U.Holon) ⇝ GroundingRelation relates described entities to grounding holons

   • Captures how values of DescribedEntitySlot are situated in holons that make evaluation possible (labs, infrastructures, organisations).
   • Need not be total or functional; an entity may admit multiple grounding holons, or none.

3. designates : (U.ReferenceScheme, U.ClaimGraph, U.Entity, U.Holon) ⇝ DesignationProfile how claims are read as statements about entities in contexts

   • Specifies, for each claim in content and each <describedEntityRef, groundingHolonRef>, what property/relation it purports to state, and under what conditions.

4. satisfies / evaluatesTo : (U.ClaimGraph, U.ReferenceScheme, U.Holon) → TruthProfile/SuccessProfile evaluation of claims under a reference scheme and grounding

   • Forms the bridge to KD‑CAL’s F, G, R evaluation; details are given in C.2 and B.3.

5. View-related morphisms (to be connected with A.6.3):

   • viewProject : (U.Episteme, U.Viewpoint) → U.View — effect-free, DescribedEntity-preserving projection that slices ClaimGraph and specialises ReferenceScheme under a given viewpoint.
   • viewEmbed : U.View → U.Episteme — embedding of a view back into the wider episteme, typically as a reference with correspondence proofs.

6. Reflexive describedEntity guard. When DescribedEntitySlot or ReferenceScheme picks out an episteme or claim that includes the referring claim itself (ReferencePlane = episteme), publishers SHALL ensure that the induced justification/evaluation structure is acyclic per evaluation chain: reflexive describedEntities may exist as literature handles, but they MUST NOT form a minimal support cycle for acceptance or KD‑CAL assurance. Self‑reference is allowed as a citation pattern, not as a way to close justification loops.

These are not yet laws; they are the hooks that A.6.2–A.6.4 will formalise into:

• U.EffectFreeEpistemicMorphing (Ep→Ep morphisms over this structure),
• U.EpistemicViewing (describedEntity‑preserving Ep→Ep),
• U.EpistemicRetargeting (describedEntity‑retargeting Ep→Ep).

#Legacy semantic triangle as didactic view (informative)

Position. The classical semiotic or semantic triangle (“Symbol–Concept–Object”, Ogden–Richards/Frege–Carnap style) is not the normative ontology for epistemes in FPF. For U.Episteme, it is treated as a didactic projection of the richer hypergraph U.EpistemeSlotGraph:

• “Symbol” corner ≈ {U.RepresentationToken, U.RepresentationScheme, U.PresentationCarrier} when C.2.1+ is in use; in the minimal core this is collapsed into whichever external artefact happens to carry U.ClaimGraph.
• “Concept” corner ≈ U.ClaimGraph + U.ReferenceScheme under a chosen U.Viewpoint. This is the intensional content plus its interpretation recipe.
• “Object” corner ≈ the occupant of DescribedEntitySlot (ValueKind U.Entity) plus the occupant of GroundingHolonSlot (ValueKind U.Holon) and the grounding relation between them.

Under this reading the triangle is a three‑node quotient of the U.EpistemeSlotGraph:

(Symbol)      = RepresentationToken + Scheme + Carrier
(Concept)     = ClaimGraph + ReferenceScheme (+ Viewpoint)
(Object)      = DescribedEntity + GroundingHolon

All viewpoints, operations, carriers and reference planes are suppressed in the classical diagram. The cost of this suppression is precisely the confusion that motivates C.2.1:

• describing becomes an single unlabeled arrow,
• inference regimes disappear,
• measurement and grounding are invisible.

Didactic use. C.2.1 allows the triangle only in the following cases:

1. As an introductory picture in guidance material (“this is the coarse triangle; the actual pattern is the episteme slot graph”).
2. As a quotient diagram: an explicit note that “this figure ignores viewpoint, grounding, carrier, and operationality; see C.2.1 for the full structure”.
3. As a legacy alignment aid when mapping to standards or literature that speak only in triangle terms.

Guard. Any pattern or documentation page that uses a “semantic triangle” diagram MUST either:

• explicitly state “this is a didactic projection of C.2.1 U.EpistemeSlotGraph”, or
• treat it as a legacy reference when aligning with external standards.

The triangle MUST NOT be used as a kernel‑level ontology or as a basis for morphism laws. All normative reasoning about epistemes proceeds via the slots and components of U.EpistemeSlotGraph.

#Interaction with I/D/S and DescriptionContext (normative)

C.2.1 is the episteme‑layer carrier that I/D/S discipline (A.7, E.10.D2) relies on. The link is made via DescriptionContext.

#DescriptionContext over C.2.1 components

For any episteme that is a Description or a Specification in the sense of E.10.D2, the field subjectRef : U.SubjectRef is interpreted as a DescriptionContext triple:

DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩

where:

• DescribedEntityRef : U.EntityRef — occupies DescribedEntitySlot (ValueKind U.Entity, species often constrained via EoIClass ⊑ U.Entity).
• BoundedContextRef : U.BoundedContextRef — points to the context that fixes vocabulary, units, and legal inferences for this description (E.10.D1).
• ViewpointRef : U.ViewpointRef — occupies ViewpointSlot (ValueKind U.Viewpoint) and determines which concerns, role‑enactor families, and conformance rules apply.

Normative requirement (IDS‑13). For every …Description / …Spec episteme:

1. subjectRef SHALL be decodable to a well‑formed DescriptionContext triple.
2. DescribedEntityRef from that triple SHALL be identical to the field describedEntityRef that fills DescribedEntitySlot in the corresponding U.EpistemeCard/U.EpistemeView.
3. ViewpointRef in DescriptionContext SHALL agree with viewpointRef in the episteme card or be uniquely derivable from a U.ViewpointBundle in E.17.1 (with the derivation rule documented).

Intensions (I‑layer) such as U.System, U.Method, U.Role do not inhabit C.2.1 directly; they are the targets of I→D operations (Describe_ID) and appear as values of DescribedEntitySlot in resulting descriptions/specs.

#I→D and D→S morphisms over C.2.1

• Describing (Describe_ID : I → D). Produces an episteme whose:

  • content : U.ClaimGraph encodes the descriptive claims about the intension,
  • describedEntityRef points to the intension’s entity,
  • groundingHolonRef (if present) fixes where the description is evaluated or tested,
  • viewpointRef selects the describing viewpoint.

  Describe_ID is conformant to A.6.2 but not an Ep→Ep morphism (domain is Intension, codomain is Episteme). C.2.1 provides the codomain schema and ensures that the resulting Description has a valid DescriptionContext.

• Specifying/Formalising (Specify_DS/Formalize_DS : D → S). Takes a Description episteme and returns a Specification episteme with:

  • the same describedEntityRef,
  • the same BoundedContextRef and ViewpointRef (hence same DescriptionContext),
  • a content : U.ClaimGraph that raises formality F (F≥4) and adds test harness hooks, but is conservative with respect to the underlying intension.

  As an Ep→Ep morphism, Specify_DS is a species of A.6.2 and must obey the invariants over the C.2.1 slots (DescribedEntityChangeMode = preserve; no change to DescribedEntity; ClaimGraph refinement only).

C.2.1 does not define I/D/S; it only insists that any …Description/…Spec species that claims to respect I/D/S discipline must:

• implement U.EpistemeCard or U.EpistemeView with content, describedEntityRef, groundingHolonRef?, viewpointRef?, and referenceScheme? fields, and
• wire these fields into subjectRef as DescriptionContext.

#Alignment with A.6.2–A.6.4 (episteme morphisms) (normative)

U.EpistemeSlotGraph is the object‑level substrate for the episteme morphism patterns:

• A.6.2 U.EffectFreeEpistemicMorphing
• A.6.3 U.EpistemicViewing
• A.6.4 U.EpistemicRetargeting

#Effect‑free episteme morphisms (A.6.2) over C.2.1

For any f : X → Y that is an instance of U.EffectFreeEpistemicMorphing:

• Typed objects. X and Y are U.Episteme instances realised as U.EpistemeCard / U.EpistemeView with at least the minimal core components:

  content            : U.ClaimGraph
  describedEntityRef : U.EntityRef      // DescribedEntitySlot
  groundingHolonRef? : U.HolonRef       // GroundingHolonSlot
  viewpointRef?      : U.ViewpointRef   // ViewpointSlot
  referenceScheme?   : U.ReferenceScheme// ReferenceSchemeSlot (ByValue)

  Any additional C.2.1+ components (RepresentationScheme, Tokens, Carriers, Operations) are visible to A.6.2 only through their declared SlotKinds (A.6.5).

• DescribedEntityChangeMode characteristic. f MUST declare a describedEntityChangeMode ∈ {preserve, retarget}:

  • preserve — describedEntityRef(Y) = describedEntityRef(X) and any change to groundingHolonRef/viewpointRef must be justified by Bridges/CorrespondenceModel, without changing the DescribedEntitySlot value;
  • retarget — permitted only for A.6.4 species; see below; in this case the characteristic records an intentional change in the pair <describedEntityRef, groundingHolonRef> under a declared KindBridge in the appropriate ReferencePlane.

  This DescribedEntityChangeMode is a CHR-style characteristic (A.17) on episteme morphisms, which points directly to DescribedEntitySlot. Avoid introducing a separate “describedEntity” term alongside DescribedEntity.

• Component discipline. P0–P5 from A.6.2 are read directly in terms of C.2.1 components:

  • purity ⇒ only C.2.1 components of Y may change; no Work/Mechanism side‑effects;
  • conservativity ⇒ claims in content_Y read via referenceScheme_Y about the new <DescribedEntity, GroundingHolon> do not go beyond what already follows from content_X via referenceScheme_X under the declared DescribedEntityChangeMode and Bridges;
  • functoriality ⇒ composition of such transformations respects the slot structure and ReferenceSchemes.

Any Ep→Ep pattern that operates on U.Episteme MUST state which C.2.1 slots it reads and which it may write, in terms of SlotKinds/ValueKinds/RefKinds (A.6.5), and then declare itself a species of A.6.2/3/4 as appropriate.

#EpistemicViewing (A.6.3) as describedEntity‑preserving projections

U.EpistemicViewing is the DescribedEntity-preserving species of A.6.2. Over C.2.1 this means:

• describedEntityRef(Y) = describedEntityRef(X) — the same value in DescribedEntitySlot.
• groundingHolonRef is preserved, or changed only within a fixed grounding context (e.g. normalising identifiers for the same lab or runtime).
• viewpointRef is either:
  • preserved (internal normalisation under the same viewpoint), or
  • replaced by another U.ViewpointRef within a U.MultiViewDescribing family (E.17.0), with invariants enforced by a CorrespondenceModel.
• content and referenceScheme are transformed conservatively: no new intensional claims about the same DescribedEntity are introduced.

Typical examples:

• filtering or aggregating U.ClaimGraph to a view relevant for a stakeholder group;
• rendering a behavioural specification into a tabular or diagrammatic episteme under a publication viewpoint;
• normalising a logic‑heavy episteme into a more operational one, while keeping the same described system and context.

In terms of SoTA, EpistemicViewing behaves like a lens or optic over C.2.1: a focus (SlotKinds for content/representation) is manipulated while the DescribedEntity is fixed.

#EpistemicRetargeting (A.6.4) as DescribedEntity-bundle retargeting on episteme morphisms

U.EpistemicRetargeting is the species of A.6.2 where describedEntityChangeMode = retarget. It is always a morphism between epistemes (f : X → Y in U.Episteme), but the adjective “retargeting” refers not to the fact that an episteme is mapped to another episteme (this is true for all A.6.2 species), and not to a separate describedEntity, but specifically to the change in the DescribedEntity-bundle selected by C.2.1:

• describedEntityRef(Y) ≠ describedEntityRef(X) — the value stored for DescribedEntitySlot changes;
• a KindBridge must relate Kind(describedEntityRef(X)) and Kind(describedEntityRef(Y));
• groundingHolonRef may remain the same (e.g. same plant, different subsystem) or be transformed along a Bridge in the same ReferencePlane.

In practice, many retargetings operate on the target bundle <DescribedEntitySlot, GroundingHolonSlot> (for example, when an episteme about a physical module is re-interpreted as an episteme about a function-holon realised in a different environment). The characteristic describedEntityChangeMode still classifies such morphisms by whether this bundle is preserved or intentionally re-identified under a KindBridge and reference-plane policy; the episteme on the codomain side is just the usual A.6.2 target object.

Over C.2.1 this is used for:

• functional vs structural reinterpretation (e.g. an episteme about a physical module retargeted to an episteme about the function it realises; StructuralReinterpretation in E.TGA becomes a species of A.6.4);
• signal vs spectrum transitions (Fourier‑style moves where the object‑of‑talk changes from time‑domain signal to frequency‑domain representation but an invariant, such as energy, is preserved);
• data vs model transitions (e.g. retargeting an episteme about raw observations to an episteme about a learnt model, with an invariant such as likelihood or sufficient statistics).

C.2.1 ensures that these retargetings have a clear source and target at the DescribedEntitySlot and that any such move is expressed as a morphism over well‑typed slots, not as an unstructured rewrite of “subject” or “object” labels.

#Alignment with E.17. (Multi‑View Describing & Publication) (normative)*

U.EpistemeSlotGraph underpins the E.17 cluster:

• E.17.0 U.MultiViewDescribing
• E.17.1 U.ViewpointBundleLibrary
• E.17.2 TEVB — Typical Engineering Viewpoints Bundle
• E.17 MVPK — Multi‑View Publication Kit

#Multi‑View Describing (E.17.0)

U.MultiViewDescribing organises families of descriptions/specifications over a shared entity‑of‑interest:

• The EoIClass parameter of E.17.0 is a species constraint on the ValueKind of DescribedEntitySlot (EoIClass ⊑ U.Entity).
• Each member of a multi‑view family is a …Description/…Spec episteme with:
  • describedEntityRef into that EoIClass,
  • viewpointRef drawn from a U.ViewpointBundle,
  • subjectRef decoding to DescriptionContext.

Within this pattern:

• U.Viewpoint is exactly the ValueKind of ViewpointSlot in C.2.1.
• U.View is U.EpistemeView, a species of U.Episteme whose content is already restricted to a particular U.Viewpoint and often also to a particular U.RepresentationScheme.

C.2.1 thus supplies the per‑episteme structure that E.17.0 rearranges into multi‑view families.

#Viewpoint bundles (E.17.1/E.17.2)

U.ViewpointBundleLibrary and TEVB specialise the U.Viewpoint node:

• A ViewpointBundle is a set of U.Viewpoint instances tailored to a class of DescribedEntities (e.g., holons in engineering contexts).
• TEVB fixes EoIClass = U.Holon (typically U.System or U.Episteme) and provides canonical engineering viewpoints: functional, structural, role‑enactor, interface‑oriented, etc.

From the C.2.1 perspective:

• these bundles populate the ValueKind of ViewpointSlot;
• engineering episteme species that want to be “TEVB‑aligned” must restrict viewpointRef to TEVB’s EngineeringVPId set, while keeping the same DescribedEntitySlot discipline.

#MVPK (E.17) as publication over C.2.1 views

MVPK treats U.View (i.e. U.EpistemeView) as its primary input:

• it uses U.EpistemicViewing species (A.6.3) to generate publication‑oriented views from engineering or logical views;
• it then packages these U.View epistemes into U.Surface artefacts via publication viewpoints and faces.

C.2.1’s distinction between:

• U.Viewpoint (intensional, epistemic perspective) and
• U.PresentationCarrier (surface in C.2.1+ and L‑SURF)

keeps epistemic perspective and physical medium separate:

• MVPK operates only on epistemes (Views) and then on carriers;
• the same View can be realised on multiple carriers without changing its describedEntity or ClaimGraph.

Any MVPK species that claims to be C.2.1‑conformant MUST:

• treat U.View as a U.EpistemeView with a valid C.2.1 core,
• document which C.2.1 slots it reads/writes (typically only representation/carrier‑related ones, leaving DescribedEntitySlot and GroundingHolonSlot untouched),
• refrain from introducing new claims about the described entity beyond what is in the source U.View’s ClaimGraph.

#Bias‑annotation (informative)

Episteme‑first and pragmatics‑first. The pattern assumes that nothing is a meaningful episteme unless it is about something for someone under some perspective. This follows the pragmatic turn in semantics: describedEntity and concerns are not afterthoughts but part of the core structure. The graph is therefore built around slots for DescribedEntity, GroundingHolon, Viewpoint and ClaimGraph, not around abstract “propositions in the void”.

Operational/representational bias. C.2.1+ anticipates that certain RepresentationSchemes are operational in Novaes’ sense (supporting direct syntactic inference, like pen‑and‑paper arithmetic or proof states) while others are purely notational. The pattern remains neutral on which schemes are used but bakes in a place for operations and carriers so that:

• symbol‑manipulating tools (SAT/SMT, proof assistants, classical programming languages),
• distributed/latent representations (LLM embeddings, latent protocols like “DroidSpeak”, “Coconut”‑style communication),
• hybrid ReAct‑style agent loops

can all be treated as different species operating over the same U.EpistemeSlotGraph. There is a bias towards making these operational differences explicit instead of hiding them behind “the model”.

Viewpoint and stakeholder bias. The pattern leans on the ISO‑style idea that viewpoints encode stakeholder concerns and role‑families, but it generalises this beyond architecture. U.Viewpoint is intentionally intensional and not bound to any single discipline; still, the examples are skewed toward engineering and epistemic use‑cases.

Didactic bias. The pattern is written to be teachable: semantic triangles are kept as didactic projections; examples like stools on lab rigs, services and SLAs, and model‑evaluation epistemes are deliberately simple. This may under‑represent more exotic epistemes (e.g. artistic, legal, or socio‑technical ones), but the intention is that these use the same slots with different species‑level constraints.

#Conformance checklist (normative)

CC‑C.2.1‑1 - Minimal core components for episteme species. Any species of U.Episteme that participates in I/D/S discipline or in E.17 multi‑view/publishing MUST be representable as U.EpistemeCard/U.EpistemeView with at least:

content            : U.ClaimGraph
describedEntityRef : U.EntityRef
groundingHolonRef? : U.HolonRef
viewpointRef?      : U.ViewpointRef
referenceScheme?   : U.ReferenceScheme      // ByValue
meta               : …                      // edition, provenance, status (A.7/F.15)

and corresponding SlotSpecs consistent with A.6.5 (DescribedEntitySlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, ReferenceSchemeSlot).

CC‑C.2.1‑2 - No kernel type for “DescribedEntity” or “GroundingHolon”. Patterns MUST NOT introduce kernel types U.DescribedEntity or U.GroundingHolon:

• DescribedEntitySlot has ValueKind U.Entity ( species‑constrained via EoIClass if needed),
• GroundingHolonSlot has ValueKind U.Holon.

Plain terms “described entity” and “grounding holon” are allowed only as role descriptions of slot occupants.

CC‑C.2.1‑3 - SlotKind/ValueKind/RefKind discipline. All episteme‑related slots, including DescribedEntitySlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, ViewSlot, ReferenceSchemeSlot (and any extensions in C.2.1+), MUST:

• follow the naming discipline of A.6.5 (*Slot for SlotKinds, *Ref only for RefKinds/fields),
• declare a ValueKind and refMode (ByValue or a RefKind),
• be used consistently across patterns that refer to the same conceptual position.

CC‑C.2.1‑4 - DescriptionContext wiring. Any episteme species whose name or pattern claims to be a …Description or …Spec in the sense of E.10.D2 MUST:

• expose subjectRef : U.SubjectRef,
• provide a decoding to DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩,
• ensure that DescribedEntityRef matches describedEntityRef (DescribedEntitySlot), and
• ensure that ViewpointRef matches viewpointRef or is derivable from a U.ViewpointBundle under documented rules.

CC‑C.2.1‑5 - Morphism declarations over slots. Any pattern in A.6.2–A.6.4, E.17, E.TGA, or discipline packs that defines morphisms between epistemes SHALL:

• state whether it is a species of U.EffectFreeEpistemicMorphing, U.EpistemicViewing, or U.EpistemicRetargeting,
• declare its describedEntityChangeMode (preserve/retarget),
• name which SlotKinds it reads and writes,
• state its behaviour on describedEntityRef, groundingHolonRef, viewpointRef, and referenceScheme.

CC‑C.2.1‑6 - Semantic‑triangle usage guard. If a semantic triangle or parallelogram diagram appears in a pattern or tutorial, there must be an explicit note that:

• it is a didactic projection of U.EpistemeSlotGraph, and
• normative laws are stated in terms of C.2.1 nodes and morphisms, not in terms of triangle corners.

CC‑C.2.1‑7 - KD‑CAL / ReferencePlane alignment. Any pattern that evaluates or compares epistemes (KD‑CAL/LOG‑CAL, CHR, CG‑Spec, etc.) MUST point out:

• how U.ClaimGraph is interpreted in a ReferencePlane,
• how GroundingHolonSlot figures into measurement or validation,

CC‑C.2.1‑8 - Context locality and Bridges. Any U.Episteme species that is consumed by KD‑CAL / LOG‑CAL / CHR‑based patterns SHALL declare a U.BoundedContextRef; all F–G–R computations and C.2.1 slot interpretations are context‑local. Cross‑context use MUST proceed via an explicit Bridge with CL / Φ‑policy (F.9/B.3), with penalties routed to R‑lanes only; F and the slot structure from C.2.1 remain unchanged.

CC‑C.2.1‑9 - Carriers and Work outside episteme content. C.2.1 inherits A.7/A.12’s separation obligations: U.PresentationCarrier / U.Surface artefacts and U.Work instances MUST NOT be treated as parts of U.Episteme or as values of any SlotKind in U.EpistemeSlotGraph. Episteme content stays in U.ClaimGraph and U.ReferenceScheme; evidence enters only via U.EvidenceRole bindings that point to external U.Work / carriers (A.10/B.3). Changing carriers or re‑publishing work alone does not change the episteme determined by ⟨content, describedEntityRef, referenceScheme⟩ in its U.BoundedContext.

CC‑C.2.1‑10 - Reflexive describedEntity guard. When an episteme uses C.2.1 to speak about another episteme (ReferencePlane = episteme), or about itself (self‑describing or meta‑specification cases), patterns SHALL ensure that the resulting JustificationGraph / evaluation chains are acyclic along support paths. Reflexive describe / citation edges may exist as literature anchors, but they MUST NOT form minimal support cycles for acceptance or KD‑CAL assurance decisions; the trust calculus MUST always bottom out in external evidence (U.Work with U.EvidenceRole) rather than in purely self‑referential claims.

#Consequences (informative)

Benefits

• Single, extensible episteme core. C.2.1 gives a small, stable set of positions (DescribedEntity, GroundingHolon, ClaimGraph, Viewpoint, View, ReferenceScheme) and components (U.EpistemeCard, U.EpistemeView, U.EpistemePublication) on which all higher‑level patterns depend. This avoids the proliferation of “epistemic objects” and “facets” with overlapping semantics. Transparent DescribedEntity & grounding discipline. The pair (DescribedEntitySlot, GroundingHolonSlot) is no longer hidden inside ad-hoc “SubjectRef” fields or semantic triangles: both are explicit, typed slots. This makes retargeting, viewing and correspondence laws (A.6.2–A.6.4, E.17.0) easier to state and check.
• Better fit for contemporary representation practice. By distinguishing ClaimGraph, RepresentationScheme, Tokens, Carriers and Operations (in C.2.1+), the pattern matches contemporary SoTA views of notation and formalism:
  • formal languages as cognitive artefacts and de‑semanticisation tools (Novaes),
  • operational iconicity and medium‑sensitive reasoning (Krämer, Malafouris),
  • hybrid symbolic–neural workflows (e.g. ReAct, tool‑augmented LLMs, latent protocols). FPF can model both symbol‑heavy and latent‑heavy workflows without privileging either.
• Uniform substrate for multi‑view description and publication. MultiViewDescribing, viewpoint bundles (TEVB), and MVPK all land on the same episteme core. This avoids the current “views vs viewpoints vs faces” confusion and leaves “architecture” as a domain‑specific specialisation rather than a competing meta‑ontology.
• Tooling alignment. Slot discipline plus explicit episteme components map cleanly to implementation types (records, row‑typed schemas, effectful handlers). Tools can generate code, schemas or telemetry from episteme species without guessing what “subject”, “context” or “object” mean.

Trade‑offs / costs

• More explicit structure. Authors must declare slots, ValueKinds and references explicitly, and keep DescriptionContext consistent. This is more upfront work than writing ad‑hoc “Subject/Object” fields, but it pays off in substitution safety and cross‑pattern reuse.
• Migration effort. Legacy uses of “EpistemicObject”, “Facet”, “Subject”/“Object”, and raw …Ref fields will need refactoring into C.2.1 slots + A.6.5 SlotSpecs. Migration notes and aliasing can ease the transition, but mechanical cleanup will still be required.
• Exposure of representation biases. Being explicit about RepresentationSchemes and Operations may surface disagreements about which representations are “primary” in a team or discipline. C.2.1 does not resolve these disagreements; it only makes them visible and therefore debatable.

#Relations (overview)

Builds on

• A.1 U.Holon — for treating episteme as a holon with components.

• A.6.0 U.Signature — for interpreting episteme kinds as n‑ary relations over slots.

• A.6.5 U.RelationSlotDiscipline — for SlotKind/ValueKind/RefKind discipline over episteme slots.

• A.7, E.10.D2 — for I/D/S discipline and the Interpretation of subjectRef as DescriptionContext.

• C.2 (KD‑CAL, LOG‑CAL) — for ClaimGraph semantics, ReferencePlanes, and Bridges.

• E.8, E.10 — for pattern authoring discipline and lexical guards.

• Constrains

• A.6.2–A.6.4 — by fixing the minimal episteme component set those morphisms operate on and by requiring an explicit DescribedEntityChangeMode characteristic (describedEntityChangeMode ∈ {preserve, retarget}) over DescribedEntitySlot/GroundingHolonSlot.

• E.17.0–E.17.2 — by specifying how DescribedEntity, Viewpoint, View and ReferenceSchemes are represented at episteme level.

• E.17 (MVPK) — by separating U.View (episteme) from U.PresentationCarrier (surface), and by requiring that publication morphisms be U.EpistemicViewing species over C.2.1‑conformant views.

• F.18 (LEX‑BUNDLE) — by providing the episteme‑specific name cards and guards for DescribedEntity/GroundingHolon/Viewpoint/View/ReferenceScheme and their SlotKinds.

Used by

• A.6.2 U.EffectFreeEpistemicMorphing — as the default episteme object structure for episteme‑to‑episteme transforms.
• A.6.3 U.EpistemicViewing — as the substrate for describedEntity‑preserving projections (views).
• A.6.4 U.EpistemicRetargeting — as the substrate for DescribedEntity-bundle retargeting transforms between epistemes (Ep→Ep with describedEntityChangeMode = retarget).
• E.17.0 U.MultiViewDescribing, E.17.1, E.17.2 — to organise families of D/S‑epistemes under Viewpoints and EoI classes.
• E.17 (MVPK) — to publish episteme views as surfaces.
• E.TGA — to interpret StructuralReinterpretation and other engineering projections as episteme morphisms over a well‑typed U.EpistemeSlotGraph.

Together, these relations make U.EpistemeSlotGraph the single normative core for thinking about epistemes, their DescribedEntity mapping, their representations, and their transformations across FPF.

#C.2.1: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 contract

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 design/run 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 burden (B.3.3 / B.3.5). It does not add a new axis and does not change the meaning of R:

• axiomatic → VA-dominant (constructive grounding / proof artifacts); 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 stronger checking and 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:12.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 axes. 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 axes

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 axes. 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 described entity (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/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 artifact; 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, weak supports can be laundered into strong 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/A.27 (crossing bundles), 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: Draft 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, A.6.Q, A.6.A.

#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 a late endpoint owner. That governed publication may later 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 occupants of 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 lawful, 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.

#Core role

U.LanguageStateSpace gives FPF one explicit home 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 lawful 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 lawful here only as shorthand for such slot-explicit A.19 coordinate claims. It does not authorize a rival lifecycle or feature-vector story.

#Facet basis

The language-state chart is coordinated by explicit facet owners rather than by an informal master ladder. 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 own the internal scale semantics of the individual facets.

#Ontological role lanes

Within this cluster, keep five roles distinct:

• occupant - 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 later 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 artefacts that hold or render a publication.

U.LanguageStateSpace owns 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 occupant 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 load-bearing grounds, witnesses, or carriers that explain those values;
• any local threshold declarations if the position is being used for a routing or gate decision;
• any note that distinguishes source anchoring from current publication-face anchoring.

A position claim may be partial when some slots are intentionally unknown, but the unknowns should be declared rather than hidden under a broad readiness label.

#Local position-reading witness

For this pattern, a position claim is reviewable when:

• the occupant 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 support 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 occupant, publication form, publication face, and carrier in distinct role lanes.

A polished note, a stronger carrier, or a more formal face does not by itself prove a new position. The chart claim remains lawful only when those role lanes 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 surface format alone;
• representation factors from articulation alone;
• or routing legality 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 not the same thing as:

• 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-owned record that may later 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, a handoff, or an 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 ownership.

A.6.Q, A.6.A, A.6.P, B.5.2, A.15, and C.25 are seam-coupled downstream owners rather than members of this language-state owner 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 owners.

#Archetypal Grounding

Tell. One note can be strongly operator-loop anchored yet still weakly closed. 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 ladder.

Show (System). A service disturbance is a system-side phenomenon. The governed occupant is the alerting U.Episteme published from that disturbance; its position claim may be moderately formal, weakly closed, strongly operator-loop anchored, 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 occupant itself. Once preserved as a cue pack, the resulting governed U.Episteme may be low in articulation, low in closure, strongly trace-anchored, and only partly symbolic even when later written 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 dimensions 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 ladder.
• CC-C.2.2a-2 Published positions SHALL cite explicit facet owners 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-owner semantics into the chart owner 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 occupant, publication form, face, and carrier SHALL remain explicit or explicitly inherited from pinned upstream material.

#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 owner.
• 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 owner set for all downstream semantics. Repair by naming whether the current statement belongs to the chart owner set, a seam publication owner, or a downstream owner.

#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 layer. It is a load-bearing alignment surface: 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 ladder or one polished publication surface.

#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,
• strong operator-loop anchoring,
• and mixed symbolic / natural-language representation.

That position explains why the alert belongs in a route-bearing seam publication before it hardens into an endpoint-owned action 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 strongly 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 occupant 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;
• any source-versus-face anchoring distinction that matters;
• the thresholds, if any, being invoked;
• and the next owner or move family that depends on the claim.

This keeps the claim operationally useful without pretending that the position is itself a full trajectory or endpoint form.

#Review Guidance

A reviewer should ask:

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 occupant?
4. Are threshold claims explicit enough for the next move or endpoint decision?
5. If the text compares two contexts, is there a real bridge or only a lexical resemblance?

#Boundary Notes

C.2.2a does not own move kinds, seam publication forms, endpoint repair semantics, or bridge substitution licence. Those belong respectively to A.16 / A.16.0, A.16.1 / B.4.1 / B.5.2.0, A.6.* / C.25, and F.9 / F.9.1.

Its job is narrower and more foundational: to make the declared language-state U.CharacteristicSpace chart readable so that downstream patterns can refer to one visible common geometry instead of rebuilding it piecemeal.

#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 owned 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 strength, and scope narrowness into one vague story about something being more formal. C.2.3 removes that drift by giving FPF one explicit owner for the rigor-of-expression axis.

#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 artifact is treated as highly formal because one segment is highly formal, even when essential support still depends on less formal parts.
5. Other axes are misused as surrogates. Authors quietly use scope, evidence, or language-state facets as if they were part of one master formality ladder.

#Forces

#Solution - U.Formality as one ordinal characteristic

C.2.3 defines U.Formality as the single owner of 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 owned 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 or carrier surface 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 axis and against stories that mix formality with status, publication quality, scope width, or evidence strength. 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 artifact 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 weakness, and plane crossings SHALL route through 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 axis 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

• Owns: the F coordinate of the typed F-G-R assurance tuple.
• Builds on: characteristic machinery from A.18 / A.19 and episteme ownership 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.
• 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 artifact 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 artifact 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 artifacts carry the relevant property in their types or proof terms.

#F9 - Univalent / higher foundations

Higher-equality foundations are load-bearing. The artifact 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 artifact 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 artifact is at least F4.
3. Does the artifact 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 artifact 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 artifact 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 artifact. 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 has weaker segments, and whether status or other axes 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 artifacts are signals for explicit formalization work, not excuses for wishful leveling.

#Glossary and Notation

• U.Formality / F. The rigor-of-expression characteristic owned 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 legacy 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 axes

For the language-space extension, F does not own 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 owned by C.2.LS and its subordinate owners.

#C.2.3:End

#U.LanguageStateFacetProfile - Thin owner for language-state facets

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

Plain-name. Language-state facet profile.

#Problem frame

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

#Problem

Without a dedicated profile owner, authors blur articulation, closure, anchoring, and representation into one vague maturity story, or they silently reuse F as a surrogate. That blocks lawful threshold publication, weakens 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 owned facets
• routeNotes? -> informative notes that help interpret routing or reopening decisions

C.2.LS is therefore a profile owner, not a characteristic owner and not a trajectory owner. Characteristic semantics remain with A.18/A.19; lawful moves remain with A.16; explicit path publication remains with E.18.

#Owner boundary

C.2.LS owns 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 ladder;
• own the scale semantics of AE, CD, LanguageStateAnchoringMode, or U.LanguageStateRepresentationFactorBundle;
• own reopen/backoff moves;
• own endpoint routing or bridge kinds.

#Threshold publication discipline

Any threshold used for routing, lawful 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 already pinned upstream material;
• 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 law, bridge law, gate state, or downstream-owner semantics into the bundle record.

A polished label, one strong facet, or one memorable route note does not by itself yield a lawful 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,
• strongly 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 owner of the facet-profile bundle. Readers who need one map of the full language-state owner set should read the corridor note in C.2.2a.

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

#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, weak candidate-space closure, an anchoring mismatch, or an unresolved representation-factor bundle.

Show (System). An operator alert note can be strongly operator-loop 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 ownership and away from master-scale stories. That cost is intentional: the goal is to prevent surrogate ladders from entering the Core.

#Conformance Checklist

• CC-C.2.LS-1 A language-state facet profile SHALL reference explicit facet owners rather than invent local unnamed axes.
• CC-C.2.LS-2 C.2.LS MUST NOT redefine F or create a second formality ladder.
• 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 path 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 axes.
• CC-C.2.LS-7 A profile bundle MUST NOT smuggle move law, bridge law, gate state, or downstream-owner semantics into what should remain a thin facet-profile record.

#Common Anti-Patterns and How to Avoid Them

• Shadow ladder. 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 law, gate state, or endpoint ownership. Keep route notes informative and push operative authority back to A.16, downstream owners, or gate/work owners.

#Consequences

The benefit is owner 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 owner boundaries.

#SoTA-Echoing

SoTA note. This section does not mint a second rule layer. It is a load-bearing alignment surface: 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 action;
• 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,
• strongly 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 strongly 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 axis.

#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 ladder;
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 reviewers

A reviewer 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 owner 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 owned set into one summary axis.

#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 laws, bridge laws, scale laws, or bundle semantics into the profile itself, they are writing in the wrong owner.

#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 materially affect routing, repair, bridge interpretation, or review burden;
• 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 lawful only if facet ownership remains legible.

#Partial-profile rule

A partial profile is lawful 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 owned 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 lawful only when they dock to explicit facet refs. Overlays remain secondary to the owned profile and must not replace the facet bundle.

#Cross-Facet Reading Law

#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

A reviewer should ask:

• is each published facet owned 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 old prose

Legacy 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 owner 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: Draft Normativity: Normative unless marked informative

Plain-name. Articulation explicitness.

#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 owner 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 later repair or endpoint routing, 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 routing.

#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, routing, and repair.

#Characteristic contract

• 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 lawful 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 bearer, action, 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 action contract 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 lawful 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 exit 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 bearer, relation, or action 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

A reviewer 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 own closure, confidence, or warrant. If authors want those meanings, they must publish them through their own owners.

#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;
• bearer/action/evaluator slots where relevant;
• a minimally relation-like skeleton;
• a candidate normal form, or an explicit note that no such form is yet lawful.

A bare AE3 label is weak publication 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

#Lawful entry into relational repair

Entry into A.6.P is lawful 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 lawful 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

A reviewer should ask:

• are the named anchors genuinely present rather than merely presupposed;
• does the claimed articulation level rest on structure rather than tone;
• are bearer, action, evaluator, or comparison slots still ghosted;
• if AE is used to justify route transfer, is the destination owner actually ready to receive the publication.

#Endpoint-boundary test

High AE does not by itself authorize endpoint claims, gate pressure, or quality ascriptions. If such consequences appear, show which downstream owner 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: Draft Normativity: Normative unless marked informative

Plain-name. Language-state closure degree.

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

#Characteristic contract

• 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 weakly closed, or weakly explicit but already strongly closed 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 lawful 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 or owner 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 reopen path 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 owners.

#Consequences

The benefit is lawful 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 a lawful 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 or owner makes the closure binding?
• what would count as a lawful reopen trigger?

#Review prompt

A reviewer should ask whether closure is being inferred from tone, from hierarchy, or from social pressure rather than from an explicit narrowing of route or frame space.

#Governance note

Whenever CD materially affects gates, commitments, or late endpoint authority, the supporting guard or owner 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/publication path 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, owner, or policy that makes the narrowing binding;
• the condition under which a lawful 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.

#Retained and Withdrawn Authority Handling

#Authority retention rule

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

#Lawful retreat record

A lawful 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 owner. When prose treats "closed" as "must now be done", reroute the claim through the actual owner.

#Review Matrix and Reopen Tests

#Review matrix

A reviewer should ask:

• what was narrowed;
• by what owner or guard it was narrowed;
• what would reopen it;
• whether any downstream 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/guard package is explicit. Final-sounding rhetoric often overstates actual closure.

#Cross-facet reminder

Low CD does not imply low articulation, weak 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 action 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 route segment is fixed.

#C.2.5:End

#U.LanguageStateAnchoringMode

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

Plain-name. Language-state anchoring mode.

#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 owner, embodiment and source anchoring are smuggled into informal prose or folded into representation terms. That weakens cue comparison, weakens bridge loss notes, and turns operator-facing language-state work into a special case with no explicit home.

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

#Starter family

#Owner boundary

U.LanguageStateAnchoringMode is not a representation factor bundle, not a closure state, and not a truth status. 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 lawful 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 often justifies a stance annotation 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 if it is later paraphrased 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 routing, trust, 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 was written down later.
• 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 burden 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 re-owning 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 later 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 later 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 later publication wording fully captures the model-side cue.

#Mixed-mode publication

A routed alert note may lawfully 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 anchoring locus?
• 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

A reviewer should watch for the common mistake where later 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 anchoring locus;
• 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 later 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 lawful 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 Law

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

If an anchoring shift matters across contexts, F.9 or F.9.1 should own 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

A reviewer 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 own 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: Draft Normativity: Normative unless marked informative

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

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

#Problem

Terms such as EncodingBasis collapse several independent choices. That makes comparison brittle and encourages one-dimensional 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.

#Minimal factor readings

#Non-collapse rules

LanguageStateRepresentationFactorBundle is not:

• LanguageStateAnchoringMode;
• Formality;
• ArticulationExplicitness;
• LanguageStateClosureDegree.

A representation may be distributed yet strongly trace-anchored; symbolic yet weakly articulated; sparse yet low-closure. Those combinations shall remain visible.

#Extension rule

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

#Archetypal Grounding

Tell. A model-state cue can be highly distributed but still strongly 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 procedure 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 axis 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 owned 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-axis 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, symbolic/neuro-symbolic stacks, 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 weakly articulated

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-stack publication

An operator-facing publication face may combine sparse alert codes, symbolic procedure 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

A reviewer 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

Reviewers 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 routing, comparison, or bridge claims.

#Boundary reminder

U.LanguageStateRepresentationFactorBundle describes representational organization only. It does not determine route authority, 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 lawful only when they dock to the underlying factor bundle. No compact label may behave as a hidden master score for routing, bridge comparison, or stage/progression talk.

#Alias docking rule

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

#Factor Interaction and Cross-Facet Reading Law

#Interaction law

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 owned by F.9 and F.9.1.

#Review Matrix and Extension Tests

#Review matrix

A reviewer 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 axis.

#Migration test for legacy terminology

Legacy 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 old 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

#Kinds, Intent/Extent, and Typed Reasoning (Kind‑CAL)

One‑line summary. Establishes U.Kind as the minimal, context‑local intensional carrier of “what a statement is about,” separates intent (KindSignature + its own F) from extent (which instances belong to the kind in a given Context slice), and situates typed reasoning alongside USM Scope (G) and F–G–R without conflation. Details of the core objects and operations live in C.3.1–C.3.5; guard shapes are standardized in C.3.A.

Status. Normative in Part C. Identifier C.3. This pattern lays the architectural invariant and manager‑level guidance. The mechanics are defined by its child patterns.

Readers. Engineering managers, architects, and assurance leads who must reason about typed claims across Contexts without mixing up describedEntity (Kinds), applicability (G), and assurance (R).

Depends on. — A.2.6 USM (Context slices & Scopes): U.ClaimScope = G, U.WorkScope, ∈/∩/SpanUnion/translate, Γ_time policy, Bridges + CL (scope). — C.2.2 F–G–R: weakest‑link composition; penalties to R for Cross‑context congruence (CL). — C.2.3 Unified Formality F: F0…F9 as an ordinal Characteristic (expression rigor).

Sub‑patterns (normative unless noted). — C.3.1 - U.Kind & U.SubkindOf (partial order). — C.3.2 - KindSignature (intent, with F) & Extension/MemberOf (extent in a slice). — C.3.3 - KindBridge & CL^k (type‑congruence; penalties route to R). — C.3.4 - RoleMask (context‑local adaptation without cloning kinds). — C.3.5 - KindAT (K0…K3, informative facet, not a Characteristic). — C.3.A - Typed Guard Macros (annex): admit/compose, masks, Cross‑context reuse; AT is forbidden in guards.

Deprecations. — “Generality ladder” for G; G is Scope only (set‑valued over U.ContextSlice). — Any “Kind scope” characteristic (Kinds carry intent/extent, not Scope). — Mark as legacy any uses of ‘validity’ as a Characteristic or ‘operation’ as a Scope‑like Characteristic; redirect to U.ClaimScope / U.WorkScope (A.2.6) for applicability. Editors SHOULD add glossary redirects in Part E.

Editorial note (cut‑over). Content formerly in C.3 that defined guard shapes, decision trees, and macro anti‑patterns now resides in C.3.A. Membership evaluation obligations live in C.3.2 with MemberOf.

#Purpose & Rationale

What you get.

1. A neutral typed layer: name what a claim quantifies over (Kinds) without binding to any particular “type technology” (OWL, PL types, shapes…).
2. A clean split of characteristics: – Scope (G) = where a claim holds (USM, set‑valued over Context slices). – Kind extent = which instances belong to a kind inside a given slice. – F = how strictly content is expressed (C.2.3). – R = how well supported (evidence & congruence penalties).
3. Typed reuse across Contexts: a dedicated KindBridge with CL^k (type‑congruence), so you can predict risk without touching F or G.
4. Manager‑oriented maps: when to invest in formalization (F), when to expand/narrow Scope (ΔG), when to test across subkinds (R), and what kind of bridge you should expect.

Why it helps. Teams routinely overspend on proofs for instance‑level questions and underspecify scope for class‑level claims. By naming the Kind, you plan ΔF/ΔR correctly and keep G honest. Typed checks also block unsafe compositions (“we were talking about different things”).

#Context

Cross‑disciplinary work mixes artifacts that look like “types” but behave differently: ontology classes, schema “shapes,” programming types, BORO super/sub categories, ad‑hoc labels. At the same time, USM made “scope” precise. What was missing was a small, neutral notion of describedEntity that (a) does not re‑invent a global “type system,” (b) composes with USM and F–G–R, and (c) lets Contexts keep their idioms—with bridges when crossing boundaries.

#Problem

1. Scope–type conflation. Authors try to widen G by “abstracting the wording,” yielding claims that sound general but are only supported on a thin slice.
2. Silent drift across Contexts. A “vehicle” here is not the same as a “transport unit” there; reuse proceeds without a declared mapping or risk accounting.
3. Wasteful planning. Without a signal about the kind‑level, teams either over‑formalize single‑slice decisions or under‑test class‑level claims (no variant coverage along subkinds).
4. Unsafe composition. Claims about incompatible “things” get composed because the describedEntity was implicit in prose.

#Forces

#Solution — Architectural Decisions (overview)

C.3‑D1 — U.Kind is intensional and context‑local. Kinds name what a claim quantifies over. They form a partial order ⊑ (SubkindOf). (See C.3.1.)

C.3‑D2 — Separate intent and extent. — KindSignature(k): the intensional content (predicates/invariants/Standards). It carries its own F (C.2.3). — Extension(k, slice)/MemberOf: which instances belong to k in a given U.ContextSlice. (See C.3.2.)

C.3‑D3 — Kinds do not carry Scope. Scope lives with claims/capabilities (USM): a set of Context slices where the statement holds. Kinds carry intent/extent only. (USM A.2.6 + C.3.2.)

C.3‑D4 — Typed reuse across Contexts is explicit. Use a KindBridge with CL^k (type‑congruence) and loss notes. Its effect is only via R penalties; F/G remain unchanged. (See C.3.3.)

C.3‑D5 — Local adaptation without cloning. Use a RoleMask to bind a kind to Context‑specific constraints/aliases; promote to a subkind if the mask becomes stable and widely reused. (See C.3.4.)

C.3‑D6 — An informative “abstraction tier” exists for Kinds (AT: K0…K3). A facet (not a Characteristic) that helps plan ΔF/ΔR and forecast bridge style; AT never appears in guards. (See C.3.5.)

C.3‑D7 — Guard shapes are standardized and fail‑closed. Typed compatibility first (same‑Context ⊑ or KindBridge), then Scope coverage (USM), then R penalties and freshness. (See C.3.A.)

Manager’s picture — Two characteristics (keep them separate). – characteristic 1 (USM, G): Where the claim holds → set of Context slices; composed by ∈ (membership) / ∩ (intersection) / SpanUnion (union across independent lines) / translate (scope mapping). – characteristic 2 (Kind extent): Which instances in a given slice belong to the kind → MemberOf(e, k, slice). Never “widen G” by abstract wording; widen only by ΔG with support.

#Core Concepts (informative summary; authoritative norms live in C.3.1–C.3.5)

This section fixes the Standard of terms used in C.3 and points to the sub‑patterns for complete mechanics. All “SHALL/MUST” statements here are normative.

Editorial note. This section is informative. It restates manager‑level takeaways and points to the canonical, normative rules in C.3.1–C.3.5. Where this section summarizes a rule, treat the cited sub‑pattern (and rule ID) as the source of truth.

#U.Kind & U.SubkindOf (⊑)

Definition. U.Kind is a context‑local intensional object naming a “kind of thing” that claims may quantify over. Order. U.SubkindOf (⊑) is a partial order (reflexive, transitive, antisymmetric). We write k₁ ⊑ k₂.

Summary of norms (authoritative text: C.3.1 K‑01–K‑02). — Contexts treat ⊑ as a partial order and document any computed meets/joins if they provide them. — Kinds do not carry Scope; Scope remains on claims/capabilities (USM).

Full treatment: C.3.1 (definitions, invariants, examples).

#KindSignature (intent) & F

Definition. KindSignature(k) is the intent: predicates/invariants/Standards that define the kind in the Context. Its expression rigor has an explicit U.Formality (C.2.3).

Summary of norms (authoritative text: C.3.2 K‑03–K‑04). — KindSignature(k) declares its F (C.2.3). Claim‑level F does not auto‑inherit; weakest‑link applies on the claim’s own support paths. — If a signature change alters membership, treat it as a content change (Contexts may version kinds).

Full treatment: C.3.2 (signature/intent with F; relation to claims).

#Extension & MemberOf (extent in a slice)

Definition. Extension(k, slice) ⊆ EntitySet(slice) = set of instances that belong to k in the given U.ContextSlice. MemberOf(e, k, slice) is the membership predicate: e ∈ Extension(k, slice).

Summary of norms (authoritative text: C.3.2 K‑05–K‑08). — Membership is deterministic for a fixed (k, slice) (no hidden “latest”). — If k₁ ⊑ k₂, then Extension(k₁,slice) ⊆ Extension(k₂,slice) for all slices. — Definedness may be bounded; outside it, guards fail closed. — Keep Scope (G) and MemberOf as distinct guard predicates.

Full treatment: C.3.2 (extent semantics, examples, authoring hints).

#KindBridge & CL^k (type‑congruence)

Summary of norms (authoritative text: C.3.3 KB‑01–KB‑12). — A KindBridge states Contexts/versions, kind mapping/rules, preserved order links, CL^k anchors, loss notes, and definedness. — No inversions of preserved subkind links; collapses must be declared. — When classification depends on a KindBridge, apply a monotone penalty Ψ(CL^k) to R (scope‑bridge Φ(CL) applies separately). F and G remain unchanged. — Chaining uses weakest‑link on CL^k.

Full treatment: C.3.3 (bridge shape, anchors, examples).

#RoleMask (adaptation without cloning)

Definition. U.RoleMask(kind, Context) is a named binding that carries constraints (optional narrowing of membership), vocabulary/notation aliases, and intended use for local procedures—without creating a new Kind.

Summary of norms (authoritative text: C.3.4 RM‑01–RM‑08). — Masks are registered/versioned; constraints are observable/deterministic at guard time. — Do not treat masks as kind synonyms; promote frequently reused constraint masks to explicit subkinds (⊑).

Full treatment: C.3.4 (mask taxonomy, guard discipline, promotion rule).

#KindAT (K0…K3) — informative facet

Status. A facet attached to U.Kind, not a Characteristic: no algebra, never used in guards or composition.

Anchors (intentional view). K0 Instance; K1 Behavioral pattern; K2 Formal kind/class; K3 Up‑to‑Iso.

Use. Helps plan ΔF/ΔR and forecast bridge style (e.g., K3↔K3 suggests up‑to‑iso mapping). Do not conflate AT with G or R.

Full treatment: C.3.5 (manager heuristics, anti‑misuse).

#Quick examples (two‑characteristic awareness)

E‑Sketch 1 — Policy over Vehicle. Claim: “For all x ∈ Vehicle: brakeDistance(x) ≤ 50 m (dry), ≤ 40 m (wet).” – describedEntity: Vehicle (Kind, typically K2) — what we quantify over. – Scope (G): {surface∈{dry,wet}, speed≤50, rig=v3, Γ_time=rolling 180d} — where the claim holds. – Extent in slice: which instances the lab currently classifies as Vehicle (via MemberOf). Typed checks happen before Scope intersection; G is not widened by “abstract wording.”

E‑Sketch 2 — API rule over AuthenticatedRequest. Producer A emits Request; consumer B expects AuthenticatedRequest. – If Request ⊑ AuthenticatedRequest does not hold, add an adapter or adopt a subkind; do not force fit by widening G. – Scope remains independent (API version, Γ_time policy); evidence/freshness sits in R.

#How to use typed reasoning

#C.3:7.1 How typed reasoning plugs into F–G–R & USM

#The basic shape of a typed claim (manager view)

A typed claim has two independent parts:

1. describedEntity (Kind). Which things the statement talks about. “For every item of kind k in the target context (the selected TargetSlice) …”. — The definition of kind k lives in KindSignature(k) (with its F, C.3.2). — Which items count as “k” is evaluated in the TargetSlice (C.3.2) by a deterministic membership check.

2. Applicability (Scope, G). Where the statement holds. U.ClaimScope(Claim) is the collection of contexts where the claim is valid (USM A.2.6). Guards test: “Scope covers the TargetSlice”.

Discipline. The guard first checks typed compatibility (in the same Context: “is‑a / subkind‑of”; across Contexts: a KindBridge, C.3.3), then Scope coverage (USM), then R freshness and any bridge congruence penalties. See C.3.A Guard_TypedClaim.

#Composition of typed claims

Rule C‑T‑1 (typed pre‑check). To compose a producer claim with a consumer claim, where the producer quantifies over kind k (source) and the consumer expects kind k (expected):

• same Context: require “is‑a / subkind‑of” to hold (the source kind is a subkind of the expected kind) (C.3.1).

• Cross‑context: require a KindBridge that maps the source kind to a local kind that is a subkind of the expected kind in the target Context (C.3.3). If neither holds, the composition is unsafe; introduce a subkind, add an adapter (or a RoleMask), or decline.

• Role‑aware option (same Context): if the consumer expects a RoleMask over the expected kind, you may satisfy the mask’s explicit constraints (C.3.4) instead of changing kinds, provided those constraints are observable at gate time.

Rule C‑T‑2 (scope after type). After typed compatibility is satisfied, compute Scope as in USM:

• Serial path: take the intersection of the contributors’ claim scopes.
• Parallel independent lines: use SpanUnion of the serial scopes (only if independence is justified).

Rule C‑T‑3 (no type‑by‑scope). A kind mismatch MUST NOT be “fixed” by widening G. Changes in describedEntity require subkind introduction, signature edits, or a KindBridge—not a scope change.

Manager hint. First confirm the port shape matches (kinds line up), then check the operating area (scope), and finally look at confidence (evidence freshness plus any bridge congruence penalties).

#F–G–R with typed claims (what changes, what doesn’t)

• F (Formality). – Claim‑level F follows C.2.3 (weakest‑link along the claim’s support paths). – KindSignature F is declared on the kind (C.3.2) and influences claims only if the claim essentially depends on those predicates (weakest‑link again). – Raising F can reveal hidden assumptions (which may trigger ΔG in the claim), but does not change G by itself.

• G (Scope). – Always set‑valued over Context slices (USM A.2.6). – Typed reasoning does not alter G’s algebra (∈/∩/SpanUnion/translate). – Never infer Scope from “how general the wording sounds.”

• R (Reliability). – Evidence freshness/decay (validation windows) remains separate from Scope coverage. – Cross‑context penalties split cleanly: a scope‑bridge penalty (USM) and a kind‑bridge penalty (C.3.3). Both reduce R only; neither changes F or G.

Manager rule of thumb. Start with the reliability from your support; then apply the scope‑bridge penalty; then apply the kind‑bridge penalty. Each step can only reduce reliability.
You never add or average F/G: you compose scope per USM rules and apply weakest‑link for F/R along support paths.

#ESG gating with typed claims

• Gate on F, if your Context requires rigor before use (e.g., U.Formality(Claim) ≥ F4).
• Gate on Scope coverage (USM) and an explicit time selector (Γ_time) policy.
• Gate on R freshness and minimum congruence for bridges (e.g., CL ≥ 2, CL^k ≥ 2).
• Do not gate on AT (C.3.5); it is an informative facet only.
• Use C.3.A guard macros to keep guards short and auditable.

#How typed reasoning plugs into the CAL chain (Lang‑CHR → Role‑CAL)

Intent. Show a clear, end‑to‑end path a manager can follow to take a typed claim from words to safe reuse across Contexts—without any tool or data‑governance assumptions. Each stage says what it supplies, what it needs, and what it hands off to the next stage.

#Lang‑CHR — stable words first

What it supplies. A disciplined vocabulary and controlled phrasing so that terms like Vehicle, AuthenticatedRequest, AdultPatient have one meaning in the Context.

What it requires. Authors use controlled narrative (C.2.3 F3) at minimum: single‑meaning terms, explicit “shall / if / then”, and no drifting synonyms.

Hand‑off. A small, curated lexicon entry for each candidate Kind‑word; these become U.Kind names in the next step.

Manager hint. If two teams cannot agree on the noun, you are not ready to type the claim. Resolve the noun in Lang‑CHR before introducing a Kind.

#Kind‑CAL (this Part) — name the describedEntity

What it supplies. • U.Kind objects for those nouns; a partial order ⊑ (subkind‑of). • KindSignature(k) (intent), with declared F. • Extension(k, slice) and MemberOf(e,k,slice) (extent). • (Optional) AT (K0…K3) as an informative facet.

What it requires. • Deterministic membership (no “latest” defaults) and a clear rule for where membership is defined in each context. • No “Kind scope”: Scope remains with claims/capabilities (USM).

Manager hint. Use the kind’s AT tag only as a planning signal (where to invest rigor and tests). AT never gates decisions and never widens scope.

Hand‑off. Typed quantifier sites for claims: “∀ x ∈ Extension(k, slice) …”, plus a visible ⊑ lattice for compatibility checks down the line. Typed claim sites written in Plain language: “for every item of kind k in the target context …”, plus a visible subkind‑of lattice for compatibility checks down the line.

Manager hint. Decide early whether your Kind is K0 (instance‑ish) or K2 (formal class). It sets your ΔF/ΔR budget expectations.

#Structure‑CAL — give Kinds usable shape

What it supplies. Structural building blocks on Kinds: • combinations (“and”), • alternatives (“either/or”), • records (named fields), • functions (inputs to outputs), plus relations like has‑attribute and part‑kind, and the minimal invariants those structures must respect.

What it requires. • Do not hide Scope inside structure. • Put structural rules into the KindSignature as checkable statements (ideally F4+).

Hand‑off. Typed ports and shapes of claims/specifications (“this policy expects PassengerCar × ControllerConfig”), making compatibility checks crisp before any Scope math.

Manager hint. If two claims expect different shapes (for example, one needs “Vehicle with ABS”, the other just “Vehicle”), plan a subkind or an adapter. Do not “solve” it by rewording the claim.

Note (informative). If a Context declares structural constructors on kinds (e.g., product/sum/record/function), editors SHOULD document the corresponding Extension inclusion laws for those constructors. Keep Scope in USM; do not hide it in structure.

#Compose‑CAL — compose with typed pre‑checks

What it supplies. The order of checks you must follow for safe composition:

1. Typed compatibility: in the same Context, the producer’s kind is a subkind of the consumer’s kind; across Contexts, a KindBridge maps the producer’s kind to a local kind that fits, with an acceptable kind‑bridge congruence level (C.3.3).
2. Scope checks (USM): along dependency paths, take the intersection of scopes; use SpanUnion only when support lines are truly independent.
3. Assurance wiring: apply the scope‑bridge penalty and the kind‑bridge penalty to R; check evidence freshness separately.

What it requires. Independence justification for SpanUnion; no “type‑by‑scope” fixes.

Hand‑off. A typed, scope‑checked composition that survives audit because each risk is accounted for in R.

Manager hint. Run the typed pre‑check first. It is the cheapest failure to catch and prevents “scope gymnastics” that mask a type mismatch.

#CT2R‑LOG — speak the logic, keep the math honest

What it supplies. • A clear logical reading of your typed claim: “for every item of kind K, condition φ holds” (or “there exists an item …”). • Rules for refinement and substitution that respect the subkind‑of relation. • When appropriate (K3), reasoning that treats structures as equivalent up to isomorphism (useful where exact identity is the wrong notion).

What it requires. • Pick a logic that matches the Formality you declare (e.g., machine‑checked logic for higher F). • When the logic travels across Contexts, use a KindBridge to keep meaning aligned; any mismatch is reflected as a kind‑bridge penalty in R.

Hand‑off. Proof obligations or reasoning templates that are consistent with your Kind/Structure setup and do not alter G. Shall‑note CT2R‑1. Transferring typed formulas that depend on MemberOf across Contexts uses a KindBridge; any mismatch is accounted as Ψ(CL^k) in R. F and G remain unchanged. For up‑to‑iso situations, see C.3.5 (AT) for when K3 is appropriate.

Manager hint. If your proof keeps failing when you move between Contexts, add a bridge at the Kind level; do not try to “fix” it by changing scope.

#Role‑CAL — adapt without cloning

What it supplies. RoleMask(kind, Context): a named, registered adaptation (extra constraints or local aliases, with optional narrowing) that reuses the same kind instead of creating a new one.

What it requires. • Constraints must be testable at gate time and give deterministic answers. • If a constraint mask is reused often, promote it to a subkind.

Hand‑off. Context‑specific views that keep identity intact and make typed guards practical (“use PaymentAccount@PCI mask in these steps”).

Manager hint. If the same mask appears in several guards, promote it to a subkind. This reduces future bridge and audit effort.

#Mini end‑to‑end example (manager‑oriented)

Scenario. A risk gate for API requests must be reused by another program across Contexts.

Lang‑CHR. Settle on Request, AuthenticatedRequest, RiskScore, BudgetSlack; write them in controlled phrases (F3).

Kind‑CAL. • Define Kind Request (K2) and a subkind AuthenticatedRequest ⊑ Request; publish a KindBridge for the PCI taxonomy with kind‑bridge congruence level 2 (loss note: token class is collapsed). • Membership MemberOf(e, AuthenticatedRequest, slice) is deterministic under API v2.3 and Γ_time policy.

Structure‑CAL. • AuthenticatedRequest is a record kind with fields (headers, tokenProof, body); invariants relate tokenProof to headers.

Compose‑CAL. • Policy P says in Plain terms: “for every AuthenticatedRequest in the target context, deny the call when riskScore is at or above the set risk threshold and budgetSlack is at or below the set budget limit.” • Another service S expects PCIRequest. Typed pre‑check: does AuthenticatedRequest ⊑ PCIRequest? No. • Remedy: adapter A proves AuthenticatedRequest → PCIRequest in this Context; if reusing across Contexts, publish a KindBridge for the PCI taxonomy with CL^k=2 (loss: token class collapsed).

CT2R‑LOG. • State P in a state P in a proof‑checked logic (where appropriate for F7+), so that changes to token rules break proofs. Proofs rely on the AuthenticatedRequest definition, not on the consumer’s scope.

Role‑CAL. • Register a RoleMask over PCIRequest for the consuming team; guards must be able to test the mask’s constraints at gate time.

Outcome. • Typed guard approves only when: (i) the type pre‑check passes (same‑Context subkind‑of or a KindBridge with an acceptable congruence level), (ii) Scope covers the target context (API v2.3, explicit time selector), and (iii) R reflects the scope‑bridge and kind‑bridge penalties and evidence is fresh. • No one widened Scope to hide a type mismatch; the adapter + bridge made the semantics explicit and auditable.

Takeaway. If you keep these six hand‑offs in view—words → kinds → structure → composition → logic → roles—you get predictable reviews, clean risk accounting, and reusable claims that travel across Contexts without silent meaning drift.

#Compliance & Regulatory Alignment — profile

Treat regulatory categories as Kinds, carry their intent in KindSignature with declared F, move them across Contexts with a KindBridge (type‑congruence CL^k + loss notes), and express applicability as Claim scope over U.ContextSlice (with explicit Γ_time). Any Cross‑context uncertainty is routed to R via Ψ(CL^k) (kind) and Φ(CL) (scope); F and G remain unchanged.

Authoritative obligations and guard macros (C‑REG‑1…8, Guard_RegAdopt / Guard_RegChange / Guard_RegXContextUse) and worked scenarios live in C.3.A, Annex A (Regulatory adoption profile).

#How typed reasoning plugs into Assurance Lanes (VA/LA/TA) & Evidence design

Intent (manager’s view). Typed reasoning turns “prove/test/qualify” into a repeatable plan by making what the rule talks about explicit (named Kinds, their subkinds, optional RoleMasks) and keeping Scope (G) over U.ContextSlice separate from membership inside the slice. Cross‑context uncertainty (Scope Bridge CL, KindBridge CL^k) always routes to R as penalties Φ/Ψ; it never changes F or G.

Evidence matrix (sketch).

Tip. For formal kinds and “up‑to‑iso” kinds (AT K2/K3), expect more rows (variants). For instance‑like kinds (AT K0), expect fewer rows and tighter columns (narrow slices, stricter freshness).

Authoritative evidence obligations and guard macros (planning/attachment, VA/LA/TA duties, anti‑patterns) are in C.3.A, Annex B.

#How typed reasoning plugs into ESG and Method–Work gating

Intent. Make state changes and work admissions deterministic, auditable, and safe by separating (1) typed compatibility (what the statement or capability is about) from (2) scope coverage (where it holds or can run). Any Cross‑context uncertainty is routed to R (reliability) only—never to F (form) or G (scope).

#Scope & fit

This subsection defines normative guard obligations for:

• ESG (Episteme State Graph) transitions whose assertions quantify over kinds, and
• Method–Work admissions where a capability expects inputs/outputs of specified kinds.

It reuses:

• USM (A.2.6): U.ClaimScope (G) and U.WorkScope coverage + Γ_time,
• Kind‑CAL core (C.3.1–C.3.2): U.Kind, MemberOf(e,k,slice), ⊑,
• KindBridge (C.3.3) with CL^k and loss notes,
• Scope Bridge (Part B) with CL and loss notes,
• RoleMask (C.3.4) when local adaptations of a kind are used,
• Formality F (C.2.3) when transitions gate on rigor,
• Assurance R (C.2.2) for evidence freshness and penalties Φ/Ψ.

Guard macros. The normative guard shapes for ESG and Method–Work (Guard_TypedClaim, Guard_TypedJoin, Guard_MaskedUse, Guard_XContext_Typed) are specified in Annex C.3.A. Use those shapes; the present section is a manager‑level overview only.

#Inputs & roles (at guard time)

• TargetSlice — the specific context you are deciding for: Context, versioned Standards, environment parameters, and an explicit time selector (Γ_time).

• Typed carriers

  • ESG: the Claim quantifies over one or more Kinds (e.g., “for all vehicles in the target context …”).
  • Method–Work: the Capability declares expected input/output kinds (and possibly RoleMasks).

• Thresholds (context‑local policy):

  • Minimum F level for the Claim (if the Context gates on rigor),
  • Minimum congruence for scope bridges,
  • Minimum type‑congruence for KindBridges,
  • Evidence freshness windows (R‑lane).

• Evidence bundle (if the transition implies trust): references, dates, windows.

#Manager’s 7‑step checklist (operational)

1. Name the slice. Write the full TargetSlice/JobSlice tuple including Γ_time.
2. Check coverage. Claim/Work scope covers the slice (USM).
3. Check typed definedness. A deterministic membership check is available in this context for every kind you use (and any masks are registered).
4. Check typed compatibility. same Context: ⊑ (or mask constraints met). Cross‑context: KindBridge with CL^k ≥ c.
5. Bridge scope if needed. Scope Bridge with CL ≥ c for Cross‑context scope.
6. Apply penalties to R. Apply the scope‑bridge penalty and the kind‑bridge penalty; then check evidence freshness windows.
7. (If gated) Check F. Enforce Formality ≥ F_k for the transition.

Remember: F and G never change because of bridges; only R is penalized. AT (K0…K3) is informative and not used in guards.

#Cross‑references

• USM / A.2.6: Scope coverage, Γ_time, serial ∩, SpanUnion, Bridge+CL.
• Kind‑CAL / C.3.1–C.3.4: U.Kind, ⊑, MemberOf, RoleMask, KindBridge + CL^k.
• Formality / C.2.3: U.Formality thresholds (when ESG gates on rigor).
• Assurance / C.2.2: Freshness windows; Φ(CL) and Ψ(CL^k) penalties to R (weakest‑link on paths).

This subsection is normative for guards in ESG and Method–Work that use kinds.

#Cross‑context typed reuse & assurance accounting

#The two‑bridge rule (mandatory)

When any part of the use crosses Contexts:

1. Scope Bridge (USM/Part B) with CL → penalty Φ(CL) to R.
2. KindBridge (C.3.3) with CL^k → penalty Ψ(CL^k) to R.

Both bridges carry loss notes; neither changes F or G. See C.3.A Guard_XContext_Typed.

#Narrowing after mapping (best practice)

If a bridge’s loss notes indicate material mismatch (dropped invariants, collapsed subkinds):

• Narrow the mapped Scope to areas where those losses are benign.
• Or introduce an adapter (plus evidence) that restores the needed properties in the target Context.
• Document the decision; the penalties still land in R.

#Typical Cross‑context patterns (manager’s catalog)

• Name‑level overlap only (low CL^k). Expect significant Ψ penalty. Limit quantification, add local checks, or refuse reuse until the kind mapping is improved.

• Up‑to‑iso mapping (high CL^k). Often seen for K3 kinds. Ψ penalty is small; treat as “shape‑preserving” transfer. Still apply the appropriate Φ(CL) for Scope.

• Mask‑to‑subkind evolution. If receivers repeatedly use the same RoleMask to make a transfer safe, promote it to an explicit subkind and update the bridge to preserve that link.

#Decision pattern (fast path)

1. Typed pre‑check: k_A ⊑ k_B (same Context) or KindBridge(k_A → k′_B) with acceptable CL^k.
2. Scope coverage: translate(Scope_A) covers TargetSlice_B.
3. Apply penalties: Φ(CL_scope) and Ψ(CL^k) to R.
4. Freshness: windows/decay for all bound evidence.
5. Publish: a short “Bridge and Loss Notes” box; include any narrowing or adapters used.

#Authoring guidance (engineers‑managers)

#When to mint a U.Kind

Create a Kind when:

• multiple claims refer to the same “describedEntity” using unstable labels;
• you need subkinds (refinement) or repeated RoleMasks;
• different Contexts must map this “describedEntity” via bridges;
• you need to quantify over a population (and plan variant coverage) instead of over a single exemplar.

Avoid creating a Kind for one‑off instance references—prefer a clear K0 facet or just a literal exemplar in the claim.

#Writing a KindSignature (and picking F)

• Start with a concise intent: the invariants/constraints that make membership meaningful.
• Aim for F4 (predicate‑like) if the kind is intended for reuse; rise to F7+ only where proof‑grade is justified.
• Use observable terms (no “latest”); if a Standard matters, name its version.
• If defining a Kind reveals systematic narrowings in use, introduce explicit subkinds (⊑) rather than accumulating opaque masks.

Example (sketch). Kind Vehicle — intent: “has VIN; has brake system; has propulsion {ICE, EV, Hybrid}; …” (F4 predicates). Subkind: PassengerCar ⊑ Vehicle. RoleMask: Vehicle@ABSRequired for processes that demand ABS (deterministic constraints; candidates for promotion to subkind if widely reused).

#Setting the AT facet (K0…K3)

Use AT to aim effort, not to gate:

• K0: instance/cohort — focus R on the TargetSlice; don’t over‑formalize.
• K1: behavioral pattern — clarify Standards; plan ΔF (F3→F4).
• K2: formal class — invest in F4–F7; plan variant coverage across subkinds in R.
• K3: up‑to‑iso — expect high‑quality bridges; consider F7–F9 for critical invariants.

Never treat AT as “wider/narrower” G.

#Writing a typed claim (with USM blocks)

Skeleton.

• Kinds used: Vehicle (K2), subkinds PassengerCar.
• Claim scope (G): surface∈{dry,wet}; speed≤50; rig=v3; Γ_time=rolling 180d.
• Statement: ∀ x ∈ Extension(Vehicle, TargetSlice) …
• Guards: use C.3.A Guard_TypedClaim; if Cross‑context, add Guard_XContext_Typed (two‑bridge rule).

Tip. Keep Scope, MemberOf definedness, F thresholds, and freshness as separate guard predicates—the auditor should be able to tick each box independently.

#Minimal “Kind card” contents (Context catalog)

• Name and intent summary (KindSignature snippet + F).
• ⊑ links (parents/children).
• Examples of MemberOf@slice (what membership looks like in practice).
• Known RoleMasks (type, constraints, determinism).
• Known KindBridges (source/target Contexts, CL^k, loss notes, definedness).
• (Optional) AT facet with one‑line rationale.

#10 - Review & integration guidance

#Reviewer’s 8‑point checklist

1. Named describedEntity. Does the claim state what it quantifies over (U.Kind)?
2. Scope explicit. Is G declared (no “domain” placeholders, no implicit “latest”)?
3. Typed compatibility. For compositions, do we have ⊑ (same Context) or a KindBridge?
4. RoleMasks. If used, are they registered, deterministic, and not masquerading as kinds?
5. Two‑bridge rule. For Cross‑context use, do we have both Scope Bridge (CL) and KindBridge (CL^k)?
6. Penalties. Are Φ(CL) and Ψ(CL^k) applied to R, not smuggled into F/G?
7. Freshness. Are validation/monitoring windows separate from Scope coverage?
8. Evidence fit. For class‑level claims, does the test plan cover subkinds/variants?

#Integrator’s composition playbook (typed first, then scope)

• Step 1: Check k_A ⊑ k_B (or KindBridge).
• Step 2: Compute Scope_serial = Scope(A) ∩ Scope(B) (USM).
• Step 3: If parallel supports exist, SpanUnion them (only where independent).
• Step 4: Apply Φ/Ψ penalties to R; enforce freshness.
• Step 5: If a mask is repeatedly required, consider promoting it to a subkind.

#Assurance lead: wiring penalties and windows

• Identify channels used: Scope bridge? KindBridge?
• Apply Φ(CL) and Ψ(CL^k) to R (monotone; higher congruence ⇒ smaller penalty).
• Verify freshness windows for all bound evidence (independent of bridges).
• Publish a one‑box summary: bridges, levels, loss notes, any narrowing/adapters, net impact on R.

#Red flags (stop‑the‑line)

• “We widened G because we reworded the type.” → Reject; redo as subkind/bridge or revise Scope honestly.
• “Mask equals kind.” → Refactor; register mask properly or promote to subkind.
• “Cross‑context without KindBridge.” → Block; demand mapping and CL^k.
• “No Γ_time.” → Block; add explicit time policy (point/window/rolling).

#Worked examples (end‑to‑end)

Each example shows the typed pre‑check, Scope composition, penalties to R, and the managerial decision. Full guard clauses for these scenarios are in Annex C.3.A.

#Cyber‑physical braking policy across labs and plants

Claim (Lab Context). “∀ x ∈ Vehicle: brakingDistance(x) ≤ 50 m (dry), ≤ 40 m (wet).” Kinds. Vehicle (K2, KindSignature F4); subkind PassengerCar ⊑ Vehicle. Scope (Lab). {surface∈{dry,wet}, speed≤50, rig=v3, Γ_time=rolling 180d}.

Reuse at Plant B. – KindBridge: Vehicle ↦ TransportUnit with CL^k=2 (loss: EV subkind collapsed). – Scope Bridge: Lab → PlantB with CL=2 (rig bias ±2 %). – Narrowing: loss notes indicate wet‑surface bias; Plant B narrows mapped Scope to temp/adhesion ranges with acceptable bias.

Decision. Typed pre‑check: OK via KindBridge. Scope coverage after translate/narrow: OK. Penalties: apply Φ(2) and Ψ(2) to R; freshness windows checked. Outcome: Adopt with reduced R; action item: qualify rig v4 to raise CL in the future.

#API decision rule with adapter and subkind promotion

Consumer claim. “∀ x ∈ AuthenticatedRequest: deny if riskScore(x) ≥ θ ∧ budgetSlack ≤ β.”

Producer reality. Service A emits Request (no auth guarantee). Option A: A proves it emits AuthenticatedRequest (introduce subkind or strengthen Standard). Option B: Insert adapter that filters/annotates Request → AuthenticatedRequest.

Typed check. Before: no Request ⊑ AuthenticatedRequest. After Option B: adapter supplies the guarantee; repeated use leads to promoting mask to subkind.

Scope. API v2.3; Γ_time = rolling 30 d. R. No Cross‑context reuse; no Φ/Ψ. Evidence: adapter correctness on the TargetSlice.

Outcome. Adopt via Option B; open task: generalize producer to subkind and remove adapter later.

#Clinical dosage rule across jurisdictions (bridge + mask)

Claim (Hospital X). “∀ x ∈ AdultPatient: dosage ≤ D per kg for drug M.” Kind. AdultPatient (K2, F4). Mask. AdultPatient@ClinicMask narrows to the clinic’s cohort (deterministic DOB policy).

Reuse in Jurisdiction Y. – KindBridge: AdultPatient ↦ AdultPerson_Y, CL^k=1 (18 vs 21 years boundary). – Scope Bridge: coding systems differ (CL depends on mapping quality). – Narrowing: restrict Scope to datasets where DOB granularity supports boundary reconciliation.

Decision. Typed pre‑check via KindBridge: OK. Scope coverage after translate/narrow: OK. Penalties: Φ(CL_scope) and Ψ(1) applied to R. Outcome: Adopt with strong R penalty; plan: negotiate a harmonized boundary to raise CL^k.

#ML fairness constraint with typed quantification

Claim (Product Context). “∀ x ∈ EligiblePerson: TPR difference ≤ δ across groups G.”

Kind. EligiblePerson transitions from K1→K2 as attributes and cohorts are formalized (KindSignature F4). Scope. {pipeline=P, features=F, Γ_time=rolling 180 d}.

Cross‑context use. Model team Context has Resident with different feature basis. – KindBridge: EligiblePerson ↦ Resident with CL^k=1 (feature loss). – Scope Bridge: pipeline P → P′, CL=2.

Decision. Typed pre‑check OK via bridges; mapped Scope covers the subset where features align. Apply Φ(2) and Ψ(1) to R; restrict groups to mapped subset; require monitoring freshness. Outcome: Adopt with reduced R and a mitigation note; action items: improve feature mapping and raise KindSignature F.

#Anti‑patterns & how to fix them

Use this section as a “red flags” sheet in reviews. Each item links to a concrete remedy that preserves F–G–R & USM discipline (F/G/R separation, USM algebra, typed pre‑checks).

#Governance & conformance pull‑ups

Contexts adopt Kind‑CAL by meeting the Context‑level obligations below. They summarize, not duplicate, the formal requirements in C.3.1–C.3.5 and C.3.A. Use this as an adoption checklist.

#Context‑level obligations (must‑haves)

1. Kinds & order. Maintain a Context catalog of U.Kind with an explicit partial order ⊑. – Conformance: C.3.1 (K‑01/K‑02).

2. Kind signatures (intent). For each Kind, publish a KindSignature with declared F (C.2.3). – Conformance: C.3.2 (K‑03/K‑04).

3. Deterministic membership. Ensure MemberOf(e,k,slice) is deterministic; declare any definedness domain. – Conformance: C.3.2 (K‑05/K‑07).

4. Typed guards. When a claim quantifies over kinds, guards SHALL use the typed guard macros (or equivalents) from C.3.A; Scope coverage and typed checks are separate predicates.

5. Role masks. If a local projection is needed, register a RoleMask (type: constraint/vocabulary/composite); avoid cloning kinds. – Conformance: C.3.4 (RM‑01…RM‑06).

6. Two‑bridge rule for Cross‑context use. – Scope Bridge (Part B) with CL → Φ(CL) to R. – KindBridge (C.3.3) with CL^k → Ψ(CL^k) to R. – Conformance: C.3.3 (KB‑01…KB‑10).

7. Decision records. For each typed state change, record: TargetSlice tuple, typed compatibility outcome (⊑ or KindBridge), Scope coverage, applied Φ/Ψ penalties to R, and freshness checks.

#ESG / Method‑Work template inserts (normative snippets)

• Kinds used: list U.Kind and any expected subkinds or RoleMasks.
• Claim scope (G): explicit predicates over U.ContextSlice inc. Γ_time.
• Typed guard lines: – same Context: k_A ⊑ k_B checked. – Cross Context: KindBridge(k_A → k′_B), CL^k ≥ c_k checked.
• Scope bridge lines: Bridge(Context_A → Context_B), CL ≥ c_s checked.
• Assurance lines: Φ(CL), Ψ(CL^k) applied to R; freshness windows hold.

#Audits & levels of adoption (informative)

• USM‑Typed‑Ready. Catalog exists; ⊑ declared; guard macros installed.
• USM‑Typed‑Guarded. All typed claims use C.3.A guard shapes; Γ_time explicit; two‑bridge rule enforced.
• USM‑Typed‑Auditable. Decision records capture TargetSlice, typed checks, bridges, penalties, freshness.
• USM‑Typed‑Composed. Compositions use typed pre‑check before Scope algebra; independence justified for SpanUnion.

#Migration & editorial impact

Apply these edits incrementally; you do not need to stop other work. The aim is to eliminate synonym drift, restore F/G/R separation, and make typed reasoning routine.

#Inventory & refactor (steps)

1. Inventory claims that implicitly talk about “things” (vehicles, requests, accounts, cohorts…).
2. Name kinds for recurring “describedEntity”; start at K1; promote to K2 as invariants stabilize.
3. Extract KindSignature (aim F4); declare F.
4. Refactor claims to typed quantification: ∀ x ∈ Extension(k, slice) … plus Scope (G) predicates.
5. Publish bridges where reuse is Cross‑context: Scope Bridge (CL) and KindBridge (CL^k) with loss notes; wire penalties Φ/Ψ to R.
6. Normalize masks: register RoleMasks; if reused, promote to subkinds (⊑).

#Edits to other parts (normative redirects, no new math)

• A.2.6 (USM). – Add “no Scope on kinds” note. – In typed examples, show MemberOf definedness + Scope coverage. – Two‑bridge rule for Cross‑context typed reuse.

• C.2.2 (F–G–R). – Replace any “generality/abstraction” wording with Claim scope (G). – Before scope composition, require typed pre‑check (⊑ or KindBridge). – Distinguish penalties: Φ(CL) vs Ψ(CL^k) → both to R.

• C.2.3 (F). – Add note: KindSignature has its own F; claim‑level F remains by weakest‑link.

• Part B (Bridges). – Introduce KindBridge with CL^k, monotone order preservation, loss notes; determinism. – Chaining uses min of levels (weakest‑link) for both CL (Scope bridges) and CL^k (KindBridges).

• Role‑CAL. – Add RoleMask for kinds; determinism; promotion rule to subkind when reused.

• Compose‑CAL. – Add typed pre‑check before Scope algebra; forbid “type‑by‑scope”.

• Part E (Lexicon). – Add: U.Kind, U.SubkindOf (⊑), KindSignature(+F), Extension, MemberOf, U.RoleMask, KindBridge, CL^k, AT (kinds, facet). – Mark as legacy aliases (not characteristic names): generality (as ladder), kind scope, validity (as characteristic), capability envelope; redirect to Claim/Work scope or Kind entries.

#Backwards compatibility

• Historical prose may keep legacy words. Guards, conformance text, and state assertions MUST use the Kind‑CAL/USM vocabulary and guard shapes.
• When annotating older records, add a small “typed note” box: Kinds, Scope, Bridges (CL/CL^k), loss notes, penalties to R.

#Extended rationale & design notes [I]

This section explains the design choices that keep Kind‑CAL compact and interoperable with F–G–R & USM without drifting into tooling or technology stacks.

#Why no Scope on kinds

Scope answers “where the claim holds” (set of Context slices, USM); kinds answer “what the claim is about”. Putting Scope on kinds would either (a) duplicate claim Scope, or (b) smuggle applicability into a classifier. We prevent both by: intent/extent on kinds (C.3.2), Scope on claims/capabilities (USM).

#Why two bridges (Scope vs Kind)

Contexts diverge along context (Standards, parameters, time) and classification (what counts as a member). A single bridge hides which characteristic is mismatched. Two explicit bridges keep fixes targeted: ΔG / narrowing for context misfit; subkind/adapter for classification misfit. Both risks land in R as separate penalties (Φ/Ψ).

#Why AT is a facet

AT (K0…K3) improves planning (ΔF/ΔR, bridge style) and navigation without introducing new algebra. Making AT a Characteristic would recreate a “G‑ladder,” blur applicability with abstraction, and invite gating on AT. As a facet, AT remains helpful but toothless in math, which is precisely what we want.

#Why RoleMask and not “clone a kind”

Operational tweaks (extra constraints, local aliases) are real but temporary. Cloning kinds creates drift and duplicate bridges. RoleMask documents the tweak without breaking identity; promotion to subkind occurs when practice stabilizes. This keeps catalogs small and bridges honest.

#Fit with Compose‑CAL and LOG‑CAL

Typed pre‑checks (same‑Context ⊑ or KindBridge) act like port compatibility before any Scope arithmetic. LOG‑CAL benefits from explicit quantification ∀ x : Kind with substitution rules aligned to ⊑. Neither alters F/G/R algebra; they prevent category mistakes before we do trust math.

#CT2R lens (intuition)

A KindBridge behaves like a functor that (approximately) preserves structure between Contexts; CL^k is a practical knob for “how functorial” it is. At K3 (up‑to‑iso), this is literal: we expect bridges to preserve equivalences, hence higher CL^k and smaller Ψ penalties.

#Rationale (Part E form)

Problem. (recap) — Authors conflate describedEntity with applicability, widening G by abstract wording. — Cross‑context reuse drifts semantically without declared mappings or risk accounting. — Planning misfires: over‑formalization for instance claims; under‑testing for class claims. — Unsafe compositions when describedEntity is implicit.

Forces. (recap) — Local freedom vs global sense; minimality vs utility; intent vs extent; typed discipline vs F–G–R; abstraction vs applicability.

Decision (C.3‑D1…D7). — D1: U.Kind is intensional and context‑local (⊑ partial order). — D2: Separate intent (KindSignature + F) and extent (Extension/MemberOf@slice). — D3: No Scope on kinds (Scope lives with claims/capabilities via USM). — D4: Typed reuse is explicit: KindBridge + CL^k, penalties route to R only. — D5: Local adaptation via RoleMask; promote stable masks to subkinds. — D6: AT (K0…K3) as facet, not a Characteristic; never used in guards. — D7: Guard shapes: typed pre‑check → scope coverage → penalties/freshness.

Consequences. (+) Predictable Cross‑context reuse: two‑bridge rule, separate penalties (Φ/Ψ) to R.
(+) Manager‑friendly planning: AT guides ΔF/ΔR; typed pre‑check blocks category mistakes.
(+) Clean F–G–R discipline: no “G‑ladder,” no hidden scope inside classifiers.
(−) Editorial discipline required: no “Kind scope”; masks must be cataloged; promote when stable.
(−) Initial bridge authoring cost; mitigated by loss‑notes and reuse.

Alternatives considered. — Global U.Type: rejected as either too thin or too prescriptive across Contexts.
— “Kind scope” in USM: rejected; duplicates/obscures Scope vs Extension split.

Known uses. — §11.1 (cyber‑physical braking); §11.2 (API with adapter); §11.3 (clinical dosage); §11.4 (ML fairness).
— ESG guard shapes in C.3.A; typed pre‑check in Compose‑CAL (§7.2.4).

Related patterns. A.2.6 (USM), C.2.2 (F–G–R), C.2.3 (F), Part B (Bridges), Role‑CAL, Compose‑CAL, C.3.1–C.3.5, C.3.A.

#Quick reference for managers

#10‑minute start

1. Name the Kind your claim talks about.
2. Write Scope (G) as slice predicates (with Γ_time).
3. If composing, check ⊑ or KindBridge first.
4. Use the typed guard macro (C.3.A).
5. Route bridge levels to R (Φ/Ψ); check freshness.

#30‑day rollout plan

Week 1: Inventory & name Kinds (K1); adopt guard macros. Week 2: Draft KindSignature for the top 5 Kinds (aim F4); register masks. Week 3: Wire two‑bridge rule into ESG; add CL/CL^k lines to decision templates. Week 4: Promote repeated masks to subkinds; publish first KindBridge records with loss notes.

#Local glossary (reading aid)

Canonical definitions live in sub‑patterns; this list is for quick recall while reading C.3.

• U.Kind — Minimal intensional “type/kind” object; carries KindSignature and ⊑ (C.3.1/C.3.2).
• U.SubkindOf (⊑) — Partial order on kinds (C.3.1).
• KindSignature(k) — Predicate‑like intent that defines the kind; has its own F (C.3.2).
• Extension(k, slice) — Set of instances of k inside a U.ContextSlice (C.3.2).
• MemberOf(e, k, slice) — Boolean membership predicate (C.3.2).
• RoleMask(k, Context) — Registered adaptation (constraints/aliases; optional narrowing), no new kind (C.3.4).
• KindBridge — Cross‑context mapping for kinds (intent/order) with CL^k and loss notes (C.3.3).
• CL^k — Kind‑congruence level; penalty Ψ(CL^k) goes to R (C.3.3).
• AT (K0…K3) — Informative facet of a Kind; aids planning/navigation; never used in guards (C.3.5).
• Guard macros — Typed guard shapes for ESG/composition (C.3.A).

End of C.3. See C.3.1–C.3.5 and C.3.A for the referenced mechanics and guard macros.

#C.3:End

#U.Kind & SubkindOf (Core)

One‑line summary. Defines U.Kind as a minimal, context‑local intensional carrier for “what a claim is about,” and U.SubkindOf (⊑) as a partial order over kinds. Kinds do not carry Scope. Scope remains on claims/capabilities (USM). This core pattern supplies only identity, locality, and ordering; intent & membership (KindSignature, Extension/MemberOf) are specified in C.3.2, bridges & congruence in C.3.3, masks in C.3.4, and the AT facet in C.3.5.

Status. Normative in Part C. Identifier C.3.1. Audience. Engineering managers, architects, assurance leads.

Dependencies.

• A.2.6 USM (Unified Scope Mechanism). Scope is a set‑valued USM property over U.ContextSlice on claims/capabilities; algebra: ∈ (membership), ∩ (intersection), SpanUnion (union across independent lines), translate (scope mapping).
• C.2.2 F–G–R. F = formality of expression; G = Claim scope; R = assurance/evidence; weakest‑link for F/R; CL penalties feed R, not F/G.
• C.2.3 U.Formality (F). Ordinal F0…F9; no arithmetic; applies to all content, including Kind signatures (defined in C.3.2).
• Part B Bridges & CL. Generic (scope) bridges and CL; Kind bridges are specialized in C.3.3.

Non‑goals.

• No data governance or repository/notation mandates.
• No membership or signature semantics here (defined in C.3.2).
• No Cross‑context mapping/congruence here (defined in C.3.3).
• No role/mask mechanics here (defined in C.3.4).
• No AT facet mechanics here (defined in C.3.5).

#Purpose & Audience

This pattern gives one small, stable vocabulary to say what a claim ranges over (its describedEntity) without entangling that with where it applies (Scope) or how well it is supported (R). For managers:

• It prevents the costly mistake “more abstract wording ⇒ wider scope.”
• It enables typed composition (you cannot combine claims about incompatible “things”).
• It keeps Scope and Assurance math unchanged and predictable.

#Context

across Contexts, “type” means OWL class, SHACL shape, code type, BORO category, etc. A neutral, minimal object is needed to name the kind of entities a claim quantifies over without importing a full type system or altering USM. U.Kind fills that role; ordering between kinds captures “is‑a/refines” relationships a Context relies on.

#Problem

1. Scope–Type conflation. Teams broaden G by “abstracting” prose, not by adding supported slices.
2. Unsafe composition. Claims are joined though they talk about different “things.”
3. Cross‑context drift. Without an explicit core notion of kind, bridges blur describedEntity vs applicability.

#Forces

#Solution — Core Objects (overview)

• U.Kind — a context‑local intensional object naming a “kind of thing” claims may quantify over.
• U.SubkindOf (⊑) — a partial order on kinds (reflexive, transitive, antisymmetric). k₁ ⊑ k₂ reads “k₁ refines k₂.”

No Scope on kinds. Scope is for claims/capabilities (USM). Kinds supply describedEntity only; membership and signature live in C.3.2.

#Norms & Invariants (normative)

C3.1‑K‑01 (Partial order). U.SubkindOf (⊑) SHALL be a partial order on U.Kind: reflexive, transitive, antisymmetric. Editors SHALL document any Context‑specific meets/joins if they supply them (optional).

C3.1‑K‑02 (No Scope on kinds). A U.Kind MUST NOT carry a Scope value. Scope lives with claims (U.ClaimScope = G) and capabilities (U.WorkScope) per A.2.6. Rationale pointer: see C.3.2 for the intent/extent vs Scope split.

C3.1‑K‑03 (Identity & locality). A U.Kind is context‑local. Cross‑context mapping of kinds is handled by KindBridge (see C.3.3); such mapping MUST NOT be conflated with Scope bridging.

C3.1‑K‑04 (Naming). A Context SHALL assign stable identifiers to kinds and SHOULD catalog parent/child ⊑ links. Synonyms/aliases SHALL point to the canonical kind id.

C3.1‑K‑05 (Separation of concerns). This core does not define kind intent or membership; those are specified in C.3.2 (KindSignature with its own F; Extension/MemberOf and determinism).

#Interactions (informative)

• With USM (A.2.6). Guards that quantify over a kind use two predicates: “Scope covers TargetSlice” (USM) and whatever membership predicate is defined for the kind (see C.3.2). Kinds themselves carry no Scope.
• With F–G–R (C.2.2). This pattern does not alter the triple; typed checks happen before scope algebra, preventing invalid compositions.
• Order of checks reference. See Annex C.3.A §5 (E‑01) for the normative evaluation order: typed compatibility first, then Scope coverage, then penalties to R and freshness.
• With Formality (C.2.3). A KindSignature (C.3.2) declares its F; claims retain their own F via weakest‑link.
• With Bridges (Part B). Use KindBridge (C.3.3) for describedEntity; use Scope Bridge (Part B) for applicability. Penalties land in R via different channels.

#Authoring & Review (informative)

When to mint a kind. Mint a U.Kind when claims repeatedly quantify over “the same sort of thing” and you need: (i) safe composition, (ii) clear Cross‑context mapping, (iii) a place to collect invariants (in C.3.2).

Don’t over‑mint. If a local constraint is temporary or purely procedural, prefer a RoleMask (C.3.4) over a new subkind.

Review prompts.

1. Does the draft introduce a new describedEntity concept? → consider a kind.
2. Does prose hint at “is‑a” relationships? → capture as ⊑, not as scope widening.
3. Are authors trying to widen scope by abstracting wording? → stop; widen G only via ΔG (USM) with support.

#Examples (informative, technology‑neutral)

1. Vehicle/PassengerCar. Mint Kind Vehicle. Later add PassengerCar ⊑ Vehicle. Claims about Vehicle may be reused by narrowing to PassengerCar without touching G. Scope remains an independent predicate over U.ContextSlice.

2. Request/AuthenticatedRequest. If multiple policies speak about “authenticated requests,” declare AuthenticatedRequest ⊑ Request. Do not widen G to compensate for missing authentication; either change the producer’s kind or insert an adapter (C.3.2/C.3.4) while keeping G honest.

#Conformance checklist (normative)

#Rationale (informative)

Why a tiny core? Contexts differ wildly in “type” practice. A large, prescriptive core would either (a) force one Tradition’s semantics on all, or (b) become an empty label. The smallest powerful core—identity + ordering—gives managers and integrators what they need (safe composition, predictable edits) and leaves intent/membership/bridges/masks to focused sub‑patterns.

Why “no Scope on kinds”? Scope (USM) answers “where a claim/capability holds” over U.ContextSlice. Kinds answer “what the claim ranges over.” Blending them recreates the failure mode we are removing (“higher abstraction ⇒ wider scope”). The right split is:

• Kind: intensional name + order (⊑) (this pattern); intent & membership (C.3.2).
• Scope: set of context slices (A.2.6).
• Assurance: evidence & penalties (C.2.2 / Part B).

#C.3.1:End

#KindSignature (+F) & Extension/MemberOf

One‑line summary. Specifies the intent and extent of kinds: (i) a KindSignature(k) (the intensional definition of kind k) that declares its own Formality F; (ii) an Extension(k, slice) ⊆ U.EntitySet(slice) and the membership predicate MemberOf(e, k, slice) that are deterministic per U.ContextSlice; (iii) monotonicity of extension under SubkindOf; (iv) a definedness policy that fails closed outside its domain. Kinds still carry no Scope (that rule lives in C.3.1); Scope stays on claims/capabilities (USM). This pattern gives managers and reviewers the observable basis to check “what counts as a member here and now” without entangling applicability (G) or assurance (R).

Status. Normative in Part C. Identifier C.3.2. Audience. Engineering managers, architects, assurance leads, editors.

Depends on.

• C.3.1 (U.Kind & SubkindOf Core): kinds are context‑local; ⊑ is a partial order; kinds carry no Scope.
• A.2.6 USM (Context slices & Scopes): Claim scope (G) and Work scope live on claims/capabilities; algebra ∈ (membership), ∩ (intersection), SpanUnion (union across independent lines), translate (scope mapping).
• C.2.3 U.Formality (F): ordinal F0…F9; no arithmetic; weakest‑link composition applies to content that depends on the signature.
• C.2.2 F–G–R: assurance calculus; CL penalties feed R, not F/G.
• Part B (Scope Bridges & CL). CL (scope congruence) and scope translation live in Part B/USM; kind‑congruence CL^k and kind mapping live in C.3.3 (KindBridge).

Non‑goals.

• No Scope semantics here (USM); no bridge semantics here (C.3.3).
• No repository/notation mandates; this is concept‑level, not tooling.

#Purpose & Audience

This pattern makes describedEntity testable in a Context:

• Authors get a place to write what defines a kind (KindSignature) and at what rigor (F).
• Reviewers can ask deterministic questions: “Given this TargetSlice, which entities are in k?”
• Managers can plan ΔF (raise signature rigor) and ΔR (evidence over members) without changing G (applicability).

No tooling assumption. The pattern is conceptual and notation‑neutral (no OWL/SHACL/type‑system requirement); it specifies reviewer‑checkable obligations that managers can read in plain language.

#Context

Different Contexts encode “type” intent differently (predicates, schemas, ontologies, Standards). Regardless of notation, a team must be able to answer, reproducibly: who belongs to the kind at this slice? If this is not stable, claims quantified over the kind are unverifiable, bridges are opaque, and composition becomes unsafe.

#Problem

1. Ambiguous membership. Membership depends on tacit “latest” states or unwritten defaults.
2. Signature opacity. A kind’s definition is scattered; no single place to declare rigor (F) or assumptions.
3. Order violations. Subkind hierarchies do not guarantee subset behavior in practice.
4. Scope leakage. Teams smuggle applicability (G) into kind definitions, recreating G‑ladders by another name.

#Forces

#Solution — Objects & Standards (overview)

• KindSignature(k) — the intensional definition of kind k in the Context; it declares U.Formality per C.2.3.
• U.EntitySet(slice) — the set (or well‑defined universe) of entities addressable in a given U.ContextSlice.
• Extension(k, slice) ⊆ U.EntitySet(slice) — which entities belong to k at slice.
• MemberOf(e, k, slice) — membership predicate: e ∈ Extension(k, slice).

Design split.

• Intent lives in KindSignature (with F).
• Extent is computed per slice via MemberOf.
• Applicability (where a claim holds) remains a Scope on the claim (USM) and MUST NOT be encoded into KindSignature.

#Norms & Invariants (normative)

IDs C3.2‑K‑03…K‑08 correspond to the rules announced in C.3; additional local rules use C3.2‑S‑*.

#Signature & Formality

C3.2‑K‑03 (Signature F). Every KindSignature(k) SHALL declare U.Formality per C.2.3 (F0…F9). — Note: Raising signature F does not automatically raise claim‑level F; claims follow weakest‑link along their own support paths.

C3.2‑K‑04 (Signature change = content change). Any change to KindSignature(k) that alters membership (i.e., would change Extension(k, slice) for some slice) SHALL be recorded as a content change (Contexts may version kinds).

#Extension & Membership

C3.2‑K‑05 (Deterministic membership). For fixed (k, slice), MemberOf(e, k, slice) MUST be deterministically evaluable from observable content in slice. — Implication: “latest” is forbidden; Γ_time must be explicit on slice (A.2.6). — If a classifier makes external assumptions, they MUST be named in KindSignature.

C3.2‑K‑06 (Monotone in ⊑). If k₁ ⊑ k₂, then for every slice: Extension(k₁, slice) ⊆ Extension(k₂, slice).

C3.2‑K‑07 (Definedness & fail‑closed). Each Context MAY restrict the domain of definedness for MemberOf(–, k, –) (e.g., only when a Standard or dataset is present at a given version). Outside that domain, MemberOf MUST be treated as not defined for guard purposes, and guards MUST fail closed (deny). Implementations MAY internally return False, but there MUST be no path where undefined membership yields implicit success.

C3.2‑K‑08 (Separation from G). Guards SHALL keep Scope coverage (USM) and membership as separate predicates: “U.ClaimScope(Claim) covers TargetSlice AND MemberOf(?, k, TargetSlice) is defined/used”.

#Entity set & time

C3.2‑S‑01 (U.EntitySet). A Context SHALL document what counts as U.EntitySet(slice) (e.g., “rows in dataset D at version v,” “live objects in service S at build b,” “ontology individuals at vocabulary v”). This documentation MUST be stable and addressable via the slice tuple. C3.2‑S‑02 (Time). slice SHALL specify Γ_time (point/window/policy). Membership MUST NOT rely on implicit recency.