#KindBridge and CL^k — Cross-local Correspondence between Distinct Kinds

C.3.3 · Cluster C.I - Core CALs / LOGs / CHRs · Stable · Part C - Kernel Extension Specifications

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

One-line summary. A changed practice, source, team, or scheme first triggers a comparison of kind definitions. If the same kind continues, reuse it and evaluate the receiving candidate afresh; no KindBridge is needed. When two independently identified kinds are distinct and a directional correspondence predicate holds, one KindBridge direct relation may obtain. A separate bridge-assertion episteme states direction, paired declaration editions, preservation or loss, CL^k, evidence, and admitted use. It never transfers source classification truth.

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

Depends on.

• C.3.1 — U.Kind and U.SubkindOf: kind identity follows candidate domain and membership distinction; subkind facts form a preorder; locality and scheme editions are not identity keys.
• C.3.2 — Kind intent, admissibility, judgment, and extension: check admissible | not-applicable before a fresh true | false | unknown receiving judgment.
• A.2.6 — USM: Claim scope and selected context slices remain separate from kind identity and kind correspondence.
• C.2.2 — F–G–R: justified bridge penalties affect reliance R, not F or G.
• C.2.3 — U.Formality: formality belongs to the declaration or assertion episteme.

Non-goals. No repository or notation mandate. No Scope mapping here. No bridge from a locality change alone. No transfer of classification truth. CL^k reuses an ordinal congruence anchor for a declared kind-correspondence use without becoming a universal interoperability score.

Typed reuse can fail because a claim's scope changed, because the receiving use employs another kind, or because wording changed meaning. These are separate questions. C.3.3 handles only a claimed directional correspondence between two distinct kind individuals. It lets a team state, for example, that source Vehicle corresponds to target TransportUnit, which distinctions are preserved or collapsed, and what loss a receiving use accepts.

#Relations

#Content

#Purpose and Audience

Typed reuse can fail because a claim's scope changed, because the receiving use employs another kind, or because wording changed meaning. These are separate questions. C.3.3 handles only a claimed directional correspondence between two distinct kind individuals. It lets a team state, for example, that source Vehicle corresponds to target TransportUnit, which distinctions are preserved or collapsed, and what loss a receiving use accepts.

#Context

Different sources or practices may use the same kind, or different kinds may coexist inside one source. Names, source labels, compatible schemes, and matching current extensions decide neither. First compare the candidate domains and membership distinctions under C.3.1. Same-kind reuse needs no bridge. Distinct-kind reuse may need a KindBridge when its exact correspondence predicate can be established. F.9 is additional only when distinct local senses and their bounded use are current.

#Problem

1. False splitting. A locality change creates two apparent kinds and a bridge even though the membership distinction is unchanged.
2. Semantic drift. A genuinely different receiving kind is treated as the source kind because names or extensions look alike.
3. Hidden order loss. Subkind facts collapse, invert, or become unsettled without being reported.
4. Entangled channels. Scope, sense, and kind correspondence are bundled into one score or record.
5. Classification transfer. A source judgment is copied as receiving truth without checking receiving admissibility and criterion satisfaction.
6. Unreplayable use. An unspecified mapping or implicit latest edition leaves a guard with no stable basis for deciding whether the bridge use is current.

#Forces

#Solution — Compare Identity, Then Relate Distinct Kinds

1. Compare kind definitions. Recover source and receiving candidate domains, membership distinctions, and continuity rules. A changed locality or scheme prompts this check; it does not decide it.
2. Stop on same-kind reuse. If the same kind continues, use the declaration edition selected for the receiving use, check admissibility, and evaluate the candidate afresh. No KindBridge obtains merely because source, practice, team, wording, or scheme changed.
3. Open a bridge only for two distinct kinds. A KindBridge occurrence is an obtaining direct relation between one exact source kind and one exact target kind. Its directional predicate states the correspondence and definedness required by the named receiving use. Identify each kind independently under C.3.1.
4. Keep the assertion separate. A C.2.1 bridge-assertion episteme designates the relation when needed and carries paired KindSignature editions, mapping rule, selected order-preservation results, CL^k, loss notes, evidence, and admitted use. A card, row, F.9 relation, or publication does not make the bridge obtain.
5. Evaluate the receiving candidate. First return admissible or not-applicable under the receiving signature and slice. Only an admissible request returns true, false, or unknown. A source judgment may support the bridge assertion or reliance but is never copied as receiving truth.
6. Route consequences narrowly. When a receiving claim relies on the obtaining bridge and fresh receiving result, apply only the justified CL^k consequence to R. Scope and any sense relation retain their own objects and rules; F and G do not change.

The kinds are the direct relation participants. Scheme and signature editions qualify interpretation, applicability, and the assertion. They do not identify the occurrence. For the ordered kind pair, the direct relation is participant-determined. An aligned scheme-edition change prompts reevaluation of whether the same relation still obtains; it does not mint another occurrence.

