Rule Sets / Orchestration

Introduction

In ZAYAZ we use a two-layer model that cleanly separates why we compute from how signals move:

Layer A — Reporting Contract Pipelines (framework-driven)

This is driven by ESRS/GRI/etc. expectations: “What outputs must exist, in what units, at what granularity, with what assurance?”

Output-driven: defines required output signals (CSIs), validation thresholds, and coverage.
Example: “For ESRS E1 we need GHG.abs (scope 1,2,3) + intensity + YoY delta + scenario alignment if disclosed.”

This layer produces a pipeline spec (what to compute) and acceptance criteria (what “done” means).

Layer B — Signal Routing & Touch Sequencing (signal-driven)

This is driven by incoming signals and context: “Given a signal of type X at quality Y from source Z, what MICE must touch it next?”

Input-driven: maps CSI patterns to an ordered set of engines (MEIDs) depending on trust/coverage/context.
Example: “If we receive raw electricity invoices → run Energy.ELEC consolidation → aggregate to Energy.total → compute intensity → compute renewable share (if RE inputs present) → validate.”

This layer is what ZSSR executes in real time.

✅ Reporting layer tells the destination and constraints. ✅ Routing layer tells the path based on what we actually have.

How it’s done in practice (recommended v1 design)

1. Define a “Contract Output Set” per framework

Create a small JSON/YAML spec per framework/topic, e.g.:

contract.esrs.e1.v1
contract.esrs.e3.v1
contract.esrs.e5.v1
later: contract.gri.302.v1 etc.

Each contract contains:

required_outputs: list of CSI patterns (e.g. ghg.scope1.abs, energy.total.abs)
optional_outputs: if data exists (e.g. scenario align)
units: canonical units + allowed conversions
granularity: org/site/product/time
minimum_data_quality: trust thresholds, required sources
assurance_level: required validation engines / evidence

This is where ESRS/GRI differences live.

2. Maintain “Routing Recipes” keyed by CSI + context

These are ZSSR rulesets that say:

applies_to: input CSI patterns (and/or source type)
conditions: trust score, completeness, jurisdiction, sector
then: an engine chain (MEID sequence)
emit: what CSIs the chain produces

This is where “a signal from this place requires sequence X” lives.

3. ZSSR chooses the plan at runtime

At runtime:

Identify active reporting contracts for tenant (ESRS, GRI…)
Expand to required output CSIs
For each required output CSI, check what input signals exist
Choose routing recipe(s) that can produce the output from available inputs
Execute chain, record lineage (cmi_short_code touches)

Concrete example (ESRS E5: Waste)

Contract (reporting-driven)

Requires:

waste.total.abs
waste.total.intensity
waste.hazardous.abs (if available or required by sector)
waste.diversion_rate

Routing recipes (signal-driven)

If we have raw waste line items:

MEID_TRANS_WASTE_HAZ_CLASSIFY (classify EWC → hazardous)
MEID_TRANS_WASTE_TREATMENT_CLASSIFY (classify treatment)
MEID_CALC_WASTE_AGGR (totals)
MEID_CALC_WASTE_SHARE (shares)
MEID_CALC_WASTE_DIV (diversion)
MEID_CALC_WASTE_INT (intensity, if revenue available)

If we only have already-aggregated totals:

skip transforms, run AGGR/INT/DIV directly.

What to build now (v1 scope)

Given the engine set:

A. 4 reporting contracts (minimal but complete)

ESRS E1: GHG totals, intensity, delta, scenario align (optional), target gap, carbon budget (optional)
ESRS E2 (optional now): pollution (we only have waste, so keep it as part of E5 for v1)
ESRS E3: water withdrawal/consumption/discharge/intensity/stress
ESRS E5: waste totals/intensity/diversion/shares/hazard classification

B. 10–15 routing recipes (cover most situations)

Organize recipes by input availability:

invoice-derived (electricity, fuels)
meter-derived
supplier-reported totals
activity-data (scope 3 categories)
“already computed” signals (just validate + rollup)

Each recipe emits standard CSIs and references MEIDs.

Rule authoring guidance (to prevent chaos)

Contracts are stable (change slowly with standards).
Recipes evolve (as data sources and engines evolve).
Recipes must declare:
- prerequisites (required input CSIs)
- outputs (CSIs produced)
- engine sequence (MEIDs)
- fallback behavior (missing inputs, low trust)

Bottom line

Use framework-driven contracts to define what must be delivered.
Use signal-driven routing recipes to define how you get there from real data.
ZSSR composes them dynamically.

Examples

Artifact 1 — Reporting Contract

contract.esrs.e1.v1

Purpose Defines what must be produced to satisfy ESRS E1 (Climate change), independent of how data arrives or which engines are used.

This is framework-driven and stable.

Contract definition (YAML)

contract-esrs-e1-v1.json
contract_id: contract.esrs.e1.v1
framework: ESRS
standard_ref: ESRS-E1
version: v1
status: active

scope:
  topic: climate_change
  domain: emissions
  jurisdiction: EU
  applicable_from: 2024

required_outputs:
  # Absolute emissions
  - csi: ghg.scope1.abs
    unit: tCO2e
  - csi: ghg.scope2.abs
    unit: tCO2e
  - csi: ghg.scope3.abs
    unit: tCO2e

  # Intensity
  - csi: ghg.total.intensity
    unit: tCO2e_per_EURm

  # Year-over-year change
  - csi: ghg.total.delta_yoy
    unit: percent

