#Unified Normalization Mechanism (UNM)

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

Type: Architectural (A)
Status: Stable
Normativity: Normative (unless explicitly marked informative) Placement: Part A / CN‑Spec cluster (A.19) / CHR mechanism owner patterns Semantic owner note (Phase‑3 canonicalization): This pattern is the designated single semantic owner of the meaning of UNM.IntensionRef (per E.20). The canonical publication anchor for UNM.IntensionRef remains A.19.UNM, while A.6.1 remains the owner of the U.Mechanism.Intension template.
Non‑ownership note: The CN_Spec surface itself (incl. CN_Spec.normalization and CN_Spec.comparability) remains owned 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 / 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. Where are the evidence pins and any transport / plane pins (Bridge/CL/ReferencePlane + UNM.TransportRegistryΦ/Phi if invoked)?

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, declared invariants, validity window, evidence pins, and any Bridge/CL/ReferencePlane pins (plus the edition pin UNM.TransportRegistryΦ/Phi when transport is invoked).

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 explicit semantic ownership and auditability.

Single-owner note (Phase‑3 canonicalization). This pattern is intended to become the single semantic owner of 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/contexts, 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 (different units, scale types, reference planes, context semantics, or validity windows).

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 owner pattern:

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

2. Comparability becomes rhetorical. People say “we normalize” but cannot answer:
   Which method? Which invariants? Which validity window? Which evidence? Which transport/plane regime?

3. Cross-context and cross-plane slips become invisible. Teams “reuse” normalizations across contexts without explicit Bridge/CL/ReferencePlane discipline.

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 (scope / context / time window constraints).

NormalizationMethodDescription. An editioned epistemic description of a normalization method (bounds, validity region/window, scope constraints, and evidence links owned 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 host 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 host). 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). A context‑local equivalence relation induced by a chosen NormalizationMethodInstance. 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”).

UNM.TransportRegistryΦ. An editioned anchor (single‑writer under UNM authoring) that enumerates the declared transport/plane pins and Φ‑penalties used when normalizations are reused across contexts/planes. Referenced via edition pins in suite/flow contracts; never re‑authored downstream.
Alias: UNM.TransportRegistryPhi is an ASCII‑safe alias token (dock via F.18); it is not a competing head.

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 owned 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 legality 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 charts/views)
• BaseType: chart/U.CharacteristicSpace family in a CN‑frame (one U.BoundedContext), where normalization acts on coordinate values (CV) for measurable slots (UNM normalizes values, not characteristics)
• SliceSet: U.ContextSliceSet (context is explicit; no implicit “global normalization”)
• ExtentRule: “coordinate values admitted for normalization within the declared context and the method instance 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⟩
• ContextSlot : ⟨ValueKind = U.BoundedContext, refMode = U.BoundedContextRef⟩

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.

Note (transport anchor, not a SlotKind). When transport/plane reuse is invoked, Audit MUST cite the edition pin key UNM.TransportRegistryΦ (aka UNM.TransportRegistryPhi) in the editions vector (see Transport/Audit), rather than introducing an ad‑hoc …Ref kind.

OperationAlgebra (conceptual)

1. apply

• Preconditions: UNM_Eligibility(…) ∈ {pass, degrade} (fail‑closed; abstain ⇒ no NCV output).
• Inputs: NormalizationMethodInstanceSlot, CoordinateValueSlot, CharacteristicSpaceSlot, CNSpecSlot, ContextSlot
• 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}), ContextSlot
• 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 owned 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 live in the method). NormalizationMethod defines invariants, closure (composition / inverses where defined), and validity rules. UNM consumes these declarations; it does not invent “extra” legality.
• 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 (Context-local by default). ≡_UNM is context‑local; cross‑context reuse requires explicit transport declarations (Bridge-only).
• 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 (Bridge‑only transport). Cross‑context reuse of normalization requires explicit Bridge-only transport declarations (Bridge id + channel + ReferencePlane(src,tgt)); describedEntity changes require a KindBridge (CL^k) and the two‑bridge rule. 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 instance, invariants, validity window, evidence pins, and any transport/plane declarations must be auditable as refs/pins.
• UNM‑L8 (No shadow writers). When UNM publishes/updates editioned anchors used downstream (e.g., UNM.TransportRegistryΦ), other patterns and faces treat them as ref‑only (single‑writer discipline; no competing centers of gravity).
• 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, ContextSlot) → GuardDecision where GuardDecision ∈ {pass | degrade | abstain} and follows this predicate semantics:

• pass iff all of the following hold:
  • (CN‑frame 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;
  • (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 owned 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).

Transport

• Bridge-only. Any cross-context use must be expressed via explicit Bridge pins and recorded in Audit.
• If the describedEntity changes, a KindBridge (CL^k) must be declared (two‑bridge rule).
• If transport/plane reuse is invoked, the edition pin key UNM.TransportRegistryΦ (aka UNM.TransportRegistryPhi) MUST be cited explicitly (in addition to Bridge/CL/ReferencePlane pins); penalties remain R‑lane only.

Γ_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

• Normalized values live on the episteme ReferencePlane by default.
• Plane crossings require explicit CL^plane and are audited; penalties route to R_eff only.

Audit Audit records MUST include:

• CNSpecRef.edition + comparability.mode
• (when present) CN_Spec.normalization.UNM_id (the selected UNM mechanism instance id for this CN‑frame)
• 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)
• all evidence pins (as declared by the instance) and their scope ids
• any Bridge/CL/ReferencePlane pins if transport or plane crossings are invoked, plus the edition pin key UNM.TransportRegistryΦ/Phi
• 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 semantic owner 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 owned by MM‑CHR (normative-by-reference)

UNM does not claim “this normalization is legitimate” by decree.
Instead, legitimacy is routed through evidence carriers and calibration/validity artifacts owned 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 / TGA integration note (normative-by-reference)

When UNM is used inside transduction flows/graphs (e.g., E.18 (E.TGA)):

• 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.
• In TGA terms, transport/plane reuse is surfaced as explicit calibration/transport artifacts pinned to TransportRegistry^Φ (editioned as UNM.TransportRegistryΦ; penalties stay R‑lane only).
• Editioned anchors referenced by faces downstream (e.g., UNM.TransportRegistryΦ, and legality anchors when applicable) remain single‑writer: downstream consumers cite them 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 / TGA). 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.
• Legality 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.
• Transport discipline: cross-context/plane reuse is Bridge-only, explicit, audited; penalties route to R/R_eff only.
• Quotient/fix discipline: if a representative is required, NormalizationFix is declared; otherwise quotient semantics remain abstract.
• Auditability: method instance, validity window, evidence pins, and transport/plane policies are recorded as refs/pins.
• No shadow writers: if editioned transport/calibration anchors are used (e.g., UNM.TransportRegistryΦ), downstream consumers treat them as ref‑only (single‑writer discipline).
• 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).
• TransportRegistry key discipline: UNM.TransportRegistryΦ (alias UNM.TransportRegistryPhi) is referenced as an edition pin key (and audited) / TransportRegistry^Φ in TGA terms, not introduced as a new …Ref kind.

#Common Anti‑Patterns and How to Avoid Them

1. Hidden normalization inside scoring or selection
   Avoid by routing via 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. Cross-context reuse without transport declaration
   Avoid by Bridge-only transport and auditing Bridge/CL/ReferencePlane pins.

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 globally comparable across contexts/planes
   Avoid by Bridge-only transport declarations + audited ReferencePlane/CL pins; otherwise stay context-local and fail‑closed.

8. Re‑authoring editioned transport/calibration anchors downstream
   Avoid by treating UNM.TransportRegistryΦ (and similar anchors) as single‑writer artifacts: downstream is ref‑only.

#Consequences

Benefits

• Makes “normalize-then-compare” a first-class governance choice.
• Centralizes semantic ownership, improving usability and reducing drift.
• Supports evolvability: method families can evolve via packs/extensions without mutating the mechanism surface.
• Prevents silent illegality (unit/scale/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.
• Bridge-only transport prevents accidental “global normalization” across contexts.

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 host 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; legality 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 artifacts, 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 (single‑owner 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 legality gates used downstream)
• G.2 (SoTA synthesis packs as the method‑family ingress; wiring‑only integration)
• E.18 (E.TGA) (when UNM is used in transduction flows/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