Jira progress: loading…

MICE

Micro Engines (MICE) — Overview

1. What is a MICE?

Micro Engines (MICE) are small, specialized, executable intelligence units within the ZAYAZ platform.
Each Micro Engine performs a well-defined task — such as calculation, aggregation, validation, transformation, or assurance — and emits machine-readable signals that can be routed, verified, and composed into higher-level sustainability intelligence.

Micro Engines are designed to be:

• Composable – chained or orchestrated by policy and routing rules
• Auditable – every execution is traceable to a specific engine identity and build
• Replaceable – engines evolve independently without breaking the system
• Federation-safe – outputs can be verified and trusted across organizational boundaries

MICE are the execution backbone of ZAYAZ’s sustainability intelligence system.

Each MICE:

• implements one well-defined responsibility
• is bound to a stable MEID (Micro Engine Identifier)
• is versioned and distributed via ZAR
• leaves a runtime lineage stamp (CMI short code) on every signal it touches
• can be composed by ZSSR rulesets into regulatory-grade workflows

Design Principle

MICE do not “solve reporting”.
They solve one precise transformation, calculation, classification, or aggregation — perfectly and provably.

---

2. Why Micro Engines?

2.1. Modular Intelligence Architectur

Traditional ESG and sustainability systems embed logic directly into:

• forms,
• reports,
• spreadsheets,
• or monolithic applications.

This leads to:

• brittle logic,
• unclear provenance,
• poor auditability,
• slow adaptation to regulatory change.

ZAYAZ replaces this with a Modular Intelligence Architecture, where:

• logic lives in executable Micro Engines,
• data flows as signals,
• trust, governance, and routing are explicit and inspectable.

2.2. The MICE Execution Model

Every Micro Engine follows the same fundamental pattern:

Inputs (signals, context, references)
        ↓
   Micro Engine
        ↓
Outputs (new signals + lineage)

Key properties:

• Engines consume signals, not raw UI inputs.
• Engines emit signals, not reports.
• Signals always carry:
  • identity references,
  • provenance (USO lineage),
  • and execution context.

This makes the system inherently traceable and auditable.

2.3. ZAR — Executable Artifact Binding

Executable versions of Micro Engines are registered in the ZAYAZ Artifact Registry (ZAR).

• ZAR artifacts carry:
  • version,
  • build hash,
  • execution reference,
  • schema contracts.
• At runtime, MEIDs are bound to ZAR artifacts.

This separation allows:

• controlled upgrades,
• parallel versions,
• reproducible calculations,
• federation-safe verification.

---

3. Identity Model: USO, CSI, MEID, and CMI

ZAYAZ uses a strict four-part identity model to separate instance, meaning, intent, and execution.

3.1 USO — Universal Signal Ontology ID

The USO ID is the signal’s passport number.

• Created when a signal is born
• Identifies a specific signal instance
• Stable for the lifetime of that signal

---

3.2 CSI — Canonical Signal Identifier

The CSI defines what kind of signal this is.

Examples:

• ghg.scope1.abs
• water.withdrawal.intensity
• assurance.statement

CSI is semantic meaning, not execution logic.

---

3.3 MEID — Micro Engine Identifier

The MEID identifies a logical engine family.

Example:

MEID_CALC_GHG_INT

This refers to the GHG Intensity Calculator as a logical engine.

MEID is:

• stable
• human-readable
• versionless
• used for intent, governance, and orchestration

---

3.4 CMI — Canonical Managed Identifier

The CMI identifies the exact governed artifact that executed.

Example:

MICE.AAE.Validator.Proof.1_0_0

As signals move through the system:

• each executed artifact appends its CMI short code
• this becomes the signal’s passport stamp trail

Rule
USO identifies the instance,
CSI identifies the meaning,
MEID identifies the intent,
CMI records the execution truth.

---

4. MICE vs Methods vs Schemas

A common source of confusion is the difference between engines, semantics, and contracts.

