#Alignment & Bridge across Contexts

F.9 · Stable · Part F - The Unification Suite (U-Suite): Concept-Sets, SenseCells & Contextual Role Assignment

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

“Translate across Contexts; never collapse them.” Type. Architectural pattern. Status. Stable. Normativity. Normative. Builds on: E.10.D1 (Context discipline: Context = U.BoundedContext); F.0.1 (senseFamily & StatusModality guard; Bridge-only crossing); F.1 (Contexts fixed); F.2/F.3 (Cells exist); F.7 (rows depend on Bridges); F.8 (thresholds and reuse choice).

Coordinates with: B.3 Trust & Assurance Calculus (uses CL penalties); A.6.1 U.Mechanism (Transport clause for cross-context use; penalties route to R/R_eff only; F/G invariant); Part C patterns (apply Bridges in formal claims); A.6.9 (RPR-XCTX for repairing umbrella “same/equivalent/align/map” prose into explicit Bridge Cards). Aliases (informative). Context-to-Context translator; Sense bridge.

Intent. Provide a conceptual discipline for relating SenseCells from different Contexts (U.BoundedContext). A Bridge states what kind of relationship holds, how far it holds (via CL: Congruence Level), and what is lost during the translation. Bridges support carefully scoped reuse (e.g., a Concept-Set row) while rejecting silent equivalence.

#Keywords

• bridge
• cross-context alignment
• CL
• direction
• loss notes
• supported use
• bridge reading
• weakest-link scope
• state export.

#Relations

#Content

#Intent & applicability

Intent. Provide a conceptual discipline for relating SenseCells from different Contexts (U.BoundedContext). A Bridge states what kind of relationship holds, how far it holds (via CL: Congruence Level), and what is lost during the translation. Bridges support carefully scoped reuse (e.g., a Concept-Set row) while rejecting silent equivalence.

Applicability. Use whenever an author needs to read across Contexts—to reuse a familiar label, to connect design-time and run-time notions, to compare two standards’ terms, or to justify a row in the Concept-Set table. This pattern is not storage, enactment protocol, or governance; it codifies thinking moves.

Non-goals. No global meaning; no PublicationSurface semantics; no editor roles. Bridges are semantic relations between local senses, not transport chains, not processes. Governed object in plain terms. One bridge card relating two SenseCells across different U.BoundedContexts; not a transport chain, not a workflow, and not one global meaning layer. Governing move in plain terms. Declare relation kind, direction, CL, and loss between local senses so cross-context reading stays inspectable without collapsing them into silent equivalence. Primary working reader. The primary working reader is an author, checker, or practitioner preparing one bridge card, one comparative mapping note, or one concept-set row that depends on cross-context reading without pretending the contexts have already collapsed. Use this when. Use this pattern when two local senses from different contexts need one explicit bridge card before a team can lawfully reuse a label, justify a row, or compare the cases without pretending they are simply the same thing. Start here when. The same term, role, quality, or status label appears in more than one context and the team is about to treat that overlap as if it were already equivalence, safe substitution, or structure-preserving reuse. What goes wrong if missed. Teams fall back to shared labels, string-equals shortcuts, or informal analogies, then quietly smuggle equivalence, substitution, or structure across contexts without publishing relation kind, strength, or loss. What this buys. One explicit bridge discipline that lets a team reuse names, compare contexts, and publish bounded cross-context support without losing track of direction, loss, and the limits of lawful substitution. Not this pattern when. Not this pattern when the case is still only a weaker source-pinned rendering with no bridge claim yet, or when the real job is storage, enactment, governance, or one single local context rather than explicit cross-context alignment.

Boundary to controlled coarsening. This pattern is also the explicit boundary pattern when a simplified or weakened cross-context rendering starts to imply equivalence, substitution, projection, or interoperability scope. If the case is still only a weaker source-pinned rendering for narrower use, keep it with that rendering's own source tether, unsupported-use line, and reopen path, using A.6.3.CSC Controlled Semantic Coarsening when that weaker-use card is primary. A lighter cross-context note may support informal orientation talk, but that is not a formal F.9 Naming-only row. Any bridge, substitution, row, or interoperability claim must reopen the stronger source-bearing material before a Bridge Card may be published under F.9. Recognition vs assurance note. Read Intent, Applicability, Non-goals, and the A.6.3.CSC neighbor boundary above as the ordinary recognition block. Read Bridge kinds, CL, conformance, and Relations below as assurance blocks that tighten the same bridge-card claim; they do not widen the pattern into transport, workflow, or one global meaning layer.

