A.2.6:7 - Scope Algebra

A.2.6:7.1 - Membership and coverage

For exact slice x and scope S, evaluate member(x, S).

• true: the slice is included and the scope condition for the attempted use passes;
• false: the slice is excluded and that use stops or selects another scope;
• unknown: the available evaluation cannot decide; the guard abstains or follows an explicitly governed reliance policy without asserting exclusion.

For a finite target set T : ContextSliceSet, coversSet(S,T) abbreviates for every x in T, member(x,S). Scope-to-scope scopeSubset(S1,S2) instead means for every x, member(x,S1) implies member(x,S2). A target set is neither a scope nor a substitute for one. There is no “close enough” membership and no implicit widening.

Membership evaluation work, its inputs and A.6.1 bindings, an optional C.2.1 result episteme, and a C.29 table remain neighboring objects.

A.2.6:7.2 - Serial Composition (Intersection)

Rule S‑INT (serial). For an essential dependency chain C1 → C2 → … → Ck that supports a claim/capability, the effective scope along that chain is:

Scope_serial = ⋂_{i=1..k} Scope(Ci)

If Scope_serial = ∅, the chain is inapplicable and MUST NOT contribute to published scope.

Monotonicity. Adding a new essential dependency can only narrow (or leave unchanged) the serial scope.

A.2.6:7.3 - Parallel Support (SpanUnion)

Rule P‑UNION (parallel). If there exist independent support lines L₁,…,Lₙ for the same claim/capability, each with serial scope S_i, the publisher MAY declare:

Scope_published = SpanUnion({S_i})  =  ⋃_{i=1..n} S_i

Constraints.

• Independence MUST be justified (different support lines must not rely on the same weakest link).
• The union MUST NOT exceed the union of supported slices; “hopeful” areas are disallowed.
• Publishers SHOULD annotate coverage density/heterogeneity (informative) to aid R assessment, but numeric “coverage” is not part of G.
• Independence criterion. Support lines in a SpanUnion MUST be partitioned so that each line has a set of essential components disjoint from the others’ essential components (no shared weakest link). The partition (or a certificate thereof) SHALL be referenced in the publication.

A.2.6:7.4 - Why a G-ladder/levels/scales is not needed (and must not be introduced)

1) G is not an ordinal scale; it is set-valued. Under USM, U.ClaimScope is a set‑valued USM scope object over U.ContextSlice. The only well‑typed primitives are membership and set operations (⊆, ∩, ⋃). Imposing ordinal “levels” such as G0…Gk violates the type discipline and produces non‑invariant behavior (the same set could be “rated” with different numbers under different heuristics). (See also LEX‑CHR‑STRICT.)

2) G composes via ∩ / SpanUnion, not via min / avg. USM already fixes composition: along a dependent path use intersection; across independent support lines publish SpanUnion. None of these operations relies on (or preserves) any linear order. An ordinal “G ladder” invites people to take minimums/averages, which is incorrect for sets and breaks the established algebra.

3) A G ladder drags in “abstraction level,” which is orthogonal. Early “G ladders” effectively encoded abstraction/typing (instances -> patterns -> formal classes/types -> up-to-iso). That is valuable didactics, but not applicability. Abstraction is captured, if needed, by AbstractionTier (AT) as an optional facet; applicability is U.ClaimScope (G).

4) A G ladder breaks locality and Bridge semantics. When exact local senses require translation, an obtaining F.9 Bridge establishes their direct semantic relation while a separate C.2.1 claim states the proposed mapping rule and tolerated loss. There is no canonical way to translate an ordinal G level: the mapped area may be narrower or differently factored. USM translates exact sets only through that bounded claim and keeps A.10 or B.3 reliance separate rather than rewriting G.

5) A G ladder duplicates ESG guards without adding decision power. What teams often want to “compress into a G number” is actually (a) the quality of expression and (b) the completeness of the declared scope. The first is an F threshold; the second is handled by explicit guards: Scope covers TargetSlice, gammaTime is explicit only when membership varies with time, and a separate freshness-window check when current. A ladder for G adds confusion but no decision power.

Normative directive. U.ClaimScope (G) SHALL remain a set‑valued USM scope object; no ordinal or numeric ladder SHALL be defined for G. If a profile needs scalar reporting, it MAY publish an explicit report‑only proxy CoverageMetric(G), but CoverageMetric(G) MUST NOT substitute for G in norms, gates, Bridge semantics, bounded-use claims, or reliance decisions. Authoring and gating SHOULD use F thresholds (C.2.3) and explicit guard predicates (A.2.6) rather than pseudo‑levels of G.

