A.2.6:10.3 - Method–Work guard families (capabilities)

WG‑1 - WorkScopeCoverage (mandatory). Reliance on a holder-ability claim for a Work step requires coverage by the WorkScope that claim designates:

WorkScope(holderAbilityClaim) covers JobSlice

WG‑2 - work-measure target set satisfied (mandatory for deliverables). Guards MUST compare the claimed attained bounds with the quantitative targets required for 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(holderAbilityClaim, 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. Neither the holder-ability claim nor the job slice supplies a hidden .Context field that automatically selects this branch.

Observed mapping loss is evidence about the use claim, and permitted loss is its tolerance. If the claim’s rule and tolerance permit translation only for part of the source Work scope, identify that part and return its target image.

WG‑5 - Δ(WorkScope). When widening Work scope (new operating ranges/platforms), the guard MUST require evidence at the new slices (measures + qualification windows). A membership-preserving refit does not itself require new deliverability evidence for the unchanged slices.