#Problem frame

Cross-context work fails in predictable ways:

1. String-equals fallacy. Identical surfaces (“process”, “role”, “accuracy”) taken as identical meaning.
2. Scope creep. A naming convenience is stretched to assignment or structural claims.
3. DesignRunTag jumping. Design artefacts are substituted for run-time occurrences (or vice-versa).
4. Direction amnesia. Narrower/broader relations treated as symmetric.
5. Loss blindness. Differences (units, granularity, preconditions) are left unstated, contaminating downstream reasoning.

Bridges cure these by making relation, direction, loss, and strength explicit.

#Forces

#Core idea (didactic)

A Bridge is a declared translator between two local senses. It always names (a) the two SenseCells, (b) a Bridge kind (what relation), (c) a direction (if non-symmetric), (d) a CL (how strong), and (e) Loss Notes (what fails to carry). Some Bridges support substitution in limited scopes; others support only explanation.

#Minimal vocabulary (this pattern only)

• Context — shorthand for U.BoundedContext (per E.10.D1).

• SenseCell - the pair (Context, Local-Sense) from F.3.

• Bridge — a conceptual relation between two SenseCells with kind, direction, CL, and loss notes.

• CL (Congruence Level) — ordinal strength (0…3) of a Bridge (see §7).

• Scope — the supported use of a Cross-context reading (as in F.7/F.8):

• Naming-only (talk consistently),

• Role Assignment & Enactment-eligibility (assignable constraints/roles/status reuse),

• Type-structure (safe structural inference).

• senseFamily — the semantic category (Role, Status, Measurement, Type-structure, Method, Execution…) per F.0.1 (normative Part F guard).

#Bridge kinds (senseFamily-aware)

Two families of Bridges: Substitution Bridges (senseFamily-preserving; can support Concept-Set rows) and Interpretation Bridges (explanatory; not for substitution).

#Substitution Bridges (sense-preserving)

These relate SenseCells of the same senseFamily and may support limited substitution:

1. Equivalence - near-identity of sense. Symmetric. Rare. Use: May support Type-structure rows when CL=3 and invariants match. Loss Notes: usually “none” or “profiling differences”.

2. Narrower-than / Broader-than - proper inclusion of sense. Directional. Use: Safe to substitute narrower > broader in Naming-only and sometimes Role Assignment & Enactment; broader > narrower is unsafe. Loss Notes: “loses special cases X”.

3. Partial-overlap - non-empty intersection, neither includes the other. Use: Naming-only at best. Never justifies Role Assignment & Enactment / Type-structure. Loss Notes: “A-only senseFamily”, “B-only senseFamily”.

4. Disjoint - explicit contrast. Use: For didactic warnings; not reuse support. Loss Notes: n/a (it asserts incompatibility).

#Interpretation Bridges (cross-senseFamily, explanatory)

These do not support substitution but explain connections across senseFamilies:

5. Design-spec -> Run-trace - a design concept relates to its run-time occurrence. Example: BPMN:Process -> PROV:Activity. Use: Explain design-to-execution correspondence. No Concept-Set rows. Loss Notes: “graph vs event”, “control-flow vs temporal extent”.

6. Measure-of / Evidence-for (->) — a measurement SenseCell evidences or quantifies another senseFamily (e.g., a Requirement clause). Example: SOSA:Observation -> ITIL:SLO fulfilment. Use: Explain evaluation. No substitution.

7. Policy-implies / Obliges (->) — a deontic statement constrains another senseFamily. Example: ODRL:Duty -> Service behaviour. Use: Explain constraint propagation.

Rule of thumb. If you want rows or substitution, you need a Substitution Bridge on the same senseFamily. If you want to explain why artefacts relate without claiming sameness, use Interpretation Bridges.

#CL scale and scope thresholds

CL expresses how safely meaning carries over.

• Thresholds (normative):

  • Publishing a Naming-only row requires CL >= 1 across the row's Cells.
  • Publishing a Role Assignment & Enactment-eligible row requires CL >= 2, the same senseFamily, and compatible stance.
  • Publishing a Type-structure row requires CL = 3 and matched invariants (acyclicity, anti-symmetry, units, etc.).

