#KindBridge & CL^k — Cross‑context Mapping of Kinds

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

One‑line summary. Defines KindBridge as the normative mechanism for moving kinds (their intent and selected subkind‑of links) between bounded contexts (“Contexts”). A bridge declares how a source kind maps to a target kind, which parts of the ⊑ order are preserved or collapsed, and publishes a type‑congruence level CL^k with loss notes and a definedness area. CL^k penalties apply only to Reliability (R) when a claim depends on Cross‑context classification; F (formality) and G (Claim scope) remain unchanged. Scope translation continues to use the USM Bridge + CL channel; KindBridge is a separate, parallel channel for describedEntity.

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

Depends on.

• C.3.1 — U.Kind & SubkindOf (Core): kinds are context‑local intensional objects; ⊑ is a partial order; kinds do not carry Scope.
• C.3.2 — KindSignature (+F) & Extension/MemberOf: signature declares its own F; membership MemberOf(e,k,slice) is deterministic per U.ContextSlice.
• A.2.6 — USM (Context slices & Scopes): Claim scope (G) and Work scope live on claims/capabilities; scope bridging and CL penalties are defined there.
• C.2.2 — F–G–R: weakest‑link; penalties land in R, not F/G.
• C.2.3 — U.Formality (F): signature rigor.

Non‑goals. — No repository/notation mandates; conceptual only. — No Scope mapping here (that’s USM); KindBridge maps kinds, not scopes. — No new arithmetic on CL^k; it reuses the ordinal anchor semantics of CL (Part B) but applies to kinds.

Cross‑context reuse fails in two orthogonal ways:

#Keywords

• KindBridge
• type-congruence
• CL^k
• cross-context mapping
• R penalty.

#Relations

#Content

#Purpose & Audience

Cross‑context reuse fails in two orthogonal ways:

1. Applicability (G): where the claim holds (handled by USM Scope Bridge).
2. describedEntity (Kind): what the claim quantifies over (handled by KindBridge).

C.3.3 gives managers an explicit, auditable channel for (2), so a team can say, with evidence: “Vehicle in Lab maps to TransportUnit in Plant with CL^k=2; the EV subkind collapses; here’s what we lost.” Guards stay deterministic; assurance math stays clean (penalties in R only).

#Context

Contexts use different classifications: ontology classes vs shape Standards, regulatory cohorts vs app types, etc. Informal “same‑name” reuse silently mutates describedEntity. USM already made scope moves explicit. KindBridge does the same for kinds: declare the mapping, rate its congruence, and capture known losses.

#Problem

1. Semantic drift. Moving a claim into a target‑context with a different taxonomy changes “what counts” without anyone noticing.
2. Hidden order breaks. Subkind relationships invert or vanish; downstream proofs/tests are misapplied.
3. Entangled channels. Teams conflate “scope mapping” with “kind mapping,” making it impossible to assign penalties coherently.
4. Incomputable guards. “We map it somehow” yields non‑deterministic classification at guard time.

#Forces

#Solution — The KindBridge object (overview)

A KindBridge connects source Context A and target Context B for a set of kinds. It declares:

1. Mapping of kinds: either to named target kinds or via signature translation rules.
2. Order preservation: which ⊑ links are preserved (monotone), which are collapsed, and which are unknown (not claimed).
3. Type‑congruence CL^k: reuses the same anchors/labels as CL (Part B) but applies to kind intent/order (not to Scope). Gloss: higher CL^k ⇒ closer preservation of kind intent and declared ⊑ links.
4. Loss notes: human‑readable list of invariants and subkinds not preserved.
5. Definedness area: the subset of U.ContextSlice characteristics where the mapping is intended to be used (e.g., certain Standards/versions).
6. Determinism: fixed versions + mapping rules ⇒ deterministic result (no “latest”).

Effect on assurance. When a claim in B depends on classification that goes through this bridge, reduce R by a monotone penalty Ψ(CL^k). Do not change F or G.

#Norms & Invariants (normative)

The following formalize the KB‑01…KB‑12 rules announced in C.3.

#Subject & Scope of a KindBridge

KB‑01 (Subject). A KindBridge maps:

• one or more KindSignature(s) from source to target; and
• an explicitly declared subset of ⊑ links (which it claims to preserve or collapse).