Concept	What it is	Purpose
MICE (MEID)	Executable logic family	Performs computation or transformation
Schema	Contract	Defines inputs, options, outputs
CSI	Signal semantics	Defines what is being computed

A single MICE can serve multiple CSIs, and a single CSI may require multiple MICE in sequence.

---

5. MICE Tiers

MICE are organized into conceptual tiers for clarity and governance.

Tier	Purpose	Examples
Tier 0	Assurance & meta engines	MEID_ASRE_AAE
Tier 1	Shared primitives	MEID_CALC_SHARE, MEID_CALC_SPLIT, MEID_CALC_DELTA
Tier 2	Domain cores	MEID_CALC_GHG_AGGR, MEID_CALC_ENERGY_AGGR
Tier 3	Disclosure-ready engines	MEID_CALC_WASTE_DIV, MEID_CALC_WATER_STRESS
TRANS	Governed transformations	MEID_TRANS_WASTE_HAZ_CLASSIFY

note

Tiers are not execution order.
They are a design and governance aid.

---

6. MICE Classification

Classification answers the question:

What kind of contract does this engine represent?

6.1. v1 Classification Types

Classification	Meaning
Contract-Engine	Deterministic, schema-governed, audit-grade
Transform-Engine	Enrichment, normalization, tagging
Scenario-Engine	Forward-looking or model-based
Validation-Engine	Checks, conformance, constraints
Meta-Engine	Routing, orchestration, scoring
Assurance-Engine	Making trust explicit and machine-readable

---

7. Orchestration with ZSSR

Micro Engines are orchestrated by the ZAYAZ Smart System Router (ZSSR).

ZSSR determines:

• when an engine should run,
• which engine family (MEID) to invoke,
• which artifact version (CMI via ZAR) to bind,
• what happens next.

Routing decisions are primarily driven by:

• explicit rulesets,
• signal type (CSI),
• trust and policy context.

---

8. Tags — Why They Matter

Tags are not decoration.
They are machine- and human-usable metadata.

Tags are used to:

1. Navigate the MICE landscape
2. Auto-generate documentation tables
3. Filter engines by regulation (e.g. ESRS E5)
4. Enable rule composition templates
5. Support partner federation and discovery

8.1 Tag dimensions (v1)

Typical tag dimensions:

• Domain: ghg, energy, water, waste
• Function: aggr, int, share, div, classify
• Tier: tier-0, tier-1, tier-2, tier-3
• Regulation: ESRS-E1, ESRS-E3, ESRS-E5
• Role: mice, calculator, transformer

Assurance Engines (Tier-0) operate outside the normal computational tiers. They validate, score, and certify signals produced by other Micro Engines and emit authoritative assurance meta-signals used for disclosure, audit, and trust propagation.

Example:

tags:
  - mice
  - waste
  - share
  - tier-3
  - ESRS-E5

tip

Tags enable policy-driven orchestration — not hard-coded pipelines.

Role of Tags (important clarification)

Tags are not primary routing rules.

They are:

• capability descriptors,
• discovery metadata,
• assistive selectors when no explicit rule applies,
• federation compatibility hints.

Explicit ZSSR rules always take precedence over tag-based behavior.

---

9. Assurance as a First-Class Concern

Assurance is handled by Tier-0 engines, not embedded in calculators.

The Autonomous Assurance Engine (AAE):

• observes outputs and lineage,
• validates integrity, governance, and trust,
• emits authoritative assurance meta-signals.

This separation ensures:

• independent verification,
• regulatory defensibility,
• federation-safe trust propagation.

---

10. MICE Registry Overview

All documented Micro Engines are listed below.
This table is generated automatically from MICE frontmatter and reflects the current documentation set.

Loading micro engines…

---

11. Canonical Composition Example

Example: ESRS E5 — Waste Disclosure

MEID_TRANS_WASTE_HAZ_CLASSIFY
  → MEID_TRANS_WASTE_TREATMENT_CLASSIFY
    → MEID_CALC_WASTE_AGGR
      → MEID_CALC_WASTE_INT
      → MEID_CALC_WASTE_SHARE
      → MEID_CALC_WASTE_DIV

