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-v3as a profile pinning standard editions and environment selectors. It leavesLabEvidenceRelevanceWindow365dto the receiving A.10/R guard and contains nogammaTime, because evidence age does not change scope membership. - A field team defines
WinterCampaign-v1withgammaTime 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 narrowsU.PublicationScopeto slices where required pins are available.