F.9:1 - Intent and applicability

Intent. Govern one actual semantic Bridge relation between two exact F.17 SchemeSenseCell values from different semantic contexts. Keep that occurrence separate from every assertion, Bridge description episteme, Bridge Card, registry record, publication occurrence, publication form, presentation carrier, bounded-use claim, evidence or assurance relation, and object created when a proposed use is actually performed.

Applicability. Use this pattern when an author needs to compare local senses across contexts, reuse a familiar label, connect design-time and run-time senses, compare two standards’ terms, or justify a cross-context row. A shared word or available mapping is only a reason to ask whether a Bridge obtains.

Primary EntityOfConcern in plain terms. One actual correspondence or difference between two exact local senses. This pattern concerns the direct Bridge occurrence, not a card, context, transport chain, work process, local system-role kind, assignment occurrence, evidence item, or global meaning layer.

Admissible move in plain terms. First resolve the two local senses. Then state and test the correspondence or difference between them. If the Bridge obtains, state the proposed use separately: what the reader will do, direction, correspondence rule, and tolerated loss. A current C.2.1 claim answers whether the Bridge suits that bounded use. Check ordinary reliance under A.10; use B.3 only when an actual named assurance claim is current. If the use happened, recover its Work, assertion, publication, relation, operation application, or other object under its subject pattern. Add a Bridge Card only when a reusable package is worth maintaining.

Primary working reader. An author, checker, or practitioner deciding first whether a cross-local semantic relation actually obtains and then whether it supports one named use.

Use this when. Use F.9 when a receiving claim needs an exact semantic relation between two local senses whose <ReferenceScheme, LocalSenseClaim> interpretation bases differ. Different schemes, identical spelling, a mapping implementation, or a request for comparison does not establish that relation.

What goes wrong if missed. Teams turn shared labels and convenient mappings into silent equivalence, substitution, structural inference, status transfer, classification under a local system-role kind, or assignment to it. They also mistake evidence about a proposed use, or a polished card, for the relation itself.

What this buys. A reader can see which relation is true, which proposed use is being judged, what evidence supports reliance on that judgement, and whether any downstream act actually happened. Those facts can change independently without silently merging local meanings.

Not this pattern when. Not F.9 when the case is still inside one semantic context, or when the live question is a local system-role kind, assignment occurrence, performed-work attribution, evidence use, status use, source use, publication, assurance, authorization, a gate, a decision, or a mathematical-lens operation. Use the subject pattern for that object; cite F.9 only when cross-context semantic correspondence is also needed.

Recognition versus assurance note. Resolving the endpoint senses and testing the direct Bridge predicate recognizes the semantic relation. A separate C.2.1 claim judges one bounded use. A.10 states whether ordinary evidence reliance passes. When an actual named assurance claim is current, B.3 supplies its bounded result for the same use. None of those steps supplies legal, policy, or deontic authorization.