#KindAT — Intentional Abstraction Facet for Kinds (K0…K3)

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

One‑line summary. Defines KindAT as an informative facet attached to U.Kind that classifies the intentional abstraction stance of a kind—K0 Instance, K1 Behavioral Pattern, K2 Formal Kind/Class, K3 Up‑to‑Iso—to guide ΔF/ΔR planning, bridge expectations, catalog/search, and refactoring. KindAT is not a Characteristic: it has no algebra, no thresholds, and MUST NOT appear in guards or composition math. All assurance remains in F–G–R; typed semantics remain in C.3.1–C.3.4.

Status. Mixed: — Informative for the anchors, heuristics, examples, and guidance. — Normative for the usage rules that forbid employing AT in guards/composition and constrain its placement.

Placement. Part C (Kinds), identifier C.3.5. Audience: engineering managers, architects, editors, assurance leads.

Depends on. — C.3.1 (U.Kind, U.SubkindOf (⊑)), C.3.2 (KindSignature + F, Extension/MemberOf), C.3.3 (KindBridge + CL^k), C.3.4 (RoleMask). — A.2.6 USM (Claim/Work scope over U.ContextSlice), C.2.2 F–G–R, C.2.3 U.Formality (F). — MM‑CHR distinction Facet vs Characteristic (editors).

Non‑goals. — No numerical scale, no gating, no composition operators, no “quality” scoring. — No effect on F, G, or R besides planning hints.

Teams constantly decide how far to formalize and how broadly to validate:

#Keywords

• KindAT
• abstraction tier
• K0-K3
• informative facet
• planning.

#Relations

#Content

#Purpose (manager’s view)

Teams constantly decide how far to formalize and how broadly to validate:

• Are we speaking about this cohort (instances), about things that behave like X (pattern), about a formal class with invariants, or about objects up to isomorphism?
• Given that stance, should we invest in F4 predicates, F7 proofs, or R across variants?
• What kind of KindBridge is realistic (coarse mapping vs up‑to‑iso), and what CL^k should we expect?

KindAT answers these with a small, shared vocabulary (K0…K3) that is safe to use (cannot distort F/G/R) yet actionable for planning and catalog/search.

#Context & Rationale

#The orthogonality we preserve

• G (Claim scope) is where a claim holds (A.2.6).
• Kinds give what a claim is about (C.3.1/3.2).
• R is assurance (evidence, freshness, penalties).
• F is expression rigor (C.2.3).

Teams often conflate abstraction with applicability (“sounds general ⇒ applies broadly”) or over‑engineer proofs where slice‑checks suffice. AT separates these concerns.

#Why a facet, not a Characteristic

Per MM‑CHR, Characteristics (e.g., F, G) carry algebra and appear in guards/composition. KindAT is only a tag on U.Kind:

• No algebra, no thresholds, not used in guards.
• Editorial placement only: on kinds, not on claims.
• Planning signal: what ΔF and ΔR typically pay off; what bridge style to expect.

This keeps AT useful without risking a “second G” or back‑door quality scores.

#Design choice recap (moved from C.3 §15.2)

• Making AT a Characteristic would duplicate G’s role and encourage gating.
• As a facet, AT remains a catalog/navigation and planning device, not an assurance dimension.

#Anchors K0…K3 (informative)

How to read. Each anchor states the intentional stance of the kind, inclusion cues, non‑examples (to prevent misuse), and planning hints (ΔF/ΔR/bridge expectations). Anchors are context‑local editorial tags on U.Kind.

#K0 — Instance‑level

Intent. The kind denotes exemplars or a tightly curated set; often a named cohort or a concrete template. Cues. Membership relies on listing or direct identity features; little to no general invariants. Non‑examples. Any kind with stable, general invariants belongs in K2. Planning hints. Focus R on TargetSlice (executable checks, F5/6); avoid premature proof engineering. Bridges are instance‑maps; expect low CL^k outside the Context.

#K1 — Behavioral Pattern

Intent. The kind is a role/behavioral pattern (“things that act like …”), typically stated via Standards or controlled NL, not a full type. Cues. “Duck‑typing” flavor; Standards reference behavior/state transitions. Non‑examples. If you can state global invariants as predicates, consider K2. Planning hints. Invest in F3→F4 (predicate‑like acceptances); R must test behavioral diversity; bridges are pattern maps with moderate CL^k.

#K2 — Formal Kind/Class