• Penalty use (informative): B.3 may convert CL into an assurance penalty when a cross-context claim is made.

#The Bridge Card (compact sketch)

A thought-format (not a form). Every bullet can be said in a sentence.

• Cells. A@contextA - B@contextB.
• senseFamily. Role / Status / Measurement / Type-structure / Method / Execution …
• Kind. Equivalence / Narrower-than / Broader-than / Partial-overlap / Disjoint / Design-spec -> Run-trace / Measure-of / Policy-implies.
• Direction. A -> B (if non-symmetric) or A <-> B.
• CL. 0–3 with a short why.
• Loss Notes (bullets). What fails to carry (units, scope, granularity, preconditions, time stance).
• Counter-example. The crispest case where substitution would mislead.
• Supported use. Naming-only / Role Assignment & Enactment-eligible / Type-structure / Explanation-only.
• Didactic hook. The helpful sentence a careful engineer can remember.

If it does not fit on a screen, you are describing the Contexts, not the Bridge.

Registry-reference note (normative). BridgeId and any policy/edition identifiers cited by a Bridge Card are registry references (keys into registries), not semantic symbols exported by signatures. Therefore they MUST NOT be demanded via SignatureManifest.provides (or "satisfied" via imports closure); conformance is checked by validating that the referenced registry entries exist and, where required, are edition-pinned (see F.15).

#State export and quantum-like route note

Use F.9 first when meaning, label, relation, field, record, model output, report, or representation crosses a bounded context or publication plane. A bridge does not become quantum-like because it is lossy, approximate, contextual, or hard to translate. It becomes quantum-like only when the bridge/export claim still depends on order sensitivity, incompatible frames, a probe that changes the represented state, or no faithful-enough export supports the intended use.

Action path:

1. Build the ordinary Bridge Card first: cells, sense family, kind, direction, CL, loss notes, counter-example, and supported use.
2. Ask what state, relation, evidence, metric, option, or viability reading is claimed to survive the crossing.
3. State what the crossing omits, coarsens, re-keys, reframes, makes incomparable, or makes unsafe for stronger use.
4. If the bridge or export claims to preserve action, intervention, manipulation, explanation, or cross-level structure, state the causal-abstraction or approximate-causal-abstraction mapping before treating the coarsened bridge as a QL issue.
5. Ask whether asking, measuring, exporting, rendering, or bridging changes the represented state itself. If yes, coordinate with C.26.1.
6. Ask whether coordinated work or live state is not exported faithfully enough for the intended use by any one report or bridge. If yes, coordinate with C.26.2.
7. Ask whether the crossing is a weakened state representation. If yes, coordinate with CSC/RT and the C.26 coarsening support section.
8. State supported use and return-to-source trigger before the bridge result is reused.

Add this row to the Bridge Card only when the bridge result will be reused for decision, comparison, assurance, release, audit, or cross-context action. For a local orientation note, state the export loss and return-to-source trigger in prose without treating the note as a Bridge Card extension.

Useful outputs:

• an ordinary Bridge Card when translation/loss is the whole issue;
• a C.26.1 note when the export/probe changes represented state;
• a C.26.2 note when coordinated state has no faithful-enough export for the intended use;
• a CSC/RT/C.26 coarsening route when the exported representation is intentionally weaker.

#Invariants (normative)

1. Locality first. A Bridge relates SenseCells, never Contexts or strings.
2. senseFamily discipline. Substitution Bridges must be senseFamily-preserving. Interpretation Bridges may cross senseFamilies but never support substitution.
3. Direction clarity. If the kind is directional, state direction explicitly.
4. CL honesty. Assign CL only if you can state at least one counter-example for CL <= 2 or explain its absence with invariants for CL = 3.
5. Loss visibility. Every Bridge carries Loss Notes (even “none”).
6. Row dependence. A Concept-Set row’s scope is bounded by the weakest CL among its participating Bridges (F.7/F.8).
7. No senseFamily jump by stealth. You must not use an Interpretation Bridge to justify a row or substitution.
8. Time DesignRunTag honesty. If a Context fixes design/run, the Bridge must respect that distinction or explicitly declare a bridge such as Design-spec -> Run-trace.
9. Kernel restraint. Bridges cannot be used to promote ad-hoc sameness into a new U.Type; A.11 applies.
10. Non-inheritance of Contexts. Bridges do not imply -is-a- between Contexts (E.10.D1).
11. Weakened-note restraint. A lighter cross-context note, comparative aid, redacted view, or surrogate SHALL NOT be treated as a Bridge Card or as bridge/substitution support by convenience. If bridge-bearing uptake is still wanted, the stronger source-bearing material must be reopened and the bridge must be declared explicitly with kind, direction, CL, and loss notes.