A.2.6:7.5 - Translation across exact local senses

Use translation only when ordinary designation resolution cannot settle the exact local senses needed by the target membership predicate. Then proceed in this order:

1. resolve the source and receiving F.17 SchemeSenseCell values and name the exact obtaining F.9 Bridge that relates them;
2. state the proposed scope translation separately: name the source scope, target scheme, source-to-receiving direction, scope-correspondence rule, and tolerated loss, then cite the exact current C.2.1 claim with that Bridge as EntityOfConcern and affirmative polarity for this use;
3. before a guard relies on the claim, require the exact A.10 evidence-provenance relation for this bounded use; ordinary reliance requires RelianceDisposition=pass; when an actual named assurance claim is current, require its B.3 AssuranceResult for that same use with disposition=supported-for-use; and
4. use translate(Bridge, UseClaim, SourceScope, TargetReferenceScheme) as the C.29 mathematical representation, or invoke deriveTranslatedScope with those same four values when one actual calculation and returned scope are needed.

The Bridge establishes the direct semantic correspondence. The separate claim selects this translation’s direction, rule, and tolerance. A Bridge profile, Bridge Card, reference-scheme difference, project label, or slice designator cannot supply that claim or its reliance basis. A missing or non-obtaining Bridge blocks the semantic branch. A missing or non-affirmative use claim blocks reliance. A non-passing A.10 disposition blocks ordinary reliance; when an actual named assurance claim is current, a B.3 result other than supported-for-use stops or narrows the assurance-bearing use. None of these outcomes makes an otherwise obtaining Bridge false.

An A.10 pass, or a B.3 AssuranceResult with disposition=supported-for-use, supports only the named use; neither authorizes it. A direct domain rule may require an assurance claim, but it must be stated separately. Observed mismatch, calibration error, and counterexamples are evidence about the use claim. The permitted loss is the tolerance inside that claim. If the rule and tolerance permit translation only for part of the source scope, identify that part and return its target image. Neither the Bridge nor the claim supplies direct support for adding a slice, and neither makes membership true. The exact deriveTranslatedScope application remains an A.6.1 operation application; the claim and reliance basis do not prove that it occurred.

A.2.6:7.6 - Δ‑Operations (Widen, Narrow, Refit)

• Δ‑G+ (widen). Monotone expansion: S proper-subset S-prime. Every added slice requires direct support under the receiving use; a Bridge and affirmative translation-use claim can define a mapping but supply no such support by themselves.
• ΔG− (narrow). Monotone restriction: S′ ⊂ S. Often used to remove areas invalidated by new findings.
• Refit. A different expression or parameterization designates the same extensional scope after normalization (for example, changing units or factoring common predicates). Refit MUST NOT alter membership and does not create another scope value.

Refit (normalization). A refit MUST preserve membership exactly: extension_RS(S_after) = extension_RS(S_before), so both expressions designate the same scope value. Any change that alters boundary inclusion through rounding, unit conversion, or discretization is a ΔG± change, not a refit.

Edition triggers. A changed extension identifies a different scope value. A changed predicate expression with the same exact extension preserves the scope value but is a content change in the declaration or claim-bearing episteme that carries the expression; its direct governor decides whether another episteme edition is needed.

Discriminating cases. Under one effective reference scheme, 20 °C <= temperature <= 30 °C and the exactly converted 293.15 K <= temperature <= 303.15 K have the same extension and can be related as a refit while designating the same scope. Replacing the inclusive upper boundary with temperature < 30 °C removes every slice exactly at 30 °C; that one membership-boundary change identifies another scope rather than a refit.

A.2.6:7.7 - Invariants

• I-LOCAL. Interpret membership under the effective reference scheme and exact local senses current to the declaration. Translate only through an obtaining F.9 Bridge plus the separate affirmative C.2.1 claim for that translation; keep A.10 or B.3 reliance outside membership truth.
• I‑SERIAL. Serial scope is an intersection; it cannot grow by adding dependencies.
• I‑PARALLEL. Parallel scope MAY grow by union, but only where independently supported.
• I‑WLNK. Weakest‑link applies to F and R on dependency paths; G follows set rules (∩ / ⋃).
• I‑IDS. Idempotence: Intersecting or unioning a set with itself does not change it.
• I‑EMPTY. Empty scope is a first‑class value; guards MUST treat it as “not applicable”.

A.2.6:7.8 - Empty & Partial Scopes

• Empty scope (∅). No slice satisfies the declared predicate. A receiving guard stops.
• Partial scope. Publishers SHOULD avoid “global” language when actual scope is thin; instead, publish explicit slices and (informatively) coverage hints to guide R assessment.