SCEN
Scenario Engines
1. Overview
Scenario Engines (SCEN) are a capability class of Micro Engines (MICE) responsible for producing forward-looking, counterfactual, or pathway-based outputs based on declared scenarios.
SCEN engines:
- project how metrics may evolve under defined assumptions,
- operate over time horizons (e.g. 2030, 2050),
- support transition, physical risk, and alignment analysis.
SCEN engines do not predict the future.
They evaluate what would happen if a declared scenario were to hold.
SCEN is a type, not an identity.
Concrete implementations are identified by MEID, versioned via ZAR, and leave CMI lineage stamps at runtime.
2. Position in the MICE Model
Capability, not identity
A Scenario Engine:
- does not define which scenario applies (that is input),
- does not define governance decisions,
- does define how a declared scenario is applied to signals.
Multiple MEIDs may implement SCEN capabilities across:
- different domains (climate, energy, finance),
- different frameworks (IEA, NGFS, IPCC),
- different tiers (typically Tier-2 or Tier-3).
Typical placement
| Dimension | Value |
|---|---|
| Capability type | SCEN |
| Common tiers | Tier-2, Tier-3 |
| Typical classification | Contract-Engine |
| Versioning | ZAR (CMI-level) |
| Lineage impact | Appends scenario CMI stamp to USO |
3. Design Principles
-
Explicit Assumptions
All scenario assumptions (pathways, curves, parameters) must be explicit and referenceable. -
Non-Predictive
SCEN engines do not claim factual truth — only conditional outcomes. -
Deterministic Evaluation
Given the same inputs and scenario definition, outputs must be reproducible. -
Temporal Awareness
Scenario outputs are inherently time-indexed and horizon-aware. -
Auditability
Outputs must reference the exact scenario artifact and version used.
4. Scope of Responsibility
What SCEN engines do
- Apply scenario pathways to baseline metrics
- Project values across future time horizons
- Translate scenario curves into metric-level outputs
- Support alignment and gap-to-target analysis
Typical examples:
- emissions trajectories under a 1.5°C pathway
- revenue exposure under transition scenarios
- energy mix evolution under policy assumptions
- climate risk stress paths
5. What SCEN Engines Do Not Do
SCEN engines intentionally do not:
- ❌ compute baseline values (CALC)
- ❌ aggregate organizational hierarchies (AGGR)
- ❌ score or rank performance (SCORE)
- ❌ validate scenario plausibility (ASSURANCE)
- ❌ select which scenario to use (ZSSR / policy)
SCEN engines apply scenarios —
they do not decide them.
6. Inputs
Typical SCEN inputs include:
- baseline computed metrics (from CALC / AGGR),
- scenario definitions (pathways, curves, narratives),
- time horizon parameters,
- optional sensitivity or variant flags.
All scenario definitions must be:
- versioned,
- referenceable,
- and auditable.
7. Outputs
SCEN engines emit:
- scenario-adjusted metric values,
- time-indexed projections,
- explicit scenario references,
- lineage metadata linking baseline and scenario artifacts.
Outputs are commonly consumed by:
- RMAP engines (risk exposure mapping),
- SCORE engines (composite indicators),
- disclosure and alignment reporting,
- assurance and governance layers.
8. Interaction with ZSSR
ZSSR does not route to “SCEN” generically.
Instead, it:
- selects specific MEIDs implementing SCEN,
- binds them to explicit scenario artifacts,
- enforces policy constraints (e.g. allowed frameworks).
Tags such as scenario, climate_risk, or framework tags
may be used as fallback selectors, but never replace explicit routing.
9. Example Scenario Engines
10. Summary
Scenario Engines:
- enable forward-looking analysis without prediction,
- make assumptions explicit and auditable,
- support alignment, transition, and risk workflows,
- integrate cleanly with ZSSR and assurance layers.
They are the counterfactual reasoning layer of the ZAYAZ platform.
Stable