optional_outputs:
  # Only required if targets or scenarios are disclosed
  - csi: ghg.scenario.alignment
    unit: percent
  - csi: ghg.target.gap
    unit: percent
  - csi: carbon.budget.remaining
    unit: tCO2e

granularity:
  required:
    - organization
    - reporting_period
  optional:
    - site
    - product

data_quality:
  minimum_trust_score: 0.75
  completeness_threshold: 0.9

assurance:
  level: limited
  required:
    - classification_consistency
    - unit_normalization
    - scope_coverage_check

acceptance_criteria:
  - rule: scope_coverage
    description: "Scopes 1, 2, and 3 must be explicitly reported or justified."
  - rule: intensity_denominator
    description: "Revenue denominator must be disclosed and non-zero."
  - rule: methodology_disclosure
    description: "GHG Protocol alignment must be stated."

notes:
  - "Scope 2 market/location split is optional but recommended."
  - "Scenario alignment only required if transition plan is disclosed."

Why this structure works

CSIs define outputs, not engines
No MEIDs mentioned → engine-agnostic
Optional outputs align with ESRS conditional disclosures
Can be reused for GRI / ISSB variants with minimal changes

Artifact 2 — ZSSR Routing Ruleset

zssr.ruleset.esrs.e5.waste.v1

Purpose Defines how signals flow through MICE to produce ESRS E5 (Waste & circular economy) outputs, depending on what data is available.

This is signal-driven, context-aware, and evolvable.

Ruleset definition (JSON)

zssr-ruleset-esrs-e5-waste-v1.json
{
  "ruleset_id": "zssr.ruleset.esrs.e5.waste.v1",
  "version": "v1",
  "status": "active",

  "applies_to": [
    "CSI:waste.*"
  ],

  "context":
  {
    "framework": "ESRS",
    "standard_ref": "ESRS-E5",
    "jurisdiction": "EU"
  },

  "routes": [

    {
      "name": "Waste from line-item or activity data",
      "when":
      {
        "inputs_present": [
          "waste.line_item"
        ]
      },
      "then":
      {
        "engine_sequence": [
          "MEID_TRANS_WASTE_HAZ_CLASSIFY",
          "MEID_TRANS_WASTE_TREATMENT_CLASSIFY",
          "MEID_CALC_WASTE_AGGR",
          "MEID_CALC_WASTE_SHARE",
          "MEID_CALC_WASTE_DIV",
          "MEID_CALC_WASTE_INT"
        ],
        "emit":
        [
          "waste.total.abs",
          "waste.hazardous.abs",
          "waste.treatment.share",
          "waste.diversion_rate",
          "waste.total.intensity"
        ]
      }
    },

    {
      "name": "Waste from pre-aggregated totals",
      "when":
      {
        "inputs_present": [
          "waste.total.abs"
        ]
      },
      "then":
      {
        "engine_sequence": [
          "MEID_CALC_WASTE_SHARE",
          "MEID_CALC_WASTE_DIV",
          "MEID_CALC_WASTE_INT"
        ],
        "emit":
        [
          "waste.treatment.share",
          "waste.diversion_rate",
          "waste.total.intensity"
        ]
      }
    },

    {
      "name": "Fallback — aggregation only",
      "when":
      {
        "inputs_present": [
          "waste.activity"
        ],
        "trust_score_below": 0.75
      },
      "then":
      {
        "engine_sequence": [
          "MEID_CALC_WASTE_AGGR"
        ],
        "emit":
        [
          "waste.total.abs"
        ],
        "flags":
        [
          "LOW_CONFIDENCE",
          "MANUAL_REVIEW_RECOMMENDED"
        ]
      }
    }
  ],

  "post_conditions":
  [
    {
      "rule": "esrs_e5_minimum_coverage",
      "description": "At least total waste and hazardous/non-hazardous split must be available or justified."
    }
  ]
}

Why this ruleset is correct

Routes are selected based on signal availability, not assumptions
Engine chains are explicit and auditable
Same ruleset works for:
- invoices
- activity data
- supplier aggregates
Fallback path is built-in (no silent failure)

How these two artifacts work together (important)

Contract (contract.esrs.e1.v1) says: “I need these outputs with this quality.”
Ruleset (zssr.ruleset.esrs.e5.waste.v1) says: “Given these inputs, here’s how to compute them.”
ZSSR orchestration

Expands contract → required CSIs
Finds rulesets that can emit them
Executes engine sequences
Records CMI lineage per step

This separation is what makes ZAYAZ:

scalable
auditable
federation-ready

GitHub Repo Request for Change (RFC)

Introduction​

Layer A — Reporting Contract Pipelines (framework-driven)​

Layer B — Signal Routing & Touch Sequencing (signal-driven)​

How it’s done in practice (recommended v1 design)​

1. Define a “Contract Output Set” per framework​

2. Maintain “Routing Recipes” keyed by CSI + context​

3. ZSSR chooses the plan at runtime​

Concrete example (ESRS E5: Waste)​

Contract (reporting-driven)​

What to build now (v1 scope)​

A. 4 reporting contracts (minimal but complete)​

B. 10–15 routing recipes (cover most situations)​

Rule authoring guidance (to prevent chaos)​

Bottom line​

Examples​

Artifact 1 — Reporting Contract​

Artifact 2 — ZSSR Routing Ruleset​