A.2.6:20 - Rationale
A.2.6 needs a scope mechanism to express 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.
A.2.6:20.1 - SoTA-Echoing - F-Cluster Unification for A.2.6 (F.17 and F.18)
Intent. This annex compares USM terms with usage in the sources below and explains the Unified Tech and Plain names used in A.2.6.
A.2.6:20.1.1 - F.17 Unified Term Survey (UTS) — Method & Scope
Compared sources:
- ISO/IEC/IEEE 42010 (architecture description)
- OMG Essence (Kernel: Alphas, Work Products, States)
- NIST AI RMF 1.0/1.1 (trustworthy AI)
- ASME V&V 40–2018 / FDA 2021–2023 (model credibility)
- W3C SHACL (2017+) / SHACL‑AF (data constraints)
- OWL 2 / ontology engineering (2012+, current practice)
- IETF BCP 14 (RFC 2119/8174) (normative keywords & guard style)
- DO‑178C + DO‑333 (avionics, formal methods supplement)
- ISO 26262:2018/2025 (automotive functional safety)
- IEC 61508 (2010+, current revisions) (basic safety)
- ACM Artifact Review & Badging v1.1 (reproducibility signals)
- MLOps/Cloud SLO practice (SRE / platform) (operational guardrails)
Terms compared: 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.
A.2.6:20.1.2 - UTS Table (F.17) — Cross‑context term mapping
| # | Context / Source | Local label(s) (native) | Closest USM concept | Notes on fit & deltas |
|---|---|---|---|---|
| 1 | ISO/IEC/IEEE 42010 | Architecture context; environment; stakeholder concerns; viewpoints and views | ContextSlice (addressable slice); Scope as view‑specific applicability | 42010 is about views in context; it has no first‑class set‑valued scope char but aligns with “evaluate in a concrete context” → USM uses explicit slice tuples. |
| 2 | OMG Essence | Alpha State; Work Product State; Level of Detail (LoD) | Work scope (guards), Detail (D) (LoD), ESG/RSG | Essence separates status (states) and work evidence; LoD is detail, not scope. USM treats scope as guardable membership over slices; states/LoD map to ESG & D, not to G. |
| 3 | NIST AI RMF | Context of use; validity, reliability, robustness; monitoring | Claim scope (G); R freshness/monitoring | “Context of use” = where a claim/model holds → maps to G. “Validity” is part of R vocabulary; we avoid naming the characteristic “validity” to prevent LA confusion. |
| 4 | ASME V&V 40 / FDA | Context of use; credibility factors; verification/validation | Claim scope (G); R (credibility) | Direct fit for G via “context of use”. Credibility/evidence freshness contribute to R, not to G; USM keeps them separate in guards. |
| 5 | W3C SHACL | Shapes; targets (sh:targetClass, sh:target); constraints | Claim scope (targets define where constraints apply); F≥4 (predicate form) | SHACL “target” ≈ membership predicate on a dataset context; analogue of Claim scope on data slices; constraint language supports F4‑style predicates. |
| 6 | OWL 2 practice | Class extension; domain/range; imports/version IRI | Claim scope as class extension over an ontology context | Class extension is set‑semantics by design; G maps to extension over a versioned ontology (part of ContextSlice). |
| 7 | IETF BCP 14 | MUST/SHALL/SHOULD; requirements language | Guard style (observable predicates) | BCP 14 doesn’t define scope but dictates how guards are worded; USM aligns by requiring observable, deterministic membership checks. |
| 8 | DO‑178C / DO‑333 | Operational conditions; DAL; formal method objectives; TQL | Work scope (operating conditions); F (proof‑grade), R (assurance objectives) | Operational applicability = Work scope; formal method objectives lift F; Tool qualification impacts TA/R, not G. |
| 9 | ISO 26262 | Operational situation & operating modes; ASIL; OSED | Work scope (operating modes/situations) | OSED/operating modes define where capability can be exercised → Work scope. Assurance level (ASIL) relates to R, not G. |
| 10 | IEC 61508 | SIL; demand mode; proof test interval | Work scope (demand vs continuous mode) + R freshness | Mode concepts influence where/how a function can be claimed → Work scope; proof test interval sits in R (freshness/decay). |
| 11 | ACM Artifacts | Available/Evaluated/Reusable; Reproduced/Replicated | R signals; ContextSlice (reproduction environment) | Badges encode evidence availability and warrant level; the declared environment maps to a slice; scope of claim is often implicit → USM makes it explicit. |
| 12 | SRE / Cloud SLO | SLOs; error budgets; regions/tiers; rollout windows | Work scope (regions/tiers) + measures; gammaTime only for a membership-changing rollout interval | SLO measures and error-budget windows stay in their measure or reliance guards. A rollout interval enters Work scope only when crossing its exact start or end changes whether that job slice belongs. |
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.
A.2.6:20.1.3 - F.18 Term Selection — Unified Tech & Plain names
A.2.6:20.1.3.1 - Selected names (normative)
| Concept in A.2.6 | Unified Tech (lexicon) | Unified Plain (manager‑friendly) | Allowed short form | Avoid / unpack |
|---|---|---|---|---|
| Addressable evaluation context | U.ContextSlice | Context slice | Slice (when local) | “domain” (as guard input), “latest” time |
| Extensional scope value | U.Scope | Scope | — | “applicability”, “envelope”, “validity” (as characteristic names) |
| Episteme applicability | U.ClaimScope (*nick G) | Claim scope | G | “generality”, “applicability/envelope (of claim)” |
| Capability applicability | U.WorkScope | Work scope | — | “capability envelope”, “operational applicability”, “operation scope” |
| Time selector | Γ_time | Time selector | — | implicit “latest” |
| Exact local-sense translation | Obtaining F.9 Bridge + separate affirmative C.2.1 use claim + current A.10 or B.3 reliance | Bridge, translation rule and tolerance, checked reliance | — | automatic Bridge use or treating a loss score as permission |
| Parallel coverage | SpanUnion | Union of supported areas | — | unqualified “union” without independence |
| Serial dependency | Intersection | Intersection of scopes | — | ordinal “more/less general” language |
| Scope edits | ΔG+ (widen), ΔG− (narrow), Refit, Translate | Widen, narrow, refit, translate | — | stealth widening (“it’s obvious”) |
| Optional didactics | Detail (D), AbstractionTier (AT) | Detail and abstraction tier | D / AT | avoid as G substitutes |
Naming rationale:
- “Scope” rather than “envelope/applicability/validity”. “Scope” is idiomatic in SRE/SW; “validity” clashes with Validation Assurance (LA), and “envelope” suggests geometry rather than membership.
- “Claim scope” vs “Work scope”. These names distinguish claim uses and capability uses of the common set-valued scope notion.
- 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.
A.2.6:20.1.3.2 - Phrasebook (for editors, normative)
- Use “Claim scope (G) covers TargetSlice” and “Work scope covers JobSlice” in guards.
- When time changes membership, name exact
gammaTimeand its membership boundary; never say “latest.” A time-independent predicate need not inspectgammaTime, but keep every selector already declared in the slice. - 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.
A.2.6:20.1.3.3 - Rosetta summary (informative, for rationale box)
| local context phrase | Use in USM wording |
|---|---|
| “Context of use” (NIST, ASME/FDA) | Claim scope (G) on explicit Context slice |
| “Operating modes/situations” (ISO 26262) | Work scope with measures & qualification windows |
| “Target (class/shape)” (SHACL/OWL) | Claim scope predicates (membership) |
| “Architecture view context” (42010) | Context slice + Scope checks inside the view |
| “Capability envelope” (safety documents) | Work scope |
| “Domain” (informal) | Context slice elements; not acceptable as a guard input |