#U.Kind & U.SubkindOf (Core)

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

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

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:

#Keywords

• kind
• subkind
• partial order
• type hierarchy.

#Relations

#Content

#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