KB‑02 (No Scope). A KindBridge MUST NOT map Claim/Work scope (G). Scope translation uses the USM Bridge + CL channel (A.2.6, Part B).

No blended score. Congruence for Scope (CL) and for Kind (CL^k) MUST NOT be aggregated into a single “interoperability” score in guards; each channel is assessed and penalized separately. See Annex C.3.A §5 (E‑06).

#Declaration & Shape

KB‑03 (Declaration). A KindBridge record SHALL include:

1. source/target Contexts and vocabulary/Standard versions;
2. a kind mapping per source kind k: either a named target kind k′ or a signature translation rule that constructs the target‑context KindSignature(k′) (the result is owned and versioned in the target Context);
3. an order preservation claim for any k₁ ⊑ k₂ it covers: preserved / collapsed / unknown;
4. CL^k value (using the CL anchor ladder) labeled “kind‑congruence”;
5. loss notes (non‑preserved invariants, collapsed subkinds, equality quirks);
6. definedness area (constraints on U.ContextSlice dimensions where the bridge is meant to apply).

KB‑04 (Determinism & local evaluation). Given fixed Context versions and mapping rules, translateₖ MUST be deterministic (no implicit “latest”). After mapping to k′, membership SHALL be evaluated using the target Context’s own KindSignature(k′) and MemberOf(–, k′, –); source‑context membership results MUST NOT be reused as truth in guards (they may be cited as evidence in R).

#Order & Monotonicity

KB‑05 (Monotone order). If the bridge claims to preserve k₁ ⊑ k₂, then in the target Context translateₖ(k₁) ⊑′ translateₖ(k₂) MUST hold. KB‑06 (No inversions). The bridge MUST NOT assert preserved links that invert order. If real‑world constraints force reversal, the link MUST be marked not preserved with a loss note. KB‑07 (Collapse semantics). Marking a link as collapsed is allowed (two subkinds mapped to one target kind), but the record SHALL list the merged subkinds and any properties thereby lost.

#Congruence & Assurance

KB‑08 (Anchor reuse & AT neutrality). CL^k reuses the ordinal anchor semantics of CL (Part B) but applies to kinds. Editors SHALL label it explicitly as kind‑congruence to avoid confusion with Scope CL. KindBridge records MUST NOT compute or alter KindAT (C.3.5 AT‑04); AT is editorial and independent of CL^k. KB‑09 (Effect on R only). When a claim in the target Context depends on MemberOf(–, translateₖ(k), TargetSlice), a monotone penalty Ψ(CL^k) SHALL reduce R (alongside any Φ(CL) penalty from the Scope Bridge). Implementations MUST NOT adjust F or G due to CL^k. KB‑10 (Chaining). For a chain of bridges, effective CL^k = min of the links (weakest‑link).

#Loss Notes & Definedness

KB‑11 (Loss notes). Bridges SHALL publish human‑readable loss notes: which invariants of KindSignature are not preserved, which subkinds are collapsed, and any higher‑equality caveats (e.g., up‑to‑iso only). KB‑12 (Definedness & guard use). The bridge’s definedness area SHALL be stated. Guards MUST fail closed outside it (i.e., if a classification relies on the bridge where it is not defined, the guard denies use).

#Interactions (informative)

#With USM Scope bridges (two channels)

When using a claim across Contexts, expect two concurrent bridges:

• Scope Bridge (USM): maps G; publishes CL; penalty Φ(CL) to R.
• KindBridge (this pattern): maps kinds; publishes CL^k; penalty Ψ(CL^k) to R.

Discipline: compute both; do not collapse them into one “interoperability score.”

See Annex C.3.A §5 (E‑01) for the normative evaluation order in guards.

#With membership (C.3.2)

After mapping k to k′ = translateₖ(k), the target Context evaluates membership as usual: MemberOf(e, k′, TargetSlice). If the bridge provides a signature translation, that definition becomes the local KindSignature(k′) (versioned per target Context policy).

#With Role masks (C.3.4)

If a claim uses a RoleMask(k) across Contexts, you need:

• a KindBridge for k (CL^k + loss notes), and
• a documented mask adapter (how mask constraints translate). Penalties still land in R. If the mask’s effect is stable and widely reused, consider promoting it to a subkind on the target side.