This produces:

• total waste
• hazardous/non-hazardous split
• intensity metrics
• composition shares
• diversion rate
• full provenance and audit trail

---

12. Why This Matters

• Engineers: clear contracts, faster onboarding
• Auditors: deterministic, inspectable chains
• Product: reusable building blocks
• Partners: federation-safe discovery
• Governance: fewer debates, clearer intent

Micro Engines are the atomic units of trustable intelligence in ZAYAZ.

---

Appendix A — Tagging in ZAYAZ (ZSSR + Federation + Governance)

A.1. Why tags exist

Tags are lightweight, human-readable metadata that power three things:

• Routing intelligence (ZSSR): as a fall-back, allow rules to select/avoid engines based on capability and regulatory context without hardcoding MEIDs/CMIs.
• Federation discovery: allow partners to discover “what we have” and map their needs to our engines across environments.
• Documentation navigation: enable meaningful grouping in docs/registry tables and reduce duplication in MICE specs.

Tags are intentionally not identity. Identity remains:

• MEID (stable engine family identifier)
• CMI / ZAR registry entry (versioned artifact identity) Tags are selectors and hints used by routing and discovery.

---

A.2. How tags are used by ZSSR

ZSSR consumes tags at two layers:

1. Artifact-level tags (preferred) Attached to the engine artifact (ZAR entry / CMI record) or derived from the MICE frontmatter, e.g.:

• mice
• tier-3
• waste
• intensity
• ESRS-E5
• Contract-Engine

ZSSR can evaluate these as a fast, pre-indexed filter before applying more expensive conditions.

2. Signal-level tags (derived) Signals (USO) can carry tags derived from CSI taxonomy and context, e.g.:

• jurisdiction:EU
• reporting:CSRD
• material-topic:waste
• data-quality:low

ZSSR uses signal tags to select compatible engines and to decide escalation paths (validate, enrich, manual review).

ZSSR tag-driven routing pattern ZSSR routing should prefer tag predicates over hardcoding engine identifiers:

• ✅ Good: “pick any engine tagged waste + intensity + Contract-Engine”
• ❌ Avoid: “always route to MEID_CALC_WASTE_INT”

Because tags allow engine substitution, partner overrides, and version upgrades without rewriting routing rules.

Example: routing to an engine family by tags

routing-example.jsonGitHub ↗

{
  "ruleset_id": "ZSSR.Router.RuleSet.ESRS_E5.WasteMetrics.v1",
  "applies_to": ["CSI:waste.*"],
  "routing": [
    {
      "select_engine_by_tags": {
        "require": ["mice", "waste", "tier-3", "Contract-Engine"],
        "prefer": ["intensity"],
        "exclude": ["deprecated", "retired"]
      },
      "operation_type": "CALCULATE",
      "fallback": {
        "select_engine_by_meid": "MEID_CALC_WASTE_AGGR"
      }
    }
  ]
}

Notes

• require is a hard filter.
• prefer is a soft ranker (tie-break).
• exclude prevents unsafe selection.
• fallback provides deterministic continuity.

---

A.3. How tags enable federation discovery

In federation, you want partners to answer:

• “Do you support ESRS E1 scope 3 category splits?”
• “Which engines can compute energy intensity?”
• “Which engines are safe for EU CSRD reporting?”

Tags enable this by making capabilities searchable and comparable across orgs.

Federation discovery workflow

1. Partner imports a registry bundle (ZAR snapshot + proofs).
2. They index engines by tags (and optionally by CSI coverage).
3. They run capability queries (tag predicates).
4. They map selected engines to their local MEIDs or accept yours as a provider.

Example: federation capability query (concept)

• Query: require=[mice, ghg, scope3, Contract-Engine] prefer=[tier-2, ESRS-E1]
• Result: list of candidate engine artifacts (MEID + CMI versions) suitable for their routing.

