#Unified Scope Mechanism (USM): Context Slices & Scopes

Pattern A.2.6 · Stable Part A - Kernel Architecture Cluster

One-line summary. Introduces a single, context-local scope mechanism for all holons: U.ContextSlice (where we reason and measure) and a family of set-valued scope types (USM scope objects, U.Scope), specialized as U.ClaimScope for epistemes (G in F–G–R), U.WorkScope for system capabilities, and U.PublicationScope for publication carriers; with one algebra (∩ / SpanUnion / translate / widen / narrow / refit) and uniform Cross-context handling (Bridge + CL).

Replaces / deprecates. This pattern supersedes the scattered use of labels applicability, envelope, generality, universality and capability envelope where they tried to stand in for the one scope mechanism. From now on:

• For epistemes, the only scope type is U.ClaimScope (nick G in F–G–R).
• For system capabilities, the only scope type is U.WorkScope.
• For publication carriers (views/cards/lanes), the only scope type is U.PublicationScope.
• The abstract architectural notion is U.Scope — a set-valued USM object over ContextSliceSet with its own algebra (∩ / SpanUnion / translate / widen / narrow / refit); it is not a U.Characteristic and MUST NOT appear in any CharacteristicSpace.

Legacy words (applicability / envelope / generality / capability envelope) MAY appear only as explanatory aliases in non‑normative notes.

Cross‑references. — C.2.3 (Unified Formality F) and C.2.2 (F–G–R): this pattern defines G as U.ClaimScope. — A.2.2 (Capabilities): capability gating now SHALL use U.WorkScope. — Part B (Bridges & CL): Cross‑context transfers MUST declare a Bridge with CL; CL affects R, not F/G. — Part E (Publication discipline; e.g., E.17 MVPK): publication views/cards/lanes MAY declare U.PublicationScope to bound where a publication is admissible; U.PublicationScope MUST NOT widen the underlying U.ClaimScope/U.WorkScope. (USM supplies the scope calculus; Part E supplies publication discipline.)

This pattern gives engineering managers and assurance architects one vocabulary, one model, and one set of operations to talk about where a claim holds and under which conditions a system can deliver a piece of Work. It removes the need to remember whether a document said “applicability,” a model said “envelope,” or a safety plan said “capability envelope.” Scope is scope. The only distinction that matters is what carries it:

#Keywords

• scope
• applicability
• ClaimScope (G)
• WorkScope
• set-valued.

#Relations

#Content

#Purpose & Audience

This pattern gives engineering managers and assurance architects one vocabulary, one model, and one set of operations to talk about where a claim holds and under which conditions a system can deliver a piece of Work. It removes the need to remember whether a document said “applicability,” a model said “envelope,” or a safety plan said “capability envelope.” Scope is scope. The only distinction that matters is what carries it:

• Knowledge/episteme → Claim scope (G).
• System/capability → Work scope (conditions under which Work at the promised measures is deliverable).

With USM, teams can:

• specify, compare, and compose scope without translation games;
• gate ESG and Method–Work steps with observable, context‑local scope checks;
• cross Contexts safely using Bridges and explicit CL penalties applied to R.

This pattern defines the scope mechanism (Context slices, set‑valued scopes, algebra, and guard usage) and the canonical lexicon (Claim scope (G), Work scope). It does not prescribe which Contexts must widen/narrow scope, nor which assurance levels are required; those are set by context‑local ESG and Method–Work policies, which SHALL reference the mechanisms defined here.

#Context

#Cross‑disciplinary pressures

Modern projects couple formal specs, data‑driven models, safety cases, and operational playbooks. Each artifact must say where it is valid—yet terminology drifts:

• Standards and specs often say applicability or scope.
• Modeling communities say envelope.
• Safety and performance documents speak about capability envelope.
• Knowledge patterns have used generality (G) as if it were “more abstract,” when we actually need “where the statement holds.”

#context‑local reasoning

FPF is context‑local: decisions, checks, and state assertions are valid inside a bounded context. Every practical question—Is this claim usable here? Can this capability deliver that Work now?—must be answered on a concrete slice of context (terminology, versions, environmental parameters, time selector Γ_time). USM provides a first‑class object for such slices and a single scope calculus atop them.

#Minimal, composable trust math

In F–G–R:

• F (formality) is “how strictly a claim is expressed” (C.2.3).
• G must be “where it holds,” not “how abstract it sounds.”
• R measures evidence and decays/penalties (freshness, CL).

When G is a set‑valued scope, composition becomes precise: serial dependencies intersect scopes; parallel, independently supported lines can publish a SpanUnion—but only where each line is supported.

#Problem

1. Synonym soup. Applicability, envelope, generality, capability envelope—different labels for the same mechanism led to mismatches in gating, review, and reuse.
2. Abstraction confusion. Calling G “generality” invited teams to treat “more abstract wording” as “broader scope,” silently masking unstated assumptions.
3. Split mechanics. Episteme vs system text used different algebra and guard language, though the same set operations were meant.
4. Cross‑context opacity. Transfers between Contexts lacked a shared carrier and a rule for what changes (trust) vs what stays (scope).
5. Overloaded words. Validity clashed with Validation Assurance (LA); operation/operational clashed with Work/Run in A.15, producing governance ambiguity.

#Forces

#Solution — Overview (preview; full definitions in Part 2)

USM introduces:

• U.ContextSlice — an addressable slice of a bounded context (terminology, parameter ranges, versions/Standards, and a mandatory Γ_time selector). All scope checks are performed on slices.
• U.Scope — the abstract set‑valued scope object over U.ContextSlice.
• Specializations: U.ClaimScope (nick G) on U.Episteme (“where the claim holds”), U.WorkScope on U.Capability (“where the capability can deliver Work at declared measures within qualification windows”), and U.PublicationScope on publication carriers (“where the publication surface is admissible”).
• One algebra: serial intersection, parallel SpanUnion (only where supported), translate via Bridge (CL affects R, not F/G), and widen / narrow / refit operations for scope evolution.

Lexical commitments (normative): — In normative text and guards, use Claim scope (G), Work scope, and Publication scope.
— Do not name the characteristic “applicability/envelope/generality/capability envelope/publication applicability/validity.” Those words are permitted only as explanatory aliases in notes.

#Normative Definitions

#USM as a U.Mechanism.Intension (normalization for A.6.1/A.6.5)

Intent. This subsection makes the USM definition in A.2.6 explicitly conform to the U.Mechanism intension requirements (A.6.1) and the …Slot / …Ref lexical discipline (A.6.5), without changing USM’s meaning.

USM Mechanism.Intension (normative; A.6.1 decomposition).

• Imports (USM). U.ContextSlice, U.ContextSliceSet, Part B Bridge/CL (U.Bridge, U.CongruenceLevel), and U.GammaTimePolicy.
• BaseType (USM). U.ContextSliceSet (set‑valued scope objects range over sets of addressable U.ContextSlice).
• SliceSet (USM). U.ContextSliceSet (addressable U.ContextSlices; see §6.1).
• SubjectKind (USM). U.Scope with kind specialisations:
  U.ClaimScope ⊑ U.Scope, U.WorkScope ⊑ U.Scope, U.PublicationScope ⊑ U.Scope.
• ExtentRule (USM). The quantifier domain is the set of well‑formed scope objects over the SliceSet: Extension(U.Scope, slice) = { S | S ⊆ U.ContextSliceSet }.
• ResultKind? (USM). U.Scope (for operators that return scopes, e.g., ∩, SpanUnion, translate).

SlotIndex (USM) for operators/guards (normative; A.6.0:4.1.1 + A.6.5).
These SlotKinds are stable names for signatures, substitution laws, and guard templates; they are not additional data slots on carriers.

OperationAlgebra (USM) with SlotSpecs (normative).

• member(SliceSlot, ScopeSlot) — surface form: SliceSlot ∈ ScopeSlot.
• subset(LeftScopeSlot, RightScopeSlot) — surface form: LeftScopeSlot ⊆ RightScopeSlot.
• intersect(LeftScopeSlot, RightScopeSlot) → U.Scope — surface form: LeftScopeSlot ∩ RightScopeSlot.
• spanUnion(ScopeFamilySlot) → U.Scope — surface form: SpanUnion(ScopeFamilySlot).
• translate(BridgeRef, ScopeSlot) → U.Scope — Cross‑context mapping via Bridge.
• widen(LeftScopeSlot, RightScopeSlot) — Δ‑move, requires LeftScopeSlot ⊂ RightScopeSlot.
• narrow(LeftScopeSlot, RightScopeSlot) — Δ‑move, requires RightScopeSlot ⊂ LeftScopeSlot.
• refit(LeftScopeSlot, RightScopeSlot) — normalization, requires LeftScopeSlot = RightScopeSlot.

Derived guard predicates (USM).

• coversSlice(ScopeSlot, SliceSlot) := (SliceSlot ∈ ScopeSlot).
• coversSet(ScopeSlot, SliceSetSlot) := (SliceSetSlot ⊆ ScopeSlot).

LawSet (USM). Serial composition uses intersection; parallel publication uses SpanUnion only with an explicit independence justification (§7.3).

AdmissibilityConditions (USM). Scope coverage predicates MUST be tri‑state under unknowns: unknown inputs yield unknown, and guards MUST either (a) abstain (fail closed) or (b) degrade trust in the admitting decision via R; unknown MUST NOT be implicitly coerced to false/0. (See also §7.1 and §10.1.)

Applicability (USM). USM governs Claim/Work/Publication scope objects inside a U.BoundedContext; coverage judgments are evaluated on explicit U.ContextSlice tuples (§6.1) and are not comparable/scorable as CHR values.

Audit (USM). Record scope‑aware decisions with the TargetSlice tuple, guard outcomes, and any Bridge+CL used (see §14.1).

Transport (USM). Cross‑context usage is Bridge‑only with explicit CL; CL penalties apply to R_eff = R · Φ(CL) and MUST NOT rewrite F or G (§7.4/§7.5).

Γ_timePolicy (USM). Γ_time is mandatory in slices and guards (§8.2); implicit “latest” is forbidden.

PlaneRegime (USM). Not applicable to set‑valued scope objects (no CL^plane effect on scopes).

Mechanism specialisation (USM; A.6.1:4.2.1). A bounded context MAY publish a specialisation of USM as either a refinement USM′ ⊑ USM (tighten LawSet/AdmissibilityConditions) or an extension USM ⊑⁺ USM′ (add new operators/slots). Any such specialisation SHALL (i) name its parent (USM), (ii) declare the morphism kind (⊑ vs ⊑⁺), (iii) preserve the same BaseType and SlotKinds for inherited operators (no renaming), (iv) avoid adding new mandatory inputs to inherited signatures. It MAY narrow ValueKinds/refModes monotonically and add admissibility constraints, but MUST remain substitutable for the inherited USM operators.

#U.ContextSlice — where scope is evaluated

Definition. U.ContextSlice is an addressable, context‑local selection of a bounded context comprising:

• Vocabulary & roles. The active terminology, role bindings, and local dictionaries.
• Standards & versions. Concrete versioned interfaces, schemas, notations, or service Standards in force.
• Environment selectors. Named parameters/ranges (e.g., temp, humidity, platform, jurisdiction, dataset cohort).
• Time selector Γ_time. A mandatory selector for the temporal frame of reference (point, window, or policy), disallowing implicit “latest”.

Semantics. All scope checks, guards, and compositions are evaluated inside an explicitly named U.ContextSlice. Cross‑context or cross‑slice usage MUST be mediated by a Bridge (Part B) with an explicit CL rating; see §7.4.

Addressability. A slice MUST be identifiable via a canonical tuple (Context, vocab‑id, Standard/version ids, env selector(s), Γ_time). A slice MAY be a singleton or a finite set if a guard tests multiple coherent sub‑conditions.

Slice key (minimal). A U.ContextSlice SHALL be addressable by a tuple containing at least: (Context, Standard/version ids (if any), environment selectors, Γ_time). Contexts MAY extend this tuple (e.g., vocab/roleset ids).

#U.Scope — the abstract set‑valued scope property (USM kind; not a CSLC measurement)

Definition. U.Scope ⊆ ContextSliceSet is a set‑valued USM property whose values are sets of U.ContextSlice where a given statement, behavior, or capability is fit‑for‑use. It is not numeric; its internal order is the subset relation ⊆. There is no “unit”. The primitive judgement is membership: slice ∈ Scope.

Guard (normative). U.Scope, U.ClaimScope (G), U.WorkScope, and U.PublicationScope are not U.Characteristics in the A.17/CSLC sense; do not include them as slots in any U.CharacteristicSpace, and do not attach normalizations/scores to them. They are USM scope objects.

Operations. USM admits:

• Intersection ∩ (serial composition).
• SpanUnion (parallel, independently supported coverage) only when an explicit named independence assumption is declared (features/axes named, validity window stated, evidence class cited). See A.6.1/USM LawSet for the normative template.
• Translate (Cross‑context mapping via Bridge).
• Widen / Narrow (monotone changes to the set).
• Refit (content‑preserving re‑expression; set equality).

Locality. U.Scope values are defined and reasoned about context‑locally. Translation between Contexts never occurs implicitly; see §7.4.

#U.ClaimScope (nick G) — scope of a claim (episteme)

Carrier. U.Episteme (claims, specifications, theories, policies).

Meaning. The set of U.ContextSlice where the claim holds as stated. This is G in the F–G–R triple. G is not “abstraction level”; it is the applicability area of the claim.

Expression. Authors SHALL declare Claim scope as explicit predicates or condition blocks (assumptions, parameter ranges, cohorts, platform/Standard versions, Γ_time windows).

Path composition (serial). Along any essential dependency path supporting the claim, the effective scope is the intersection of contributors’ Claim scopes (see §7.2). Empty intersection makes the path inapplicable.

Parallel support. Where independent lines of support justify disjoint areas, the episteme MAY publish a SpanUnion (see §7.3) limited strictly to the covered slices.

Δ‑moves.

• ΔG+ (widen). Replace scope S with S′ such that S ⊂ S′.
• ΔG− (narrow). Replace scope S with S′ such that S′ ⊂ S.
• Refit. Replace S with S′ where S′ = S (normalization, re‑parametrization).
• Translate. Map S across Contexts via a declared Bridge; CL penalties apply to R, not to F/G.

Orthogonality. Changes in F (form of expression) or D/AT (detail/abstraction tiers) do not change G unless the declared area of validity changes.

#U.WorkScope — scope of doing Work (capability)

Carrier. U.Capability (a system’s ability to deliver specified U.Work).

Meaning. The set of U.ContextSlice (conditions, Standards, platforms, operating parameters, Γ_time) under which the capability can deliver the intended Work at the declared measures, within declared qualification windows.

Expression. Capability owners SHALL declare U.WorkScope as explicit conditions/constraints over U.ContextSlice only (environment, platforms, Standards by version, resource regimes, Γ_time). Quantitative deliverables and operation windows are not part of the scope value:

• Declare targets as U.WorkMeasures (e.g., latency ≤ L, throughput ≥ T, tolerance ≤ ε) bound in guards (WG‑2).
• Declare inspection/recertification policies as U.QualificationWindow bound in guards (WG‑3).
  The use‑time admission requires all of: WorkScope covers JobSlice AND WorkMeasures satisfied AND QualificationWindow holds.

Method–Work gating. A Work step’s guard MUST check that the target slice is covered by the capability’s Work scope and that required measures and qualification windows are satisfied.

Composition and Δ‑moves. Work scope uses the same algebra as Claim scope (∩ / SpanUnion / translate / widen / narrow / refit). Translation across Contexts follows §7.4.

Separation from knowledge. Work scope does not assert a proposition about the world; it asserts deliverability of Work under conditions. Evidence for deliverability feeds R (Reliability) via measurements and monitoring.

Required guard facets (capabilities).

• U.WorkMeasures (mandatory). A set of measurable targets with units and tolerated ranges, evaluated on the JobSlice.
• U.QualificationWindow (mandatory for operational use). A time policy (point/window/rolling) stating when the capability is considered qualified; evaluated at Γ_time.
  These facets are separate from U.WorkScope and live in the R‑lane (assurance). They MUST be referenced in Method–Work guards (see §10.3 WG‑2/WG‑3).

#U.PublicationScope — scope of a publication (view/surface)