#Micro-examples (illustrative, one-liners)

1. Participant vs Agent (process model vs provenance) Cells: BPMN:Participant - PROV:Agent - senseFamily: Role - Kind: Partial-overlap - CL: 2 - Loss: participation vs attribution scopes differ - Use: Naming-only ("actor").

2. Process (design) vs Activity (run) Cells: BPMN:Process -> PROV:Activity - senseFamily: Method / Execution - Kind: Design-spec -> Run-trace - CL: 2 - Loss: graph vs event; concurrency vs temporalization - Use: Explanation-only.

3. Observation vs SLO check Cells: SOSA:Observation -> ITIL:SLO-fulfilment - senseFamily: Measurement / Status - Kind: Measure-of - CL: 2 - Loss: sampling window; target definition - Use: Explanation-only.

4. Subtype across OWL and curated taxonomy Cells: OWL:SubClassOf - TaxonomyX:is-a - senseFamily: Type-structure - Kind: Equivalence - CL: 3 (only if TaxonomyX is acyclic and anti-symmetric) - Loss: profile differences - Use: Type-structure rows supported.

5. Accuracy (metrology vs data-quality) Cells: ISO80000:accuracy - ISO25024:accuracy - senseFamily: Measurement - Kind: Partial-overlap - CL: 2 - Loss: instrument vs dataset perspective - Use: Naming-only row -accuracy-; methods stay context-local.

#Anti-patterns & remedies

#Worked examples (didactic)

#Service acceptance (design) vs executions & observations (run)

• Cells & Contexts ITIL4:SLO (Status, design) <- SOSA:Observation(availability) (Measurement, run) BPMN:Process (Method, design) -> IEC61131:Task-Execution (Execution, run)
• Narrative Availability SLOs are evaluated by observations of task executions. No substitution follows: an SLO is not an observation, and a process is not an execution occurrence.
• Bridge Cards (sketch) ITIL:SLO <- SOSA:Observation - CL=2 - Loss: sampling window, clock skew. BPMN:Process -> IEC:Execution - CL=2 - Loss: control-flow vs temporalization, concurrency collapse.
• Supported use Explanation-only; Concept-Set rows may be Naming-only ("availability") with CL >= 1 label coherence across Contexts.

#Behavioural role vs access role

• Cells & Contexts BPMN:Participant (Role) - NIST-RBAC:Role (Status)
• Narrative Both talk about -who acts-, but one is a behavioural mask in a process model, while the other is an authorization grouping.
• Bridge Kind: Partial-overlap, CL=2; Loss: assignment moment, enforcement locus, multiplicity.
• Supported use
• Naming-only row “actor”; no Role Assignment & Enactment reuse across senseFamilies.

#Equivalence of subtype notions for structural rows

• Cells & Contexts OWL2:SubClassOf (Type-structure) - TaxX:is-a (Type-structure curated)
• Bridge Kind: Equivalence, CL=3 iff the curated taxonomy is acyclic and anti-symmetric and uses class-level reasoning.
• Supported use Type-structure rows supported (CL = 3); Loss: OWL profile limitations (RL/EL/QO).

#Accuracy (metrology) vs accuracy (data-quality)

• Cells & Contexts ISO80000:measurement-accuracy (Measurement) - ISO25024:data-accuracy (Measurement)
• Bridge Kind: overlap, CL=2; Loss: “true value” notion differs (instrument vs dataset), scale transformations.
• Supported use Naming-only row “accuracy” used for reports; no shared methods.

#Setpoint (control) vs target (service)

• Cells & Contexts CTRL:text:setpoint (Status/Control) - ITIL:target (Status/Service)
• Bridge Kind: Disjoint - Rationale: physical reference value vs business objective; different target kinds (control parameters vs requirement clause).
• Supported use Didactic contrast only; prevents accidental substitution in SLO calculus.

#Role substitution & CL gating (RoleAssignment/enactment scope)

Use. A worked, role-focused restatement of Bridge usage for the recurring question: “May Role_B@B satisfy Role_A@A for requiredRoles / enactment checks-”