Why this matters Tags:

• reduce bilateral integration effort
• allow late binding (select engines at install-time, not build-time)
• support partner override packs (“use my local engine if present, else fall back to provider engine”)

---

A.4. Tag governance rules (draft)

This is the minimal governance needed to keep tags useful.

A.4.1. Tag classes (small, practical)

Tags fall into four classes:

1. Domain tags (what topic)

• ghg, energy, water, waste, pollution, taxonomy, …

2. Function tags (what operation)

• abs, intensity, share, split, delta, adjust, scenario, classify, …

3. Regulatory tags (why it matters)

• ESRS-E1, ESRS-E5, CSRD, EU-Taxonomy, GHG-Protocol, …

4. Lifecycle/quality tags (safety)

• active, deprecated, experimental, retired
• assurance-ready (optional later, only if enforced)

Rule: lifecycle tags should be derived from the artifact status where possible (avoid manual drift).

A.4.2. Who can add/change tags

• Owner team of the engine (from ZAR record) can propose tag changes.
• Platform governance (Core/CTO) approves changes that:
  • add/remove regulatory tags
  • change tier tags
  • introduce new tag vocabulary (new canonical tags)

A.4.3. How tags evolve

• Tags are versionless labels, but their meaning can evolve.
• Any semantic change must be documented in the “Tag Dictionary” (single source of truth).
• When tags are replaced:
  • old tag remains for at least one minor cycle as an alias
  • routing rules should accept both during transition

A.4.4. Naming rules

• lowercase for general tags: waste, intensity
• uppercase for frameworks: ESRS-E5, CSRD
• hyphenated for multiword: assurance-ready, tier-3
• no spaces, no punctuation beyond -

A.4.5. Anti-patterns

• Don’t encode versions into tags: ❌ v1_0_0
• Don’t encode identities into tags: ❌ MEID_CALC_WASTE_INT
• Don’t over-tag: prefer 5–12 meaningful tags per engine

---

Reusable code examples for “contract engines”

Example 1 — Standard request payload

All contract engines should accept a common envelope:

envelope-example.jsonGitHub ↗

{
  "meid": "MEID_CALC_WASTE_INT",
  "inputs": { "waste_total": 120.5, "revenue": 14.2 },
  "options": { "unit_system": "SI", "jurisdiction": "EU" },
  "context": {
    "org_id": "ORG-123",
    "period": "2026",
    "source_quality": "invoice"
  }
}

Example 2 — Standard result payload

All contract engines should emit a common result structure:

common-result-example.jsonGitHub ↗

{
  "meid": "MEID_CALC_WASTE_INT",
  "status": "ok",
  "outputs": {
    "value": 8.49,
    "unit": "tonnes/€m"
  },
  "lineage": {
    "cmi_short_code": "000241",
    "build_hash": "sha256:…",
    "inputs_hash": "sha256:…"
  },
  "warnings": [],
  "assumptions_used": ["revenue_nonzero_guard"],
  "framework_refs": ["ESRS:E5", "ISO:14001"]
}

---

Tag Dictionary v1

1.1. Canonical tag namespaces

To keep tags small but unambiguous, we use four tag classes. In frontmatter they are all flat strings, but the dictionary defines what each “family” means.

A. Domain tags (what topic)

Use exactly one domain tag per MICE.

• emissions (GHG scope metrics, CO₂e, carbon accounting)
• energy (electricity, fuels, renewable energy, energy totals)
• water (withdrawal, consumption, discharge, stress)
• pollution (waste, hazardous, treatment, EWC)
• climate_risk (scenario alignment, budgets, transition metrics)
• meta (shared primitives: delta/share/split, utilities)

B. Operation tags (what it does)

Pick 1–3.