Intent. A formal class with explicit invariants/relations (ontology class, type with Standards). Cues. Predicate‑like signature, subkind lattice, invariants reviewed. Non‑examples. Pure examples/cohorts (K0); informal roles (K1). Planning hints. Raise KindSignature F to F4+, consider F7 for safety‑critical cores; R should cover subkinds/variants; bridges are type‑maps, CL^k often medium/high.

#K3 — Up‑to‑Iso

Intent. Defined up to isomorphism/equivalence (category‑theoretic flavor; “equal as structure,” not by identity); equality‑as‑structure matters. Cues. Statements invariant under isomorphism; reasoning by equivalence classes. Non‑examples. Classes where identity matters beyond structure. Planning hints. Expect up‑to‑iso bridges; CL^k can be high where equivalence is respected. F7–F9 likely for key properties; R focuses on witnesses of equivalence at interfaces.

#Manager Heuristics (informative)

#Misuse & Antidotes (informative)

• “Higher AT ⇒ wider G.” Wrong. G changes only via ΔG (USM). AT does not alter scope.
• “Gate on AT.” Wrong. Use F thresholds and scope/evidence guards; AT is never a gate.
• “Depth in ⊑ ⇒ AT.” Wrong. AT is about intentional stance, not graph depth.
• “AT on claims.” Wrong. AT tags U.Kind only.
• “AT as quality score.” Wrong. Use F and R for rigor/reliability.

#Usage Rules (normative)

These are the only normative constraints in this pattern. Everything else is guidance.

AT‑01 (Facet, not Characteristic). KindAT SHALL be treated as a Facet per MM‑CHR: it has no algebra, no thresholds, and MUST NOT appear in guards or composition math.

AT‑02 (Placement). If recorded, KindAT SHALL be attached to U.Kind (or its catalog card). It MUST NOT be attached to claims/capabilities or used as a proxy for G/F/R.

AT‑03 (Editorial discipline). Editors SHALL NOT write text implying “higher AT widens scope” or “higher AT increases rigor/reliability.” Any such text MUST be revised to reference ΔG/F/R explicitly.

AT‑04 (Bridge neutrality). KindBridge records MUST NOT compute or adjust AT; they may include informative remarks about likely anchor alignment. CL^k is independent of AT and is assessed from signature/order preservation.

AT‑05 (Catalog). Contexts that use AT SHOULD record it in Kind catalog entries alongside: signature snippet & F, subkinds, RoleMasks, KindBridges. Absence of AT implies “not set”, not K0.

#Authoring & Review Guidance (informative)

#How to tag (fast rubric)

• If the card lists concrete items/cohorts, tag K0.
• If the card defines behavioral obligations in prose/templates but few global invariants, tag K1.
• If the card states predicates/invariants and participates in a subkind lattice, tag K2.
• If the card explicitly reasons up to isomorphism, tag K3.

#Review checklist (5 minutes)

1. Is the carrier a U.Kind (not a claim)?
2. Does the tag match the signature (intent)?
3. Are ΔF/ΔR implications noted for planning (not gating)?
4. Any RoleMasks that should be promoted to subkinds (K2 hygiene)?
5. Any Cross‑context reuse that suggests bridge style (pattern/type/iso)?

#Integration Notes (informative)

• With C.3.1/3.2 (Kinds, Signature, Extension). AT guides how to evolve signature F and what R coverage is sensible; it does not change membership semantics.
• With C.3.3 (KindBridge). AT hints at likely bridge style (instance‑map / pattern‑map / type‑map / up‑to‑iso), but CL^k is still computed from signature/order preservation; penalties route to R.
• With C.3.4 (RoleMask). Persistent K1‑style masks often warrant promotion to K2 subkinds.
• With A.2.6 (USM). All scope decisions remain under G. AT text should never be used to infer coverage.
• With C.2.3 (F). AT does not raise/lower F; it suggests where raising F is cost‑effective.

#Worked Mini‑Examples (informative)

• K0 (Instance). Account_US_GAAP_2025_Q1_Cohort. Plan R slice checks; avoid type‑maps across Contexts.
• K1 (Behavior). CacheableRequest (“idempotent under retry; cache key well‑formed”). Raise F3→F4; design R for failure‑mode diversity; expect pattern bridges.
• K2 (Formal). Account with invariants (balance = debits−credits; posting rules). Raise F4+; plan R over Asset/Liability subkinds; bridge via type maps.
• K3 (Up‑to‑Iso). UndirectedGraph up to node relabeling. Expect up‑to‑iso bridges; proofs at F7+; R checks interface equivalence witnesses.

#Conformance Checklist (normative)

#C.3.5:End