Skip to main content
Jira progress: loading…

CALC

Calculation Engines

1. Identity​

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

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

2. Purpose and boundary​

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.

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.

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.

3. Membership criteria​

3.1 Inclusion tests​

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

  • Compute quantitative values from declared inputs
  • Apply domain-specific formulas or algorithms
  • Emit schema-valid, semantically explicit outputs

Examples

  • GHG absolute or intensity calculations
  • Energy totals or normalization
  • Water withdrawal or consumption metrics
  • Ratio-based indicators or performance scores

3.2 Exclusions​

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

  • ❌ validate structural correctness (VALI)
  • ❌ convert units or formats (TRFM / NORM)
  • ❌ 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.

3.3 Boundary cases​

  • CALC versus NORM: CALC produces an absolute or first-order value; NORM rescales an existing value against a declared base. An intensity computed directly from activity data and a denominator in one step is CALC; an intensity derived from an already computed absolute value is NORM.
  • CALC versus AGGR: CALC applies a formula to one declared input set; AGGR combines several already computed results along a dimension.
  • CALC versus TRFM: a unit conversion that leaves the quantity unchanged is TRFM, even when it involves a multiplication.

4. Design rules​

RULE-CALC-001 — Determinism

Given identical inputs and options, a CALC engine SHALL produce the same output.

RULE-CALC-002 — Explicit logic

All formulas, coefficients, and assumptions are explicit, inspectable, and versioned.

RULE-CALC-003 — Input-bound responsibility

CALC engines operate only on declared inputs — they SHALL NOT infer, guess, or fill gaps.

RULE-CALC-004 — Auditability

Outputs SHALL be reproducible and traceable via lineage metadata and registry references.

5. Contract​

5.1 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 SHALL conform to declared schemas.
If data is incomplete or malformed, responsibility lies upstream.

5.2 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).

6. Position in the computation chain​

6.1 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.

7. Identity rules for members​

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

  • mice.category SHALL be CALC.
  • The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of CALC, ALLOCATE.
  • The DOMAIN segment SHALL be any registered MEID domain.
  • Typical FUNCTION segments: CALCULATOR, SCOPE1, SCOPE2, SCOPE3, SHARE, BUDGET, TARGET_GAP, DELTA, SPLIT.
  • 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-1, tier-2, tier-3; invocation: chained; payload effect: derive.

10. Members​

Loading micro engines…
  • VALI — Validator Engines
  • TRFM — Transformation Engines
  • EXTR — Extraction Engines
  • CONN — Connector Engines
  • SENS — Sensor Logic Units
  • TSER — Time-Series Engines
  • AGGR — Aggregation Engines
  • NORM — Normalization Engines
  • AME — Assurance / Meta engines


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