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

A.2.6 · Stable · Ontic pattern · Part A - Kernel Architecture Cluster

#About this pattern

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

#How to use this pattern

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

Status: Stable Type: Ontic pattern

U.ContextSlice and U.Scope are the durable USM values for scope work. U.ClaimScope, U.WorkScope, and U.PublicationScope are C.3-governed scope specializations under U.Scope, not independent root ontics. ContextSliceSet := Set[U.ContextSlice] is the mathematical ValueKind whose values are exact sets of independently identified context slices; it is neither a durable scope nor another U-kind. Each exact U.Scope has one ContextSliceSet value as its extension under the effective reference scheme. GammaTimePolicy, work-measure target sets, qualification-window policies, formality thresholds, detail values, abstraction-tier values, scope profiles, coverage metrics, guards, reports, and publication views remain policy values, characteristic values, non-U records, lenses, guard facets, or publication forms unless a direct governing pattern admits them. Dotted forms such as U.Mechanism.Intension name the intension slot or intension form governed by U.Mechanism and A.6.1; they do not admit a separate structural U-kind.

#Relations

#Content

#Kind Settlement

U.ContextSlice and U.Scope are the durable USM values for scope work. U.ClaimScope, U.WorkScope, and U.PublicationScope are C.3-governed scope specializations under U.Scope, not independent root ontics. ContextSliceSet := Set[U.ContextSlice] is the mathematical ValueKind whose values are exact sets of independently identified context slices; it is neither a durable scope nor another U-kind. Each exact U.Scope has one ContextSliceSet value as its extension under the effective reference scheme. GammaTimePolicy, work-measure target sets, qualification-window policies, formality thresholds, detail values, abstraction-tier values, scope profiles, coverage metrics, guards, reports, and publication views remain policy values, characteristic values, non-U records, lenses, guard facets, or publication forms unless a direct governing pattern admits them. Dotted forms such as U.Mechanism.Intension name the intension slot or intension form governed by U.Mechanism and A.6.1; they do not admit a separate structural U-kind.

One-line summary. A.2.6 lets a practitioner test one exact U.ContextSlice against one exact set-valued scope. For a claim, ask member(slice, claimScope): true admits the claim-scope condition, false stops that use, and unknown means the available evaluation cannot decide. The predicate is not a U.Relation occurrence, and the evaluation work or result record does not make membership true.

Use this pattern when a receiving action needs to decide whether a claim, capability, or publication use covers one exact combination of standards, environment, local sense, platform, cohort, or time selectors.

First useful move. Name the exact claim, its exact U.ClaimScope, and the target U.ContextSlice; evaluate membership. Stop on false. On unknown, obtain the missing evaluation input, narrow the attempted use, or abstain. Add a result episteme or table only when the receiving use needs one. If exact local senses must be translated, first name the obtaining F.9 Bridge, then state the separate affirmative C.2.1 claim for this translation's direction, rule, and tolerance. Before using the translated scope, establish evidence-based reliance through A.10 or assurance-based reliance through B.3.

What goes wrong if missed. Teams infer coverage from a document, table, “current context” label, or selected structure; treat an unevaluated slice as excluded; or mint ScopeDelimitationRelation occurrences for included and excluded slices. Those moves collapse predicate truth, evaluation, representation, and structure.

What this buys. One set-valued scope algebra supports exact membership, intersection, supported union, translation, widening, narrowing, and refit while keeping claim content, evaluation work, result epistemes, model-applicability relations, and selected structures separate. Vocabulary boundary. Use these scope names in live FPF wording:

• 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, and lanes), the only scope type is U.PublicationScope.
• The abstract architectural notion is U.Scope — a durable scope value identified extensionally through one exact ContextSliceSet value under the effective reference scheme. Intersection, SpanUnion, translation, widening, and narrowing operate on those extensions; refit changes an expression without changing the extension. U.Scope is not a U.Characteristic and MUST NOT appear in any CharacteristicSpace.

Source words such as applicability, envelope, generality, and 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. — F.9 (Bridges): use an exact obtaining Bridge only when membership content must be translated across exact local senses; a different label or reference scheme alone does not trigger translation. F.9 supplies the direct semantic relation only. The separate C.2.1 claim states the exact translation use, direction, rule, tolerance, and polarity; A.10 or B.3 governs reliance on that claim. — Part E (Publication discipline; e.g., E.17 MVPK): publication views, cards, and 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.)

#Problem frame - Purpose and Audience

This pattern gives practitioners one exact question: does this slice belong to the scope needed by this use? It applies first to claim scope and reuses the same value algebra for work and publication scopes.

The claim-bearing episteme, capability, or publication object is not the scope. It designates or uses an exact U.ClaimScope, U.WorkScope, or U.PublicationScope. The membership predicate, evaluation work, result episteme, gate, and evidence claim also remain separate.

With USM, a practitioner can:

• declare exact slice selectors and an exact scope predicate;
• evaluate membership as true, false, or currently unknown;
• combine exact scopes by intersection or independently supported union;
• translate only when exact local senses require an obtaining F.9 Bridge, a separate affirmative C.2.1 claim about this translation, and the current A.10 or B.3 reliance branch; and
• stop without inventing a relation occurrence, context object, or selected structure.

A.2.6 defines the scope values, membership predicate, mathematical scope algebra, exact reusable A.6.1 operation declarations, and use boundaries. It does not decide a gate, perform evaluation work, establish evidence, identify an A.22 structure, or prescribe which claim should widen.

#Context

#Cross‑disciplinary pressures

Modern projects couple formal specs, data‑driven models, safety cases, and operational playbooks. Each specification, model, safety case, or operational-playbook publication 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.”

#Slice-bounded reasoning

U.ContextSlice is not a bounded-context object or a part of one. It is an addressable value identified by its exact declared selector schema and selector values under the effective reference scheme: for example local senses, named standard editions, environmental values, platform or cohort selectors, and a time selector when that selector belongs to the declared schema. One scope predicate may inspect only a projection of those selectors, but that projection does not reidentify the slice.

The practical question is therefore concrete: does this exact slice belong to this exact scope? A phrase such as “inside the current context,” a project label, or a selected U.Structure does not answer it.

#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 carries evidence and reliance currentness. Observed semantic mismatch or loss may be evidence about a proposed translation, while the permitted-loss tolerance belongs to the separate C.2.1 claim about that use.

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. Translation opacity. Exact local-sense translation was confused with ordinary designation resolution, causing automatic Bridge use and hidden changes to the supported slice set.
5. Overloaded words. Validity clashed with Validation Assurance (LA); operation and operational clashed with Work and Run in A.15, producing governance ambiguity.

#Forces

#Solution - Overview

USM keeps the following things distinct:

