#Unified Normalization Mechanism (UNM)

A.19.UNM · Stable · Architectural (A) · Normative (unless explicitly marked informative) · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A / CN‑Spec cluster (A.19) / CHR mechanism-governing patterns Governing-pattern note (Phase‑3 canonicalization): This pattern governs the meaning of UNM.IntensionRef (per E.20). The canonical publication anchor for UNM.IntensionRef remains A.19.UNM, while A.6.1 governs the U.Mechanism.Intension template. Boundary note: The CN_Spec surface itself (incl. CN_Spec.normalization and CN_Spec.comparability) remains governed by A.19.CN; this pattern specifies only UNM’s stable semantic surface and how UNM consumes/interprets the CN‑frame routing fields (no shadow CN‑spec). ID‑continuity: legacy UNM mentions remain valid via Tell + Cite stubs (e.g., cite A.19.UNM:4.1). Canonicalization hook (Phase‑3): Any other location that mentions UNM (including legacy “card fragments”) SHALL be reduced to Tell + Cite and SHALL NOT restate SlotIndex / OperationAlgebra / LawSet / AdmissibilityConditions / Applicability / Transport, Γ_timePolicy, PlaneRegime, and Audit. This is the usability+didactic guard against “scattered semantics”. If someone says “we normalized”, ask (in this order):

1. Which UNM_id (if applicable) and which NormalizationMethodInstanceId (and its validity window) was used?
2. Which NormalizationInvariant[*] were declared (i.e., what is preserved)?
3. Which bearer, scope/window, reference or comparison basis, evidence, and intended comparison were recorded, and does this use actually rely on an F.9 Bridge, kind relation, or plane relation?

Mental model. UNM re‑parameterizes a raw coordinate value (CV) into an NCV under declared invariants and exposes ≡_UNM so downstream steps can be stated as “compare on invariants” explicitly (and audited).

Intent. Provide a single, explicit normalization mechanism for coordinate values in a U.CharacteristicSpace, so that comparability and downstream characterization steps can be stated as “normalize-then-compare” (governance), rather than as hidden arithmetic inside scoring/selection.

#Keywords

• normalization
• CV→NCV
• ≡UNM
• NormalizationMethodId
• NormalizationMethodInstanceId
• NormalizationInvariant[]
• NormalizationFixSpec
• validity window (no implicit “latest”)
• fail-closed tri-state guard (pass|degrade|abstain)
• CN-Spec.normalization
• CN-Spec.comparability.mode
• Bridge-only transport + ReferencePlane/CL pins
• penalties→R/Reff only.

#Relations

#Content

#At a glance — didactic, informative

Intent. Provide a single, explicit normalization mechanism for coordinate values in a U.CharacteristicSpace, so that comparability and downstream characterization steps can be stated as “normalize-then-compare” (governance), rather than as hidden arithmetic inside scoring/selection.

Where it sits.

• CN-frame governance card: CN_Spec.normalization + CN_Spec.comparability.mode route whether comparison is coordinatewise or normalization-based.
• CHR suite role: stage normalize (first-stage, when enabled by the suite protocol / comparability routing).

Key outputs.

• NCV (NormalizedCharacteristicValue) values for coordinates.
• A declared congruence ≡_UNM (equivalence) induced by a chosen normalization method instance.
• Optionally, an explicit representative selection policy (NormalizationFixSpec, aka “NormalizationFix” in prose) when quotient objects must be presented as concrete chart items.

Two IDs (do not conflate).

• UNM_id? selects the UNM mechanism instance used by this CN‑frame (a U.Mechanism instance of type UNM; routing/governance level).
• NormalizationMethodInstanceId selects the normalization method instance applied to specific coordinate(s), with its validity window and evidence pins (method/application level).

Minimum declaration set (didactic).

• In CN_Spec.comparability: set mode, and (when UNM participates in acceptance/comparison) set minimal_evidence.
• In CN_Spec.normalization: declare UNM_id?, methods, instances, method_descriptions, invariants, and (if representatives are required) fix.
• In Audit: cite the chosen NormalizationMethodInstanceId, NormalizationMethodDescriptionRef.edition, characteristic-space and CN-Spec editions, bearer, scope/window, reference or comparison basis, invariants, evidence, and intended comparison. Cite a Bridge, kind relation, or plane relation only when the result or receiving use actually relies on it.