Carrier. Publication carriers (e.g., PublicationSurface/InteropSurface views/cards/lanes in Part E; MVPK faces). Meaning. The set of U.ContextSlice where a publication (a view/card/lane about some object or morphism) is admissible for use without introducing claims beyond its underlying carrier.

Relation to other scopes (normative).

• If the publication is about an episteme E:
  PublicationScope(view_E) ⊆ ClaimScope(E).
• If the publication is about a capability C:
  PublicationScope(view_C) ⊆ WorkScope(C).
• If the publication is about a composition and/or crosses Contexts:
  PublicationScope(view) ⊆ translate(Bridge, ⋂ scopes of contributors); CL penalties apply to R only (scope set membership is unaffected).

Expression. Authors SHALL declare U.PublicationScope as explicit predicates over U.ContextSlice (Context, Standard/version ids, environment selectors, Γ_time). It MAY be narrower than the underlying scope (e.g., due to pin availability, labeling, or audience constraints) but MUST NOT be wider.

Algebra & Δ‑moves. Inherits the USM algebra (∩ / SpanUnion / translate / widen / narrow / refit). Widen is permitted only when the underlying U.ClaimScope/U.WorkScope widens accordingly; otherwise the publication MAY refit or narrow.

Orthogonality to measurement. U.PublicationScope is a USM scope object (set‑valued), not a CHR Characteristic and MUST NOT appear as a slot in a U.CharacteristicSpace.

View refinement (profiles). When a stricter publication profile/view refines another (e.g., a typed card that requires additional pins), its U.PublicationScope MUST NOT be wider than that of the less formal view.

#Scope Algebra

#Membership & Coverage

• Membership judgement. slice ∈ Scope is the primitive check.

• Coverage guard. A guard “Scope covers TargetSlice” means either:

  • singleton: TargetSlice ∈ Scope, or
  • set: TargetSet ⊆ Scope.

• No implicit expansion. Absent an explicit declaration, guards MUST NOT treat “close” slices as covered; widening requires a ΔG+ change.

Tri‑state admissibility under unknowns (normative; aligns A.6.1).

• If any required input to a membership/coverage check is unknown (missing slice selector, unknown Standard version, unmappable Bridge leg, unspecified Γ_time, etc.), the check result is unknown, not false.
• Guards MUST either abstain (fail closed) or explicitly route the outcome through an R‑lane degradation policy; unknown MUST NOT be coerced to false/0.

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

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

#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. We have already separated these concerns: abstraction is captured, if needed, by U.AbstractionTier (AT) as an optional facet; applicability is U.ClaimScope (G).

4) A G ladder breaks locality and Bridge semantics. Cross‑context transfer maps a set Scope via a Bridge and penalizes R by CL. There is no canonical way to “translate” an ordinal G level between Contexts: the mapped area may be strictly narrower or differently factored. Level numbers would become non‑portable, causing hidden loss or inflation of trust. With USM, we translate sets and keep the CL penalty where it belongs—in R, not in 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 (e.g., require U.Formality ≥ F4 so the scope is predicate‑like and addressable); the second is handled by explicit ESG guards: “Scope covers TargetSlice,” “Γ_time is specified,” and “freshness window holds” (R‑lane). A ladder for G adds confusion but no additional control.

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, or CL routing. Authoring and gating SHOULD use F thresholds (C.2.3) and explicit guard predicates (A.2.6) rather than pseudo‑levels of G.

#Translation across Contexts (Bridge & CL)

Rule T‑BRIDGE. To use a scope in a different bounded context (room), an explicit Bridge MUST be declared with:

• Mapping. A documented mapping from source to target U.ContextSlice vocabulary/characteristics.
• Congruence Level (CL). A rating of mapping congruence.
• Loss notes. Any known losses, assumptions, or non‑isomorphisms.

Effect. The mapped scope is T(Scope) in the target Context. CL penalties apply to R (the trust in support/evidence), not to F or G. If mapping is coarse, the publisher SHOULD also narrow the mapped scope to the area where losses are negligible (best practice, not a requirement).

#Δ‑Operations (Widen, Narrow, Refit)

• ΔG+ (widen). Monotone expansion: S ⊂ S′. Requires new support or stronger bridges.
• ΔG− (narrow). Monotone restriction: S′ ⊂ S. Often used to remove areas invalidated by new findings.
• Refit. S′ = S after normalization (e.g., re‑parameterization, changing units, factoring common predicates). Refit MUST NOT alter membership.

Refit (normalization). A refit MUST preserve membership exactly (S′ = S). Any change that alters boundary inclusion (due to rounding, unit conversion, discretization) is a ΔG± change, not a refit.

Edition triggers. Any change that alters the published set (ΔG±) is a content change and MAY trigger a new edition per Context policy (see A.2.x on editions). Refit is not a content change.

#Invariants

• I‑LOCAL. All scope evaluation is context‑local. Cross‑context usage MUST follow §7.4.
• 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”.

#Empty & Partial Scopes

• Empty scope (∅). The claim/capability is currently not usable anywhere in the Context; guards MUST fail.
• Partial scope. Publishers SHOULD avoid “global” language when actual scope is thin; instead, publish explicit slices and (informatively) coverage hints to guide R assessment.

#Locality, Time & Version Semantics

#context‑locality

Scopes are owned and evaluated within a U.BoundedContext. State assertions (ESG/RSG) and Method–Work gates MUST NOT assume that a scope declared in another Context applies verbatim; see §7.4.

#Time selector Γ_time

Every scope declaration and every guard MUST specify a Γ_time selector (point, window, or policy such as “rolling 180 days”) whenever time‑dependent assumptions exist. Implicit “latest” is forbidden. When Γ_time differs between contributors, serial intersection resolves the overlap.

