AGGR
Aggregation Engines
1. Identity
| Attribute | Value |
|---|---|
| Type code | AGGR |
| Canonical name | Aggregation Engines |
| Parent type | — |
| Type status | review |
| Tier scope | tier-2, tier-3 |
| Invocation | chained |
| Payload effect | derive |
| Lineage role | stamps-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
- Given the same inputs and aggregation rules, AGGR engines always produce the same output.
- AGGR engines SHALL NOT estimate, extrapolate, or fill gaps.
- Missing data SHALL be handled upstream (e.g. SEM).
- AGGR engines operate exclusively on validated computation outputs and SHALL NOT operate on raw inputs.
- 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.categorySHALL beAGGR.- The
CAPABILITYsegment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one ofAGGR. - The
DOMAINsegment SHALL be any registered MEID domain. - Typical
FUNCTIONsegments:AGGREGATION. - CMI kinds bound through
zar.meid_cmi_bindingSHALL be amongENGINE. - 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
11. Related types
- 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
Other related documents
- SEM — Stochastic Extrapolation Module
- ZARA — Explainability & orchestration