A.2.6:16 - Playbooks (Informative)

A.2.6:16.1 - 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. Bind the full independently identified slice as targetSlice; put the selector resolutions and translation inputs needed by this evaluation in interpretationBasis.
3. Translate only when needed. Use ordinary designation resolution first. If the membership predicate needs translation between exact local senses, name the obtaining F.9 Bridge and the separate affirmative C.2.1 claim for this translation’s direction, rule, and tolerance. Derive the scope for the target reference scheme and establish its A.10 or B.3 reliance branch before using the returned scope.
4. Evaluate membership. Use the returned translated scope when step 3 derived one; otherwise use the named scope. True admits the scope condition; false stops it; unknown calls for abstention, obtaining the missing input, or narrowing the attempted use.
5. Keep other checks separate. Evaluate any required freshness, formality-threshold, time-currentness and assurance conditions separately, along with capability measures and qualification when required. The gate decision remains under A.21.
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. Use A.15.PROD only when the current claim is that the work first constituted that episteme.

A.2.6:16.2 - 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.
• Publish supported scope. 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.

A.2.6:16.3 - 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.)

A.2.6:16.4 - 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 context container). A profile expands to predicates; it is not a context object, scope pattern, 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.