Rule. No cross-context substitution by name. If a step in Context A needs Role_A, and the performer only holds Role_B in Context B, an explicit Bridge MUST state how Role_B@B relates to Role_A@A, with direction, CL, and Loss Notes.

#Directional substitution (role-oriented shorthand)

A Bridge may assert, directionally:

• substitutesFor(Role_B@B > Role_A@A) with a CL and a list of kept and lost characteristics (for roles: typical losses are RCS characteristics and/or RSG nuances).
• The reverse direction does not follow unless declared (F.9:13.7).

#CL > gating policy (didactic default)

Notes. The substitution scope is defined in F.9:13.2-13.3 (Role-Assignment/Enactment-eligible substitution requires CL >= 2; Naming-only is CL >= 1). CL penalties route to assurance (R) per B.3; safety-critical policies may require CL >= 2 by default (D.2).

#Typical bridges (worked patterns)

• BPMN Task - PROV Activity. substitutesFor(Task@BPMN > Activity@PROV) with CL=2; lost: BPMN control-flow guards; kept: “bounded occurrence consuming/producing entities.” Effect. A Work logged as Activity@PROV may satisfy a step requiring a Task@BPMN iff an extra guard enforces the BPMN pre-/post-conditions.

• Essence Alpha-State - RoleStateGraph state. substitutesFor(“Alpha.State:Ready”@Essence > “Ready”@RSG) with CL=2; lost: Alpha-specific narrative criteria; kept: checklist-based readiness. Effect. A team may reuse Essence states as labels in RSG, but still maintains local checklists as StateAssertions.

• ITIL Service Owner - RBAC Administrator. Typically CL=1 and directional (Administrator@RBAC > ServiceOwner@ITIL) rejected unless a policy Bridge enumerates compensating controls. Effect. Prevents “ops admin = service owner” conflations without an explicit waiver.

#Bridge invariants (role-relevant reminders)

• Local first. Substitution never overrides in-Context role algebra (its own role relations, guards, and exclusions).
• Loss honesty. If a Bridge’s loss notes indicate that a dropped characteristic is required by a step, substitution is invalid (regardless of CL).
• No silent inversion. Direction is explicit; substitution does not reverse unless declared (F.9:13.7).

#Reasoning primitives (judgement schemas)

All judgements are conceptual. They support or reject specific thinking moves-not enactment steps and not process-enactment records.

#Bridge declaration

Bridge(A@RA, B@RB) : senseFamily, kind, dir, CL, Loss, scope

Reading: There exists a declared Bridge between SenseCells A and B with stated attributes.

#Substitution scope (senseFamily-preserving)

Bridge(A,B): same senseFamily f, kind in {Equivalence, Narrower-than, Broader-than}, dir A->B, CL>=2, Loss L -> A may stand in for B at senseFamily f (Role-Assignment/Enactment-eligible)

Reading: A Substitution Bridge on the same senseFamily with CL >= 2 supports Role-Assignment/Enactment-level substitution in the stated direction. (Type-structure requires CL = 3.)

#Naming-only scope

Bridge(A,B): kind in {Equivalence, Narrower-than, Broader-than, Partial-overlap}, CL>=1 -> A and B may share a label (Naming-only)

Reading: A Bridge with CL >= 1 supports using a shared label in prose or Concept-Set Naming-only rows, without structural or Role Assignment & Enactment commitments.

#Prohibition by kind

Bridge(A,B): kind=Disjoint -> no substitution and no shared row

Reading: Disjoint supports neither substitution nor rows; only contrastive teaching remains supported.

#Interpretation embargo

Bridge(A,B): kind in {Design-spec -> Run-trace, Measure-of, Policy-implies} -> Explanation-only

Reading: Interpretation Bridges never support substitution or rows.

#Weakest-link rule for rows

row R uses {Bridge_i} -> scope(R) = min_i(scopeSupported(Bridge_i)) and CL(R) = min_i(CL_i)

Reading: The row scope and row CL are bounded by the weakest participating Bridge.

#Direction guard

Bridge kind=Narrower-than with dir A->B -> not(B may stand in for A)

Reading: Narrower>Broader does not invert; only A may substitute into B under the stated scope.

#SenseFamily purity

Bridge scope=Role Assignment & Enactment-eligible -> same senseFamily(A,B) and same stance(A,B)

