ESTM
Estimation & Forecasting Engines
1. Identity
| Attribute | Value |
|---|---|
| Type code | ESTM |
| Canonical name | Estimation & Forecasting Engines |
| Parent type | — |
| Type status | review |
| Tier scope | tier-1, tier-2, tier-3 |
| Invocation | chained |
| Payload effect | derive |
| Lineage role | stamps-cmi |
ESTM is a category boundary, not an identity. Members are identified by MEID, versioned through ZAR as CMIs, and carry mice.category: ESTM. The type itself has no MEID, no CMI and no runtime presence.
2. Purpose and boundary
Estimation & Forecasting Engines (ESTM) produce values that were not observed: they fill gaps in the reporting period (interpolation, extrapolation, imputation), forecast future values from observed series, and infer a class or hypothesis probabilistically (device identification, statistical inference, significance testing).
Three properties set an ESTM member apart from every other type: its output is an estimate and carries an uncertainty measure as part of the contract; its method is a model — statistical or learned — with declared assumptions and calibration provenance; and the estimate is never presented as an observed fact. The Smart Extrapolation Module (SEM) is the founding member.
Model-based implementation alone does not establish ESTM membership; the estimated-output and uncertainty contract is decisive. Everything they produce is flagged as estimated so that AME, reporting and federation treat it accordingly.
3. Membership criteria
3.1 Inclusion tests
A micro engine is a member of ESTM when its specification satisfies the following:
- It produces a value, class or hypothesis for something that was not observed — missing, future or latent.
- Its output carries an explicit uncertainty or confidence measure (interval, probability, score) as part of the contract.
- Its method is a registered model or statistical procedure with declared assumptions, parameters and calibration provenance (CMI kind
MODEL). - Each output CSI declares exactly one EXACT, BANDED or RECORDED mode, with an optional engine default. Stochastic methods record a seed where supported; unsupported seed control must be disclosed. Online learning during execution is not admissible.
- Its MEID capability is
PREDICTorCLASSIFY.
3.2 Exclusions
A micro engine is not a member of ESTM when any of the following is its responsibility; each belongs to the type named:
- ❌ compute values from observed inputs by a formula, including spend-based factors (CALC)
- ❌ evaluate a declared scenario or pathway (SCEN)
- ❌ condition or align time series by explicit rules, including rule-based interpolation (TSER)
- ❌ apply device plausibility rules (SENS)
- ❌ decide whether an estimate is admissible (VALI, AME)
3.3 Boundary cases
- ESTM versus SCEN: SCEN evaluates a declared pathway deterministically; ESTM infers from data with uncertainty. A 1.5 °C trajectory is SCEN; an LSTM forecast of next year's consumption is ESTM.
- ESTM versus TSER: carry-forward or linear interpolation under a declared rule is TSER; a fitted interpolation with an uncertainty band is ESTM.
- ESTM versus CALC: spend × emission factor is called an estimate in GHG Protocol terms but is a deterministic formula — CALC. The test is formula versus fitted model.
- ESTM versus SENS: a Bayesian classifier that infers what device produced a stream (IoT-DI) is ESTM; the device-aware plausibility rules applied once the device is known are SENS.
- ESTM versus RSLU: a learned entity matcher is ESTM and emits candidates with probabilities; the deterministic decision which candidate is canonical is RSLU.
4. Design rules
An ESTM engine SHALL emit an uncertainty measure with every estimate. An estimate without one is a contract violation.
Every output SHALL reference the model artifact (CMI kind MODEL), its version, the training or calibration data reference and the declared assumptions.
An ESTM engine SHALL declare exactly one governed replay mode per output CSI, with an optional engine default. EXACT requires identical governed outputs; BANDED requires pinned model identity and inference parameters with policy-defined tolerances. Stochastic methods SHALL retain the seed where supported and all reproducibility controls required by the selected mode; unsupported seed control SHALL be disclosed. A seed alone is not proof of exact replay. Where model pinning cannot be guaranteed, policy may select RECORDED: the output SHALL be DAL-anchored at creation, with its hash, lineage and provenance retained. RECORDED verifies that evidence without recomputation and does not require an unavailable seed.
Outputs SHALL be flagged as estimated in signal metadata. An estimate SHALL NOT overwrite an observed value; it MAY stand beside one with its own lineage.
Model artifacts SHALL be registered in ZAR and approved before use. Where EXACT is not supported, the governing policy SHALL select BANDED with explicit tolerances or RECORDED with retained outputs and provenance, as governed by the Replay Constitution. The engine SHALL NOT choose a weaker profile at runtime.
5. Contract
5.1 Inputs
ESTM engines consume:
- observed series or values with lineage, and the declared gap, horizon or question,
- a registered model artifact reference and its parameters,
- optional priors, constraints and calibration references,
- policy context stating whether estimation is permitted for the metric and jurisdiction.
5.2 Outputs
ESTM engines emit:
- estimated values, classes or hypotheses,
- an uncertainty measure per estimate (interval, probability, score),
- the model reference, assumptions, inference parameters and seed where supported (otherwise an explicit unsupported-seed declaration),
- the declared replay mode per output CSI and its required pins or creation-time anchor, hash, lineage and provenance,
- the
estimatedflag in signal metadata.
Consumers: CALC and AGGR (as flagged inputs), SCORE, AME (admissibility of the estimate), reporting with estimation disclosure.
6. Position in the computation chain
6.1 Placement
Gap filling runs before computation; forecasting runs after consolidation:
EXTR / SENS / TSER → (gap) → ESTM → VALI → CALC / AGGR → AME
AGGR → ESTM (forecast) → SCORE / reporting
EXTR (stream) → ESTM (device inference) → SENS
6.2 Interaction with ZSSR
ZSSR selects an ESTM MEID only where policy permits estimation for the metric, period and jurisdiction. Estimation is never a silent fallback for missing data: the gap is declared, the estimate is flagged, and AME decides admissibility.
7. Identity rules for members
Members are micro engines (CMPS-001 mice: block) whose identity satisfies all of the following:
mice.categorySHALL beESTM.- The
CAPABILITYsegment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one ofPREDICT,CLASSIFY. - The
DOMAINsegment SHALL be any registered MEID domain. - Typical
FUNCTIONsegments:INTERPOLATOR,FORECASTER,INFERENCE,DEVICE,CARBON_PRICE. - CMI kinds bound through
zar.meid_cmi_bindingSHALL be amongENGINE,MODEL. - Lineage: members append their CMI stamp to the USO lineage tail.
- Tier scope: tier-1, tier-2, tier-3; invocation: chained; payload effect: derive.
8. Bounded lifecycle assessment — 2026-10-25
Decision: advance to review. ESTM covers missing, future or latent values
inferred through a registered model or statistical procedure, with uncertainty,
assumptions and calibration provenance. These requirements distinguish it from
CALC formulas, TSER rule-based interpolation, SCEN declared scenarios, and RSLU
deterministic identity decisions. Model-based implementation alone is not the
membership criterion.
AgriVision, BOM Interpolator, Forecaster LSTM, Carbon Credit Expected Price Engine and Statistical Inference currently declare ESTM. Several pages are identity stubs, as expected during development. This indicates incomplete documentation, not an invalid type or incorrect MEIDs; frontmatter classifications remain subject to member-level review as the contracts are populated.
The type already defines the observed inputs, model and policy context, estimated outputs with uncertainty, non-overwrite rule, model governance and replay requirements. Those boundaries justify type review independently of whether a member is ready to execute. Each member must later supply its concrete schemas, uncertainty semantics, model/calibration lineage and estimation-permission policy. It must demonstrate its declared EXACT, BANDED or RECORDED behavior; a seed alone does not prove reproducibility across runtimes. No model may silently learn, recalibrate or change version during a calculation.
Review permits classification only. It does not approve any model or engine, create change authority, change existing MEIDs or authorize deployment.
9. Members
10. Related types
- EXTR — Extraction Engines
- SENS — Sensor Logic Units
- TSER — Time-Series Engines
- CALC — Calculation Engines
- AGGR — Aggregation Engines
- SCEN — Scenario Engines
- SCORE — Scoring Engines
- AME — Assurance / Meta engines
- VALI — Validator Engines