KindBridge is the direct relation kind governed here under A.6.REL. This spelling does not by itself admit a public dependent U-kind named U.KindBridge. If admission later matters, E.24.UK must close it separately.

#Norms & Invariants (normative)

The KB‑01…KB‑12 rules below govern kind correspondence.

#Direct Relation Subject and Scope

KB-01 (Distinct participants and obtaining). One KindBridge occurrence has exactly two ordered participants: an independently identified source kind and an independently identified distinct target kind. It obtains only when its directional correspondence predicate holds within declared definedness. A different locality, label, scheme, or extension supplies no bridge. Signatures, assertions, evidence, CL^k, loss notes, and slices are not participants.

KB-02 (No Scope or sense substitution). A KindBridge maps neither Claim/Work scope nor local wording. Scope translation uses A.2.6 when the receiving claim actually consumes it. An F.9 relation is added only for a current distinct-sense use. Neither channel is required merely because a kind bridge exists.

No blended score. Scope congruence, sense-relation loss, and kind congruence remain separate. Do not aggregate them into one interoperability score.

#Settlement, Assertion, and Identity

KB-03 (Direct settlement). The C.3.3 settlement SHALL make recoverable:

1. exact ordered source-kind and target-kind participants and the proof that they are distinct;
2. the directional correspondence predicate, applicability, and definedness; and
3. participant-determined occurrence identity for that ordered pair.

The separate bridge assertion states whether obtaining is affirmed, denied, or unresolved; only an affirmative assertion may designate an obtaining occurrence. It also names the declaration and scheme editions used to interpret the predicate, selected source and target subkind facts, preservation/collapse/non-preservation/unknown results, CL^k, loss, evidence, and admitted use. Another assertion, mapping expression, card, signature, scheme edition, or publication does not create another relation occurrence. A changed interpretation prompts a renewed obtaining test. If the same ordered participants and correspondence continue, the same relation continues; if not, the prior obtaining claim is no longer current.

KB-04 (Fresh receiving classification). With fixed receiving candidate, signature edition, and slice, check admissibility first. not-applicable forms no classification judgment. An admissible request is evaluated reproducibly as true, false, or unknown. A source judgment or bridge assertion may support reliance but is never copied into the receiving result. An unavailable bridge dependency blocks that bridge use without rewriting an independently evaluated receiving result.

#Order & Monotonicity

KB-05 (Monotone order). If a bridge assertion states that source order fact SubkindOfObtains(k1, k2; sourceRS) is preserved, it SHALL designate exact target kinds k1' and k2', the respective obtaining KindBridge relations from k1 to k1' and from k2 to k2', and the basis on which SubkindOfObtains(k1', k2'; targetRS) holds. Identify a target R_sub : U.SubkindOf occurrence only when a receiving use needs occurrence identity. KB-06 (No inversions). A bridge assertion MUST NOT state preservation when the mapped target order is inverted. If SubkindOfObtains(k2', k1'; targetRS) holds for distinct mapped kinds and the required forward fact SubkindOfObtains(k1', k2'; targetRS) is established not to hold, state non-preservation and the exact loss. If the required target order cannot be settled, state unknown; do not turn non-settlement into either preservation or inversion. KB-07 (Collapse semantics). A bridge assertion may classify selected source subkind distinctions as collapsed when several source kinds correspond to one target kind. The assertion SHALL designate the affected obtaining U.SubkindOf relations and state the lost properties; the direct bridge relation does not alter either local order.

#Congruence & Assurance

KB-08 (Anchor reuse and AT neutrality). CL^k reuses the ordinal anchor semantics of CL but assesses the declared bridge use over kind intent and order. The bridge-assertion episteme labels it kind-congruence. KindAT remains editorial under C.3.5 and independent of CL^k. KB-09 (Effect on R only). After receiving admissibility has been checked and an admissible candidate has received a fresh target judgment, a claim that relies on both that result and an obtaining KindBridge may apply only the bridge assertion's justified monotone Ψ(CL^k) consequence to R, alongside any independently established scope-relation consequence. A not-applicable candidate forms no judgment; unknown stays unknown; F and G do not change. KB‑10 (Chaining). For a chain of bridges, effective CL^k = min of the links (weakest‑link).

#Loss Notes & Definedness

KB-11 (Loss notes). The bridge-assertion episteme SHALL state which KindSignature invariants are not preserved, which obtaining source U.SubkindOf relations are collapsed or not preserved, and any higher-equality caveats. These claims do not rewrite the source or target kinds. KB-12 (Definedness and guard use). The bridge predicate and assertion SHALL state definedness. Outside it, a receiving guard declines that bridge use. Independently, receiving classification keeps not-applicable or its admissible true, false, or unknown result; bridge inapplicability rewrites none of them.