#Standards, versions & notations

Scope predicates SHALL name Standards/interfaces/schemas by version. Changing symbols/notations with a faithful mapping does not change G (it may change CL for the mapping and thus affect R).

#Determinism of evaluation

Given fixed inputs (slice tuple, declared scope), the membership judgement MUST be deterministic. Guards SHALL fail closed (no membership ⇒ no use).

#Interaction with R (freshness & decay)

For empirical claims and operational capabilities, R typically binds evidence freshness windows. Scope does not decay with time; trust in the support does. Guards MAY combine “Scope covers” with “Evidence freshness holds” as separate predicates.

#Lexical Discipline (Part E compliance)

L‑USM‑1 (names). Use Claim scope (G) for epistemes, Work scope for capabilities, and Publication scope for publication carriers. Use Scope only when discussing the abstract mechanism. Avoid naming any characteristic as “applicability,” “envelope,” “generality,” “capability envelope,” or “validity”.

L‑USM‑2 (Work/Run). Prefer Work/Run vocabulary from A.15 for system execution contexts. Do not introduce “operation/operating” as characteristic names; use Work scope.

L‑USM‑3 (Validation). “Validation/Validate” remain reserved for LA in assurance lanes (Part B). Do not name a scope object “validity”.

L‑USM‑4 (Domain). “Domain” is a descriptive convenience. Scopes are evaluated on Context slices; guards SHALL reference slices, not generic “domains”.

L‑USM‑5 (First mention). On first use in a Context, include the parenthetical nick: “Claim scope (G)” to preserve the F–G–R mapping.

#Guard Patterns (ESG & Method–Work)

#Common guard shape

A scope‑aware guard has the form:

Guard := ScopeCoverage AND TimePolicy AND (EvidenceFreshness?) AND (BridgePolicy?)

Admissibility note (normative; A.6.1 alignment). If ScopeCoverage is unknown (due to unknown slice keys, unmappable translation, missing Γ_time, etc.), the guard MUST NOT silently treat this as false. It MUST either abstain (fail closed) or apply an explicit R‑lane degradation policy.

Where:

• ScopeCoverage: Scope covers TargetSlice (singleton or finite set), see §7.1.
• TimePolicy: explicit Γ_time selector(s); implicit “latest” is forbidden (§8.2).
• EvidenceFreshness: optional R‑lane freshness/decay predicates; separate from ScopeCoverage (§8.5).
• BridgePolicy: required if the Scope and TargetSlice are in different Contexts; declares Bridge, CL, loss notes (§7.4).

The guard fails closed (no membership ⇒ denial), and evaluation is deterministic given the slice tuple (§8.4).

#ESG guard families (epistemes)

EG‑1 - ClaimScopeCoverage (mandatory). The state transition MUST include a predicate:

U.ClaimScope(episteme) covers TargetSlice

• Singleton: TargetSlice ∈ ClaimScope.
• Finite set: TargetSet ⊆ ClaimScope.

EG‑2 - Formality threshold (if required by ESG). When rigor is gated, the guard MUST reference C.2.3:

U.Formality(episteme) ≥ F_k

EG‑3 - Evidence freshness (R‑lane). If the state implies trust, a separate predicate MUST assert freshness windows for bound evidence:

Fresh(evidence, window)  AND  (NoExpiredBindings)

EG‑4 - Cross‑context usage. If TargetSlice.Context ≠ episteme.Context, the guard MUST require a declared Bridge and CL:

Bridge(source=episteme.Context, target=TargetSlice.Context)  AND  CL ≥ c

Effect: CL penalties apply to R, not to F/G (§7.4). The ESG guard MAY also narrow the mapped Claim scope when mapping losses are known.

EG‑5 - ΔG triggers. If the transition publishes a wider Claim scope (ΔG+), the guard MUST capture the new support or the new Bridge and, if Context policy so dictates, mint a new edition (PhaseOf).

EG‑6 - Independence for SpanUnion (when claiming parallel scope). When the episteme declares a SpanUnion across independent lines, the guard MUST include an independence justification (pointer to the support partition). No independence ⇒ no union.

(Informative note.) Managers often combine EG‑1 (coverage) + EG‑2 (F threshold) + EG‑3 (freshness) for “Effective” or “Approved” states, and EG‑4 when adopting claims across Contexts.

#Method–Work guard families (capabilities)

WG‑1 - WorkScopeCoverage (mandatory). A capability can be used to deliver a Work step only if:

U.WorkScope(capability) covers JobSlice

WG‑2 - U.WorkMeasures satisfied (mandatory for deliverables). Guards MUST bind quantitative measures that the capability promises in the JobSlice:

SLO/target measures satisfied (latency ≤ L, throughput ≥ T, tolerance ≤ ε, … )

WG‑3 - U.QualificationWindow holds (mandatory for operational use). Operational guards MUST assert that qualification windows (qualification/inspection/recert intervals) hold at Γ_time:

ValidityWindow(capability) holds at Γ_time

WG‑4 - Cross‑context use of capability. If the JobSlice is in another Context:

Bridge(source=capability.Context, target=JobSlice.Context)  AND  CL ≥ c

CL penalties affect R (confidence in deliverability), not Work scope; however, the guard SHOULD narrow the mapped Work scope to account for known mapping losses.

WG‑5 - Δ(WorkScope). When widening Work scope (new operating ranges/platforms), the guard MUST require evidence at the new slices (measures + qualification windows). Refit (e.g., new units/parametrization) requires no new evidence.

#Bridge‑aware guard macro (reusable)

A reusable macro for Cross‑context guards:

Guard_XContext(Scope, TargetSlice) :=
    exists Bridge b: (b.source = owner(Scope).Context AND b.target = TargetSlice.Context)
AND CL(b) ≥ c
AND Scope’ = translate(b, Scope)
AND Scope’ covers TargetSlice
AND (Apply CL penalty to R)

• Owner(Scope). The carrier that declares the scope: an Episteme (for U.ClaimScope), a Capability (for U.WorkScope), or a Publication carrier (for U.PublicationScope).
• Translate(b, Scope). The partial mapping of a set of source slices to target slices induced by Bridge b. If a source slice is unmappable, it is dropped. The result is a set of target slices; CL penalties apply to R only.
• Penalty to R: applied per trust calculus; F and G remain as declared.

#Selector policy (Γ_time)

All ESG and Method–Work guards MUST spell out Γ_time:

• Point (“as of 2026‑03‑31T00:00Z”).
• Window (“rolling 180 days”).
• Policy (“last lab calibration within 90 days”).

Implicit “latest” is not allowed. If multiple contributors declare different policies, serial intersection computes the overlap (§8.2).

#Conformance Checklist (USM)

#Worked Examples

Each example declares the Context, the scope, the target slice, and shows the guard outcome. Where relevant, serial intersection, SpanUnion, and Bridge & CL are illustrated.

#Research claim (controlled narrative → predicate)

• Context: MaterialsLab@2026.
• Episteme: claim “Adhesive X retains ≥85 % tensile strength on Al6061 for 2 h at 120–150 °C.”
• Claim scope (G): {substrate=Al6061, temp∈[120,150]°C, dwell≤2h, Γ_time = window(1y), rig=Calib‑v3}.
• Target slice: {substrate=Al6061, temp=140 °C, dwell=90 min, Γ_time=2026‑04‑02, rig=Calib‑v3}.
• Guard (EG‑1, EG‑2): covers(TargetSlice) true; U.Formality ≥ F4 true (predicates in spec).
• Outcome: state transition allowed (freshness checked separately under R).

#Cross‑context use of the research claim

• target Context: AssemblyFloor@EU‑PLANT‑B.
• Bridge: declared mapping of rigs and temp measurement correction; CL=2 (loss: ±2 °C bias).
• Mapped Claim scope: translate(Bridge, G) narrows temp to [122,148]°C.
• Guard (EG‑4): Bridge present, CL≥2 true; R is penalized per Φ(CL).
• Outcome: allowed; G remains the mapped set; R lowered.

#Capability: robotic weld Work scope

• Context: RobotCell‑Weld@2026.
• Capability: “Weld seam W at bead width 2.5 ± 0.3 mm, cycle ≤ 12 s.”
• Work scope: {humidity<60 %, current∈[35,45]A, wire=ER70S‑6, Γ_time=rolling(90d), controller=FW‑2.1}.
• Job slice: {humidity=55 %, current=40A, wire=ER70S‑6, Γ_time=now, controller=FW‑2.1}.
• Guards (WG‑1..3): coverage true; measures satisfied; qualification window true (controller certified 60 d ago).
• Outcome: capability admitted for this Work.

#Serial intersection (API + dataset compatibility)

• Claim A (API Standard): v2.3 request schema with constraint “idempotent under retry”.
• Claim B (Dataset cohort): “metrics valid for cohort K with schema ds‑14”.
• Composition: service S depends on both A and B → serial intersection of Claim scopes: {api=v2.3} ∩ {cohort=K, schema=ds‑14}.
• Target slice: {api=v2.3, cohort=K, schema=ds‑14} → membership true.
• Any drift (e.g., ds‑15) empties the intersection ⇒ path inapplicable.

#Parallel support (SpanUnion) in a safety case

• Line L1: tests on dry asphalt support braking property; scope S1={surface=dry, speed≤50 km/h}.
• Line L2: simulations for wet asphalt; scope S2={surface=wet, speed≤40 km/h}.
• Published scope: SpanUnion({S1,S2}) = {(dry, ≤50), (wet, ≤40)} with independence note (L1 empirical, L2 model‑validated).
• Guard: allowed; union does not include (wet, 45) because not supported.

#ML model deployment across Contexts

• Model claim: “AUC ≥ 0.92 on cohort K, pipeline P, features F, Γ_time=rolling(180d).”
• Claim scope: {cohort=K, pipeline=P, features=F, Γ_time=rolling(180d)}.
• target Context: product On‑Device@v7, features F’ (subset), pipeline P’.
• Bridge: declared mapping F→F’, P→P’, CL=1 (notably lossy).
• Guard: Bridge present; translate(G) covers a strict subset; CL=1 penalizes R strongly; ESG requires F≥F5 (executable semantics) and freshness < 90 d.
• Outcome: allowed only for the covered subset; adoption flagged with reduced R.

#Playbooks (Informative)

#Manager’s 6‑step adoption checklist

1. Name the TargetSlice. Write the tuple (Context, versions, environment params, Γ_time).
2. Check scope coverage. “Claim/Work scope covers TargetSlice?” If no, either ΔG+ (publish wider scope with support) or decline.
3. Check rigor if gated. If ESG requires it, ensure U.Formality ≥ F_k.
4. Check evidence freshness (R). Validate windows/decay policies; do not conflate with coverage.
5. Bridge if Cross‑context. Require declared Bridge, CL, and loss notes; accept R penalties.
6. Record the decision. Keep the slice and guard outcomes with the StateAssertion (auditability).

#Architect’s design rubric for scopes

