Skip to main content
Jira progress: loading…

AGGR

Aggregation Engines

1. Identity​

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

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


2. Purpose and boundary​

Aggregation Engines (AGGR) are Micro Engines responsible for deterministically combining already-computed and validated results into higher-order, consolidated outputs.

AGGR engines do not compute new primary values.
They derive secondary results strictly by aggregating existing outputs along explicitly defined dimensions.

Design rationale​

By elevating aggregation to a dedicated engine type, ZAYAZ ensures:

  • a clear semantic distinction between computed, estimated, and aggregated values,
  • deterministic behavior suitable for assurance and verification,
  • long-term scalability as reporting and disclosure complexity increases.

Aggregation is not an implementation detail — it is a semantic operation, and AGGR makes it explicit.


3. Membership criteria​

3.1 Inclusion tests​

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

AGGR engines perform mathematical and structural aggregation across explicit dimensions:

Structural

  • asset → site
  • site → company
  • company → group

Temporal

  • day → month
  • month → quarter
  • quarter → year

Logical

  • scope-level consolidation (e.g. Scope 1 + Scope 2)
  • category-level roll-ups (e.g. Scope 3 categories)
  • portfolio, region, or segment summaries

Supported aggregation modes​

Depending on the metric type and rule definition, AGGR engines support:

  • Sum
  • Weighted sum
  • Average
  • Weighted average
  • Minimum / maximum (only where explicitly allowed)
  • Count

All aggregation rules are explicitly declared, versioned, and auditable.

3.2 Exclusions​

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

  • ❌ Primary computation (CALC)
  • ❌ Validation of raw inputs (VALI)
  • ❌ Unit or format conversion (TRFM)
  • ❌ Estimation or extrapolation (SEM)
  • ❌ Policy routing or enforcement (ZSSR)
  • ❌ Interpretation or narrative generation (ZARA)

This strict separation is essential for explainability and assurance.

3.3 Boundary cases​

  • AGGR versus CALC: AGGR consumes several execution outputs and combines them; CALC consumes declared input data and applies a formula. Scope 1 + Scope 2 is AGGR; Scope 1 from fuel data is CALC.
  • AGGR versus TSER: resampling one series to a coarser grid is TSER; summing several series or entities into one result is AGGR.
  • AGGR versus UOM-TYPE: a roll-up over the organizational graph that depends on Resource Point boundaries is a UOM-TYPE responsibility while that type exists; a roll-up over an explicit hierarchy passed as input is AGGR.

4. Design rules​

RULE-AGGR-001 — Deterministic
  • Given the same inputs and aggregation rules, AGGR engines always produce the same output.
RULE-AGGR-002 — No Assumptions
  • AGGR engines SHALL NOT estimate, extrapolate, or fill gaps.
  • Missing data SHALL be handled upstream (e.g. SEM).
RULE-AGGR-003 — Post-Compute Only
  • AGGR engines operate exclusively on validated computation outputs and SHALL NOT operate on raw inputs.
RULE-AGGR-004 — Full Lineage Preservation
  • Every aggregated result retains a complete reference to all contributing executions.

5. Contract​

5.1 Inputs​

AGGR engines consume:

  • Collections of validated computation outputs
  • Aggregation context, including:
    • hierarchy or scope definition
    • time window
    • aggregation rule reference
  • Optional weighting parameters (e.g. revenue, production volume, area)

All inputs SHALL conform to declared output schemas.

5.2 Outputs​

AGGR engines produce:

  • A consolidated output payload (schema-validated)
  • Aggregation metadata:
    • aggregation rule identifier
    • aggregation dimensions
    • engine version
  • Provenance references:
    • list of contributing execution IDs
    • source method identifiers and versions

Aggregated outputs may be further consumed by:

  • higher-level AGGR passes,
  • reporting and disclosure pipelines,
  • assurance and verification workflows.

6. Position in the computation chain​

6.1 Placement​

AGGR engines operate after computation and normalization:

INPUT
→ VALI
→ CALC
→ TRFM
→ (optional SEM)
→ AGGR
→ Reporting / Disclosure / Assurance

This ordering ensures aggregation is applied only to trusted, normalized data.


7. Identity rules for members​

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

  • mice.category SHALL be AGGR.
  • The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of AGGR.
  • The DOMAIN segment SHALL be any registered MEID domain.
  • Typical FUNCTION segments: AGGREGATION.
  • 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: produces aggregated signals from validated source signals

AGGR identifiers are used consistently across:

  • execution logs,
  • provenance records,
  • USO naming,
  • explainability surfaces.

9. Governance and audit​

9.1 Audit & Provenance​

Every AGGR execution produces an auditable aggregation record linking:

  • all source execution IDs,
  • the aggregation rule definition,
  • the AGGR engine version,
  • timestamps and execution context.

This enables:

  • full replay of aggregated results,
  • verifier inspection,
  • regulatory audit readiness.

AGGR engines are fully integrated with ALTD / DAL logging.


10. Members​

Loading micro engines…

  • CALC — Calculation Engines
  • TRFM — Transformation Engines
  • VALI — Validator Engines
  • TSER — Time-Series Engines
  • GEOX — Geospatial Engines
  • NORM — Normalization Engines
  • META — Metadata Enrichment Engines
  • RMAP — Risk Mapping Engines
  • AME — Assurance / Meta engines
  • SEM — Stochastic Extrapolation Module
  • ZARA — Explainability & orchestration



GitHub RepoRequest for Change (RFC)