Skip to content

fix: normalize USM checklist language so scope is never typed as characteristic #32

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
iqdoctor wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix: normalize USM checklist language so scope is never typed as characteristic #32

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions FPF-Spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3817,7 +3817,7 @@ When **G** is a **set‑valued scope**, composition becomes precise: serial depe
| Force | Tension to resolve |
| ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **One mechanism vs two worlds** | We must serve both **knowledge about the world** (claims) and **doing work in the world** (capabilities) **without** duplicating concepts. |
| **Locality vs interoperability** | Scope must be **context‑local** and precisely checkable, yet transferable across Contexts via Bridges **without redefining** the characteristic. |
| **Locality vs interoperability** | Scope must be **context‑local** and precisely checkable, yet transferable across Contexts via Bridges **without redefining** the scope object. |
| **Expressivity vs minimal vocabulary** | Teams need to capture rich conditions (time windows, environment, versions) but not explode the lexicon into “envelope/applicability/…” variants. |
| **Static content vs operational change** | Claims may hold broadly while current operations are narrow (or vice versa). The mechanism must keep “what is true” and “what can be done” aligned yet distinct. |
| **Open‑world exploration vs closed‑world gating** | Exploration benefits from permissive drafts; **gates** require crisp, observable checks. The same scope object must support both. |
Expand All @@ -3837,7 +3837,7 @@ When **G** is a **set‑valued scope**, composition becomes precise: serial depe

**Lexical commitments (normative):**
— In normative text and guards, use **Claim scope (G)**, **Work scope**, and **Publication scope**.
— Do **not** name the characteristic “applicability/envelope/generality/capability envelope/**publication applicability**/validity.” Those words are permitted only as explanatory aliases in notes.
— Do **not** name the scope object “applicability/envelope/generality/capability envelope/**publication applicability**/validity.” Those words are permitted only as explanatory aliases in notes.

### A.2.6:6 - Normative Definitions

Expand Down Expand Up @@ -4125,7 +4125,7 @@ For empirical claims and operational capabilities, **R** typically binds evidenc

### A.2.6:9 - Lexical Discipline (Part E compliance)

**L‑USM‑1 (names).** Use **Claim scope (G)** for epistemes, **Work scope** for capabilities, and **Publication scope** for publication carriers. Use **Scope** only when discussing the abstract mechanism. Avoid naming any **characteristic** as “applicability,” “envelope,” “generality,” “capability envelope,” or “validity”.
**L‑USM‑1 (names).** Use **Claim scope (G)** for epistemes, **Work scope** for capabilities, and **Publication scope** for publication carriers. Use **Scope** only when discussing the abstract mechanism. Avoid naming any **scope object** as “applicability,” “envelope,” “generality,” “capability envelope,” or “validity”.

**L‑USM‑2 (Work/Run).** Prefer **Work/Run** vocabulary from A.15 for system execution contexts. Do not introduce “operation/operating” as characteristic names; use **Work scope**.

Expand Down Expand Up @@ -4270,12 +4270,12 @@ Implicit “latest” is not allowed. If multiple contributors declare different
| ID | Requirement |
| ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **CC‑USM‑1 (Declaration).** | Epistemes **SHALL** declare **`U.ClaimScope`**, capabilities **SHALL** declare **`U.WorkScope`**. The abstract `U.Scope` MAY be used in architectural notes but not in guards. |
| **CC‑USM‑2 (Set‑valued).** | Scope characteristics are **set‑valued** over `U.ContextSlice`. Implementations MUST support **membership**, **intersection**, **SpanUnion**, **translate**, **widen/narrow**, **refit**. |
| **CC‑USM‑2 (Set‑valued).** | Scope objects are **set‑valued** over `U.ContextSlice`. Implementations MUST support **membership**, **intersection**, **SpanUnion**, **translate**, **widen/narrow**, **refit**. |
| **CC‑USM‑3 (Coverage guards).** | ESG and Method–Work guards **MUST** use `Scope covers TargetSlice` predicates and **MUST** specify `Γ_time`. Guards fail closed. |
| **CC‑USM‑4 (Serial intersection).** | Along essential dependency paths, effective scope **SHALL** be the **intersection**; empty intersection invalidates the path. |
| **CC‑USM‑5 (SpanUnion constraints).** | Parallel scope **MAY** use **SpanUnion** only if independent support lines are **justified**; published union **MUST NOT** exceed supported slices. |
| **CC‑USM‑6 (Cross‑context).** | Any Cross‑context use **MUST** declare a Bridge and **CL**; CL penalties apply to **R**, not **F/G**. |
| **CC‑USM‑7 (No synonym drift).** | In normative text and guards, **MUST** use **Claim scope (G)** or **Work scope**. Terms “applicability/envelope/generality/capability envelope/validity” **MUST NOT** name the characteristic. |
| **CC‑USM‑7 (No synonym drift).** | In normative text and guards, **MUST** use **Claim scope (G)** or **Work scope**. Terms “applicability/envelope/generality/capability envelope/validity” **MUST NOT** name the scope object. |
| **CC‑USM‑8 (Determinism).** | Membership evaluation **MUST** be deterministic given the slice tuple; no heuristic “close enough” matching. |
| **CC‑USM‑9 (Edition triggers).** | ΔG± (widen/narrow) constitutes a **content change**; refit does not. |
| **CC‑USM‑10 (Publication discipline).** | Publication carriers that gate usage **SHALL** declare `U.PublicationScope`. For any publication **about** an episteme or capability, `PublicationScope` **MUST** be a subset of the underlying `U.ClaimScope`/`U.WorkScope`. Cross‑context publications **MUST** cite Bridge + CL; CL penalties **apply to R only** (scope membership unchanged). |
Expand Down