• Prefer predicates over prose. Name parameters, ranges, Standards by version, and Γ_time.
• Factor common conditions. Use Refit to normalize units and factor shared predicates; do not widen by stealth.
• Partition support lines. If you plan a SpanUnion, document independence up front.
• Keep scope thin & honest. Publish what you can support; add slices as support appears (ΔG+).
• Design Bridges early. When interop is planned, sketch mapping characteristics and expected CL; plan R penalties.

#Review anti‑patterns & fixes

#Minimal DSL snippet for scope blocks (illustrative)

claimScope:
  Context: MaterialsLab@2026
  Standards:
    - rig: Calib-v3
    - api: v2.3
  env:
    substrate: Al6061
    temp: [120, 150] # °C
    dwell: { max: "2h" }
  gamma_time: { window_days: 365 }

(Illustrative only; the specification does not mandate a particular syntax.)

#Profiles as Scope configurations (informative)

Idea. A Scope profile is a named, editioned configuration that expands to a concrete U.Scope predicate block (over U.ContextSlice), used to avoid repetition and to keep declarations consistent across carriers.

Rules.

• P1 (Expansion). Profiles are macros: guards MUST expand them to explicit predicates before evaluating Scope covers TargetSlice.
• P2 (Edition). Profiles are editioned; changing a profile’s predicates is a content change for any carrier that references it.
• P3 (No stealth widen). A profile update MUST NOT implicitly widen a carrier’s published scope; ΔG+ must be explicit in that carrier.
• P4 (Bridge awareness). If a profile implies Cross‑context use, it MUST name the Bridge and CL policy; CL penalties apply to R only.
• P5 (Locality). Profiles are context‑local conveniences; they do not introduce new scope types.

Examples (illustrative).
— An engineering context defines Ops‑Lab‑v3 as a profile pinning Standards, environment selectors, and a rolling Γ_time policy; claims, capabilities, and publications may reference it as a shorthand.
— A publication stack defines TechCard‑Lite@Σ as a profile that narrows U.PublicationScope to slices where required pins are available.

#Governance Hooks & Audits

#Governance metadata (normative)

Contexts that adopt USM SHALL record, per scope‑aware decision:

• Owner. Episteme (for Claim scope) or Capability (for Work scope).
• TargetSlice tuple. Context, vocab/roles, versioned Standards, environment selectors, Γ_time.
• Guard outcomes. Membership result, Bound measures (for Work scope), Freshness predicates (R).
• Bridge info (if any). Mapping summary, CL, loss notes, applied R penalty.
• ΔG log. Widen/narrow/refit; edition policy outcome.

#USM compliance levels (informative)

• USM‑Ready. Context declares adoption; editors trained; lexicon updated.
• USM‑Guarded. All ESG/Method–Work guards use Claim/Work scope and Γ_time.
• USM‑Auditable. Decision records include TargetSlice tuples and Bridge/CL details.
• USM‑Composed. Serial intersection and SpanUnion are implemented in composition tooling.

#Audit checklist (informative)

• Does each guard name a concrete TargetSlice?
• Is membership deterministically recomputable from published predicates?
• Are freshness and coverage separate predicates?
• For Cross‑context use: is there a Bridge with CL and loss notes?
• For parallel support: is independence justified?

#Risk controls (informative)

• Silent widening. Require ΔG+ review; flag any scope increase without new support/Bridge.
• Opaque slices. Disallow “domain” placeholders; enforce addressable selectors.
• Time drift. Require Γ_time policies (rolling windows) for time‑sensitive scopes.

#Cross‑Pattern Coordination

#With F–G–R (C.2.2)

• G is Claim scope. Use set algebra (∩ / SpanUnion).
• F remains the expression rigor (C.2.3); R captures evidence freshness and CL penalties.
• Weakest‑link. On dependency paths: F_composite = min(F), R_composite = min(R); G follows §7.2–§7.3 (set rules).

#With Formality (C.2.3)

• No conflation. Raising F does not change G unless scope predicates change.
• Guarding rigor. ESG may use U.Formality ≥ F_k alongside scope coverage.

#With Work & Run (A.15)

• Work scope aligns with the execution context of U.Work.
• Method–Work gates use Work scope coverage plus measures and qualification windows.

#With Bridges & CL (Part B)

• CL only impacts R. CL penalties reduce trust; they never rewrite F or G.
• Best practice. Narrow mapped scopes where mapping losses are material.

#With Capability governance (A.2.2)

• Capabilities MUST declare Work scope, measures, qualification windows; gates MUST verify all three.
• Capability refits that preserve the set (unit changes) are Refit, not Δ(WorkScope).

#Extended FAQ (informative)

Q1. Is “Claim scope” the same as “domain”? No. “Domain” is descriptive and often fuzzy. Claim scope is addressable: it names concrete U.ContextSlice conditions and a Γ_time policy. Guards MUST reference slices, not generic “domains”.

Q2. How do we express partial coverage across different cohorts or platforms? Declare each supported serial scope (S₁, S₂, …) and publish SpanUnion({Sᵢ}) with independence justification. Do not include unsupported slices.

Q3. Can raising F (formalizing) widen G? Only if the formalization explicitly changes the scope predicates (ΔG+). Formalization alone does not widen scope.

Q4. What is the difference between Work scope and SLOs? Work scope is where the capability can deliver; measures within the guard are what it promises there (SLO targets). Both are required at use time (WG‑1..3).

Q5. Can we assign numeric coverage to G? Not normatively. G is set‑valued. You MAY attach an informative, explicitly declared CoverageMetric(G) (e.g., a proportion under a pinned policy) to aid R assessment, but guards use set membership and CoverageMetric(G) MUST NOT replace G.

