Skip to main content
Jira progress: loading…

NORM

Normalization Engines

1. Identity​

AttributeValue
Type codeNORM
Canonical nameNormalization Engines
Parent type—
Type statusreview
Tier scopetier-2, tier-3
Invocationchained
Payload effectderive
Lineage rolestamps-cmi

NORM is a category boundary, not an identity. Members are identified by MEID, versioned through ZAR as CMIs, and carry mice.category: NORM. The type itself has no MEID, no CMI and no runtime presence.

2. Purpose and boundary​

Normalization Engines (NORM) are micro-engines that rescale or normalize numeric values to enable comparability across entities, time periods, or benchmarks.

NORM engines preserve the semantic meaning of a metric while expressing it relative to a declared reference base (e.g. revenue, production volume, area, FTE).

Normalization is a mathematical operation, not a representational one.

Design rationale​

Normalization is not a formatting concern — it is a semantic scaling operation.

By isolating normalization into its own engine type, ZAYAZ ensures:

  • clear separation between absolute truth and relative insight,
  • auditability of intensity metrics,
  • consistent treatment of denominators across reports,
  • safe reuse of normalization logic across domains.

3. Membership criteria​

3.1 Inclusion tests​

A micro engine is a member of NORM when its specification satisfies the following:

NORM engines perform value rescaling without changing semantic intent:

  • Convert absolute values to intensities
  • Normalize metrics for peer comparison
  • Express metrics relative to capacity, revenue, or activity

Examples

  • tCO₂e per revenue
  • energy per m²
  • water per unit produced
  • waste per FTE

Normalization may be applied:

  • after CALC,
  • after AGGR,
  • or at disclosure-preparation stage.

3.2 Exclusions​

A micro engine is not a member of NORM when any of the following is its responsibility; each belongs to the type named:

  • ❌ Primary computation (CALC)
  • ❌ Unit or format conversion (TRFM)
  • ❌ Aggregation across entities or time (AGGR)
  • ❌ Metadata tagging or classification (META)
  • ❌ Estimation or extrapolation (SEM)
  • ❌ Policy or routing decisions (ZSSR)

Normalization changes scale, not structure, meaning, or policy.

3.3 Boundary cases​

  • NORM versus TRFM: NORM divides by a declared base and produces an intensity; TRFM converts units or formats and the quantity is unchanged. The TrustGate signal normalizer (MEID_SIGNAL_NORMALIZE_NORMALIZER) is representational and therefore TRFM, despite its capability code.
  • NORM versus CALC: NORM operates on an already computed or aggregated value; a one-step intensity from raw activity data is CALC.

4. Design rules​

RULE-NORM-001 — Comparability Over Absolutes

NORM engines exist to support comparison, benchmarking, and analysis — not raw reporting.

RULE-NORM-002 — Explicit Reference Bases

Every normalization explicitly declares its denominator or baseline.

RULE-NORM-003 — Deterministic Scaling

Given identical inputs and bases, normalization always yields the same result.

RULE-NORM-004 — Lineage Preservation

Normalized outputs always reference their source values and bases.

5. Contract​

5.1 Inputs​

NORM engines consume:

  • Validated numeric values (absolute or aggregated)
  • A declared normalization base, such as:
    • revenue
    • production volume
    • floor area
    • headcount
  • Optional benchmark or peer group context

Inputs SHALL be numerically valid and temporally aligned.

5.2 Outputs​

NORM engines produce:

  • Normalized value payload
  • Explicit reference metadata, including:
    • base type
    • base value
    • normalization rule identifier
  • Provenance links to source signals and base signals

Normalized outputs are typically consumed by:

  • reporting and disclosure pipelines,
  • benchmarking and analytics,
  • scenario and scoring engines.

6. Position in the computation chain​

6.1 Placement​

Normalization typically occurs after computation and aggregation:

INPUT
  → VALI
  → CALC
  → TRFM
  → AGGR
  → NORM
  → META
  → Reporting / Analysis

This ordering ensures that normalization operates on trusted, consolidated values.

7. Identity rules for members​

Members are micro engines (CMPS-001 mice: block) whose identity satisfies all of the following:

  • mice.category SHALL be NORM.
  • The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of NORMALIZE.
  • The DOMAIN segment SHALL be any registered MEID domain.
  • Typical FUNCTION segments: INTENSITY.
  • CMI kinds bound through zar.meid_cmi_binding SHALL be among ENGINE.
  • Lineage: members append their CMI stamp to the USO lineage tail.
  • Tier scope: tier-2, tier-3; invocation: chained; payload effect: derive.
  • USO role: expresses values relative to a declared base

NORM identifiers appear in:

  • signal lineage (CMI stamps),
  • audit trails,
  • explainability layers.

10. Members​

Loading micro engines…
  • CALC — Calculation Engines
  • AGGR — Aggregation Engines
  • TSER — Time-Series Engines
  • META — Metadata Enrichment Engines
  • RMAP — Risk Mapping Engines
  • SCEN — Scenario Engines
  • SCORE — Scoring Engines
  • AME — Assurance / Meta engines
  • TRFM — Transformation Engines


GitHub RepoRequest for Change (RFC)
Last updated on by ZAYAZ