• U.ContextSlice - one addressable value identified independently of the predicate that later inspects it;
• ContextSliceSet - the mathematical ValueKind Set[U.ContextSlice], used for scope extensions and finite target sets;
• U.Scope - one durable scope value whose extension is one exact ContextSliceSet value;
• U.ClaimScope, U.WorkScope, and U.PublicationScope - C.3 specializations for claim, capability, and publication uses;
• membership semantics, mathematical scope algebra, and reusable operations - three separate layers: the bivalent predicate, its C.29 set representations, and the exact A.6.1 declarations used only when a receiving use needs an actual application and binding. None is a field or relation occurrence stored on the object being checked.

The primitive claim-scope question is member(x, S) for exact slice x and exact scope S. Intersection handles serial dependence. spanUnion is allowed only for independently supported areas. widen and narrow change the extension; refit preserves it while changing only a scope expression or parameterization. translate is used only when exact local-sense content must cross an obtaining F.9 Bridge and a separate affirmative C.2.1 claim names this translation's direction, rule, and tolerance. A receiving guard relies on that claim only through the current passing A.10 branch or positive B.3 branch; a different label or reference scheme alone selects none of these.

One exact U.ClaimScope may participate in a ModelApplicabilityRelation. That relation, its actual obtaining extent, a selected A.22 structure, a membership evaluation, and a table displaying members remain separate.

Lexical commitments. In normative text and guards, use Claim scope (G), Work scope, and Publication scope. Source words such as applicability, envelope, generality, capability envelope, or validity may remain only when quoted or explained; they do not name additional scope kinds.

#Normative Definitions

#Predicate semantics, mathematical algebra, and A.6.1 operations

Keep three layers explicit:

1. Scope semantics. member(x,S) is a bivalent predicate over one exact U.ContextSlice and one exact U.Scope.
2. Mathematical representation. The formulae below represent membership and set operations under C.29. Operand order and notation do not declare an operation application or create a scope.
3. Reusable actual operations. When a receiving use needs one identified calculation or evaluation application and its bound result, use one of the exact A.6.1 OperationDeclarations below. These are argument and result declarations, never A.6.5 SlotSpecs.

Mathematical semantics.

member(x, S)                        : Bool
scopeSubset(S1, S2)                 := for every x, member(x,S1) implies member(x,S2)
coversSet(S, T)                     := for every x in T, member(x,S)
extension(intersect(F))             := intersection of extension(S) for S in F
extension(SpanUnion(F))             := union of extension(S) for S in F
extension(translate(B,C_use,S,RS))  := the target-slice image of extension(S) selected by C_use's rule and tolerance over Bridge B under RS
widen(S0,S1)                        := extension(S0) proper-subset extension(S1)
narrow(S0,S1)                       := extension(S1) proper-subset extension(S0)
refit(E0,E1,S)                      := expressions E0 and E1 both designate exact scope S

Here T : ContextSliceSet is a finite target set, F : Set[U.Scope] is a finite scope family, B is an exact obtaining F.9 Bridge, C_use is the exact current C.2.1 claim with B as EntityOfConcern and affirmative polarity for this named scope-translation use, and RS is the exact target reference scheme. The claim's content names the direction, scope-correspondence rule, and permitted-loss tolerance used to select the target image; its effective ReferenceScheme makes those designations interpretable. scopeSubset, coversSet, widen, narrow, and refit are mathematical predicates or comparison classifications, not actual A.6.1 operations in this edition. The formula represents the claim's proposed mapping but proves neither the claim nor reliance on it and declares no operation application. Work that authors or compares scope declarations remains separately governed.

A.6.1 declaration A — ScopeMembershipEvaluationMechanism.

• EntityOfConcernRef: exact operation family ScopeMembershipEvaluationOperationFamily = {evaluateMembership}.
• effective U.ReferenceScheme: the scheme under which this mechanism's argument, result, and application meanings are interpreted.
• SubjectKind: U.Scope.
• RangedValueKind: U.ContextSlice.
• ResultKind: declaration-local finite U.Kind MembershipEvaluationValue = {true, false, unknown} under C.3. Its membership rule admits exactly those three values. It is not a world-side third truth value, public U-kind, gate decision, or result episteme.
• SliceSet and ExtentRule: absent; membership of the kind U.Scope is not slice-dependent in the A.6.0 sense.

OperationDeclaration evaluateMembership:

ApplicationPredicate: with those bindings, evaluate member(targetSlice, scope) under the bound interpretation basis; return true or false when the basis determines the predicate and unknown when a required selector resolution or translation input is unavailable. The application neither makes membership true nor changes either argument.

ApplicationIdentityRule: one application is one independently bounded evaluation invocation selected by the current calculation or evaluation-work locus. Repeating the evaluation with the same arguments is another application when another invocation occurs; argument equality alone does not merge them.

ApplicationExtentRule: the application begins when its exact argument bindings and interpretation basis are fixed for the invocation and ends when membershipJudgment is returned or the invocation stops without a result. A result binding cannot begin before the value is returned.

ScopeMembershipEvaluationMechanism LawSet. With the same exact argument bindings, interpretation basis, and effective reference scheme, evaluation is deterministic. true reports that the basis determines member(targetSlice, scope); false reports that it determines non-membership; unknown reports only that it cannot determine either result. No returned value changes the bivalent predicate.

ScopeMembershipEvaluationMechanism AdmissibilityConditions. Admit an application only after the exact slice, exact scope, and exact interpretation basis are bound. unknown is admitted when that basis records an unavailable required selector resolution or translation input. A missing exact scope, slice, or basis blocks the application rather than creating a guessed binding.

ScopeMembershipEvaluationMechanism Applicability. Use this declaration only for evaluating exact U.ContextSlice and U.Scope values under its effective reference scheme. The receiving use names its exact U.ClaimScope, selected evaluation time when current, selected CHR:ReferencePlane only when the use is plane-dependent, and any mechanism-specific condition; it does not replace them with generic context wording.

ScopeMembershipEvaluationMechanism SignatureManifest (optional). When dependency replay needs it, name the actual imported or provided declarations for U.ContextSlice, U.Scope, and the local MembershipEvaluationValue. A list of nearby policies or operands is not a second operation signature.

ScopeMembershipEvaluationMechanism neighboring objects. An evaluation application can occur within dated work governed by A.15.1. A separately persisted result episteme remains optional under C.2.1; A.15.PROD enters only for a current claim that work first constituted that episteme. Evidence-use and gate occurrences stay under A.10 and A.21. None of those objects, nor another evaluation invocation, reidentifies this mechanism unless it reveals changed declaration content.

ScopeMembershipEvaluationMechanism refinement or conservative extension. A refinement preserves evaluateMembership, its argument and result meanings, binding rules, application predicate, identity and extent, and the bivalent-truth boundary while stating every strengthened law or admission condition. A conservative extension adds exact optional arguments, results, or operations without changing those inherited meanings or admitted uses.

A.6.1 declaration B — ScopeDerivationMechanism.

