CALC
Calculation Engines
1. Overview
Calculation Engines (CALC) are a capability class of Micro Engines (MICE) responsible for performing deterministic, first-order computations over declared input data.
CALC engines:
- apply explicit formulas or algorithms,
- produce quantitative results with well-defined semantics,
- form the computational backbone of most disclosure and reporting pipelines.
CALC is a type, not an identity.
Concrete engines are identified by MEID, versioned via ZAR, and leave CMI lineage stamps at runtime.
2. Position in the MICE Model
Capability, not identity
A Calculation Engine:
- does not define which engine runs (MEID does),
- does not define version or deployment (ZAR does),
- does define what kind of computation is performed.
Multiple MEIDs may implement the CALC capability, across different domains and tiers.
Typical placement
| Dimension | Value |
|---|---|
| Capability type | CALC |
| Common tiers | Tier-1, Tier-2, Tier-3 |
| Typical classification | Contract-Engine |
| Versioning | ZAR (CMI-level) |
| Lineage impact | Appends CMI stamp to USO |
3. Design Principles
-
Determinism
Given identical inputs and options, a CALC engine must always produce the same output. -
Explicit logic
All formulas, coefficients, and assumptions are explicit, inspectable, and versioned. -
Input-bound responsibility
CALC engines operate only on declared inputs — they do not infer, guess, or fill gaps. -
Auditability
Outputs must be reproducible and traceable via lineage metadata and registry references.
4. Scope of Responsibility
What CALC engines do
- Compute quantitative values from declared inputs
- Apply domain-specific formulas or algorithms
- Emit schema-valid, semantically explicit outputs
Typical examples:
- GHG absolute or intensity calculations
- Energy totals or normalization
- Water withdrawal or consumption metrics
- Ratio-based indicators or performance scores
5. What CALC Engines Do Not Do
CALC engines are intentionally narrow.
They do not:
- ❌ validate structural correctness (VALI)
- ❌ convert units or formats (TRANS / normalization)
- ❌ aggregate across entities or hierarchies (AGGR)
- ❌ estimate missing data (SEM)
- ❌ apply governance, policy, or routing logic (ZSSR / assurance)
This separation keeps CALC engines:
- simple,
- composable,
- and easy to reason about.
6. Inputs
Typical inputs include:
- activity or measurement data,
- financial or normalization denominators,
- calculation options (method flags, scope selection),
- contextual metadata (boundaries, time period).
All inputs must conform to declared schemas.
If data is incomplete or malformed, responsibility lies upstream.
7. Outputs
CALC engines emit:
- computed values,
- explicit units and metric semantics,
- execution metadata for lineage and audit.
Outputs are commonly consumed by:
- AGGR engines (roll-ups),
- TRANS engines (classification or normalization),
- VALI engines (conformance checks),
- Assurance engines (Tier-0 validation).
8. Interaction with ZSSR
ZSSR does not route to “CALC” directly.
Instead, it selects specific MEIDs that implement CALC capabilities.
Tags associated with CALC engines (e.g. calc, intensity, ghg) may be used as:
- pre-filters or
- fallback selectors
…but explicit routing rules always take precedence.
9. Example Calculation Engines
10. Summary
Calculation Engines:
- provide deterministic, auditable computations,
- are foundational to Tier-1–3 pipelines,
- remain narrowly scoped by design,
- enable safe composition via ZSSR and assurance layers.
They are the numerical truth-builders of the ZAYAZ platform.
Stable