Non-goals.

• Not indicator selection (that is UINDM).
• Not scoring, aggregation, comparison, selection (USCM / ULSAM / CPM / SelectorMechanism).
• Not a data governance system: UNM is a concept-level mechanism with an explicit governing pattern and auditability.

Governing-pattern note (Phase‑3 canonicalization). This pattern is the governing pattern for the canonical U.Mechanism.Intension for UNM.IntensionRef. Other locations that currently carry UNM “card fragments” should be reduced to Tell + Cite stubs pointing here, preserving public IDs/anchors.

#Problem frame

FPF needs a disciplined way to talk about measurable slots (coordinates/scales) such that engineers can reason about:

• What it means to compare values across charts, slices, bearers, or reference bases, and
• Where the “meaning-preserving” transformations live, so comparisons are lawful and explainable.

In practice, teams routinely face a mismatch between:

• values that look comparable (“they’re numbers”), and
• values that are not comparable without normalization—for example, because their units, scale types, reference planes, bearer or population assumptions, comparison bases, intended uses, or validity windows differ.

FPF’s CHR family explicitly separates stages (normalize → indicatorize → score → fold → compare → select). UNM is the normalization stage, and its job is to make “compare-on-invariants” explicit and auditable.

#Problem

Without an explicit UNM governing pattern:

1. Normalization drifts into hidden places. It gets embedded inside scoring, comparison, or selection, making admissibility and governance non-local.

2. Comparability becomes rhetorical. People say “we normalize” but cannot answer: Which method? Which invariants? Which bearer, comparison basis, scope and window? Which evidence? Does the receiving comparison rely on an actual Bridge, kind relation, or plane relation?

3. Basis and relation changes become invisible. Teams reuse normalizations for another bearer, comparison basis, source-local meaning, or reference plane without naming what changed or the relation on which the new use depends.

4. Engineers cannot reconstruct the mechanism. When UNM semantics are scattered, the pattern structure (problem/forces/solution) is lost, hurting didactic use by engineering managers.

#Forces

#Solution

UNM is a U.Mechanism that normalizes coordinate values using declared method classes, producing:

• normalized values (NCV),
• an induced congruence ≡_UNM,
• and (when needed) a representative policy (NormalizationFix) for quotient objects.

UNM is not a bag of algorithms. It is a canonical semantic surface:

• Routing lives in CN_Spec.normalization and CN_Spec.comparability.mode.
• Evidence/calibration legitimacy lives in C.16 (MM‑CHR).
• Method families can be supplied by SoTA packs and wired via extensions, without mutating UNM’s surface.

#Vocabulary (normative)

NormalizationMethodId. A stable token naming a normalization method kind, used in CN_Spec.normalization.methods.

NormalizationMethod. The method kind (class) that defines:

1. the invariants it preserves (NormalizationInvariant[*]),
2. its closure rules (composition, and inverses where defined), and
3. its validity rules (admitted bearer, scope, qualification window, reference or comparison basis, and intended-use constraints).

NormalizationMethodDescription. An editioned epistemic description of a normalization method (bounds, validity region/window, scope constraints, and evidence links governed by C.16). NormalizationMethodDescriptionRef. A ref to an editioned NormalizationMethodDescription, used in CN_Spec.normalization.method_descriptions.

NormalizationMethodInstanceId. A stable token naming a concrete, declared application of a normalization method to specific coordinate(s)/slot(s) in a base U.CharacteristicSpace, with a named validity window and (when required) evidence pins. Used in CN_Spec.normalization.instances.

NormalizationMethodInstance. The instance binding itself (conceptual); referenced in specs/logs/gates by NormalizationMethodInstanceId.

CV (CoordinateValue). A raw coordinate value for a named measurable slot in a chart: conceptually ⟨slot_id, raw_value⟩ (plus any chart/slice scoping needed by the chart). UNM re‑parameterizes CV → NCV under declared invariants and validity constraints.

NCV (NormalizedCharacteristicValue). A normalized value for a coordinate (UNM does not “normalize characteristics”; it normalizes coordinate values under declared invariants).