• EntityOfConcernRef: exact operation family ScopeDerivationOperationFamily = {deriveIntersectionScope, deriveSpanUnionScope, deriveTranslatedScope}.
• effective U.ReferenceScheme: the scheme under which this mechanism's operation meanings and returned scopes are interpreted.
• SubjectKind: U.Scope.
• RangedValueKind: U.Scope; each derivation operation still returns a U.Scope, so no distinct mechanism-level ResultKind is current.
• SliceSet and ExtentRule: absent for the same A.6.0 reason stated above.

ApplicationPredicate rules. deriveIntersectionScope returns the scope represented under C.29 by intersection of extension(S) for S in scopeFamily. deriveSpanUnionScope implements the already established SpanUnion: it is admitted only when independenceBasis establishes the section 7.3 independence condition and returns the scope represented by SpanUnion(scopeFamily). deriveTranslatedScope is admitted only when the bound Bridge obtains and the bound C.2.1 claim has that Bridge as EntityOfConcern, affirmative polarity, and content naming this scope-translation use, its direction, rule, and tolerance. The application applies that rule within that tolerance and returns the scope represented by translate(bridgeOccurrence, scopeTranslationClaim, sourceScope, targetReferenceScheme). The formulae and claim alone declare no application or result binding.

For every governed-reference argument, record presence, citation, or a compatible token is insufficient: the reference must resolve to the exact value actually used. For every result row, the result binding obtains only when that exact application returns the independently identifiable extensional scope. The application and formula do not constitute that scope or make any membership predicate true.

ApplicationIdentityRule: each derivation application is one independently bounded calculation invocation identified through its exact invocation boundary, mechanism edition, and operation designator rather than the argument tuple alone. Repeated calculations with equal arguments remain distinct applications.

ApplicationExtentRule: the application begins after every required argument is bound for that invocation and ends when the derived-scope value is returned or the invocation stops without a result. A result-binding extent cannot begin before that scope value is returned.

ScopeDerivationMechanism LawSet. Serial composition uses intersection. Parallel publication uses the one established SpanUnion and preserves only slices supplied by independently supported lines. Translation returns only the target-slice image selected by the bound claim's rule and tolerance over the bound obtaining F.9 Bridge. No derivation operation widens support by itself.

ScopeDerivationMechanism AdmissibilityConditions. Intersection and SpanUnion require at least two exact scopes. deriveSpanUnionScope additionally requires the bound independence basis to meet section 7.3. deriveTranslatedScope requires both an exact obtaining Bridge and the exact affirmative C.2.1 claim whose named rule and tolerance select the claimed target image. A missing or non-obtaining Bridge or a missing or non-affirmative claim blocks that positive derivation application rather than creating a guessed scope; the latter does not negate an otherwise obtaining Bridge.

ScopeDerivationMechanism Applicability. Name the exact source scopes and reference schemes required by the selected derivation. For translation, also name the bound Bridge and separate C.2.1 claim. Before a receiving guard, assertion, publication, or structure selection relies on the returned scope, require either the exact A.10 evidence-provenance graph relation plus RelianceDisposition=pass for this bounded use, or a current positive B.3 assurance claim that carries this bounded assurance use and has its sufficient minimum reliance safety assurance record. Enter B.3 when an assurance claim is being made or its material-reliance threshold is met, and decide first whether a current assurance claim exists. The threshold requires the minimum record but does not create a positive claim.

A missing or non-affirmative use claim, a non-passing A.10 disposition, or a B.3 no-assurance-claim, insufficient-record, narrowed, rejected, withdrawn, abstaining, or blocked disposition stops or narrows the receiving use without changing membership truth or the Bridge. An A.10 pass or positive B.3 assurance claim supports reliance only for its named use; neither is legal, policy, or deontic authorization, and neither proves that a derivation application or another receiving object occurred. Any required authorization remains under its direct governor. The receiving use also names its exact U.ClaimScope, selected time when current, selected CHR:ReferencePlane only when plane-dependent, and derivation-specific conditions. GammaTimePolicy enters only when time changes membership; ReferencePlane is absent from ordinary set algebra.

ScopeDerivationMechanism SignatureManifest (optional). When dependency replay needs it, name the actual imported or provided declarations for U.Scope and, for translation, the exact F.9 Bridge declaration and C.2.1 claim identity rules. The independence basis, particular Bridge, and particular scope-translation claim are application arguments, not declaration-manifest entries by adjacency. scopeTranslationClaim is only this declaration's argument label; it names no public claim kind. A.10 and B.3 reliance objects remain under their direct owners rather than becoming a common mechanism signature.

ScopeDerivationMechanism neighboring objects. A derivation can occur within dated calculation work governed by A.15.1. Its bound independence-basis episteme, Bridge, and C.2.1 scope-translation claim retain their own identities and direct governors. The exact A.10 relation and disposition or B.3 claim and record govern reliance on the use claim; they are neither mechanism arguments nor results. The returned U.Scope is independently identified by its extension; neither the application nor its C.29 formula constitutes it. Evidence, publication, gate, assurance, and any downstream Work, assertion, relation, or publication occurrence remain with their direct owners. None of those objects, nor another derivation invocation, reidentifies this mechanism unless it reveals changed declaration content.

ScopeDerivationMechanism refinement or conservative extension. A refinement preserves the inherited derivation operations, argument and result meanings, binding rules, application predicates, identity and extent, and the intersection, SpanUnion, and translation semantics while stating every strengthened law or admission condition. A conservative extension adds exact optional arguments, results, or operations without changing those inherited meanings or admitted uses.

Relation between the declarations. These are two independently identified U.Mechanism epistemes, not sections of an undeclared common parent. They coordinate by value: a later evaluateMembership application may bind a scope returned by one derivation application. That reuse does not merge the mechanism identities. If a receiving claim needs a refinement, extension, equivalence, or other direct relation between exact mechanism editions, state its endpoints, predicate, scope, and preserved and changed content under A.6.1; adjacency supplies no relation.

#U.ContextSlice - exact membership target

U.ContextSlice is an addressable durable value formed from one exact declared selector schema and one value for every selector present in that schema. A scope predicate may inspect a declared projection of the slice, but it does not determine the slice's identity. A minimal slice declaration contains:

ContextSlice:
  effectiveReferenceScheme:
  declaredSelectorSchema:
  exactLocalSenseRefs?, when included by that schema:
  standardOrInterfaceEditionRefs?, when included by that schema:
  environmentOrPlatformSelectors?:
  cohortOrJurisdictionSelectors?:
  gammaTime?, when included by that schema:
  otherDeclaredSelectors?:

The slice is one value, not a finite set and not a U.BoundedContext, selected structure, project, system part, or description. A finite target is one value of mathematical ValueKind ContextSliceSet. Two slice designators resolve to the same U.ContextSlice exactly when their declared selector schemas match and every declared selector resolves to the same value under the effective reference scheme. A predicate's current argument projection, missing evaluation input, or receiving action cannot merge or split slice identity.

For example, slice_A and slice_B may share substrate Al6061, temperature 140 °C, and rig edition Calib-v3 while carrying different declared cohort selectors. A temperature-only scope predicate can return the same result for both slices, but the slices remain distinct; a cohort-sensitive predicate can distinguish them without reidentifying either one.