#Interactions (informative)

#With Scope and Sense Relations

A receiving use may need none, one, or several independent relations:

• an A.2.6 scope relation when the claim's admitted extent is translated or compared;
• a C.3.3 KindBridge when two distinct kinds are directionally related; and
• an F.9 relation when distinct local senses are related for a bounded use.

Open only the channels the receiving claim consumes. Keep their definedness, losses, and R consequences separate.

#With Receiving Classification

After same-kind reuse or an obtaining bridge, use the receiving KindSignature edition. Check candidate and slice admissibility. If admissible, evaluate the exact receiving judgment. If a mapping motivates another signature, author that declaration episteme separately. A source judgment can support a claim but never supplies receiving truth.

#With Kind-use Adaptations

For same-kind reuse, select the receiving C.3.4 declaration and evaluate afresh without a bridge. For distinct-kind use, recover the obtaining KindBridge, bridge assertion, receiving adaptation declaration, and any exact adaptation-correspondence declaration needed for differing constraints or bindings. Source adaptation results are not receiving truth.

#With Guards

A typed receiving guard first determines whether the same kind continues or a distinct-kind bridge is current. It then checks receiving admissibility and, when admissible, the fresh judgment. It independently checks any scope or sense relation the claim consumes and applies only justified consequences to R. not-applicable, unknown, absent bridge, and guard refusal remain different results.

#Authoring, Review & Rating Guidance (informative)

#Authoring a KindBridge assertion

• Compare identity before authoring a bridge. For a changed locality, source, team, spelling, or scheme, first repeat the kind-definition comparison under C.3.1. Stop without a bridge when the same kind continues.
• Start narrow and honest. For two distinct kinds, declare only the directional correspondence and subkind facts the receiving use actually relies on; mark any required but unsettled order result unknown.
• Prefer an existing suitable target kind. If the target already has a suitable kind and declaration edition, relate that kind directly. If a new target declaration is required, author it separately before asserting bridge obtaining; list what the mapping predicate preserves, relaxes, or drops.
• 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. Identity checked first? Same kind reused without a bridge, or two distinct kinds and the obtaining correspondence shown? Add Scope or F.9 relations only when the receiving use consumes them.
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 relaxed or lost; selected subkinds collapsed; order preserved on critical path.
• Low CL^k: name‑only correspondences; properties diverge; order not preserved. Establish that the KB-01 correspondence predicate holds before bridge use, even for a name-only match. Expect significant R penalty and/or adapters.

#Worked Examples (informative)

#Vehicle → TransportUnit (manufacturing)

Source kinds Vehicle and PassengerCar, target kinds TransportUnit and PassengerTransportUnit, and their exact declaration editions are independently identified. One KindBridge relation obtains from Vehicle to TransportUnit and another from PassengerCar to PassengerTransportUnit under the pinned scheme editions. The bridge assertion states that source fact SubkindOfObtains(PassengerCar, Vehicle; sourceRS) is preserved by target fact SubkindOfObtains(PassengerTransportUnit, TransportUnit; targetRS), while the EV distinction is collapsed; it records CL^k=2, the lost battery-health invariants, and definedness limited to registryAPI v1.4 in the selected time window. A candidate is first checked for admissibility and, if admissible, then classified by the exact receiving declaration; source classification is not copied. If the receiving claim also relies on an independently established scope translation, that relation's consequence remains separate from the kind-bridge consequence; the kind-bridge consequence leaves F and G unchanged.

#Same AuthenticatedRequest kind across services — no bridge

Frontend and gateway services use the same AuthenticatedRequest kind: the candidate request domain, signature-validity condition, and intended member/non-member distinction are aligned. Each service uses its selected declaration edition and evaluates the request afresh. The gateway spelling x-auth may require a C.3.4 vocabulary binding when that wording use is relied on; an F.9 sense relation is added only if that use also needs a relation between distinct local senses. The service boundary and spelling alone create neither another kind nor a KindBridge.

#AdultPatient across jurisdictions (clinical)

The obtaining bridge relates source kind AdultPatient to independently identified target kind AdultPerson_Y. Its assertion gives CL^k=1, states the 18-versus-21 boundary loss, and limits definedness to the declared jurisdictional editions. The target classification uses its own signature edition. For an admissible candidate, missing DOB support yields unknown; a mask adapter or narrower Scope may support a later use, while the guard's refusal and R penalty remain separate from target truth.

#Anti‑patterns & Remedies (informative)

#Conformance Checklist

Integration requirements with Part B. Part B distinguishes the C.3.3 kind-correspondence channel from scope and F.9 sense channels, routes justified CL^k consequences to R, and retains weakest-link chaining. Templates designate exact relied-on relations and assertions; their fields create none of them.

#C.3.3:End

---

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)