• aggr (aggregation / sum / consolidate across categories)
• calc (calculation)
• transform (transformation)
• validation (validation)
• norm (normalization)
• rmap (risk mapping)
• geox (processing, resolving, and enriching signals that contain spatial or geographic attributes)
• sens (device-aware conditioning and plausibility control of sensor/IoT data streams)
• tser (time series - conditioning, validating, and synchronizing temporal sequences of data)
• alert (detecting threshold violations, trigger conditions, and escalation events)
• score (produces indicators, ratings, indices, or maturity scores)
• extr (extraction of unstructured or semi-structured source material)
• intensity (normalize per denominator, typically revenue)
• share (ratio / composition / % of total)
• split (allocation across dimensions; outputs breakdown)
• delta (period-over-period change)
• adjust (market/location or other adjustment transformation)
• scenario (uses scenario curves / pathways)
• budget (budget / remaining budget calculations)
• classify (classification / mapping to categories)
• treatment (waste treatment classification / grouping)

C. Tier tags (where it sits)

Exactly one tier tag.

• tier-1 shared primitives (generic calculators used by others)
• tier-2 GHG core (scope engines and GHG-specific)
• tier-3 domain-specific (energy/water/waste specifics, ESRS-aligned)

D. Framework tags (why it matters)

Optional but recommended when applicable.

• ESRS-E1 (climate)
• ESRS-E2 (pollution) (only when explicitly mapped)
• ESRS-E3 (water)
• ESRS-E5 (resource use & circular economy / waste)

Also allowed:

• GHG-Protocol (when method aligns with GHG Protocol scope logic)

E. Lifecycle tags (don’t manually set)

Do not set status as tags. Status lives in frontmatter/registry:

• mice.status: active|experimental|deprecated|retired

(If lifecycle tags is needed later, derive them automatically into registry JSON.)

F. Always-on tags

Every MICE in this list should include:

• mice (required)

---

1.2. Classification values (v1)

Keep this controlled. E.g.:

• Contract-Engine (takes contract inputs → deterministic output; the default)
• Transform-Engine (classification/mapping/transformation; produces enriched outputs)

---

1.3. Tag governance rules (v1 minimal)

• Owner team can add/remove operation tags + framework tags.
• Core/CTO approval required for:
  • introducing a brand-new canonical tag
  • changing tier tags
  • adding/removing framework tags (ESRS-*, GHG-Protocol)
• Dictionary is source of truth: tags not in the dictionary are treated as “local/freeform” and should not be used by ZSSR for selection.

---

Note for v1 implementation

• We keep tags in MICE frontmatter (docs), but treat ZAR registry as the runtime truth.
• We use a small “Tag Dictionary” page and enforce it with a CI lint later.
• We use tag predicates in ZSSR rulesets, with MEID fallback for determinism.

---

Appendix B — CMI vs MEID — what is the difference?

Short version

Concept	What it identifies	Stability	Purpose
MEID	Engine family / intent	Stable	Design-time, governance, documentation, orchestration intent
CMI (cmi_name)	Concrete managed artifact	Versioned	Runtime execution, lineage stamping, auditability

If MEID is “what engine is this?”, CMI is “exactly which governed thing ran?”.

---

B.1. MEID — Micro Engine Identifier

MEID identifies the logical engine concept.

Example:

MEID_CALC_GHG_INT

What it means:

• “This is the GHG Intensity Calculator”
• Independent of:
  • version
  • implementation
  • container image
  • programming language
  • Stable across years

MEID exists so that:

• humans can reason about the system,
• ZSSR can express intent (“run a GHG intensity calc”),
• governance can approve engine families,
• documentation stays readable.

MEID never appears in signal lineage. It is not precise enough.

---

B.2. CMI (cmi_name) — Canonical Managed Identifier

CMI identifies the exact managed artifact that executed.

Example:

MICE.AAE.Validator.Proof.1_0_0

Structure:

<DOMAIN>.<COMPONENT>.<KIND>.<NAME>.<VERSION>

What it means:

• “This specific validator module”
• “This exact version”
• “This governed artifact”

CMI exists so that:

• every execution can be reproduced,
• lineage is unambiguous,
• auditors can verify exact code provenance,
• federation partners can validate claims.