Do not write an implicit “current” or “latest” selector. If time changes membership, name the exact point, interval, or policy. If time does not change membership, do not add a fictitious temporal field merely to complete the tuple.

#U.Scope - set-valued scope

U.Scope is a durable value with one exact extension of mathematical ValueKind ContextSliceSet. U.ClaimScope, U.WorkScope, and U.PublicationScope are its C.3 specializations for receiving uses; the specialization does not copy the extension or add another identity discriminator. A scope is not its predicate expression, a U.Characteristic, U.Structure, collection holon, context, description, representation, or direct relation occurrence.

For exact scope S and exact slice x, the primitive delimitation semantics is:

member(x, S)

The predicate has the exact slice and exact scope as arguments. It is not by itself an explicitly individuated U.Relation occurrence. Included slices satisfy it; excluded slices do not. The excluded area is not materialized as an unbounded complement entity.

For effective reference scheme RS, define extension_RS(S) := { x : U.ContextSlice | member(x, S) }. Two scope designators resolve to the same extensional U.Scope value when their extensions contain exactly the same independently identified slices under the same or explicitly reconciled reference scheme. An equivalent predicate expression, unit conversion, factoring, or publication change can preserve that value; a boundary change that adds or removes even one slice identifies another scope value.

A set or predicate expression, table, diagram, or query result can represent or designate a scope or a set of evaluated slices under C.29 and C.2.1. Its form does not make membership true, identify the scope by syntax, or create a membership occurrence.

USM admits subset, intersect, spanUnion, translate, widen, and narrow over exact scope extensions. refit is a same-extension normalization: it changes a predicate expression, units, or factoring while preserving member(x,S) for every exact slice under the effective reference scheme. A changed expression may require another declaration or claim-bearing episteme edition under its direct governor; it identifies another U.Scope only when the extension changes.

If a future receiving use genuinely requires stable identity for membership occurrences, A.2.6 must first declare a direct relation kind with exact participant meanings, obtaining condition, recurrence rule, and non-optional occurrence-identity rule under A.6.REL. Until then, do not use ScopeDelimitationRelation, ScopeDelimitationMode, or ScopeDelimitationInterval.

#U.ClaimScope (G) and membership evaluation

U.ClaimScope is the exact set-valued scope used to say where one claim holds. The claim-bearing U.Episteme and the scope value are distinct; the episteme designates the exact scope current for that claim.

An evaluation of member(x, S) is also separate:

• the predicate semantics determine membership;
• an exact system performs dated evaluation work by an exact method, using a direct evaluation relation or A.6.1 operation binding;
• a separately current C.2.1 result episteme may state true, false, or unknown;
• evidence and freshness claims remain under A.10 and their direct governors.

unknown reports that the evaluation cannot currently decide because a required selector, designation resolution, or translation input is unavailable. It does not mean false, does not exclude the slice, and does not create a third world-side membership state. A receiving guard abstains, narrows the attempted use, or follows an explicitly governed reliance policy; it does not rewrite the predicate.

One exact U.ClaimScope participates in ModelApplicabilityRelation when model applicability is current. A declared ModelApplicabilityInterval belongs to an assertion or occurrence description. The actual applicability occurrence uses the maximal continuous extent over which its predicate obtains, as governed by A.1.1; the interval is not another direct participant.

A BoundedModelUseStructure may be selected over exact model-applicability and other governed relation occurrences under applied constraints that refer to exact claim-scope values. Keep three routes distinct. A bare scope, slice, membership outcome, or displayed boundary never enters A.22 identity. One exact U.ClaimScope remains a participant of an independently governed ModelApplicabilityRelation; when that exact obtaining occurrence is selected into the structure, the occurrence contributes through A.22's relation-occurrence discriminator. Separately, one exact applied constraint claim may refer to that scope and contribute through A.22's applied-constraint discriminator. Neither route turns the scope into a structure constituent, a membership-relation occurrence, or a second delimiter. The same scope may participate in differently selected relation occurrences or be referenced by differently identified structures, and a changed structure does not by itself reidentify the scope.

Expression. State a Claim scope as an exact predicate or condition block over slice selectors: assumptions, parameter ranges, cohorts, platform or standard editions, exact local senses when current, and time conditions only when they change membership.

Algebra. Serial dependencies use intersection. Independently supported areas may use spanUnion with the independence basis stated. widen and narrow change the declared set; refit preserves it. translate uses the section 7.5 Bridge-plus-use-claim branch and keeps reliance separate.

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

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

Meaning. U.WorkScope is the set of U.ContextSlice values under which a capability's deliverability claim may be evaluated. Work-measure targets and qualification windows are checked separately at use time; they are not members or identity fields of the scope.

Expression. The capability declaration designates an exact U.WorkScope expressed only as conditions over U.ContextSlice: environment, versioned standards or platforms, resource regimes, exact local senses when current, and gammaTime only when time changes membership. Quantitative deliverables and qualification windows are not part of the scope value:

• Declare targets as work-measure target sets (e.g., latency <= L, throughput >= T, tolerance <= epsilon) bound in guards (WG‑2).
• Declare inspection/recertification policies as qualification-window policies bound in guards (WG‑3). The use‑time admission requires all of: WorkScope covers JobSlice AND WorkMeasures satisfied AND qualificationWindowHolds(capability, qualificationWindowPolicy, evaluationTime).

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 Delta-moves. Work scope uses the same algebra as Claim scope (intersection / spanUnion / translate / widen / narrow / refit). Section 7.5 selects translate only for exact local-sense translation through an obtaining F.9 Bridge plus the separate affirmative C.2.1 claim and its current reliance branch.

Separation from knowledge. A Work scope is a set-valued scope, not an assertion. The capability declaration uses it to delimit where a deliverability claim is evaluated. Measurements and monitoring may support that claim through separately governed evidence and reliance judgments; they do not make a slice a member.

Required guard facets (capabilities).

• Work-measure target set (mandatory). A set of measurable targets with units and tolerated ranges, evaluated on the JobSlice.
• Qualification-window policy (mandatory for operational use). A time policy stating when the capability is considered qualified; evaluated at the exact evaluation time selected by the receiving guard, not copied into U.WorkScope. 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 or publication form

