A.19.UNM:4.1 - UNM operation declaration (normative)

UNM.IntensionRef is the retained citation name for the exact A.6.1 declaration episteme presented here. It does not identify a generic family in place of that declaration. The CHR baseline selects its edition before use; the normalize stage resolves to the declaration-local apply operation below. Its four named input meanings, NCV result and eligibility guard come from that selected declaration.

A different realizer of the same declaration changes no suite member. A corrected layout or citation can preserve its C.2.1 identity. A changed argument, law or guard changes the declaration contract and must be selected explicitly in the suite and protocol. For example, replacing pass|degrade admission with pass only would change whether apply may produce an NCV for degraded evidence; that hypothetical revision cannot enter through the unqualified name UNM. Whether two declarations concern the same operation family is a separate claim requiring that subject’s direct kind and identity rule; the UNM label supplies neither.

Scope note. This operation declaration uses the U.Mechanism content rules 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 A.15.2 baseline and, only for independently declared positions, A.15.3 typed filling under 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, specialization discipline)
• 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: declared normalization methods, with their actual domains, output kinds and preserved/lost distinctions; functional methods may additionally supply ≡_UNM over their admitted inputs
• RangedValueKind: 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
• Input qualification: coordinate values admitted by the selected CN-Spec for this bearer and use, within the configured method’s declared validity window. This is not an operation-application extent or an A.6.1 slice-membership ExtentRule.
• ResultKinds:
  • NormalizedCharacteristicValue (NCV)
  • optional function-kernel equivalence (≡_UNM) and its set of classes; a congruence claim only for separately checked operations
  • optional quotient objects and/or Normalization-fixed representatives (via NormalizationFixSpec) Operation-local argument and result declarations

The names below are declaration-local designators. ByValue carries the stated value; each named Ref resolves to one exact value and edition under this declaration’s effective reference scheme. Cardinality is per application. The first four arguments are shared declarations instantiated separately for apply and UNM_Eligibility.

For each argument row, its bindingPredicate obtains exactly when that application uses the resolved value for the row’s stated purpose: as the transformation operand, selected method, governing space/CN-Spec, ordered composition pair or quotient domain. A supplied but unused value is not bound. UNM_Eligibility may assess an incomplete proposal; an absent argument has no binding and the corresponding missing-input condition gives abstain. This does not relax apply’s inputs.

For each result row, its bindingPredicate obtains exactly when that application returns the resolved value as the row’s declared result, subject to the result laws below. A returned NCV binds the transformation value; compose binds the identifier of the method it constructed; quotient binds the relation and class set it constructed; the guard binds the judgment it evaluated. Each binding has the A.6.1 identity and maximal continuous extent within its application; a result binds at return, not before. Equal values returned by different applications have distinct bindings because their applications differ.

SlotIndex (derived projection). Project the designators, ValueKinds, designation rules and cardinalities from these operation-local declarations; the index adds no meanings. The historical Slot suffix permits CHR lookup. A.6.5 relation SlotSpecs are not the source of these operation meanings. Method descriptions, invariants and any NormalizationFixSpec are resolved from the selected configured method and CN-Spec. They qualify the method or a separately chosen representative use; they are not additional arguments of every operation.

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

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 for an input in the selected transformation’s actual domain, with the declared preservation/loss basis. Undefined inputs produce no NCV; an eligibility result cannot create a transformation value. The optional class/operation results follow their separate conditions below.

2. compose

   • Purpose: build a composed method when the inner outputs lie in the outer operation’s actual domain and the claimed preservation laws compose. Losses and receiving-use restrictions remain explicit.
   • 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) (optional)

   • Preconditions: one fixed functional normalization on its actual domain, with an explicit output equality. Recover that domain and the exact method/use basis.
   • Inputs: domain, resolved from the characteristic-space declaration or a declared chart domain, and NormalizationMethodInstanceSlot.
   • Outputs: UNMEquivalenceSlot and its classes set. Inherited operations additionally require equivalent-output and representative-independent-availability proofs; a class query additionally requires constancy on each class.
   • Use the declared NormalizationFixSpec only when a representative is needed. It selects a member of a class rather than proving that member was the original input.

Particular applications of these operations

The ApplicationPredicate differs by operation:

• apply: a calculation actually applies the selected configured method to the bound CV under the bound space and CN-Spec. Its defined, admitted return is the NCV required above. An abstain decision prevents this application from starting; passing eligibility alone does not start it.
• compose: a construction actually resolves the bound inner/outer methods, checks the domain and preservation conditions and constructs their composite for the bound space and CN-Spec. A failed condition yields no composed-method result.
• quotient: a mathematical construction actually uses the bound functional method and domain to determine equality of outputs and form its classes. A symbolic construction is sufficient; enumeration of an infinite domain is not required. Stronger inherited-operation and query claims retain their separate proofs.
• UNM_Eligibility: an evaluation actually assesses the bound proposal under the eligibility predicates below and returns the corresponding GuardDecision. Its result is separate from any subsequent normalization.

For each operation, the ApplicationIdentityRule identifies one invocation at its calculation or construction locus, from taking up those operands for that operation until return or termination. References to the same uninterrupted invocation reidentify one application. A second invocation, including a nested or later one with the same operands, method, qualification window and result, is another application. Changing an operand after beginning a fresh calculation starts another invocation; a continuation of an interrupted calculation counts as the same application only when continuity of that same invocation is established.

The ApplicationExtentRule takes that invocation’s actual interval: first use of its arguments through its return or termination. For the guard it is the eligibility evaluation; for compose it is the composite construction; for quotient it is the class construction; for apply it is the value calculation. An unfinished invocation has an open extent and no unreturned result binding. The data’s qualification window and the method’s validity window do not date these invocations. A trace may designate an invocation; a copied record, matching value or valid method identifier does not establish it. Ordinary function and projection guidance remains usable without an assertion of dated U.Work.

For example, with fixed method n(x)=x/10, domain [0,100] and the same CN-Spec, two separate calculations of n(20) both return 2. The first operand-to-return episode and the second are two apply occurrences; each binds 20 and its own return of 2. A third record containing 2, with no corresponding calculation, supplies no third result binding. Two constructions of g∘n, or of the same quotient, are likewise distinct when performed in separate construction episodes; their equal constructed mathematical values do not merge those episodes. Conversely, a second description of the first episode adds no application.

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 (Directed result before narrower claims). Return the defined transformed value with its domain and preserved/lost distinctions. Functional equality of outputs forms equivalence classes on that domain. A receiving operation descends only after compatibility and, for a partial operation, representative-independent availability hold. A query descends only when constant on the classes; otherwise retain/refine the input or return the missing distinction.
• UNM-L2a (Declared-basis locality). Every transformed value, function-kernel equivalence and stronger operation/query claim retains the selected method, actual domain, characteristic-space and CN-Spec editions, bearer, scope/window and comparison basis. Reusing an unchanged equivalence for a new query does not make that query recoverable; assess its own constancy/compatibility and the receiving-use conditions.
• 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)