Reading: Role Assignment & Enactment-level substitution requires same senseFamily and same stance (run-time or design time).

#Loss accumulation

A->B with Loss L1 and B->C with Loss L2 -> A->C is supported only if the same senseFamily is preserved, CL=min(CL1,CL2), and Loss accumulates as L1 union L2

Reading: Chained substitution is rarer; if used, accumulate Loss and respect the minimum CL. When in doubt, avoid chaining across Contexts.

#Relations

Builds on: E.10.D1 (Context discipline: Context = U.BoundedContext); F.0.1 (senseFamily guard; Bridge-only crossing); F.1 (Contexts fixed); F.2/F.3 (Cells exist); F.7 (rows depend on Bridges); F.8 (thresholds and reuse choice).

Coordinates with: F.9.1 for stance overlays that remain subordinate to bridge cards; E.17.1 when viewpoint bundles need explicit cross-family correspondence; A.6.Q / C.25 when evaluative endpoints or bundle-shaped quality families cite bridge cards without absorbing bridge semantics.

Constrains:

• F.7 Concept-Set Table: each cross-context row must name supporting Bridges; row scope <= the weakest supporting Bridge.
• F.8 Mint or Reuse: reuse choices reference CL and kind; no reuse without a Bridge.
• Part C patterns: formal claims that span Contexts cite Bridges and respect senseFamily/StatusModality & CL constraints.
• B.3 Trust & Assurance Calculus: may interpret CL as a penalty factor in Cross-context reasoning.

#Migration notes (conceptual)

1. Edition shift in a Context. Re-read affected Cells; if sense moved, split the Bridge or lower CL; keep the older Bridge for historical claims.
2. New evidence of mismatch. Add a counter-example; decrease CL or change bridge kind (for example from Equivalence to Partial-overlap or Disjoint).
3. Convergence over time. When invariants demonstrably match, and counter-examples evaporate, raise CL cautiously; for CL=3, cite invariants.
4. senseFamily refactor. If a Cell’s senseFamily was mis-typed, fix the senseFamily first in F.3, then revisit Bridges; Interpretation is safer than forced substitution.
5. Row under-protected. If a row’s scope exceeds the weakest Bridge, either split the row by Context or downgrade scope to Naming-only.
6. Bridge sprawl. Consolidate near-duplicates into one Bridge with richer Loss Notes; retire the rest.

#Acceptance tests (SCR/RSCR — concept-level)

#Static conformance (SCR)

• SCR-F9-S01 (Well-typed). Every Bridge names two SenseCells, each bound to a Context from F.1, and states senseFamily, kind, dir (if needed), CL, Loss, and scope.
• SCR-F9-S02 (senseFamily discipline). Any Bridge that supports Role/Enactment-eligible substitution is senseFamily-preserving and has kind in {Equivalence, Narrower-than, Broader-than}.
• SCR-F9-S03 (Loss visibility). Every Bridge has non-empty Loss Notes (the word "none" is valid only with CL=3 and stated invariants).
• SCR-F9-S04 (Counter-example hygiene). Bridges with CL <= 2 carry at least one counter-example; Bridges with CL=3 cite matching invariants.
• SCR-F9-S05 (Row compliance). Every Concept-Set row shows a scope no greater than the minimum CL across its supporting Bridges; no row relies on Interpretation Bridges.

#Regression (RSCR)

• RSCR-F9-E01 (Edition churn). When a Context's edition changes, re-validate all Bridges touching it; flag CL drift and update rows' scopes if needed.
• RSCR-F9-E02 (Counter-example drift). New counter-examples lower CL; deletions do not automatically raise CL.
• RSCR-F9-E03 (senseFamily drift). If a Cell's senseFamily is corrected, all Bridges crossing that Cell are re-typed; any substitution that would now cross senseFamilies is invalidated.
• RSCR-F9-E04 (Weakest-link enforcement). Adding a low-CL Bridge to a row reduces the row's scope; if the row's published scope would exceed the new minimum, split or downgrade the row.

#Didactic distillation (90-second script)

