#KindSignature (+F) & Extension/MemberOf

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

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.

This pattern makes describedEntity testable in a Context:

#Keywords

• KindSignature
• intension
• extension
• MemberOf
• Formality F
• determinism.

#Relations

#Content

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

U.EntitySet(slice) MUST NOT expand implicitly via external defaults or time; its extent is fixed by the slice tuple (see C3.2‑S‑02).

#Interactions & Placement (informative)

• With C.3.1. Kinds carry identity and ⊑; no Scope on kinds. This pattern adds the intent/extent layer under those constraints.
• With A.2.6 (USM). A typed claim’s guard normally evaluates, in the order specified by Annex C.3.A §5 (E‑01): (1) typed compatibility, (2) Scope coverage at TargetSlice, (3) MemberOf(?, k, TargetSlice) definedness and any instantiation, followed by penalties to R and freshness checks. Use Guard_TypedClaim / Guard_TypedJoin rather than ad‑hoc shapes.
• With C.2.3 (F). Signature F influences claims only if the claim depends on the signature content; weakest‑link min applies along the claim’s support path.
• With C.3.3 (KindBridge). When MemberOf is computed via a kind mapping across Contexts, kind‑congruence CL^k contributes a **monotone penalty to R only (Ψ(CL^k)); F/G MUST NOT be adjusted.
• With Role‑CAL (C.3.4). A RoleMask may narrow membership (context‑local adaptation). Frequent masks that encode stable narrowing SHOULD be promoted to subkinds (⊑).

#Authoring & Review Guidance (informative)

#Authoring KindSignature

• Be explicit and observable. Prefer predicate‑like clauses over prose (“has VIN format …”; “axles ≥ 2”).
• Bind to versions. Name Standards/schemas by version; avoid “current.”
• Declare F honestly. F3 for controlled narrative is fine in early phases; aim F4+ for durable kinds; consider F7+ for safety‑critical cores.
• Name assumptions. If membership requires external conditions (e.g., calibrated rig), put them in the signature.

#Authoring membership

• Define U.EntitySet(slice). Write it down once per Context, make it addressable via the slice tuple, and reuse.
• Determinism first. No hidden IO, no implicit time; membership must be recomputable from the slice.
• Document definedness. If MemberOf is undefined without a Standard, say so; guards will fail closed.
• Respect ⊑. If you declare k₁ ⊑ k₂, verify subset behavior (C3.2‑K‑06).

#Review checklist (10 minutes)

1. Is signature F declared? Is the signature sufficient to evaluate membership?
2. Is U.EntitySet(slice) documented and addressable?
3. Is membership deterministic with explicit Γ_time (no “latest”)?
4. If ⊑ links exist, does subset behavior hold at sample slices?
5. Are Scope and membership kept separate in guards?
6. Any Cross‑context classification? If yes, is KindBridge referenced (C.3.3)?

#Worked Examples (informative)

#Vehicle (signature F4) and membership

KindSignature(Vehicle) (F4):

• hasVIN(x) is true and parseable;
• axles(x) ≥ 2;
• hasBrakeSystem(x);
• Standards: registryAPI v1.4; Γ_time policy: rolling 365 d for registry fields.

U.EntitySet(slice): “records in registryAPI v1.4 for plant A at build b, as of Γ_time.” Extension(Vehicle, slice): all records satisfying the predicates in that slice. Monotonicity: PassengerCar ⊑ Vehicle ⇒ Extension(PassengerCar, s) ⊆ Extension(Vehicle, s).

#AuthenticatedRequest (definedness & fail‑closed)

KindSignature(AuthenticatedRequest) (F4):

• Request with authHeader present and authSignature valid according to AuthStandard v2.3;
• Γ_time: point in time for key validity check.

Definedness: MemberOf(–, AuthenticatedRequest, slice) is undefined if AuthStandard v2.3 is absent in slice ⇒ guards fail closed (C3.2‑K‑07).

#Clinical cohort (low‑F signature; deterministic membership)

KindSignature(AdultPatient) (F3→F4 as it hardens):

• ageYears(x, Γ_time) ≥ N (jurisdictional N varies; recorded in the Context’s signature note).
• EntitySet(slice): EHR ehr‑east v7.5 @ Γ_time;
• Membership deterministic if DOB present; undefined otherwise (fail closed).

#Anti‑patterns & Remedies (informative)

#Rationale (informative)

#Why give F to KindSignature?

Because rigor in the definition of a kind materially affects how safely teams can quantify over it. A signature at F4 (predicate‑like) makes membership checkable in principle; F7+ (machine‑checked) can support proof‑carrying development. Keeping this separate from claim‑level F prevents “signature formalization” from inflating unrelated claims.

#Why Extension is not Scope

• Extension answers: “Which entities count as k in this slice?”
• Scope (G) answers: “In which slices does this claim hold?” Blending the two recreates the old failure mode where “more abstract wording” was treated as “wider applicability.” USM already gives the set‑algebra for G; Kind‑CAL supplies the typed universe the claim quantifies over.

#Why determinism and fail‑closed?

Guards must be reproducible and auditable: same slice ⇒ same membership result. If inputs are missing (undefinedness), the safest default is deny (fail closed), prompting either a richer slice or a scope/claim change.

#Conformance checklist (normative)

#C.3.2:End