≡_UNM (UNM-congruence). The equivalence relation induced by one chosen NormalizationMethodInstance for its declared characteristic-space and CN-Spec editions, bearer, scope/window, reference or comparison basis, and intended comparison. Two charts (or chart items/views) are ≡_UNM iff they are related by a finite chain of admissible transformations that preserve the declared invariants.

NormalizationInvariant. A named invariant (e.g., unit alignment, polarity, reference plane) declared in CN_Spec.normalization.invariants and/or the selected NormalizationMethodDescription. Preserving the declared NormalizationInvariant[*] is the core admissibility claim for a normalization method instance.

NormalizationFixSpec. A declared policy selecting a canonical representative of a ≡_UNM equivalence class when downstream consumers require a concrete chart item/view. Bound via CN_Spec.normalization.fix (otherwise keep quotient objects abstract). UNM_id. An optional identifier in CN_Spec.normalization.UNM_id? selecting the UNM mechanism instance used by this CN‑frame. This is routing/governance; it is distinct from NormalizationMethodInstanceId (method/application). ValidityWindow. A named validity window attached to a NormalizationMethodInstanceId, bounding where/when the instance is admissible (no implicit “latest”).

Relation and reuse boundary. A normalized value remains tied to the exact normalization-method instance and edition, characteristic-space and CN-Spec editions, bearer, scope and window, reference or comparison basis, evidence, and intended comparison. Reusing it does not by itself establish a transfer relation. Cite an F.9 Bridge or a plane relation only when that relation actually obtains, and state the receiving use separately. Lexical guard (strict distinction). Avoid the word map / mapping for UNM transforms (especially Map), because Map is a specialized FPF term and creates ontology drift. Prefer “normalization”, “re‑parameterization”, “transform under invariants”. Legacy κ‑notation for normalization is retired; do not re‑introduce it.

#UNM as a U.Mechanism.Intension (normative)

Scope note. This Mechanism.Intension is authored to the U.Mechanism.Intension shape governed by A.6.1. It defines only UNM’s stable semantic surface. It does not bind project pins (editions/policy‑ids), which belong to the P2W seam (A.15.3 + A.19.CHR), and it does not emit GateDecision/GateLog. It may emit tri‑state GuardDecision and Audit pins.

IntensionHeader

• IntensionId: UNM
• IntensionRef: UNM.IntensionRef
• Name: Unified Normalization Mechanism
• Status: Stable
• Version: v1.0
• SuiteRole: CHR.normalize (when enabled by CN/CHR routing)

Imports (cite, don’t duplicate)

• A.6.1 (shape: U.Mechanism.Intension, specialization discipline)
• A.6.5 (slot discipline; SlotIndex is a projection)
• A.19.CHR:4.2 (CHR suite boundary / membership)
• A.19.CHR:4.2.1 (CHR SlotKind Lexicon)
• A.19.CHR:4.5 (suite protocols: ordering/optionality; suite closure)
• A.19.CN (CN-frame routing: normalization, comparability.mode)
• G.0 (CG-frame admissibility gates where required downstream)
• C.16 (evidence carriers; calibration/validity for normalization legitimacy)
• A.17/A.18 (measurement meaning & scale lawfulness; not redefined here)

SubjectBlock

• SubjectKind: NormalizationMethod classes (with induced ≡_UNM over admitted chart items or views)
• GovernedValueDomain: coordinate values (CV) for named measurable slots in the exact U.CharacteristicSpace and CN-Spec editions; UNM normalizes values, not characteristics
• BearerAndUseBoundary: the exact bearer, scope and window, reference or comparison basis, evidence, and intended comparison declared for those values
• ExtentRule: “coordinate values admitted by the selected CN-Spec for this bearer and use, within the normalization-method instance's declared validity window”
• ResultKinds:
  • NormalizedCharacteristicValue (NCV)
  • UNM-congruence (≡_UNM)
  • optional quotient objects and/or Normalization-fixed representatives (via NormalizationFixSpec) SlotIndex (derived projection; minimum)
• CharacteristicSpaceSlot : ⟨ValueKind = U.CharacteristicSpace, refMode = U.CharacteristicSpaceRef⟩
• CNSpecSlot : ⟨ValueKind = CN‑Spec, refMode = CNSpecRef⟩
• The CNSpecSlot resolves the exact bearer, claim scope and selected slices, qualification window, reference or comparison basis, evidence requirements, and intended comparison; these qualify the use and do not form a generic setting SlotKind.