A Bridge translates between local senses from different Contexts. It always declares what relation holds (Equivalence, Narrower-than, Broader-than, Partial-overlap, Disjoint, or an interpretation such as Design-spec -> Run-trace), how strong (CL 0-3), which way (when direction matters), and what is lost. Substitution is supported only on the same senseFamily and only with CL >= 2; Type-structure needs CL = 3. Interpretation Bridges explain, never substitute. Rows in the Concept-Set table obey the weakest-link: their scope cannot exceed the lowest CL among their Bridges. When editions change or counter-examples appear, lower CL or change bridge kind; if two senses truly converge and invariants match, raise to CL = 3, rarely and with reasons. Translate across Contexts; never collapse them.

#Bridge stance overlay compatibility

A bridge card may carry a F.9.1 Bridge Stance Overlay such as localRename, operationalizes, partialAnalogy, projection, or nonEquivalent. The overlay is a local interpretive annotation and does not replace the underlying bridge kind, direction, CL, or loss notes.

#Archetypal Grounding

#Tell

A Bridge is not a synonym claim and not an enactment edge. It is a context-bounded correspondence record that tells a reader what may be reused, what may only be explained, and what is lost when meaning is transported.

#Show (System lane)

A service team may reuse the word availability across monitoring, SLO review, and architecture discussion. F.9 requires the team to publish Bridge Cards that separate observation, status target, and architectural concern rather than treating the shared label as silent sameness. The benefit is that naming convenience survives while substitution rights stay bounded by senseFamily, CL, and Loss Notes.

#Show (Episteme lane)

A comparative bundle may say that two traditions both discuss readiness or capability. Under F.9, that statement is only explanatory until the author publishes the two SenseCells, the Bridge kind, direction, CL, and the counter-example that marks where the comparison stops. The Bridge then becomes an auditable correspondence rather than a rhetorical shortcut.

#Weakened cross-context note is not yet a Bridge Card

A service or review bundle may circulate a short cross-context note such as the vendor bulletin is basically the same readiness signal as our rollback worksheet. That note may be useful as informal orientation talk, but it is not yet a lawful Bridge Card and not yet a formal F.9 Naming-only row.

Before any substitution, equivalence, Naming-only row, or interoperability claim is made, the stronger source-bearing material must be reopened and an explicit Bridge Card must publish the two SenseCells, bridge kind, direction, CL, Loss Notes, and supported use. Friendly summary prose does not carry bridge support by itself.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for cross-context correspondence and reuse.

• Gov bias: F.9 raises the declaration bar by requiring explicit Bridge Cards. Mitigation: keep the card compact and teach weakest-link discipline as the default review heuristic.
• Arch bias: the pattern prefers typed bridge declarations over friendly synonym prose. Mitigation: allow Naming-only scope and explanatory Interpretation Bridges so useful comparisons are not blocked.
• Onto/Epist bias: F.9 is strongly local-first and resists global meaning claims. Mitigation: reuse remains possible, but only through explicit correspondence, direction, and Loss Notes.
• Prag bias: conservative CL assignment may feel slower than informal reuse. Mitigation: the pattern still supports bounded substitution when the evidence is good enough; it only blocks silent overreach.
• Did bias: the didactic script can make Bridge Cards look simpler than they are. Mitigation: Conformance, counter-examples, and weakest-link rules keep the teaching explanation tied to real constraints.

#Conformance Checklist (CC-F.9)

A Bridge publication conforms to F.9 iff:

1. CC-F.9-1 - Well-typed Bridge declaration. Every Bridge names two SenseCells bound to declared Contexts and publishes kind, direction (if needed), CL, Loss Notes, and supported use.

2. CC-F.9-2 - Substitution discipline. Any substitution or row support comes only from a Substitution Bridge on the same senseFamily; Role Assignment & Enactment-level substitution requires CL >= 2, and Type-structure substitution requires CL = 3 plus matched invariants.

3. CC-F.9-3 - Interpretation embargo. Interpretation Bridges remain explanation-only and are not used to justify substitution or Concept-Set rows.

4. CC-F.9-4 - CL honesty and loss visibility. Bridges with CL <= 2 publish a counter-example or explicit boundary case; Bridges with CL = 3 publish the invariants that justify the stronger scope; all Bridges publish Loss Notes.

5. CC-F.9-5 - Weakest-link row discipline. Cross-context rows never claim a scope or row-level CL stronger than the weakest participating Bridge.

6. CC-F.9-6 - Overlay non-collapse. If a F.9.1 Bridge Stance Overlay is used, it remains an annotation and does not replace bridge kind, direction, CL, or Loss Notes.

7. CC-F.9-7 - Registry-reference discipline. BridgeId and cited policy pins are treated as registry references, not as signature-exported semantic symbols.

