Skip to main content
Jira progress: loading…

SCEN

Scenario Engines

1. Identity​

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

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

2. Purpose and boundary​

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.

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

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.

3. Membership criteria​

3.1 Inclusion tests​

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

  • 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

Examples

  • emissions trajectories under a 1.5°C pathway
  • revenue exposure under transition scenarios
  • energy mix evolution under policy assumptions
  • climate risk stress paths

3.2 Exclusions​

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

  • ❌ compute baseline values (CALC)
  • ❌ aggregate organizational hierarchies (AGGR)
  • ❌ score or rank performance (SCORE)
  • ❌ validate scenario plausibility (AME)
  • ❌ select which scenario to use (ZSSR / policy)

SCEN engines apply scenarios —
they do not decide them.

3.3 Boundary cases​

  • SCEN versus ESTM: SCEN evaluates a declared pathway deterministically (what holds if the scenario holds); ESTM infers unobserved or future values from data with uncertainty. A 1.5 °C trajectory is SCEN; an LSTM forecast is ESTM.
  • SCEN versus CALC: a value for the reporting period from observed inputs is CALC; a value for a future horizon under a declared pathway is SCEN, even when the formula is the same.
  • SCEN versus SCORE: a projected trajectory is SCEN; a readiness or alignment rating derived from it is SCORE.

4. Design rules​

RULE-SCEN-001 — Explicit Assumptions

All scenario assumptions (pathways, curves, parameters) SHALL be explicit and referenceable.

RULE-SCEN-002 — Non-Predictive

SCEN engines SHALL NOT claim factual truth — only conditional outcomes.

RULE-SCEN-003 — Deterministic Evaluation

Given the same inputs and scenario definition, outputs SHALL be reproducible.

RULE-SCEN-004 — Temporal Awareness

Scenario outputs are inherently time-indexed and horizon-aware.

RULE-SCEN-005 — Auditability

Outputs SHALL reference the exact scenario artifact and version used.

5. Contract​

5.1 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 SHALL be:

  • versioned,
  • referenceable,
  • and auditable.

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

6. Position in the computation chain​

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

7. Identity rules for members​

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

  • mice.category SHALL be SCEN.
  • The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of PROJECT, OPTIMIZE.
  • The DOMAIN segment SHALL be any registered MEID domain.
  • Typical FUNCTION segments: ALIGNMENT, LIFECYCLE.
  • CMI kinds bound through zar.meid_cmi_binding SHALL be among ENGINE, MODEL.
  • Lineage: members append their CMI stamp to the USO lineage tail.
  • Tier scope: tier-2, tier-3; invocation: chained; payload effect: derive.

10. Members​

Loading micro engines…
  • CALC — Calculation Engines
  • AGGR — Aggregation Engines
  • NORM — Normalization Engines
  • META — Metadata Enrichment Engines
  • RMAP — Risk Mapping Engines
  • SCORE — Scoring Engines
  • AME — Assurance / Meta engines
  • ESTM — Estimation & Forecasting Engines


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