UNM‑specific slots (must be alias‑docked into the CHR SlotKind lexicon if used across the suite):

• NormalizationMethodInstanceSlot : ⟨ValueKind = NormalizationMethodInstanceId, refMode = ByValue⟩
• NormalizationMethodDescriptionSlot? : ⟨ValueKind = NormalizationMethodDescription, refMode = NormalizationMethodDescriptionRef⟩
• NormalizationInvariantSetSlot? : ⟨ValueKind = NormalizationInvariant[*], refMode = ByValue⟩
• NormalizationMethodInstancePairSlot? : ⟨ValueKind = NormalizationMethodInstanceId[2], refMode = ByValue⟩ (used only by compose; roles = {inner, outer})
• CoordinateValueSlot : ⟨ValueKind = CV, refMode = ByValue⟩
• NCVSlot : ⟨ValueKind = NCV, refMode = ByValue⟩
• UNMCongruenceSlot : ⟨ValueKind = UNM‑congruence (≡_UNM), refMode = ByValue⟩
• NormalizationFixSlot? : ⟨ValueKind = NormalizationFixSpec, refMode = ByValue⟩

Authoring note (didactic). NormalizationMethodDescriptionSlot, NormalizationInvariantSetSlot, and NormalizationFixSlot are typically resolved/derived from CN_Spec.normalization.{method_descriptions,invariants,fix} plus the selected NormalizationMethodInstanceId. They are listed here because they participate in eligibility/audit semantics — not because every operation takes them as explicit inputs.

Relation note (not a SlotKind). A Bridge, kind relation, or plane relation is cited only when the use relies on that obtaining relation. Its declaration and receiving use remain separate from the UNM SlotIndex.

OperationAlgebra (conceptual)

1. apply

   • Preconditions: UNM_Eligibility(…) ∈ {pass, degrade} (fail‑closed; abstain ⇒ no NCV output).
   • Inputs: NormalizationMethodInstanceSlot, CoordinateValueSlot, CharacteristicSpaceSlot, CNSpecSlot; the selected CN-Spec supplies the exact bearer, scope/window, basis, evidence requirements, and intended comparison.
   • Outputs: NCVSlot (+ availability of UNMCongruenceSlot for the same method instance)

2. compose

   • Purpose: build a composed method (only when explicitly declared lawful).
   • Inputs: NormalizationMethodInstancePairSlot (roles = {inner, outer}), CharacteristicSpaceSlot, CNSpecSlot; both instances must be admitted for the same declared bearer, scope/window, basis, and intended use.
   • Output: NormalizationMethodInstanceSlot (new composed NormalizationMethodInstanceId), with an explicit validity window and evidence pins.

3. quotient(≡_UNM)

• Inputs: CharacteristicSpaceSlot (or chart view), NormalizationMethodInstanceSlot
• Output: quotient object under UNMCongruenceSlot (When a concrete representative is required, NormalizationFixSlot (NormalizationFixSpec) must be declared and used.)

LawSet (UNM laws; identifiers are stable)

