Part K – Lexical debt

Preface node heading:part-k-lexical-debt:60576

Content

Mandatory replacement map for measurement terms

Rule: In all normative content (specifications, data schemas, etc.), the deprecated terms “axis” and “dimension” (and their plural or compound forms) MUST NOT be used to denote a measurable aspect. Use Characteristic in the Tech register instead. Other colloquial terms should be mapped to canonical terms as listed below. In Plain narrative, the legacy words may appear only on first use and only if paired with their canonical equivalent for clarity.

Legacy Term (context)Replace with (Tech register)Plain register allowanceCanonical Reference
axis (of measurement); dimension (of a system or quality)(disallowed in Core prose) → use CharacteristicNo parenthetical allowance in Core; use Characteristic / Measure / Coordinate onlyA.17 (CHR-NORM)
point (on an axis); data pointCoordinate (on a Scale)“point” (in explanations only, e.g. “a point on the scale”)A.18 (CSLC-KERNEL)
metric value; raw scoreCoordinate (or Value)“value” (acceptable in plain usage when context is clear, but formally it’s a Coordinate tied to a Characteristic)A.18, C.16
score (composite or normalized)Score (produced via a ScoringMethod)“score” (if needed in narrative, ensure it’s explained as a result of a defined ScoringMethod)A.17/A.18 (ScoringMethod/Score)
unit dimension; unit axisUnit (of a Scale)“unit” (plain usage okay)A.18 (Scale/Unit)
metric (as a noun)Avoid in Tech and as primitive → use U.DHCMethodRef / U.Measure / Score“metric” (Plain only on first use, with pointer to canonical terms)C.16 § 5.1 (L5), A.18

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

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 legacy 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).

Backwards compatibility (informative)

Legacy artifacts MAY keep their historical phrasing in body prose. 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.