Carrier. Publication faces, publication forms, interop publication forms, cards, lanes, and MVPK faces are publication-lane objects whose renderings live on carriers; the carrier remains separate from the publication view or form. Meaning. The set of U.ContextSlice where a publication (a view, card, or 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, its scope is a subset of the intersection of the exact contributing scopes. When exact local senses require translation, use section 7.5 for each affected source scope: obtaining F.9 Bridge, separate affirmative C.2.1 use claim, and current A.10 or B.3 reliance before the returned scopes are intersected.

Expression. Declare U.PublicationScope as an exact predicate over only the U.ContextSlice selectors that restrict publication use: for example versioned standards, environment, audience, interface availability, exact local senses, or gammaTime when time changes membership. It may be narrower than the underlying scope but must not be wider.

Algebra and Delta-moves. Publication scope uses the USM algebra. A widened publication scope is admissible only when the resulting set remains a subset of every relevant underlying Claim scope or Work scope and the publication conditions support each added slice; the underlying scope need not change when it was already broader.

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 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. None changes predicate truth by being performed, recorded, or displayed.

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

#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 graph relation plus RelianceDisposition=pass for this bounded use; when an assurance claim is made or B.3's material-reliance threshold is met, first decide whether a current assurance claim exists, then require a current positive claim carrying this use with its sufficient minimum record, or stop or narrow the use under the exact non-positive B.3 disposition; 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, a non-passing A.10 disposition, or a non-positive B.3 branch blocks reliance on the translation without making an otherwise obtaining Bridge false.

Meeting B.3's threshold creates the minimum-record obligation, not a positive claim. A passing A.10 classification or positive B.3 assurance claim supports reliance only for the named use; neither authorizes it. 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 support only a proper subset of the source area, return that explicitly narrower target scope. 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.

#Δ‑Operations (Widen, Narrow, Refit)

• Δ‑G+ (widen). Monotone expansion: S subsetOf 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.

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

#Empty & Partial Scopes

• Empty scope (∅). No slice satisfies the declared predicate. A receiving guard stops; this does not identify a context, structure, or complement entity.
• 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

#Local interpretation without a context owner

A scope is not owned by a U.BoundedContext. Interpret its predicate under the effective reference scheme and exact local senses named by the claim or scope declaration. Evaluate it against exact U.ContextSlice values.

Do not assume that a similarly named selector elsewhere has the same sense. Use ordinary designation resolution when it suffices. Use translate only when exact local senses need an obtaining F.9 Bridge and a separate affirmative C.2.1 claim states the proposed translation's direction, rule, and tolerance; establish the current A.10 or B.3 reliance branch before acting on the returned scope.

#Time selector Γ_time

When membership depends on time, the scope predicate and target slice name an exact gammaTime point, interval, or policy and state which boundary changes a slice from member to non-member or back. Implicit “latest” is forbidden. When time does not change membership, omit the selector. Evidence freshness remains a separate R-lane predicate.

#Standards, versions & notations

When a standard, interface, or schema edition affects membership, name the exact edition. A notation change with faithful designation resolution does not change G. If exact local senses require translation, the F.9 Bridge establishes their relation, the separate C.2.1 claim states this translation's rule and tolerance, and A.10 or B.3 governs reliance; none redefines membership truth.

#Determinism of evaluation

For a fixed exact scope, exact slice, and available evaluation inputs, the evaluation method returns one reproducible result. false stops the attempted use. unknown also blocks admission but does not assert non-membership.

#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 and Run). Prefer Work and Run vocabulary from A.15 for system execution contexts. Do not introduce “operation” or “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 recognition cue, not a guard input. Name the exact U.ContextSlice selectors needed by the membership predicate.

L-USM-5 (First mention). On first use in a pattern or working instruction, write “Claim scope (G)” so the F-G-R meaning is recoverable.

#Guard Patterns (ESG & Method–Work)

#Common guard shape

A claim-scope guard starts with one exact judgment:

membershipResult := evaluateMembership(TargetSlice, ClaimScope, InterpretationBasis)

Admit the scope condition only when the result is true. Stop on false. On unknown, abstain, obtain the missing input, narrow the attempted use, or apply a separately governed reliance policy. Evidence freshness, formality, time currentness, decision, and assurance remain separate predicates.

Add a translation branch only when the membership predicate uses exact local senses that ordinary designation resolution cannot align. Require the obtaining F.9 Bridge and the separate affirmative C.2.1 claim for this translation before deriving a scope, then require the current A.10 or B.3 reliance branch before the receiving guard relies on it. A different reference scheme or location label alone is not such a trigger.

#Claim-scope guard family

EG-1 - Exact membership.

member(TargetSlice, ClaimScope) = true

Name the exact claim-bearing episteme, exact U.ClaimScope, and exact target slice. The episteme, scope, and slice remain different values.

EG-2 - Formality or evidence, only when current. A receiving state may separately require a C.2.3 formality threshold or an A.10 freshness judgment. Neither changes membership.

EG-3 - Unknown evaluation. When a required selector, designation resolution, or translation input is unavailable, return unknown as the result binding of the exact evaluateMembership application, or as the result of the directly governed evaluation when no reusable application is current. Abstain or follow the exact receiving reliance policy; do not assert member = false. Add a C.2.1 result episteme only when a named receiving use needs the conclusion to persist. Use A.15.PROD only when the current claim is that dated work first constituted that episteme.

EG-4 - Translation. When exact local senses differ, require the obtaining F.9 Bridge and the separate affirmative C.2.1 claim naming this scope translation's direction, rule, and tolerance. After the exact A.10 or B.3 branch supports reliance for that use, derive the scope with deriveTranslatedScope(SourceScope, ExactBridgeOccurrence, ExactUseClaim, TargetReferenceScheme), then use that returned scope in evaluateMembership. Scheme difference alone does not select this branch.

EG-5 - Scope-value versus declaration change. Widen or narrow only when the extension gains or loses at least one independently identified slice; that extension change identifies another U.ClaimScope. A changed predicate expression with the same exact extension is a refit: it preserves the exact scope value and may require another scope declaration or claim-bearing episteme edition under its direct governor. A result-record, table, or selected-structure change alone changes neither the scope value nor its declaration.

#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 - work-measure target set satisfied (mandatory for deliverables). Guards MUST bind quantitative measures that the capability promises in the JobSlice:

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

WG‑3 - qualification-window policy holds (mandatory for operational use). Operational guards MUST assert that the exact qualification-window predicate (qualification, inspection, or recertification) holds at the receiving guard's exact evaluation time:

qualificationWindowHolds(capability, qualificationWindowPolicy, evaluationTime) = true

WG-4 - Translation branch for capability use.

Translate U.WorkScope only when its condition predicates use exact local senses that differ from those needed by the job slice. Require the obtaining F.9 Bridge and a separate affirmative C.2.1 claim naming this Work-scope translation's direction, rule, and tolerance; establish the exact A.10 or B.3 reliance branch before the capability guard uses the result. A capability object and job slice carry no hidden .Context field that automatically selects this branch.

Observed mapping loss is evidence about the use claim, and permitted loss is its tolerance. When the claim's rule and tolerance support only a subset, return an explicitly narrower Work scope. Neither fact changes membership truth by itself.

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.

#Translation guard

Use this branch only after the exact local-sense translation need, the obtaining F.9 Bridge, and the separate affirmative C.2.1 claim for this translation are current. The claim names the source-to-receiving direction, scope-correspondence rule, and tolerated loss. Before the receiving guard relies on it, require the exact passing A.10 branch or a current positive B.3 assurance claim that carries this use with its sufficient required record.

translatedScope := deriveTranslatedScope(SourceScope, ExactBridgeOccurrence, ExactUseClaim, TargetReferenceScheme)
membershipResult := evaluateMembership(TargetSlice, translatedScope, InterpretationBasis)

The source claim-bearing episteme designates SourceScope; it does not own that value as a hidden context field. The Bridge relates exact local senses under F.9. The C.2.1 claim supplies this translation's rule and tolerance, and A.10 or B.3 supplies the separate reliance basis. None of them makes the A.6.1 operation application occur. An unmapped slice yields unknown for the attempted evaluation unless the returned scope explicitly excludes it; it is not silently dropped and reported as false.

#Time selector

Name gammaTime in the context slice only when the applicable membership predicate varies with time. State the boundary that changes membership. If a work qualification or evidence-freshness condition varies with time, name its exact evaluation time and interval or policy under that condition's direct governor rather than copying it into scope. For example, qualificationWindowHolds(controller, Recertification90d, evaluationTime) is a separate guard; it is not a scope selector.

Do not write implicit “latest.” When time does not affect membership, omit the selector instead of inventing a nominal current value.

#Archetypal Grounding - Worked Examples

#Claim-scope membership boundary

Claim-bearing episteme E_adhesive states that Adhesive X retains at least 85 percent tensile strength on Al6061 for two hours at 120-150 °C under rig edition Calib-v3. It designates exact claim scope G_adhesive.

• slice_in = {substrate=Al6061, temp=140°C, dwell=90min, rig=Calib-v3}. member(slice_in, G_adhesive) is true.
• slice_out = {substrate=Al6061, temp=160°C, dwell=90min, rig=Calib-v3}. Membership is false; the attempted use stops.
• slice_unknown = {substrate=Al6061, temp=140°C, dwell=90min, rigEdition=unavailable}. Evaluation returns unknown. It neither excludes the slice nor permits the use.

LabEvaluator_A may perform exact membership-evaluation work through the declared USM operation. When a named audit or replay use needs a judgment to persist, a C.2.1 episteme may record it. Neither the work nor the optional episteme makes membership true. A table showing the three rows is a C.29 representation and creates no ScopeDelimitationRelation.

The same G_adhesive may participate in two independently governed model-applicability relation occurrences and may be referred to by exact applied constraint claims in two A.22 structures. Only a selected obtaining model-applicability occurrence or an exact constraint claim as applied contributes through its corresponding A.22 discriminator; the common scope itself contributes through neither path and neither merges nor identifies the relations or structures. A declared applicability interval in either occurrence description is separate from the actual maximal continuous obtaining extent.

#Translation only when local senses require it

An assembly use expresses temperature through an exact local calibration sense different from the laboratory sense used in G_adhesive. F.9 Bridge B-lab-assembly-temp obtains between those two cells under its calibration-correspondence profile; the profile contains no translation-use rule or loss tolerance.

Separate C.2.1 claim C-adhesive-scope-translation has that Bridge as EntityOfConcern and affirmative polarity. Its content names use translate G_adhesive for the assembly membership check, direction laboratory-to-assembly, the calibration rule for mapping the source interval, and tolerance no selector-meaning loss and at most 2 °C boundary uncertainty.

Use that translation only while exact A.10 relation EP-adhesive-scope-translation connects the claim and that bounded use to evidence record CalibrationComparisonRecord.Calib-v3-to-AssemblyCalibration-v5.2026-07-25. Provenance edge CalibrationComparisonRecord.Calib-v3-to-AssemblyCalibration-v5.2026-07-25 --carriedBy--> CalibrationComparisonRegister.Calib-v3-to-AssemblyCalibration-v5.2026-07-25.csv names its carrier. The window runs from 2026-07-25 through 2026-10-23 and closes earlier if either calibration edition, the mapping rule, or the 2 °C tolerance changes.

The path supports neither reverse translation, a mapping outside the named rule or tolerance, nor a claim that the A.6.1 application or membership evaluation occurred. This fixture asserts no evidence-producing or evidence-interpreting Work, current role assignment, or method trace. If the record, carrier, or provenance edge is missing or stale, or the window closes, stop before translation and set RelianceDisposition=reopen; otherwise RelianceDisposition=pass applies only to this bounded use. No assurance claim is made and the use does not meet B.3's material-reliance threshold.

The actual A.6.1 application deriveTranslatedScope(G_adhesive, B-lab-assembly-temp, C-adhesive-scope-translation, AssemblyReferenceScheme) applies the named rule and tolerance and returns the explicitly narrowed receiving scope [122,148]°C. The receiving membership evaluation uses that scope. The Bridge and claim alone do not prove that this calculation occurred or that any target slice is a member.

If the receiving use merely uses another designation for the same sense under an ordinary resolvable reference scheme, introduce no Bridge, use claim, or translation.

#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, controller=FW‑2.1}.
• Job slice: {humidity=55 %, current=40A, wire=ER70S‑6, controller=FW‑2.1}.
• Qualification evaluation time: 2026-07-25, outside the Work-scope tuple.
• Guards (WG‑1..3): coverage true; measures satisfied; qualificationWindowHolds(controller, Recertification90d, 2026-07-25) is true because certification occurred on 2026-05-26.
• Outcome: capability admitted for this Work.

Controller certificate age does not change Work-scope membership in this case. When the 90-day qualification condition fails, WG-3 stops operational use without removing the Job slice from the scope.

#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 with different local feature senses

• Model claim: “AUC >= 0.92 on cohort K, pipeline P, feature sense Training.F.”
• Claim scope: {cohort=K, pipeline=P, exactLocalSense=Training.F}. No gammaTime selector is present because this example does not claim that model applicability changes with the slice time.
• Target slice: product On-Device@v7, pipeline P-prime, feature sense Device.F-prime.
• Translation trigger: ordinary designation resolution fails because Training.F and Device.F-prime have different declared semantics, not merely different labels. Exact F.9 Bridge B-training-device-feature obtains between those cells under a lossy-subset correspondence profile; the profile carries no device-use rule or tolerance.
• Bounded translation claim: exact current C.2.1 claim C-device-feature-scope-translation has that Bridge as EntityOfConcern and affirmative polarity. It names use translate the training claim scope for the On-Device@v7 membership check, direction training-to-device, the subset-mapping rule, and tolerance no feature-kind substitution and no target slice outside the tested mapped subset.
• Evidence and reliance: Before translating, verify that exact A.10 relation EP-device-feature-scope-translation connects claim C-device-feature-scope-translation and this bounded use to both records below.
  • Mapping evidence: MappingTestRecord.TrainingF-to-DeviceFprime.OnDevice-v7.2026-07-25, with exact carrier edge MappingTestRecord.TrainingF-to-DeviceFprime.OnDevice-v7.2026-07-25 --carriedBy--> MappingTestReport.TrainingF-to-DeviceFprime.OnDevice-v7.2026-07-25.json.
  • Training evidence: TrainingEvaluationEvidence.K-P-TrainingF.2026-07-25, with exact carrier edge TrainingEvaluationEvidence.K-P-TrainingF.2026-07-25 --carriedBy--> TrainingEvaluationReport.K-P-TrainingF.2026-07-25.json.
  • Window and stop: the 180-day window runs from 2026-07-25 through 2027-01-21 and closes earlier if pipeline P or P-prime, either feature-sense edition, or the tested mapped subset changes. If a record, carrier, or edge is missing or stale, the window closes, or a named dependency changes, stop before translation and set RelianceDisposition=reopen; otherwise RelianceDisposition=pass applies only to this bounded use.
  • Boundary: the path supports neither feature-kind substitution, a target outside the tested subset, material release or assurance, nor a claim that deployment occurred. This fixture asserts no evidence-producing or evidence-interpreting Work, current role assignment, or method trace. No assurance claim is made and the B.3 material-reliance threshold is not met; a material release or assurance use must instead enter B.3.
• Guard: bind translatedScope := deriveTranslatedScope(G, B-training-device-feature, C-device-feature-scope-translation, ProductReferenceScheme), then evaluate evaluateMembership(TargetSlice, translatedScope, InterpretationBasis); separately require the chosen formality predicate. The translated scope covers only the tested mapped subset. Neither the claim nor its passing reliance makes the derivation application or deployment occur.
• Outcome: admit only a target slice in the returned subset; otherwise return false or unknown according to the exact returned scope and available evaluation input.

#Bias-Annotation

USM counters three recurring biases. First, scope wording can hide a claim that the object is usable everywhere; require an addressable U.ContextSlice instead of a vague domain phrase. Second, abstract wording can be mistaken for wider scope; keep abstraction tier and detail separate from U.Scope. Third, publication convenience can be mistaken for content permission; U.PublicationScope bounds the publication surface and does not widen U.ClaimScope or U.WorkScope.

#Conformance Checklist (USM)

#Common Anti-Patterns and How to Avoid Them

#Consequences

A correct USM use makes scope checks reproducible: every judgment names an exact scope and slice, and true, false, and unknown evaluation results have different actions. Translation appears only for exact local senses after an obtaining F.9 Bridge, a separate affirmative C.2.1 claim about the proposed translation, and its current A.10 or B.3 reliance branch are distinguished. The cost is naming the selectors, mapping rule, tolerated loss, and evidence that actually affect the receiving use while keeping membership truth, operation application, result epistemes, representations, model applicability, and structure separate.

#Playbooks (Informative)

#Manager’s six-step use

1. Name the claim and exact scope. Do not start from a context label or table.
2. Name the target slice. Designate the independently identified slice; bind only the declared selector projection that this membership evaluation needs.
3. Evaluate membership. True admits the scope condition; false stops it; unknown requires abstention, a missing input, or a narrower attempted use.
4. Keep other checks separate. Formality, evidence freshness, capability measures, qualification, gate, and decision have their own predicates.
5. Translate only when needed. Name the exact local senses and obtaining F.9 Bridge; then state the separate affirmative C.2.1 claim for this translation's direction, rule, and tolerance and establish its A.10 or B.3 reliance branch before using the returned scope.
6. Persist only what the use needs. A C.2.1 result episteme may record the judgment when a named receiving use needs it to persist; a C.29 table may display it. Neither changes membership. Use A.15.PROD only when the current claim is that the work first constituted that episteme.

#Architect’s design rubric for scopes

• Prefer predicates over prose. Name the parameters, ranges, and standard editions that affect membership; name gammaTime only when time affects membership.
• 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 translations early. Test the direct F.9 Bridge first, then state each proposed translation use separately with its direction, mapping rule, tolerated loss, and evidence plan; do not turn an expected loss score into permission to use the mapping.

#Minimal DSL snippet for scope blocks (illustrative)

claimScope:
  effectiveReferenceScheme: MaterialsLabScheme@2026
  Standards:
    - rig: Calib-v3
    - api: v2.3
  env:
    substrate: Al6061
    temp: [120, 150] # °C
    dwell: { max: "2h" }
receivingGuards:
  evidenceProvenanceUse:
    relevance_window_days: 365 # A.10/R guard, not Claim scope

(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. A changed predicate expression is a content change for a carrier that references the profile even when the exact scope extension is preserved; a changed extension additionally identifies another scope value.
• P3 (No stealth widen). A profile update MUST NOT implicitly widen a carrier’s published scope; ΔG+ must be explicit in that carrier.
• P4 (Translation awareness). If a profile expands to predicates whose exact local senses require translation, name the obtaining F.9 Bridge and the separate affirmative C.2.1 claim for that translation's direction, rule, and tolerance. The receiving guard must recover the current A.10 or B.3 reliance branch; a different label, scheme, profile, or Bridge Card alone is insufficient.
• P5 (No hidden owner). A profile expands to predicates; it is not a context object, scope owner, or additional scope kind.

Examples (illustrative). — An engineering team defines Ops-Lab-v3 as a profile pinning standard editions and environment selectors. It leaves LabEvidenceRelevanceWindow365d to the receiving A.10/R guard and contains no gammaTime, because evidence age does not change scope membership. — A field team defines WinterCampaign-v1 with gammaTime in [2026-11-01, 2027-03-31] because the exact scope predicate admits only slices during the declared winter campaign; a slice before or after those boundaries is a non-member. — A publication stack defines TechCard‑Lite@Σ as a profile that narrows U.PublicationScope to slices where required pins are available.

#Governance Hooks & Audits

#Durable audit evidence, when needed

When a scope-aware decision needs durable audit evidence, its C.2.1 result episteme may name:

• Using object and exact scope. The claim-bearing episteme, capability, or publication object designates or uses the exact scope; it does not own the scope as a hidden context field.
• Exact target slice. Designate the independently identified slice with its complete declared selector schema and values. An evaluation may bind only the projection its scope predicate inspects; that projection does not replace slice identity. Include gammaTime in the schema only when that temporal selector is part of the exact slice being evaluated.
• Evaluation outcome. Record true, false, or unknown, plus the evaluation method or work occurrence when replay needs it.
• Separate guard outcomes. Record work measures, qualification windows, formality, or freshness only when the receiving use checks them; none is membership.
• Translation evidence, only when triggered. Name the exact obtaining F.9 Bridge, the separate C.2.1 claim with its polarity, use, direction, rule, and tolerance, and the exact A.10 or B.3 reliance branch. Record any observed loss as evidence rather than a Bridge identity field.
• Scope change. Say whether the declared set widened, narrowed, or remained identical under refit.

Recording these facts does not make membership true, identify the scope, or create a membership-relation occurrence.

#USM compliance levels (informative)

• USM-Ready. Exact scope and slice values are declared; editors can distinguish membership from evaluation, evidence, representation, and structure.
• USM-Guarded. Guards evaluate exact Claim scope or Work scope membership and keep measures, qualification, freshness, and gammaTime when material as separate checks.
• USM-Auditable. Durable result epistemes identify the exact scope, slice, and evaluation result. When translation was triggered, they cite the obtaining F.9 Bridge, separate bounded-use claim, and current A.10 or B.3 reliance without treating those citations as membership truth.
• USM‑Composed. Serial intersection and SpanUnion are implemented in composition tooling.

#Audit checklist (informative)

• Does each guard name a concrete TargetSlice?
• Is membership reproducibly evaluable from the exact declared predicate and required inputs?
• Are freshness and coverage separate predicates?
• When exact local-sense translation was required, are the obtaining F.9 Bridge, separate C.2.1 use claim, direction, rule, tolerance, polarity, and current A.10 or B.3 reliance branch named?
• For parallel support: is independence justified?

#Risk controls (informative)

• Silent widening. Require ΔG+ review; flag any scope increase without new direct support. A Bridge may translate supported conditions but does not supply support.
• Opaque slices. Disallow “domain” placeholders; enforce addressable selectors.
• Time drift. Require an exact gammaTime boundary only when the scope predicate itself changes membership across time; keep qualification, calibration, recertification, data-age, and evidence-freshness windows under their direct guards.

#Extended FAQ (informative)

Q1. Is “Claim scope” the same as “domain”? No. “Domain” is descriptive and often fuzzy. Claim scope is addressable: it supplies an exact predicate over the U.ContextSlice selectors that determine membership, including gammaTime only when the predicate changes membership across time. Guards reference the exact slice, not a generic domain.

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? First decide what “latest” is doing. If it means that evidence or data must be no older than 90 days, do not put it in Claim scope: require the A.10 evidence-provenance path to satisfy its exact 90-day relevance or currentness window at the receiving use time. Put gammaTime in the scope only when claim applicability itself changes with the slice time, and state the membership boundary—for example, slices whose observation time falls outside the declared interval are non-members. The word “latest” alone supplies neither boundary.

Q7. How do we use a scope with differently named slice selectors? First resolve whether the designations refer to the same values under the effective reference scheme. If exact local senses differ and membership must be expressed across them, name the obtaining F.9 Bridge. Then state the separate affirmative C.2.1 claim for the proposed translation's direction, mapping rule, and tolerated loss, establish the exact A.10 or B.3 reliance branch, and evaluate the scope returned by deriveTranslatedScope. A different project, place, label, reference scheme, profile, or card alone does not move or translate the scope. Q8. What about abstraction level or detail? Keep AT (AbstractionTier) and D (Detail and Resolution) as orthogonal, optional annotations. They never substitute for Claim scope or 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? No slice satisfies the declared predicate, so the receiving guard stops. This may occur during early drafting or after a refutation; it does not create a special context, time, or complement entity.

#Annexes (informative)

#Source wording -> USM dictionary

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

#Minimal data model hints

ContextSlice tuple (suggested keys): effectiveReferenceScheme, one exact declaredSelectorSchema, the values of every selector in that schema, and optional selector families such as exactLocalSenseRefs, standardOrInterfaceEditions, environmentOrPlatformSelectors, cohortOrJurisdictionSelectors, and gammaTime only when that selector belongs to the declared schema because membership changes across time. A scope predicate declares which projection it inspects; it does not define the tuple's identity.

Claim-scope predicate block: assumptions, cohorts, platformOrStandardEditions, environmentSelectors, exactLocalSenseRefs?, and gammaTime? when time changes membership.

Work-scope predicate block: environmentSelectors, platformOrStandardEditions, resourceRegimeSelectors, exactLocalSenseRefs?, and gammaTime? when time changes membership.

Publication-scope predicate block: the exact audience, interface, availability, and other selectors that restrict publication use, always as a subset of the underlying claim or work scopes.

Separate use-time guard: work-measure targets, qualification windows, evidence freshness, and any decision threshold. These are not fields of the scope value. (These are informative; the spec does not mandate a concrete serialization.)

#Pseudocode membership evaluation (illustrative)

def evaluate_membership(scope, target_slice, available_inputs):
    required = scope.required_selectors(target_slice)
    if not required.issubset(available_inputs):
        return UNKNOWN
    return TRUE if scope.predicate(target_slice) else FALSE

required_selectors returns the projection needed by this scope predicate; it neither creates nor reidentifies target_slice. UNKNOWN belongs to the evaluation result because a required input is unavailable. The underlying membership predicate remains bivalent for an exact, fully interpreted scope and slice.

#Rationale

A.2.6 needs a scope mechanism because scope is neither evidence freshness nor expression rigor: it is the set-valued condition under which a claim, work capability, or publication surface may be used. USM makes those membership conditions addressable, composable, and reopenable while preserving the F/G/R separation. When exact local senses require translation, F.9 supplies the Bridge, C.2.1 supplies the separate claim about this use, and A.10 or B.3 supplies reliance; A.2.6 alone governs the scope calculation and membership question.

#SoTA-Echoing - F-Cluster Unification for A.2.6 (F.17 and 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 plus a separate bounded-use claim and reliance basis, Γ_time, widen, narrow, refit, translate, SpanUnion, serial intersection, separation from F and R, and avoidance of overloaded validity and 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 or 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 and 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” keeps the evaluation target addressable through its exact declared selector schema and values; one membership predicate may inspect only a projection without reidentifying the slice.
• “Operation”, “operating”, and “validity” avoided. They are overloaded in existing FPF lanes (Work, Run, and LA) and create policy ambiguities in guards.

#Phrasebook (for editors, normative)

• Use “Claim scope (G) covers TargetSlice” and “Work scope covers JobSlice” in guards.
• When time changes membership, name exact gammaTime; never say “latest.” Omit it when time is irrelevant.
• To compose, say: “intersection along dependency paths; SpanUnion across independent support lines.”
• When exact local-sense translation is current, say: “through an obtaining F.9 Bridge and a separate affirmative C.2.1 claim for this direction, rule, and tolerance; rely on it only through the current A.10 or B.3 branch, then evaluate membership on the returned 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 clear 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.

#Relations - 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 currentness and bounded reliance. Observed loss may bear on the translation-use claim; its permitted-loss tolerance remains in that claim rather than in G or the Bridge profile.
• 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 Formality >= F_k alongside scope coverage.

#With Work & Run (A.15)

• Work scope delimits the exact job slices on which a capability's deliverability claim is evaluated; it is not the U.Work occurrence or its execution setting.
• Method–Work gates use Work scope coverage plus measures and qualification windows.

#With exact F.9 Bridge occurrences

• Translation boundary. Use an exact F.9 Bridge only for exact local-sense translation. State the translation's direction, rule, tolerated loss, and polarity in a separate C.2.1 claim, then recover the exact passing A.10 or positive B.3 reliance branch before the receiving use proceeds; none makes membership true or false by itself.
• Best practice. Return an explicitly narrower scope when the bounded-use claim's rule and tolerance support only a proper subset; do not turn observed mapping loss into a Bridge identity field or a generic R penalty.

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

#A.2.6:End

Last Updated: 2026-08-04 — upstream FPF commit 7ba40a95 (github.com/ailev/FPF)