• UNM‑L0 (Values, not characteristics). UNM produces NCV as a value under declared invariants; it does not redefine the underlying characteristic meaning (measurement meaning remains governed by A.17/A.18 and evidence by C.16).
• UNM‑L1 (Declared method class gate). A normalization method instance is admissible only if its method is declared in the allowed method class set: {ratio:scale, interval:affine, ordinal:monotone, nominal:categorical, tabular:LUT(+uncertainty)}.
• UNM‑L1a (Method semantics are governed by the method). NormalizationMethod defines invariants, closure (composition / inverses where defined), and validity rules. UNM consumes these declarations; it does not invent extra admissibility.
• UNM‑L2 (Congruence is first-class). Each chosen method instance induces ≡_UNM over charts/views; equality/comparability decisions that rely on normalization are defined on the quotient (or on a declared fix), not on raw labels.
• UNM-L2a (Declared-basis locality). ≡_UNM holds only for the selected method instance, characteristic-space and CN-Spec editions, bearer, scope and window, reference or comparison basis, and intended comparison. A later use must show that those premises still hold or constitute a new result.
• UNM‑L3 (Fail‑closed). If admissibility/evidence is insufficient (or required inputs are missing/stale), UNM does not silently coerce; it yields abstain or degrade (tri‑state guard discipline) and may surface an explicit freshness/work request (see A.19.UNM:4.5). Didactic reading: abstain ⇒ no lawful NCV/comparability for this slice; degrade ⇒ NCV may be produced but must be treated as policy‑gated and auditable (never “quietly good enough”).
• UNM‑L4 (No implicit indicatorization). NCV does not imply “indicator”; indicator status is a separate policy step (UINDM).
• UNM-L5 (Relation before reuse). When a receiving comparison depends on an F.9 Bridge, kind relation, or plane relation, cite the exact obtaining relation, its direction, what it preserves or loses, and the receiving use. A change of bearer, scope, corpus, scale, method, or window is not by itself such a relation. Supported penalties route to the R-lane only (never to F/G; if scalarized, into R_eff).
• UNM‑L6 (Time explicitness). Validity windows are named; no implicit “latest”.
• UNM‑L7 (Auditability). The applied method and CN-Spec editions, normalized values, bearer, scope and window, comparison basis, evidence pins, intended comparison, and any actually relied-on Bridge, kind relation, or plane relation must be auditable as refs or pins.
• UNM-L8 (No shadow writers). Downstream patterns cite the exact method, CN-Spec, basis, and evidence editions they use; they do not re-author those anchors or make a registry substitute for them.
• UNM‑L9 (No publish/telemetry ops). UNM defines no publish/telemetry step. Any publication/telemetry is out of suite closure and does not mutate UNM semantics (NCV, ≡_UNM, quotient/fix); only Audit pins are produced here.

AdmissibilityConditions Definition (UNM‑Eligibility): UNM_Eligibility(NormalizationMethodInstanceSlot, CoordinateValueSlot, CharacteristicSpaceSlot, CNSpecSlot) → GuardDecision where GuardDecision ∈ {pass | degrade | abstain} and follows this predicate semantics:

• pass iff all of the following hold:
  • (CN-Spec binding) the selected NormalizationMethodInstanceId is declared in CN_Spec.normalization.instances (or an equivalent declared surface), its method kind is included in CN_Spec.normalization.methods, and (if present) it satisfies normalization.admissible_reparameterizations; the exact characteristic-space and CN-Spec editions, bearer, claim scope and selected slices, qualification window, reference or comparison basis, and intended comparison are recoverable;
  • (Target coordinate binding) the input CV’s slot_id belongs to the method instance’s declared bound coordinate set;
  • (Scale‑regime compatibility) the method kind is compatible with the coordinate’s regime (ratio:scale | interval:affine | ordinal:monotone | nominal:categorical | tabular:LUT(+uncertainty)) and preserves the declared NormalizationInvariant[*] (from CN_Spec.normalization.invariants and/or the method description);
  • (Validity window) the method instance’s validity window covers the active slice/time policy (no implicit “latest”);
  • (Evidence sufficiency when routed into governance) when comparability.mode = normalization-based (or downstream uses NCV in gated decisions), the method instance’s evidence pins satisfy CN_Spec.comparability.minimal_evidence (structure typically gated by G.0; evidence semantics governed by C.16).
• degrade iff all non‑evidence conditions above hold, but the evidence check does not pass and the declared failure behavior permits producing a policy‑gated degraded NCV rather than abstaining.
• abstain otherwise (including missing binding, coordinate mismatch, out‑of‑window validity, or evidence failure when the declared failure behavior is abstain).

Applicability UNM is applicable when:

• CN_Spec.comparability.mode = normalization-based, or
• a declared downstream step requires “compare-on-invariants” and thus requires explicit normalization. UNM is typically skipped when comparability.mode = coordinatewise (unless an explicit downstream step requires a declared quotient/fix anyway).

Relation and reuse boundary

• A normalized value remains local to the exact method instance and edition, characteristic-space and CN-Spec editions, bearer, scope and window, reference or comparison basis, evidence, and intended comparison recorded for it.
• If a receiving use depends on a relation between distinct source-local meanings, cite the exact F.9 Bridge, its direction, what it preserves or loses, and that receiving use. If reference planes differ and the comparison depends on their relation, cite the exact plane relation as a separate claim.
• A changed bearer, scope, corpus, scale, method, or window does not by itself establish either relation. If the bearer kind also changes, state the separate kind relation rather than hiding it inside a Bridge. Any loss penalty remains on the R-lane and is used only when the corresponding relation claim supports it. Γ_timePolicy
• Default: point (no implicit “latest”).
• If normalization relies on time windows, the validity window is part of the method instance and must be declared.

