FPF Reference

    Migration debt from A.2.6 (Scope, ClaimScope, WorkScope)

    Preface node heading:migration-debt-from-a-2-6-scope-claimscope-workscope:85209

    What this page is

    This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

    Methodology

    Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

    Content

    Deprecations (normative)

    The following terms MUST NOT name scope objects in normative text, guards, or conformance blocks:

    • applicability, envelope, generality, capability envelope, validity (as a characteristic name).

    Use instead:

    • U.ClaimScope (Claim scope, nick G) for epistemes;
    • U.WorkScope (Work scope) for capabilities;
    • U.Scope only when explaining the abstract mechanism (not in guards).

    Affected locations and required edits (normative)

    Editors SHALL apply the following replacements:

    1. Part C.2.2 (F–G–R).

      • Replace any internal definition of “Generality” with a normative reference to A.2.6 §6.3 (Claim scope (G)).
      • Where “abstraction level” is mentioned as G, replace with “Claim scope (where the claim holds)”; keep AT (AbstractionTier) only as optional didactics (non‑G).
      • Ensure composition examples use intersection/SpanUnion for G, not ordinal “more/less general”.

    2. Part C.2.3 (Formality F).

      • No change to F itself.
      • Any example that implies “raising F widens G” MUST be rephrased: F changes expression form; G changes only via ΔG.

    3. Part A.2.2 (Capabilities).

      • Replace “capability envelope/applicability” with U.WorkScope.
      • Method–Work gates MUST test Work scope covers JobSlice, with measures and qualification windows bound.

    4. Part B (Bridges & CL).

      • Add a note: CL penalties apply to R, not to F/G; mapping MAY recommend narrowing the mapped scope (best practice).

    5. Part E (Lexicon).

      • Add entries for Claim scope (G), Work scope, Scope (mechanism).
      • Mark listed deprecated terms as deprecated aliases allowed only in explanatory notes.

    6. ESG & Method–Work templates.

      • Replace any “applicability”/“envelope” guard phrasing with ScopeCoverage (see §10).
      • Require explicit Γ_time selectors in all scope‑sensitive guards.

    Migration playbook (informative)

    1. Inventory scope‑like phrases across your Context (search: applicability, envelope, generality, capability envelope, valid*).
    2. Classify each occurrence as Claim scope (episteme) or Work scope (capability); replace any “scope characteristic(s)” with “scope object”, “scope type”, or “USM scope object” depending on sentence grammar.
    3. Rewrite guards to use Scope covers TargetSlice + explicit Γ_time; remove “latest”.
    4. Publish any required Bridges with CL for Cross‑context usage.
    5. Document ΔG changes separately from evidence freshness (R).

    Alias and body-prose continuity (informative)

    Existing body prose may keep older phrasing only when it is explanatory and carries no current requirement. All guards, conformance checklists, and state assertions MUST be rewritten to the USM terms and semantics.

    Change Log (normative migration record)

    • A.2.6 introduced. Defines U.ContextSlice, U.Scope, U.ClaimScope (G), U.WorkScope; sets algebra and guard patterns.
    • Deprecated labels. “applicability / envelope / generality / capability envelope / validity” as characteristic names.
    • Edits required. C.2.2 (G = Claim scope), A.2.2 (Work scope for capabilities), Part B (CL→R note), Part E (Lexicon updates), ESG/Method–Work guard templates (ScopeCoverage + Γ_time).
    • No change. C.2.3 (F) unchanged; its examples updated only for wording consistency.

    Last Updated: 2026-06-17 — upstream FPF commit 646b0b9b (github.com/ailev/FPF)