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

Pattern C.3 · Stable Part C - Kernel Extension Specifications

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.

What you get.

#Keywords

• kind
• type
• intension
• extension
• subkind
• typed reasoning
• classification
• vocabulary.

#Relations

#Content

#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