PlaneRegime

• A normalized value keeps the reference plane declared for its input and intended comparison; normalization creates no implicit plane crossing.
• When a comparison actually relies on a relation between different planes, cite that exact relation, its direction and loss, and keep its use separate from the normalization result. Audit Audit records MUST include:
• CNSpecRef.edition + comparability.mode, the exact U.CharacteristicSpace edition, and the evaluated bearer
• (when present) CN_Spec.normalization.UNM_id (the selected UNM mechanism instance id for this CN-Spec)
• chosen NormalizationMethodInstanceId, its validity window, and any NormalizationMethodDescriptionRef.edition
• declared NormalizationInvariant[*] and NormalizationFixSpec (if used)
• any declared admissible re-parameterizations (if present in CN_Spec.normalization)
• claim scope and selected slices, reference or comparison basis, intended comparison, and all evidence pins used by the instance
• an exact F.9 Bridge, kind relation, or plane relation only when the recorded result or receiving use actually relies on it, including direction, preserved or lost meaning, and the receiving use
• any emitted FreshnessRequest / work request identifiers (when applicable; see A.19.UNM:4.5)

#CN-frame wiring: normalization and comparability routing (normative-by-reference)

Tell. CN-frame does not “do normalization”; it routes normalization.

• comparability.mode ∈ {coordinatewise, normalization-based} governs whether comparisons are done directly or “normalize-then-compare”.
• normalization.UNM_id? selects the UNM mechanism instance used by this CN-frame.
• normalization.methods / instances / method_descriptions / invariants / fix provide the declared surface that UNM consumes. (If present) normalization.admissible_reparameterizations constrain which re‑parameterizations count as “admissible” under the declared invariants. (See CN-frame definition in A.19.CN; A.19.CN remains the governing pattern of the CN-frame surface. This section only states the UNM consumption/interpretation constraints and does not introduce a shadow spec.)

#Evidence and calibration are governed by MM‑CHR (normative-by-reference)

UNM does not claim “this normalization is legitimate” by decree. Instead, the legitimacy claim is supported by evidence carriers, calibration records, and validity records governed by C.16 (MM‑CHR) and referenced from the chosen NormalizationMethodInstance.

#Didactic rule: quotients or fixes, never “labels” (normative)

When UNM is used to support comparability/acceptance:

• Think in invariants and equivalence classes (quotients), not in labels.
• If a concrete representative is needed, declare a NormalizationFix explicitly. Do not silently treat an arbitrary representative as canonical.

#P2W and transformation-flow integration note (normative-by-reference)

When UNM is used inside transformation-flow structures/graphs (e.g., E.18):

• UNM occurs before selection/decision steps.
• If required measurements are missing or stale, UNM does not “guess a number”; it surfaces an explicit freshness/work request that must be planned in U.WorkPlanning and executed in U.WorkEnactment.
• A receiving step cites the exact normalized values, method and CN-Spec editions, bearer, scope/window, comparison basis, evidence and intended use. It cites a Bridge, kind relation or plane relation only when its conclusion actually relies on that obtaining relation and keeps any supported loss on the R-lane.
• Downstream consumers cite editioned method, basis and evidence anchors as refs and do not re-author them.

#Archetypal Grounding (Tell–Show–Show)

Tell. UNM is the conceptual “front gate” that turns “raw coordinate values” into “values comparable under declared invariants”, by:

1. choosing an admissible normalization method instance (with evidence and validity window),
2. applying it to produce NCVs,
3. exposing ≡_UNM and (optionally) quotient/fix structure so downstream mechanisms can remain lawful and explicit.

Show (System). A team compares alternatives using normalization-based comparability:

• CN-Spec declares:
  • comparability.mode = normalization-based
  • normalization.invariants = {unit-alignment, polarity}
  • a method instance M_unitScale with validity window VW_2026Q1 and evidence pins.
• UNM applies M_unitScale to each coordinate value, producing NCVs.
• CPM compares the NCV-profiles (not raw profiles).
• If evidence pins are missing for a slice, UNM returns GuardDecision = abstain, preventing “fake comparability”.