#With guards (Annex C.3.A)

Use the Guard_XContext_Typed macro (Annex C.3.A), which requires both bridges and applies both penalties to R:

• find Scope bridge (CL≥threshold), translate G, check coverage;
• find KindBridge (CL^k≥threshold), translate kind, check membership definedness;
• apply Φ(CL) and Ψ(CL^k) to R; keep F/G untouched.

#Authoring, Review & Rating Guidance (informative)

#Authoring a KindBridge

• Start narrow & honest. Declare only the kinds and ⊑ links you actually preserve; mark the rest unknown.
• Prefer named targets. If the target already has a suitable kind, map to it; use signature translation only when necessary, and list what’s preserved vs weakened vs dropped.
• Write loss notes in plain language. Example: “EV vs ICE subkinds collapsed; battery‑health invariants dropped.”
• Fix the definedness area. Bind to target Standards/versions and any environment selectors essential to classification.
• Assign CL^k from exemplars. Calibrate on concrete counter‑examples and preserved properties; resist optimistic ratings.

#Review playbook (10 minutes)

1. Two bridges present? Scope Bridge and KindBridge?
2. Order claims honest? Any ⊑ inversions? Collapses disclosed?
3. CL^k plausible? Based on preserved properties, not name similarity?
4. Loss notes present? Will they force narrowing of Scope or extra tests?
5. Definedness area clear? Guard will fail closed outside it?
6. Penalties wired to R? No hidden tweaks to F/G?

#Rating CL^k (rules of thumb)

• High CL^k: signature equivalence or up‑to‑iso; ⊑ fragment preserved; only cosmetic losses.
• Medium CL^k: some invariants weakened; selected subkinds collapsed; order preserved on critical path.
• Low CL^k: name‑only correspondences; properties diverge; order not preserved. Expect significant R penalty and/or adapters.

#Worked Examples (informative)

#Vehicle → TransportUnit (manufacturing)

Source kind: Vehicle (K2, signature F4). target Context: PlantB, kind TransportUnit exists.

KindBridge:

• Vehicle ↦ TransportUnit; order: preserves PassengerCar ⊑ Vehicle; collapses EV ⊑ Vehicle into TransportUnit (no EV subkind).
• CL^k=2 (mid); loss notes: “battery‑health invariants not carried”; definedness: only for registryAPI v1.4, Γ_time in last 365 d.

Use: Claim quantified over Vehicle crosses to PlantB. Guards: scope bridge CL=2 (rig bias); kind bridge CL^k=2; both penalties reduce R. F/G unchanged.

#AuthenticatedRequest across services (software)

Source kind: AuthenticatedRequest defined by AuthStandard v2.3. target Context: Frontend with different auth header scheme.

KindBridge: signature translation (authHeader → x‑auth), preserves “signature valid” property; CL^k=3 (high). Loss notes: none; definedness: only where AuthStandard v2.3 is in scope.

Effect: Rules quantified over AuthenticatedRequest can be reused; R penalty small (Ψ(3) near 1). Scope remains independent (API v2.3).

#AdultPatient across jurisdictions (clinical)

Source kind: AdultPatient (≥ 18 at Γ_time). target Context: JurisdictionY uses ≥ 21.

KindBridge: AdultPatient ↦ AdultPerson_Y with boundary mismatch; CL^k=1. Loss notes: “Boundary 18 vs 21; map narrows to ≥ 21”. Guard: Require mask adapter or narrow Scope to cohorts where DOB is known and ≥ 21. R penalty strong; F/G remain as declared.

#Anti‑patterns & Remedies (informative)

#Conformance Checklist (normative)

Integration requirements with Part B (bridges):

• B‑P1. Part B (Bridges) SHALL list KindBridge as a distinct bridge class alongside USM Scope bridges.
• B‑P2. Part B SHALL state that CL^k penalties route to R via a monotone Ψ, never to F/G.
• B‑P3. Part B SHALL define chaining = min for both CL and CL^k (weakest‑link).
• Templates. ESG/Method templates should expose fields for Scope Bridge (CL) and KindBridge (CL^k) with loss notes & definedness.

#C.3.3:End