At runtime:

• the CMI short code is appended to the signal’s USO lineage tail
• this is the passport stamp

CMI is what actually ‘touched’ the signal.

---

B.3. Relationship between MEID and CMI (this is the key)

MEID ──(binds to)──▶ one or more CMIs (via ZAR)

Example:

MEID_CALC_GHG_INT
  ├── CMI: MICE.GHG.Calc.Intensity.1_0_0
  ├── CMI: MICE.GHG.Calc.Intensity.1_1_0
  └── CMI: MICE.GHG.Calc.Intensity.2_0_0

• MEID = family / capability
• CMI = concrete executable artifact
• ZAR = the binding registry between them

---

B.4. Why we need both

If we only had MEID:

• lineage would be vague (“some GHG engine ran”)
• audits would fail
• federation would be impossible

If we only had CMI:

• routing rules would be brittle
• documentation would be unreadable
• governance would be impossible at scale

MEID is for intent.

MEID identifies what kind of engine should run.

CMI is for truth.

CMI identifies the exact governed artifact that did run.

---

APPENDIX C - MICE Capability Map

C.1. The Big Picture

The MICE ecosystem is not a linear pipeline. It is a layered, governed capability graph with:

• Data-ingest & conditioning
• Deterministic computation
• Aggregation & normalization
• Meta, assurance, alerting, and orchestration
• Optional forward-looking / composite reasoning

Think of it as three planes:

1. Signal Production Plane – creates values
2. Signal Conditioning & Coordination Plane – makes them comparable and usable
3. Governance & Assurance Plane – decides if and how they can be used

---

C.2. Visual Capability Map (Mermaid)

---

C.3. How to Read the Map

C.3.3. Solid arrows (→)

Data / signal flow

“This engine produces outputs consumed by the next capability.”

C.3.2. Dashed arrows (– – >)

Observation / governance

“This engine observes outputs but does not mutate them.”

---

C.4. Capability Layers Explained

C.4.1. Signal Production & Conditioning

Purpose: turn raw reality into trustworthy signals

• EXTR – extract structured data from unstructured sources
• SENS – apply device-aware logic to physical sensors
• TSER / TSYN – clean, align, and synchronize time-series

➡ No ESG meaning yet — just trustworthy signals

---

C.4.2. Deterministic Computation

Purpose: produce audit-grade numbers

• VALI – structural & rule validation
• CALC – first-order deterministic computation
• TRFM – unit / structural transformation

➡ This is where “numbers” are born

---

C.4.3. Consolidation & Comparability

Purpose: make results usable at scale

• AGGR – roll-ups across scope, hierarchy, or time
• NORM – normalize values for comparison

➡ From raw results → disclosure-ready metrics

---

C.4.4. Semantic & Contextual Enrichment

Purpose: attach meaning, context, and frameworks

• META – taxonomy, regulation, classification tags
• RMAP – risk framework mapping
• GEOX – spatial attribution

➡ Metrics become “about something”

---

C.4.5. Advanced Reasoning

Purpose: go beyond raw reporting

• SCEN – forward-looking pathways and projections
• SCORE – composite indicators, indices, maturity scores

➡ Decision support and strategic insight

---

C.4.6. Governance, Assurance & Control

Purpose: trust, escalation, and orchestration

• AME – assurance, trust scoring, coverage validation
• ALERT – threshold violations and escalation signals
• LINK – cross-signal linkage, lineage reasoning

➡ Nothing here changes data — it governs its use

---

C.4.7. ZSSR (Outside the Graph)

Purpose: orchestration, not computation

• ZSSR consumes:
  • alert meta-signals,
  • link/lineage signals,
  • assurance outputs
• ZSSR decides:
  • routing,
  • gating,
  • escalation paths

➡ ZSSR is the “conductor,” not an engine

---

C.5. One-Sentence Mental Model

MICE engines compute and enrich signals. Governance engines observe and judge them. ZSSR decides what happens next.

---