Show (Episteme). Quotient thinking:

• Two chart items x and y are different raw values (different units or reference planes).
• Under a chosen normalization method instance, x ≡_UNM y holds.
• Comparability claims are made over [x]_{≡_UNM} and [y]_{≡_UNM} (equivalence classes).
• If reporting needs a single representative, a declared NormalizationFix selects it; otherwise, do not pretend a representative is canonical.

Show (P2W and transformation flow). Missing/stale inputs:

• A selector (or comparator) requires comparability under normalization-based mode.
• UNM finds that a required coordinate value is missing/stale for the current slice and the instance validity window.
• UNM returns GuardDecision = abstain (fail‑closed) and emits a FreshnessRequest that must be handled via planned baseline + enactment (UNM does not silently proceed).

#Bias‑Annotation

Common cognitive traps around normalization:

• Normalization-as-truth bias: treating NCVs as “objective” instead of “objective under declared invariants and validity window”.
• Hidden-steps bias: assuming normalization “happened somewhere” and skipping explicit routing/pins.
• Unit-blindness: treating numeric sameness as semantic sameness.
• Proxy legitimacy: assuming a popular method is legitimate without evidence pins or validity region.

Mitigation: enforce explicit NormalizationMethodInstance + validity window + evidence pins; and keep ≡_UNM/quotient semantics explicit.

#Conformance Checklist

• Template compliance: canonical E.8 sections 1–13 present in order; pattern ends with ### A.19.UNM:End.
• Terminology: uses NormalizationMethodId, NormalizationMethodInstanceId, NormalizationMethodDescription(Ref), CV, NCV, ≡_UNM, NormalizationInvariant[*], NormalizationFixSpec; avoids “map” wording (esp. Map); κ‑notation is retired.
• CN routing: uses CN_Spec.comparability.mode and the CN_Spec.normalization surface; does not embed “shadow CN-spec”.
• Fail-closed: eligibility is tri-state and never coerces unknown to pass.
• Lawfulness classes declared: method class is one of {ratio:scale, interval:affine, ordinal:monotone, nominal:categorical, tabular:LUT(+uncertainty)} and the instance's validity window is named.
• No indicator conflation: does not treat NCV as automatically implying indicator status.
• Relation and reuse discipline: every NCV names the method and CN-Spec editions, bearer, scope/window, reference or comparison basis, evidence and intended comparison; cite a Bridge, kind relation, or plane relation only when the use actually relies on it, with any supported loss on R/R_eff.
• Quotient/fix discipline: if a representative is required, NormalizationFix is declared; otherwise quotient semantics remain abstract.
• Auditability: method and CN-Spec editions, bearer, scope/window, basis, evidence, intended comparison, and any actually used relation are recorded as refs or pins.
• No shadow writers: downstream consumers cite the exact method, basis, and evidence editions and do not re-author them or replace them with a generic registry.
• P2W awareness (when used in flows): missing/stale inputs lead to explicit FreshnessRequest emissions (planned via P2W), not silent coercion.
• SlotKind discipline: SlotKind tokens reuse the CHR SlotKind lexicon where applicable; UNM‑specific SlotKinds are docked into the suite lexicon before use (no ad‑hoc drift).
• No proxy registry: no registry key stands in for the exact normalized values, method, CN-Spec, bearer, scope/window, basis, evidence, intended comparison, or actually obtaining relation.

#Common Anti‑Patterns and How to Avoid Them

1. Hidden normalization inside scoring or selection Avoid by using CN_Spec.comparability.mode and explicit UNM use.

2. “NCV ⇒ indicator” shortcut Avoid by treating indicatorization as UINDM policy, not a byproduct of normalization.

3. “We normalized” without declaring invariants Avoid by naming NormalizationInvariant[*] and exposing ≡_UNM.

4. Reusing a normalized value after its basis changed Avoid by checking the exact bearer, method and CN-Spec editions, scope/window, comparison basis, evidence, and intended use again; cite a Bridge, kind relation, or plane relation only when the new use actually relies on it.

5. Choosing a representative implicitly Avoid by either keeping quotient objects abstract or declaring NormalizationFix.