8. CC-F.9-8 - Weakened cross-context note is not treated as a Bridge Card. If bridge-bearing reuse begins from a lighter note, summary, or comparison aid, the stronger source-bearing material is reopened and a full Bridge Card is published before any equivalence, substitution, Naming-only row, interoperability, or other row support is claimed.

#Consequences

Benefits. F.9 lets FPF compare, translate, and partially reuse ideas across Contexts without collapsing them into one vocabulary. It gives downstream rows, claims, and assurance reasoning an explicit Bridge Card record instead of relying on prose intuition.

Trade-offs / mitigations. The pattern adds explicit bridge declaration and may feel heavier than informal comparison. Mitigation: use Naming-only scope when explanation is enough, and reserve stronger scopes for Bridges that really earn them.

#Rationale

The core move of F.9 is simple: cross-context work is unavoidable, but silent sameness is unacceptable. A Bridge therefore does two jobs at once:

• it preserves practical reuse where bounded transport is genuinely available, and
• it keeps non-identity visible through direction, Loss Notes, CL, and weakest-link scope.

Without that discipline, every shared label becomes a hidden ontology merger. With it, cross-context comparison stays teachable, auditable, and compatible with the rest of FPF.

#SoTA-Echoing

SoTA note. This section does not mint an independent second bridge rule track. It stays truthful only when Bridge kinds, CL, Loss Notes, weakest-link scope, the A.6.3.CSC neighbor boundary, and the review matrix below still tell the same story about lawful cross-context reading.

Worked-slice docking. The nearest practical recovery anchors here are the micro-examples in F.9:10, the worked examples in F.9:12, the revision law in F.9:14, and the review matrix in F.9:26. If the SoTA claim cannot be recovered through those explicit bridge-card anchors, do not let the alignment rationale stand in for live bridge law.

Local stance. Best-known current practice supports a narrow rule: cross-context reuse is lawful only when correspondence is typed, directional where needed, explicit about loss, and weaker than silent lexical identity or convenience equivalence.

#Bridge Card Publication Discipline

#Minimal bridge-card declaration

A usable Bridge Card should make visible:

• the two typed SenseCells,
• the bridge kind,
• direction where direction matters,
• declared senseFamily,
• CL,
• explicit Loss Notes,
• and the supported use or row consequence.

If any of these fields is absent, later readers are forced back into inference by prose similarity, which is exactly what F.9 is supposed to block.

#One-pair default rule

The default declaration discipline is one primary Bridge per cell pair per relevant senseFamily, with richer Loss Notes rather than many near-duplicate cards. Local exceptions are lawful only when the cards genuinely differ in bridge kind, direction, or admissible use.

#Revision over silent drift

If later evidence changes bridge strength, direction, or loss, the Bridge Card should be revised explicitly. It should not be left in place while surrounding prose quietly changes the practical scope.

#Bundle and Endpoint Interaction Law

#Viewpoint and bundle interaction

Viewpoint bundles, quality bundles, and other endpoint bundles may cite Bridges, but they do not absorb bridge semantics. F.9 remains the pattern for cross-context alignment, while the citing bundle keeps its own ontology.

#Quality-family interaction

When a quality family claim crosses contexts, bridge loss and CL affect what may be compared or reused, but they do not retype the quality family itself. Any resulting assurance penalty routes to R rather than changing the ontology of F, G, or the Q-Bundle head.

#Overlay interaction rule

A F.9.1 stance overlay may help readers interpret a bridge, but the bridge card remains primary. If the overlay sounds stronger than the bridge kind, direction, CL, or Loss Notes, the card wins and the overlay should be weakened or removed.

#Review Matrix and Migration Tests

A reader can test bridge integrity with six questions:

1. Are the two cells and contexts explicit?
2. Is the bridge kind the weakest truthful kind rather than the friendliest one?
3. Does CL match the published counter-example or invariant evidence?
4. Are Loss Notes specific enough that the supported use is really bounded?
5. If a row or bundle cites the bridge, does it stay within the bridge's supported use?
6. If a stance overlay exists, does it remain strictly weaker than the bridge card itself?

Migration from legacy "same/equivalent/align/map" prose should therefore recover the Bridge Card first, then any row support, then any optional stance overlay. Doing it in the opposite order recreates silent equivalence under new vocabulary.

#F.9:End