Q6. How do we handle “latest data” scopes? You don’t. Declare a Γ_time policy (e.g., rolling 90 days). “Latest” is forbidden to ensure reproducible evaluation.

Q7. How do we move a scope to another Context? Declare a Bridge with CL and loss notes; compute translate(Bridge, Scope); apply CL penalty to R; consider narrowing the mapped set.

Q8. What about abstraction level or detail? Keep AT (AbstractionTier) and D (Detail/Resolution) as orthogonal, optional annotations. They never substitute for Claim/Work scope.

Q9. Can a capability’s Work scope be broader than a predecessor claim’s Claim scope on a dependency path? They are on different carriers. In a serial dependency, the effective scope is the intersection; the broader one does not dominate.

Q10. When does an empty scope make sense? It indicates “not usable anywhere (here, now)”. Guards MUST fail. This is common during early drafting or after a refutation.

#Annexes (informative)

#Legacy → USM dictionary

(Use legacy terms only in explanatory notes; not in guards or conformance text.)

#Minimal data model hints

ContextSlice tuple (suggested keys): Context, vocabId, rolesetId?, Standards: [{name, version}], env: {param: range/value}, gamma_time: {point|window|policy}.

Claim scope block: assumptions, cohorts, platforms/Standards, env, gamma_time.

Work scope block: conditions (env/platform/Standards), measures (targets & units), validity_windows, gamma_time.

(These are informative; the spec does not mandate a concrete serialization.)

#Pseudocode membership (illustrative)

def covers(scope: Set[Slice], target: Union[Slice, Set[Slice]]) -> bool:
    if isinstance(target, Slice):
        return target in scope
    return target.issubset(scope)

#A.2.6:17. 4 Rationale - F‑Cluster Unification for A.2.6 (F.17 / F.18)

Intent. This annex applies the F‑cluster method to triangulate USM terms against a diverse set of post‑2015 sources and communities (“Contexts”), and then fixes the Unified Tech and Plain names used in A.2.6. Results are ready for downstream lexicon entries (Part E) and guard templates (ESG / Method–Work).

#F.17 Unified Term Survey (UTS) — Method & Scope

Contexts surveyed (SoTA, diverse):

1. ISO/IEC/IEEE 42010 (architecture description)
2. OMG Essence (Kernel: Alphas, Work Products, States)
3. NIST AI RMF 1.0/1.1 (trustworthy AI)
4. ASME V&V 40–2018 / FDA 2021–2023 (model credibility)
5. W3C SHACL (2017+) / SHACL‑AF (data constraints)
6. OWL 2 / ontology engineering (2012+, current practice)
7. IETF BCP 14 (RFC 2119/8174) (normative keywords & guard style)
8. DO‑178C + DO‑333 (avionics, formal methods supplement)
9. ISO 26262:2018/2025 (automotive functional safety)
10. IEC 61508 (2010+, current revisions) (basic safety)
11. ACM Artifact Review & Badging v1.1 (reproducibility signals)
12. MLOps/Cloud SLO practice (SRE / platform) (operational guardrails)

Survey focus (terms we align): U.ContextSlice, generic Scope and set algebra, Claim scope (G), Work scope, Bridge & CL, Γ_time, widen/narrow/refit/translate, SpanUnion / serial intersection, separation from F and R, avoidance of overloaded validity/operation terms.

#UTS Table (F.17) — Cross‑context term mapping

Summary. Across all Contexts, two stable notions recur: (1) evaluate in a concrete context (→ U.ContextSlice), and (2) declare where something holds/is deliverable (→ set‑valued Scope). “Context of use,” “operating modes,” “targets,” “class extension,” and “OSED” are all Context‑flavored presentations of Claim scope or Work scope. Terms like validity and operation are semantically close but collide with LA and FPF’s Work/Run lexicon; we therefore do not adopt them as characteristic names.

#F.18 Term Selection — Unified Tech & Plain names

#Selected names (normative)

Why these names (decision grounds):

• “Scope” wins over “envelope/applicability/validity”. It is short, self‑documenting, and already idiomatic in SRE/SW, while “validity” clashes with Validation Assurance (LA) and “envelope” suggests geometry, not membership.
• “Claim scope” vs “Work scope”. Two‑word compounds meet the FPF clarity rule: the first token reveals the carrier (Claim vs Work/Capability), the second the mechanism (scope).
• Keep G. The F–G–R triple is canonical; we retain G as nickname for Claim scope.
• “Context slice” is the only term that makes the evaluation target addressable (Context, versions, params, Γ_time).
• “Operation/operating/validity” avoided. They are overloaded in existing FPF lanes (Work/Run, LA) and create policy ambiguities in guards.

#Phrasebook (for editors, normative)

• Use “Claim scope (G) covers TargetSlice” and “Work scope covers JobSlice” in guards.
• Always spell Γ_time; never say “latest”.
• To compose, say: “intersection along dependency paths; SpanUnion across independent support lines.”
• For Cross‑context use, say: “via Bridge; CL penalties apply to R (trust), not to F/G (content/scope).”
• When widening/narrowing, write “ΔG+ / ΔG−” and log the support change; use “Refit” for unit/param normalization.

#Rosetta summary (informative, for rationale box)

Outcome. The UTS shows strong convergence across SoTA Contexts on addressable context and set‑valued applicability. F.18 therefore fixes: Context slice, Scope, Claim scope (G), Work scope, Publication scope with the algebra and guard clauses mandated in A.2.6. This closes synonym drift while remaining readable for engineering managers and precise for assurance tooling.

#A.2.6:End