6. Using “map/mapping/Map” language as if it were harmless Avoid by using “normalization / re‑parameterization under invariants” and by keeping Map for its specialized FPF meaning.

7. Treating UNM outputs as comparable beyond their declared bearer, basis, scope/window, or reference plane Avoid by keeping comparison local to the recorded premises. Where a conclusion depends on another source-local meaning, bearer kind, or plane, cite the exact obtaining relation and its loss; otherwise constitute a new normalization result or fail closed.

8. Re-authoring method, basis, or evidence anchors downstream Avoid by citing the exact editioned method, basis, and evidence anchors as refs; a downstream pattern neither rewrites them nor replaces them with a generic registry.

#Consequences

Benefits

• Makes “normalize-then-compare” a first-class governance choice.
• Centralizes governing-pattern assignment, improving usability and reducing drift.
• Supports evolvability: method families can evolve via packs/extensions without mutating the mechanism surface.
• Prevents silent inadmissibility (unit, scale, and plane errors) by fail-closed guards.

Costs

• Requires explicit declarations (method instance, invariants, validity window, evidence pins).
• Some workflows must learn quotient/fix thinking (a conceptual overhead).

#Rationale

UNM is designed as a minimal canonical semantic surface:

• Enough structure to prevent illegal comparisons and hidden transformations.
• Explicit routing in CN-frame so normalization is governance, not an algorithmic trick.
• Evidence/calibration are delegated to MM‑CHR to avoid redefining measurement meaning.
• Exact bearer, basis, scope/window and intended-use checks prevent accidental global normalization; actual Bridge, kind, and plane relations are cited only when a conclusion relies on them.

This balances evolvability (methods evolve) with didactic usability (one place to read what UNM is).

#SoTA‑Echoing (post‑2015 practice alignment)

UNM does not prescribe algorithms, but it is designed to wire in SoTA normalization families via NormalizationMethodDescriptionRef + evidence pins (typically shipped as G.2 SoTA packs and wired via GPatternExtension modules, not as mutations of UNM’s surface). Examples of post‑2015 method families that often appear as evidence-backed normalization candidates (domain-dependent):

• SoTA ≠ popular. Method families enter UNM through G.2 claim structures + edition pins + evidence pins; “widely used” is not a validity claim by itself.
• Calibration of probabilistic coordinates (e.g., temperature scaling; multiclass calibration families such as Dirichlet calibration). Typical citations: Guo et al., 2017; Kull et al., 2019.
• Shift-/validity-region-aware normalization where “validity window/region” is explicit and shift detection enters as evidence, not as hidden branching. Typical citations: Lipton et al., 2018 (shift estimation); Ovadia et al., 2019 (uncertainty under shift) — as evidence motifs.
• Order-preserving transforms for ordinal regimes (normalization constrained to monotone transforms; scale lawfulness forbids arithmetic). Typical citations: modern monotonic modeling toolkits (post‑2017) used as method families, not as silent arithmetic.
• Set-valued / uncertainty-aware normalization outputs where uncertainty is preserved as a first-class outcome (tri‑state guards + set-valued uncertainty carriers, rather than coerced point values). Typical citations: conformal-style families (post‑2018+) used as evidence/uncertainty carriers.

SoTA is connected as wiring (packs/extensions) while UNM’s surface remains stable.

#Relations

Builds on / cites

• E.8 (pattern template)
• E.20 (governing-pattern discipline for mechanism‑intension content)
• A.15.3 (P2W planned baseline seam, when UNM is used in flows)
• F.18 (alias docking / token continuity, when renaming or retiring legacy UNM tokens)
• A.6.1 (U.Mechanism.Intension shape; specialization discipline)
• A.19.CHR (CHR suite boundary; slot lexicon; suite protocols)
• A.19.CN (CN_Spec normalization + comparability routing)
• C.16 (MM‑CHR evidence/calibration carriers)
• G.0 (CG-frame admissibility gates used downstream)
• G.2 (SoTA synthesis packs as the method‑family ingress; wiring‑only integration)
• E.18 (when UNM is used in transformation-flow structures/graphs; P2W freshness/work routing)
• B.3 (congruence/quotient intuition, when referenced)

Used by

• CHR suite protocols (normalize stage), when comparability.mode requires normalization-based comparability.

#A.19.UNM:End

---

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)