Jira progress: loading…

WST-AGGR

Waste Generation Aggregation

1. Identity

Loading identity…

Depends on module:

Purpose
Aggregates waste generated into canonical totals and structured breakdowns aligned with ESRS E5.
This engine is the anchor for all Waste KPIs (intensity, hazardous share, diversion rate, YoY deltas).

It focuses strictly on waste generated, not treatment outcomes (recycling, disposal), which are handled downstream.

Typical usage

• Total waste generated (tonnes)
• Waste by type (hazardous / non-hazardous)
• Waste by category (if provided)
• Input to intensity and share engines

---

2. Contract References (ZAR)

2.1 Input Schema

ZAR Address: schema.compute.waste.generated.inputs.v1_0_0

Required conceptual fields:

• waste_items: list of waste generation records
• alignment: BY_YEAR | BY_INDEX (default BY_YEAR)

Each waste_item conceptually includes:

• period (typically year)
• value
• unit (e.g. kg, tonne)
• hazard_class: HAZARDOUS | NON_HAZARDOUS
• optional:
  • ewc_code (EWC code or internal taxonomy)
  • site_id
  • process_id
  • is_estimate (boolean)
  • regulatory_ref (e.g. EWC / Basel reference)

---

2.2 Options Schema

ZAR Address: schema.compute.waste.generated.options.v1_0_0

Common options:

• unit_output: default tonne
• hazard_normalization: STRICT | LENIENT (default STRICT)
• unknown_hazard_policy: ERROR | ASSIGN_NON_HAZARDOUS | ASSIGN_UNKNOWN (default ERROR)
• negative_values_policy: ERROR | ALLOW_WITH_FLAG
• missing_policy: ERROR | SKIP
• rounding: optional digits

---

2.3 Output Schema

ZAR Address: schema.compute.waste.generated.output.v1_0_0

Outputs include:

• $W_{\mathrm{generated,total}}(t)$
• $W_{\mathrm{generated,hazardous}}(t)$
• $W_{\mathrm{generated,non\_hazardous}}(t)$
• optional $W_{\mathrm{generated,by\_category}}(c,t)$
• metadata (unit conversions, hazard handling, completeness)

---

3. Accepted Input Shapes

A. Flat waste item list (preferred)

{
  "waste_items": [
    { "period": 2025, "value": 1200, "unit": "tonne", "hazard_class": "NON_HAZARDOUS" },
    { "period": 2025, "value": 85,   "unit": "tonne", "hazard_class": "HAZARDOUS" }
  ],
  "alignment": "BY_YEAR"
}

B. Mixed units

{
  "waste_items": [
    { "period": 2025, "value": 850000, "unit": "kg", "hazard_class": "NON_HAZARDOUS" },
    { "period": 2025, "value": 12000,  "unit": "kg", "hazard_class": "HAZARDOUS" }
  ]
}

C. With waste categories (EWC-style)

{
  "waste_items": [
    { "period": 2025, "value": 500, "unit": "tonne", "hazard_class": "NON_HAZARDOUS", "ewc_code": "17 01 07" },
    { "period": 2025, "value": 40,  "unit": "tonne", "hazard_class": "HAZARDOUS",     "ewc_code": "13 02 05*" }
  ]
}

All supported shapes MUST be normalized internally to:

Map<period, { hazardous_t, non_hazardous_t }> (+ optional category dimension)

---

4. Hazard Classification Rules (Normative)

4.1 Canonical hazard classes

Input MUST normalize to:

• HAZARDOUS
• NON_HAZARDOUS

If hazard_normalization = STRICT:

• missing or unknown hazard_class MUST error

If LENIENT:

• unknown handled per unknown_hazard_policy

4.2 Unknown hazard handling

• ERROR: fail
• ASSIGN_NON_HAZARDOUS: assign to non-hazardous (discouraged for audit-grade)
• ASSIGN_UNKNOWN: retain but exclude from totals (v1 discouraged)

Metadata MUST record:

• unknown hazard count
• any assignments performed

---

5. Compute Semantics (Normative)

Let $W(h,t)$ be waste generated of hazard class $h$ at time $t$ (after unit normalization).

5.1. Waste by hazard class

$W_{\mathrm{generated,hazardous}}(t) = W(\mathrm{HAZARDOUS}, t)$

$W_{\mathrm{generated,non-hazardous}}(t) = W(\mathrm{NON_HAZARDOUS}, t)$

---

5.2. Total waste generated

$W_{\mathrm{generated,total}}(t)$

$W_{\mathrm{generated,hazardous}}(t) + W_{\mathrm{generated,non-hazardous}}(t)$

---

5.3. Optional category breakdown

If ewc_code is provided:

$W_{\mathrm{generated,by-category}}(c,t)$

$\sum_{i \in I(c,t)} v(i)$

Where $I(c,t)$ are items with category $c$ in period $t$.

---

6. Completeness & Coverage Metadata (Normative)

This engine MUST compute a structural completeness measure:

• $H_{\mathrm{present}}$: hazard classes present
• $H_{\mathrm{expected}} = {\mathrm{HAZARDOUS}, \mathrm{NON_HAZARDOUS}}$

$coverage_{ratio} = \frac{|H_{\mathrm{present}}|}{|H_{\mathrm{expected}}|}$

Metadata MUST include:

• hazard_classes_present
• coverage_ratio
• unknown_hazard_count
• negative_value_count (if allowed)

---

7. Validation & Error Model

Invariants

• Values must be finite
• Units must be convertible to unit_output
• Negative values rejected unless explicitly allowed
• Hazard class must resolve under policy

Error codes (suggested)

• WASTE_AGGR_INVALID_HAZARD_CLASS
• WASTE_AGGR_UNIT_CONVERSION_FAILED
• WASTE_AGGR_NEGATIVE_VALUE
• WASTE_AGGR_NON_FINITE_VALUE
• WASTE_AGGR_ALIGNMENT_MISMATCH

Errors MUST include:

• engine cmi_short_code
• hazard class and period context

---

8. Dependencies

MEID_CALC_WASTE_AGGR depends on:

• schema resolver (ZAR)
• unit conversion capability (delegated)
• canonical hazard classification reference (EWC / regulatory)

Declared via ZAR dependencies.

---

9. Federation & Audit Requirements

To reproduce waste aggregation externally, the export MUST include:

• engine identity (cmi or zar_code)
• engine build proof (execution_ref + build_hash)
• input/options/output schemas used
• raw waste items
• hazard normalization policy
• unit conversion reference/version used

Provenance chain MUST show:

… → MEID_CALC_WASTE_AGGR → …

with cmi_short_code recorded in USO tail arrays.

---

10. Performance Notes

• Complexity: $O(n_{items})$
• Memory: $O(|T|)$
• Suitable for batch reporting and KPI analytics

---

11. Methods Served (v1)

• Waste.generated.abs
• Waste.generated.by_hazard.abs
• Waste.generated.by_category.abs
• Waste.generated.total.abs

---