S3-ARCH
Scope 3 Engine Architecture
Depends on module:
1. Purpose
This document is the master specification of the Scope 3 micro-engine family in the ZAYAZ Computation Hub. It fixes the structure once so that every Scope 3 engine — existing or still to be written — is specified, registered and built against the same model.
It answers four questions:
- Where does a value-chain signal get its Scope 3 category? In one place: the Scope 3 Post Office.
- Who owns a category? A dedicated, thin category controller — fifteen of them, one per GHG Protocol category.
- Where does the arithmetic live? In shared method kernels, governed by the KISMET kernel framework (
KISMET), that the controllers call. Never in a controller. - How does it come back together? In one Summary engine that rolls category results up, applies the inclusion policy, produces the Scope 3 total and the disclosure object, and hands the total to
GHG-AGGR.
The result is seventeen core Scope 3 engines (1 Post Office + 15 controllers + 1 Summary) resting on a small set of shared method kernels, several of which already exist. The kernels, the mode engines beneath the transport kernel and the supporting services are shared dependencies, not members of the seventeen: they are reusable outside Scope 3 and are governed by KISMET and their own specifications.
This document is the parent of every Scope 3 engine specification. A child specification that conflicts with it is a defect in the child.
1.1. What this document governs
- the division of responsibility between classification, control, calculation and consolidation;
- the contract shape of each engine class (Post Office, controller, Summary) and the Scope 3 result profile that kernels satisfy when Scope 3 calls them;
- the signal flow and the ZSSR routing obligations;
- the evidence each stage must emit;
- identifier, artifact and registry requirements for the family;
- the build sequence for the child specifications.
1.2. What this document does not govern
- emission-factor data and its lookup (see
EFDERand the reference-data design); - the common kernel contract — declaration, invocation and result envelope, composition, selection and fallback, evidence, replay and release — which is
KISMET's; this document adds the Scope 3 profile on top of it and SHALL NOT weaken it; - Scope 1 and Scope 2 computation (
S1-CON,S2-CON), except where Scope 3 reuses them; - disclosure rendering (Reports & Insights Hub);
- the per-engine ZAR schema addresses beyond those inherited in section 8 — the rest are declared in the child specifications.
1.3. Lineage
Two earlier specifications, Scope 3 Category Aggregation (S3-CAT, canonical MEID MEID_GHG_AGGR_SCOPE3_CATEGORY, legacy MEID_CALC_GHG_SCOPE3_CAT) and Scope 3 Consolidation (S3-CON, canonical MEID MEID_GHG_AGGR_SCOPE3, legacy MEID_CALC_GHG_SCOPE3), were the first pass at this problem. They are withdrawn by this document. Their normative content that survives — canonical category identifiers, the subcategory resolution ladder, the unknown-category and duplicate policies, the compute semantics, the inclusion policy, structural coverage, the error model and the federation requirements — is carried forward in section 8 as the contract baseline of the single Summary engine (S3-SUM). The canonical MEID MEID_GHG_AGGR_SCOPE3 passes from S3-CON to S3-SUM, so downstream consumers (GHG-AGGR, intensity, target-gap and scenario engines) keep their dependency unchanged; MEID_GHG_AGGR_SCOPE3_CATEGORY is retired (see section 14).
2. Design Decisions (Normative)
The following rulings are binding for every engine in the family.
D1 — Classification is a capability of its own
Assigning a signal to one of the fifteen categories is not a step inside a calculator. It is performed by exactly one engine, the Scope 3 Post Office (S3-PO), and its output is consumed by many parties that never calculate anything: ledger tagging at ingestion, supplier onboarding, the PCAF/ESGX output profile, the ESRS E1-6 category breakdown, and Watchtower monitoring.
Rationale: the category is the most contested point in a Scope 3 audit (category 1 versus 2 versus 4; category 3 leaking into Scope 1 and 2). It must carry its own evidence object and its own version history, independent of calculation methods, which change on a different cadence.
D2 — Categories are governed units, but controllers are thin
Each category is a separate micro engine with its own MEID, version, ownership, evidence object and replay profile. This is what makes category 15 move when PCAF moves while category 6 stays still, and what lets an auditor scope a review to one category.
A controller owns the category's boundary, the authorization of calculation capabilities and policies, category-allocation decisions, exclusion codes and category-result evidence. It owns no arithmetic: emissions estimation, numerical allocation, uncertainty propagation and calculated data-quality scores are executed by governed kernels or shared executable capabilities that the controller selects (rule S3C-001, 6.1). The controller decides that and how a value is allocated; a governed capability computes the allocation.
D3 — Methods cut across categories; the arithmetic lives once
The calculation methods of the GHG Protocol Scope 3 Standard (spend-based, average-data, supplier-specific, hybrid, distance-based, fuel-based, waste-type-specific, use-phase, investment-specific) do not align with the categories one-to-one. Categories 1 and 2 are the same calculation split by capitalisation; 4 and 9 are one transport problem with a different boundary; 5 and 12 share waste-treatment factors; 6 and 7 are both distance × transport factor; 8, 13 and 14 are somebody else's Scope 1 and 2; 15 is PCAF attribution.
Therefore the arithmetic is implemented in shared method kernels (MICE type CALC; existing engines are reused where they exist), each written once and called by whichever controllers need it. Kernels follow KISMET: a kernel exposes a coherent capability through a versioned contract, MAY implement several declared methods, and MAY be composite — composing independently governed micro engines or child kernels under a versioned composition — rather than being restricted to one method per kernel.
Transport is the first composite case. K4 is the transport entry point for every mode — air, road, rail, sea and inland waterway. It accepts a journey of explicit legs and executes each leg through an independently governed mode engine. The Air Transportation Micro Engine (ATME) is K4's air engine and keeps its own MEID, ownership and release line; the road, rail, sea and inland-waterway engines are specified the same way. Scope 3 profiles call K4, never a mode engine directly.
D4 — Routing belongs to ZSSR, not to the Post Office
The Post Office stamps; ZSSR carries. The Post Office emits a category-assignment artifact and a routing hint. The ZAYAZ Smart System Router resolves the destination controller from a governed ruleset keyed on the assignment outcome. No engine in this family implements its own dispatch logic. This keeps the post-office metaphor without introducing a parallel router.
The same holds inside a composite kernel. K4's execution plan — which mode engine and method each leg needs — is a logical requirement; destination resolution and dispatch of each child execution go through the existing MICE execution and ZSSR mechanisms (KISMET §4). K4 does not route.
D5 — Nothing is dropped, nothing is force-routed
A signal the Post Office cannot classify with the required confidence is held, not guessed. The hold destination is the existing TrustGate Quarantine Manager (TG-QUARANTINE-MANAGER), which already provides review status, evidence requirements, remediation paths and replay hooks. The Summary engine reports the held residual (count and, where known, value) as an explicit line, so an incomplete inventory is visible rather than silently smaller.
D6 — Rules first; AI proposes, never decides
Category assignment is decided by deterministic rulesets in the ZAYAZ Ruleset Registry (ZRR) and governed mapping tables. An AI tier (executed through the governed AI DIAL gateway, AI-DIAL) may propose a category for signals the rules cannot resolve, at a confidence that is capped below the auto-accept threshold, so an AI proposal always lands in review and never silently becomes ground truth. Human overrides are recorded as their own tier with actor, reason and timestamp.
D7 — Controllers are generated, not hand-written
The fifteen controllers are produced from one controller template plus fifteen category profiles. A change to the controller contract is made once in the template; a change to a category's boundary or permitted methods is made once in that category's profile. Hand-edited divergence between controllers is non-conformant.
D8 — Governed parameters are administered, never user-set
Every numeric parameter that shapes an outcome in this family — the AI confidence cap, auto-accept thresholds, minimum coverage ratios, the routing-deviation distributions in the air kernel, simulation counts — is a governed platform value: it lives in a ZAR-governed dataset or policy, is adjustable only by ZAYAZ administrators through the ZAYAZ administration dashboard, and is never exposed as a user or client setting. Client policy may select among administered options or tighten within administered bounds; it may not loosen them. Nothing is hard-coded in engine logic.
The parameter set. All such values live in one governed registry, config/system/scope3/parameters.json (proposed; registered with the category profiles, section 14), validated by its own JSON Schema and versioned as a whole. Each parameter has a stable key; contracts in this document and in the child specifications reference keys only, never values. Every execution resolves the parameters it uses from the set and records the set version in its evidence, so a result can always be traced to the exact values in force. The administration dashboard edits the set through a governed change (actor, reason, timestamp, new set version); it never writes values into engine configuration.
| Key | Meaning | Constraint | Seed value at registration |
|---|---|---|---|
s3po.ai_confidence_cap | ceiling on any AI_PROPOSED confidence | SHALL be < s3po.auto_accept_threshold_min | 0.60 |
s3po.auto_accept_threshold_min | lowest auto-accept threshold any client may be assigned | 0 < value ≤ 1 | 0.90 |
s3po.map_confidence_ceiling | ceiling for the MAP tier | ≤ 1 | 0.95 |
s3po.auto_accept_threshold_default | threshold when no stricter client threshold is administered | ≥ s3po.auto_accept_threshold_min | 0.90 |
s3po.unverified_mapping_confidence_cap | ceiling on decisions resting on an unverified chart mapping (S3-PO 4.4) | SHALL be < s3po.auto_accept_threshold_min | 0.80 |
s3po.split_min_line_coverage | minimum invoice coverage by classified lines for a split (S3-PO 6.4) | 0 < value ≤ 1 | 0.95 |
atme.deviation_method | routing-deviation method in force | LINEAR_SCALED | MONTE_CARLO | LINEAR_SCALED |
atme.linear.uplift_pct_shortest / atme.linear.uplift_pct_longest | uplift at the shortest / longest distance in the dataset | shortest ≥ longest ≥ 0 | 30 / 10 |
atme.linear.distance_km_shortest / atme.linear.distance_km_longest | distance bounds of the interpolation | shortest < longest | 200 / 15,000 |
atme.mc.route_factor | distribution of the route-adjustment factor F_R | normal (μ, σ) | N(1.05, 0.02) |
atme.mc.no_fly_zone_factor | distribution of the no-fly-zone factor F_N | normal (μ, σ) | N(1.02, 0.01) |
atme.mc.approach_factor | distribution of the airport-approach factor F_A | normal (μ, σ) | N(1.03, 0.015) |
atme.mc.sample_count | Monte Carlo iterations | integer > 0 | 10,000 |
atme.radiative_forcing_enabled | apply the radiative-forcing uplift to air legs | boolean | set at registration |
s3sum.minimum_coverage_ratio | minimum structural coverage when require_minimum_coverage is set | 0 < value ≤ 1 | 0.67 |
The seed values come from the ATME functionality description and the withdrawn S3-CON specification. They are registration data, not contract constants: once the set is registered, the set is the only source.
Reuse beyond Scope 3. Every key above remains authoritative under its current name. The atme.* keys are ATME's parameters held in the Scope 3 set as a compatibility binding: when K4 and ATME are reused outside Scope 3 they read the same keys, and no second store may hold competing values. Moving them to a reusable transport namespace requires an explicitly registered migration; keys are never silently renamed or duplicated. Parameters of the road, rail, sea and inland-waterway engines (load factors, empty running, vessel and vehicle profiles) are not Scope 3 parameters and are not added to this set: they need a reusable transport parameter namespace, which is a registration request (section 14).
3. Architecture Overview
3.1. Position in the canonical pipeline
The family respects the canonical TrustGate order (Parser → Structure Validation → Normalizer → Context Enrichment → Rule Evaluation → Policy Resolution → Trust Scoring → Decision). The Post Office is a Context Enrichment engine: it attaches taxonomic meaning and never alters a quantitative value. Controllers, kernels and the Summary engine execute after Decision, on signals that have passed the assurance pipeline.
INPUT HUB SOURCES
general ledger (TAC) · AP / invoices (AP-CONN, INV-GHG) · supplier data (E-C-O)
activity feeds (travel, logistics, waste, fleet) · product & asset registers · portfolio holdings
│
▼
┌──────────────────────────── TrustGate canonical pipeline ────────────────────────────┐
│ Parser → Structure Validation → Normalizer → ┌──────────────────────┐ → Rule Eval → │
│ │ CONTEXT ENRICHMENT │ Policy Res → │
│ │ S3-PO Post Office │ Trust Score →│
│ │ (classify + stamp) │ Decision │
│ └──────────────────────┘ │
└───────────────────────────────────────────────────────────────────────────────────────┘
│ ARTIF-ADENGINE-SCOPE3-CATEGORY-ASSIGNMENT (outcome + category + evidence)
▼
┌─────────────── ZSSR routing ruleset (keyed on assignment.outcome / .category) ───────────────┐
│ ASSIGNED cat N → S3-C0N SPLIT → n envelopes → S3-C.. REROUTE_SCOPE1 → S1-CON │
│ REROUTE_SCOPE2 → S2-CON NOT_APPLICABLE → ledger note HOLD → TG-QUARANTINE-MANAGER│
└───────────────────────────────────────────────────────────────────────────────────────────────┘
│
▼
┌───────────────────────── 15 CATEGORY CONTROLLERS (CALC) ──────────────────────────┐
│ S3-C01 … S3-C15 — boundary · authorized capability + policy · allocation decision │
│ · exclusion codes · category-result evidence │
│ │ invokes (MICE execution + ZSSR dispatch) │
│ ▼ │
│ SHARED METHOD KERNELS (CALC, governed by KISMET) │
│ K1 spend-based (GHG-NACE) K2 activity × factor K3 supplier-specific │
│ K5 waste treatment K6 use-phase K7 PCAF attribution │
│ K8 entity proxy (= S1-CON / S2-CON under a delegated entity context) │
│ │
│ K4 TRANSPORT (composite) — validate journey · resolve permitted plan per leg │
│ │ │
│ ├── air: ATME (own MEID) ├── road ├── rail ├── sea ├── inland waterway│
│ │ mode engines, independently governed and versioned │
│ ▼ │
│ K4 combination · leg and journey results · completeness · execution evidence │
│ ▲ factors via EFDER · units via NORM-UNIT · route/distance resolution │
│ │
│ Category allocation, where the profile requires it: separate governed execution │
│ (SPT), decided by the controller, outside K4 │
│ Data-quality scoring: governed scoring capability, decided by the controller │
└────────────────────────────────────────────────────────────────────────────────────┘
│ ARTIF-ADENGINE-SCOPE3-CATEGORY-RESULT (per category, per period, per entity)
▼
┌──────────────────────── S3-SUM Scope 3 Summary engine ───────────────────────────┐
│ stage A category roll-up → stage B inclusion policy, total, coverage, │
│ disclosure object, double-count checks, unclassified residual │
└───────────────────────────────────────────────────────────────────────────────────┘
│ ARTIF-ADENGINE-SCOPE3-INVENTORY
▼
GHG-AGGR (S1 + S2 + S3) · Reports & Insights · ESGX / PCAF profile · Watchtower · Carbon Passport
3.2. The four engine classes
| Class | Count | MICE type | Owns | Must not |
|---|---|---|---|---|
| Post Office | 1 | META | category assignment, outcome, confidence, evidence, override trail | hold quantities, compute, route |
| Category controller | 15 | CALC | boundary, authorized capabilities and policies, capability selection, allocation and data-quality decisions, exclusion codes, category-result evidence | contain arithmetic (estimation, numerical allocation, uncertainty, DQ formulas), classify, see other categories |
| Method kernel | see 4.2 | CALC | a coherent calculation capability under KISMET: declared methods, atomic or composite execution, factor provenance, uncertainty, completeness and execution evidence | decide category applicability or reporting boundaries, select a method outside the caller's authorization, hard-code factors |
| Summary | 1 | AGGR | roll-up, inclusion policy, total, coverage, disclosure object, double-count checks, residual | re-classify, re-calculate |
All four classes use registered MICE types (config/system/mice-types.json): the Post Office is META (capability CLASSIFY), controllers and kernels are CALC (capability CALC), the Summary engine is AGGR. Controllers are CALC, not CTRL: a CTRL engine runs the control plane, is never selected by ZSSR as a computation step and never produces a sustainability value (MTPS-001, CTRL 3.1–3.2), whereas a controller is routed to by ZSSR and emits the category result. That a controller delegates its arithmetic to kernels is a design rule of this family (D2, S3C-001), not a type distinction.
A kernel is atomic or composite (KISMET §2). Atomic and composite describe implementation structure, not MICE type: K4 coordinates child executions and is still a CALC kernel, not a controller. The mode engines beneath K4 are CALC micro engines in their own right; they are dependencies of K4, not additional kernels of this family.
4. The Engine Family
4.1. Governed engines (the seventeen)
| # | Role | Doc ID | MEID | MICE type | State |
|---|---|---|---|---|---|
| 1 | Scope 3 Post Office | S3-PO | MEID_GHG_CLASSIFY_SCOPE3 (proposed) | META | new |
| 2 | Cat 1 — Purchased goods and services | S3-C01 | MEID_GHG_CALC_PURCHASED_GOODS (proposed) | CALC | new |
| 3 | Cat 2 — Capital goods | S3-C02 | MEID_GHG_CALC_CAPITAL_GOODS (proposed) | CALC | new |
| 4 | Cat 3 — Fuel- and energy-related activities | S3-C03 | MEID_GHG_CALC_FUEL_ENERGY_ACTIVITIES (proposed) | CALC | new |
| 5 | Cat 4 — Upstream transportation and distribution | S3-C04 | MEID_GHG_CALC_UPSTREAM_TRANSPORT (proposed) | CALC | new |
| 6 | Cat 5 — Waste generated in operations | S3-C05 | MEID_GHG_CALC_OPERATIONAL_WASTE (proposed) | CALC | new |
| 7 | Cat 6 — Business travel | S3-C06 | MEID_GHG_CALC_BUSINESS_TRAVEL (proposed) | CALC | new |
| 8 | Cat 7 — Employee commuting | S3-C07 | MEID_GHG_CALC_EMPLOYEE_COMMUTING (proposed) | CALC | new |
| 9 | Cat 8 — Upstream leased assets | S3-C08 | MEID_GHG_CALC_UPSTREAM_LEASED_ASSETS (proposed) | CALC | new |
| 10 | Cat 9 — Downstream transportation and distribution | S3-C09 | MEID_GHG_CALC_DOWNSTREAM_TRANSPORT (proposed) | CALC | new |
| 11 | Cat 10 — Processing of sold products | S3-C10 | MEID_GHG_CALC_PRODUCT_PROCESSING (proposed) | CALC | new |
| 12 | Cat 11 — Use of sold products | S3-C11 | MEID_GHG_CALC_PRODUCT_USE (proposed) | CALC | new |
| 13 | Cat 12 — End-of-life treatment of sold products | S3-C12 | MEID_GHG_CALC_END_OF_LIFE (proposed) | CALC | new |
| 14 | Cat 13 — Downstream leased assets | S3-C13 | MEID_GHG_CALC_DOWNSTREAM_LEASED_ASSETS (proposed) | CALC | new |
| 15 | Cat 14 — Franchises | S3-C14 | MEID_GHG_CALC_FRANCHISES (proposed) | CALC | new |
| 16 | Cat 15 — Investments | S3-C15 | MEID_GHG_CALC_INVESTMENTS (proposed) | CALC | new |
| 17 | Scope 3 Summary (roll-up, inventory and disclosure object) | S3-SUM | MEID_GHG_AGGR_SCOPE3 (canonical, inherited from S3-CON) | AGGR | new specification; replaces S3-CAT and S3-CON |
These are the seventeen core Scope 3 engines. Kernels (4.2), K4's mode engines and the supporting services (4.3) are shared dependencies of the family, not members of it.
4.2. Shared method kernels
| Kernel | Method (GHG Protocol Scope 3 Standard) | Engine | MEID | Type | State | Used by |
|---|---|---|---|---|---|---|
| K1 | Spend-based (EEIO factor per NACE / spend class) | GHG-NACE | MEID_GHG_CALC_SPEND | CALC | existing | 1, 2, 4, 9, 10 (fallback for most) |
| K2 | Average-data: activity quantity × emission factor (incl. well-to-tank, T&D-loss, floor-area and asset-type factors) | new | MEID_GHG_CALC_ACTIVITY_FACTOR (proposed) | CALC | new | 1, 2, 3, 8, 10, 13, 14 |
| K3 | Supplier-specific: supplier PCF / allocated supplier emissions | new | MEID_GHG_CALC_SUPPLIER_SPECIFIC (proposed) | CALC | new | 1, 2, 4, 10 |
| K4 | Transport, all modes (composite): a journey of explicit legs and participating items; per leg a permitted mode engine and method (distance-, fuel- or activity-based), combined into leg and journey results with completeness and evidence (7.3) | new, composite | MEID_GHG_CALC_TRANSPORT (proposed) | CALC | new | 4, 6, 7, 9 |
| ↳ air | Air mode engine: great-circle distance with routing-deviation adjustment, aircraft type, passenger load factor and seat capacity, cargo weight, per-gas factors | ATME | MEID_GHG_CALC_AIR_TRANSPORT (canonical) | CALC | existing specification, own MEID and release line | through K4 (air legs) |
| ↳ road | Road mode engine: distance- and fuel-based, vehicle and fuel profiles, load factor, empty running | new | to be proposed in its specification | CALC | new | through K4 |
| ↳ rail | Rail mode engine: distance- and energy-based, traction profile | new | to be proposed in its specification | CALC | new | through K4 |
| ↳ sea | Sea mode engine: distance- and fuel-based, vessel profile and load basis | new | to be proposed in its specification | CALC | new | through K4 |
| ↳ inland waterway | Inland-waterway mode engine: distance- and fuel-based, vessel profile | new | to be proposed in its specification | CALC | new | through K4 |
| K5 | Waste: mass by treatment route × treatment factor | new, uses WST-CLASS for route | MEID_GHG_CALC_WASTE_TREATMENT (proposed) | CALC | new | 5, 12 |
| K6 | Use-phase: direct and indirect use-phase energy of sold products over lifetime | new | MEID_GHG_CALC_USE_PHASE (proposed) | CALC | new | 11 |
| K7 | Investment-specific: PCAF attribution factor × investee emissions | new | MEID_GHG_CALC_FINANCED_EMISSIONS (proposed) | CALC | new | 15 |
| K8 | Entity proxy: another entity's Scope 1 and 2 under a delegated entity context | S1-CON, S2-CON | existing | CALC / TRANS | existing | 8, 13, 14 |
K4 is one public transport capability with a versioned composition. A controller profile names K4 and an authorized transport policy; K4 resolves the permitted mode engine and method for each leg, executes the legs and combines the results. A multimodal shipment is one K4 execution, not a controller calling several kernels. The mode engines are separate engines because their models and governance lifecycles differ materially; vehicle, fuel and vessel subtypes are governed data inside a mode engine, not further engines. ATME keeps its own MEID because its method — see 7.2 — is a self-contained, parameterised estimation with its own reference datasets and uncertainty model, maintained on a cadence of its own. ATME stays independently callable by authorized consumers through its own contract; Scope 3 calls it only through K4.
All other kernels are atomic at present. K4 is the family's composite kernel and KISMET's reference composite (KISMET §11).
K8 is not a new engine. Categories 8, 13 and 14 are the lessor's, lessee's or franchisee's own Scope 1 and 2; the controller invokes the existing Scope 1 and Scope 2 consolidation engines with the counterparty as the entity in scope. When no counterparty data exists, the controller falls back to K2 with floor-area or asset-type factors.
4.3. Supporting services (existing, reused as-is)
| Service | Doc ID | Role in the family |
|---|---|---|
| Emission-factor lookup | EFDER | sole source of factors and governed parameter datasets for every kernel; resolves ZAYAZ reference data first, external provider second |
| Unit normalisation | NORM-UNIT | every envelope and every kernel input is normalised before use |
| Split / allocation | SPT | executes the numerical category allocation the controller decides (e.g. cat 1 versus 2 on partially capitalised spend; multi-tenant leased assets; a shared freight journey allocated to the reporting company), as its own execution with its own reference |
| Route / distance resolution | none registered | resolves leg distance from endpoints where the transport policy permits; route evidence is recorded separately from emission-factor evidence. ATME's flight lookup is a connector (CONN) dependency of ATME. A reusable route/distance resolver is a missing concept and a registration request (section 14) |
| Data-quality scoring | none identified | executes the data-quality formulas (6.4) the controller applies; to be identified or specified as a governed scoring capability in build step 2 |
| Share / ratio | SRC | category shares computed from the Summary engine's category series |
| Ledger and AP sources | TAC, AP-CONN, INV-GHG | primary envelope producers |
| Hold / review | TG-QUARANTINE-MANAGER | destination of every HOLD outcome |
| Routing | ZSSR | resolves assignment outcome to destination engine |
| AI proposals | AI-DIAL | executes the AI tier of the Post Office under the governed gateway |
5. The Scope 3 Post Office (S3-PO)
5.1. Purpose
Attach to every value-chain signal exactly one of the following outcomes, with evidence:
| Outcome | Meaning | ZSSR destination |
|---|---|---|
ASSIGNED | one category cat1 … cat15, with upstream/downstream flag and, for cat 3, the sub-activity (3a purchased fuels, 3b purchased electricity, 3c T&D losses, 3d generation of purchased electricity sold on) | the matching controller |
SPLIT | the signal covers more than one category (e.g. one utility invoice carrying water supply and wastewater treatment); the Post Office emits n child envelopes, each ASSIGNED, with the split rule reference | each matching controller |
REROUTE_SCOPE1 | the signal belongs to Scope 1 (e.g. fuel for owned vehicles posted to a Scope 3 account) | S1-CON |
REROUTE_SCOPE2 | the signal belongs to Scope 2 | S2-CON |
NOT_APPLICABLE | no GHG relevance (e.g. financial transfers, VAT, intra-group eliminations) | ledger note only |
HOLD | cannot be assigned at the required confidence | TG-QUARANTINE-MANAGER |
The Post Office never emits a category without an outcome, and never emits ASSIGNED below the auto-accept threshold.
5.2. Inputs — typed envelope adapters
The Post Office accepts one envelope contract with typed adapters rather than one classifier per source. Each adapter normalises its source into the common envelope; the classification logic is shared.
| Adapter | Source signal | Discriminating fields carried into the envelope |
|---|---|---|
transaction | general-ledger or AP line (TAC, AP-CONN, INV-GHG) | Scope 3 account class resolved chart-agnostically from the client's chart mapping (S3-PO 4), capitalised-vs-expensed flag, supplier identity and NACE, cost-centre, description text, direction (payer/receiver) |
supplier | supplier onboarding record (E-C-O) | NACE/UNSPSC, product classes supplied, contractual role (supplier, logistics provider, lessor, franchisee) |
activity | activity feed (travel booking or airline ticket itinerary, logistics shipment, waste manifest, fleet, commuting survey) | activity type, mode, counterparty role, ownership/control flag |
product | sold-product or BOM record | product class, lifetime, energy-using flag, end-of-life route, downstream processing flag |
asset | lease, franchise or asset register | lease direction (lessor/lessee), operational-control flag, floor area, asset type |
investment | portfolio holding | asset class (PCAF), attribution basis, investee identity |
Envelope fields are governed in the S3-PO input schema. A signal that no adapter accepts is not a Post Office error; it is not a Scope 3 signal.
5.3. Decision ladder (Normative)
Classification proceeds down the ladder and stops at the first rung that yields a decision at or above its threshold:
| Tier | Mechanism | Governed in | Confidence ceiling | Auto-accept |
|---|---|---|---|---|
EXPLICIT | signal already carries a governed category tag from an upstream engine or an accepted supplier declaration | envelope | 1.00 | yes |
RULE | deterministic ruleset (account class × capitalisation × direction × counterparty role × ownership flag) | ZRR ruleset for S3-PO | 1.00 | yes |
MAP | controlled mapping tables (NACE → category, UNSPSC → category, CN → category, treatment code → category) | ZAR mapping datasets, versioned | s3po.map_confidence_ceiling | yes, at or above threshold |
AI_PROPOSED | governed model proposes category and rationale from description text and context | AI-DIAL | s3po.ai_confidence_cap | never — always HOLD with proposal attached |
HUMAN_OVERRIDE | reviewer assigns or corrects; actor, reason, timestamp recorded | quarantine review workflow | 1.00 | yes |
Per D8, the AI confidence cap and the auto-accept thresholds are governed platform values administered by ZAYAZ administrators in the ZAYAZ administration dashboard; neither is a client or user setting. An administrator may adjust the cap, but the parameter-set schema SHALL reject any s3po.ai_confidence_cap at or above s3po.auto_accept_threshold_min, so an AI proposal can never auto-accept by configuration. Auto-accept thresholds are resolved per client and per adapter from the administered set.
5.4. Evidence object
Every outcome carries an evidence object that makes the assignment reproducible:
- ruleset identity and version, matched rule identity, or mapping dataset identity and version and matched key;
- the discriminating field values actually used (account code, capitalisation flag, NACE, counterparty role, direction, ownership flag);
- tier reached, confidence, threshold in force and the administered cap in force;
- for
SPLIT: the split rule and the allocation shares; - for
AI_PROPOSED: model identity, prompt and policy references as governed byAI-DIAL, and the proposal text; - for
HUMAN_OVERRIDE: actor, reason code, free-text reason, prior outcome; - the envelope hash, the adapter identity, and the Post Office CMI.
The evidence object is persisted as part of ARTIF-ADENGINE-SCOPE3-CATEGORY-ASSIGNMENT.
5.5. Exclusions
The Post Office does not:
- screen categories for relevance or justify exclusions (that needs quantities and is a boundary ruleset in the controller and the Summary engine);
- allocate values across categories beyond emitting split envelopes with governed shares;
- detect or resolve double counting across categories (Summary engine);
- choose a calculation method (controller).
5.6. Idempotency and re-classification
Classification is idempotent on the envelope hash plus ruleset/mapping versions. When a ruleset or mapping is re-versioned, affected assignments are re-run and the delta (changed outcomes) is emitted as an event so downstream controllers and the Summary engine can restate. The prior assignment is never overwritten; it is superseded with lineage.
6. Category Controllers (S3-C01 … S3-C15)
6.1. Common controller contract
Every controller is an instance of one template and exposes the same contract:
Inputs
- one or more
ASSIGNEDenvelopes for its own category (a controller SHALL reject an envelope whose category is not its own — ruleS3C-002); - its category profile (see 6.3);
- period and entity context;
- client policy selections (permitted-method restrictions, materiality thresholds) resolved through Policy Resolution, within administered bounds (D8).
Process
- validate the envelope against the category boundary (
in boundary/out of boundary with exclusion code); - select the capability and policy: the highest-ranked capability in the profile's preference order for which the required data elements are present, unless policy pins one; for transport this is K4 together with an authorized transport policy, within which K4 selects per-leg methods (
S3C-003); - normalise inputs (
NORM-UNIT); kernels resolve factors throughEFDER; - invoke the selected kernel(s); a hybrid method is the controller invoking more than one capability for one envelope; a multimodal journey is one K4 invocation;
- where the profile requires category allocation, decide the allocation and have it executed by a governed capability (
SPT) as its own execution, distinct from any allocation inside the kernel's method (7.3); - have data quality scored by the governed scoring capability (6.4);
- assemble and emit the category result with evidence.
Outputs
ARTIF-ADENGINE-SCOPE3-CATEGORY-RESULT: value in tCO2e, by period and entity, with capability and methods used, the root execution reference of each contribution and its child execution references (for K4: per leg and per mode engine), the resolved execution configuration (7.1), factor provenance (dataset, version, factor identity), data-quality score and indicators with their scoring execution reference, primary-data flag, allocation execution references, exclusion codes, uncertainty where the kernel supplies it, completeness (COMPLETEorPARTIALwith the unresolved items listed), and the assignment identity it derives from.
Rules
S3C-001separation of control and calculation. A controller owns category-boundary enforcement, authorization of calculation capabilities and policies, category-allocation decisions, exclusions and category-result evidence. It SHALL delegate domain calculations — emissions estimation, numerical allocation, uncertainty propagation and calculated data-quality scores — to governed kernels or shared executable capabilities, and SHALL NOT duplicate their formulas or implement alternative calculation paths. It MAY perform the bookkeeping needed to coordinate execution and assemble its output, provided this introduces or alters no domain calculation semantics. Every reported quantity SHALL retain lineage to the execution that produced it;S3C-002own category only;S3C-003authorized selection. A controller SHALL select capabilities and policies from the category profile according to data availability and resolved policy. A kernel (K4) MAY select internal methods and fallbacks only within that authorization. Neither controller nor kernel SHALL select a method to obtain a preferred numerical result. A change from transport modelling to supplier-specific or spend-based estimation SHALL return to controller-level selection unless it is explicitly included in an authorized higher-level composition;S3C-004execution lineage. Every category-result contribution SHALL reference the root execution that produced it. A root execution MAY contain child executions; repeated applications of the same method to different legs or activities SHALL remain individually identifiable. Allocation and later transformations SHALL carry their own execution references. A root total and its component results SHALL NOT both be counted as independent contributions;S3C-005an envelope that cannot be computed by any permitted method is emitted asUNCOMPUTEDwith the missing-data elements listed, not dropped. A kernel result with outcomePARTIAL(KISMET§6.2) is carried as aPARTIALcontribution with its unresolved items; it is never presented as complete and its missing part is never zero-filled;S3C-006S3-C03consumes only the validated activity data already consumed byS1-CONandS2-CON(fuel quantities, purchased electricity, heat, steam and cooling, and their grid context); it never consumes raw fuel or energy envelopes, so the well-to-tank and T&D-loss base always equals the reported Scope 1 and 2 base.
6.2. Why fifteen engines and not one engine with fifteen profiles
Because the unit of governance is the category: separate MEID, separate version line, separate replay profile, separate owner, separate Jira epic, and an audit can be scoped to one. The template guarantees uniformity; the profile carries the difference; the MEID carries the accountability.
6.3. Category profiles
The profile is a governed data document, one per category, consumed by the template and by the generation script. Profiles live at:
config/system/scope3/category-profiles/cat1.json … cat15.json
as governed JSON under the Constitutional System Registry, with a generated MDX view in the micro-engines folder, so the generation script and the documentation lint share one source. A profile declares:
category_profile:
category: cat4
name: Upstream transportation and distribution
direction: upstream
boundary:
includes: [...] # governed boundary statements
excludes: [...] # with exclusion codes
payer_rule: reporting_company_pays # cat 4 vs cat 9 discriminator
capabilities: # preference order, highest first
- { kernel: K3, method: supplier_specific, requires: [carrier_reported_emissions] }
- { kernel: K4, policy: transport-freight-default, # authorized transport policy (governed)
requires: [journey_legs, leg_modes, item_participation],
permitted_leg_methods: [fuel_based, distance_based],
permitted_fallbacks: [endpoint_distance] } # K4 may use only these
- { kernel: K1, method: spend_based, requires: [spend, nace_or_spend_class] }
allocation_rules: [...] # decided here, executed by SPT as a separate execution
data_quality:
schemes: [ghg_protocol_scope3_indicators, pcaf_score] # both, always
evidence_requirements: [...]
double_count_checks: [cat9]
frameworks: [GHG-Protocol-Scope3, ESRS-E1]
Category profile summary
| Cat | Name | Direction | Primary kernels | Profile-specific rules |
|---|---|---|---|---|
| 1 | Purchased goods and services | up | K3 → K2 → K1 | expensed spend only; capitalised spend is cat 2 (shared allocation rule with cat 2 for partially capitalised items) |
| 2 | Capital goods | up | K3 → K2 → K1 | capitalised in the reporting year; no depreciation spreading |
| 3 | Fuel- and energy-related activities | up | K2 (WTT, T&D-loss, generation factors) | S3C-006: consumes the validated Scope 1 and 2 activity data; sub-activities 3a–3d; never recomputes Scope 1 or 2 |
| 4 | Upstream transportation and distribution | up | K3 → K4 → K1 | payer rule: reporting company pays (inbound and third-party outbound it pays for); cross-check cat 9 |
| 5 | Waste generated in operations | up | K5 | treatment route from WST-CLASS; wastewater included; excludes sold products (cat 12) |
| 6 | Business travel | up | K4 | one K4 journey per trip; air legs executed by ATME (ticket itinerary → airports → distance → per-passenger allocation), surface legs by the road and rail engines; radiative-forcing policy flag administered; hotel nights optional per policy |
| 7 | Employee commuting | up | K4 | survey- or average-based journeys; air commuting, where it occurs, is an air leg executed by ATME; teleworking optional per policy |
| 8 | Upstream leased assets | up | K8 → K2 | lessee position; Appendix A boundary (S3-PO 6.6): operating leases under financial control or equity share; never finance leases |
| 9 | Downstream transportation and distribution | down | K3 → K4 → K1 | payer rule: not paid by the reporting company (customer or third party); includes retail and storage of sold products |
| 10 | Processing of sold products | down | K3 → K2 → K1 | intermediate products only; requires downstream processing flag |
| 11 | Use of sold products | down | K6 | direct (energy-using, fuels, GHG-containing) and indirect use-phase; lifetime and usage profile from product profile |
| 12 | End-of-life treatment of sold products | down | K5 | every sold product; treatment mix from the product profile, default disposal scenarios when absent; shares K5 with cat 5 |
| 13 | Downstream leased assets | down | K8 → K2 | lessor position; Appendix A boundary (S3-PO 6.6): finance leases always, operating leases under operational control |
| 14 | Franchises | down | K8 → K2 | franchisor position; franchisee Scope 1 and 2 |
| 15 | Investments | down | K7 | PCAF asset classes; attribution denominator by asset class; PCAF score 1–5 mandatory |
6.4. Data quality
Each controller is accountable for scoring every result with both schemes, always: the GHG Protocol Scope 3 data-quality indicators (technological, temporal and geographical representativeness; completeness; reliability) with the primary-data flag (supplier- or partner-specific data versus secondary data), and the PCAF data-quality score 1–5. Both are carried into the category result, because ESRS E1-6 asks for the share of emissions calculated from primary data and the PCAF/ESGX profile needs the score without a second pass. The cost is one field per result. The controller decides which inputs and scheme apply; the scoring formulas are executed by a governed scoring capability (4.3), whose execution reference is carried in the result (S3C-001).
6.5. Exclusions and relevance
A controller may mark its category excluded for a period only with a governed exclusion code (not relevant by size, not relevant by activity, data unavailable with estimation attempted, not relevant per policy). The justification is carried into the Summary object. A category with no envelopes and no exclusion code is reported by the Summary engine as not screened.
7. Method Kernels
7.1. Common kernel contract
A kernel is category-agnostic. It receives normalised activity data, an authorized policy and factor selectors, returns a result with provenance, and knows nothing about why it was called.
Every kernel uses the common invocation and result envelope of KISMET (§6): contract and operation, inputs or immutable input references, execution context, authorization and policy references, correlation identity; and a result carrying execution identity, resolved configuration, typed output, outcome (COMPLETE, PARTIAL, REJECTED, FAILED), methods and branches used with selection and fallback reasons, root and child execution references, uncertainty, replay declaration, failures and evidence references. This document adds the Scope 3 result profile (KISMET KIS-007):
Inputs (profile): activity data (typed per kernel), factor selectors (class, geography, year), the authorized method or transport policy, period, requested output basis.
Outputs (profile): value in tCO2e (and by gas where the factor set provides it), the emissions boundary and characterization basis used, factor provenance (dataset, version, factor identity, retrieval proof from EFDER), uncertainty where available, kernel CMI and version.
Rules
KRNL-001no hard-coded factors, weights, distributions or thresholds; every factor and parameter set is resolved throughEFDERor a ZAR-governed dataset;KRNL-002the category reaches the kernel only as a provenance tag, never as a branch in the logic;KRNL-003coherent capability and governed composition. A kernel SHALL expose a coherent, reusable executable capability through a versioned contract. It MAY implement several declared methods and MAY compose independently governed micro engines or child kernels. Method selection, branching, fallback and result combination SHALL follow a versioned execution policy authorized by the caller or governing context; the execution record SHALL identify the methods, component versions, policy and dependencies actually used. A kernel SHALL NOT redefine domain applicability, reporting boundaries or the caller's permitted methods, and selection SHALL NOT depend on obtaining a preferred result (KISMETKIS-001, KIS-002);KRNL-004resolved execution configuration. Every result SHALL identify its kernel contract and implementation release and the immutable resolved execution configuration — composition version, transitive executable dependencies, policies, factors and parameter datasets actually used. A factor-data update SHALL NOT falsely change an unchanged executable version, but SHALL produce distinguishable execution evidence (KISMET§6.1, §7.5);KRNL-005a kernel that produces a distribution rather than a point value (ATME's deviation model) returns the governed point estimate for the inventory together with the distribution summary (mean, median, mode, confidence interval) as uncertainty inputs. Sampling SHALL be deterministic: the pseudo-random generator algorithm and the seed are recorded with the execution, and the sample count is taken from the governed parameter set, so re-running with the recorded seed reproduces the samples bit for bit. The confidence interval is an output, never a replay tolerance.
7.2. Kernel notes
-
K1 spend-based (
GHG-NACE, existing). Already the Supply Chain Carbon Engine. Remains the fallback for most categories and the usual first-year method. Its specification is extended only to accept the common kernel contract. -
K2 activity × factor (new). The generic average-data kernel: quantity × factor with factor class selection. Serves well-to-tank and T&D-loss factors for cat 3, product-class factors for cat 1/2/10, and floor-area or asset-type factors for cat 8/13/14 fallbacks.
-
K3 supplier-specific (new). Ingests supplier-provided product carbon footprints or allocated emissions arriving through supplier onboarding (E-C-O). Validates the declaration's scope and allocation basis, converts to the reporting unit, and carries the supplier's own evidence reference. This is the kernel that lifts a category from secondary to primary data.
-
K4 transport, all modes (new, composite). Accepts a journey of explicit legs and participating items (7.3), validates it, resolves a permitted mode engine and method per leg within the authorized transport policy, executes the legs, verifies that their outputs share a compatible basis, and combines them into leg and journey results with completeness and evidence. K4 is the normal Scope 3 entry point for transport; it does not decide a journey's category, reporting inclusion or business ownership.
-
Road, rail, sea and inland-waterway mode engines (new). Distance-based (mode × distance × weight, or passenger-km), fuel- or energy-based variants; well-to-wheel option; vehicle, fuel, vessel, load-factor and empty-running data from governed datasets. One engine per mode; subtypes are governed data.
-
ATME, air mode engine (existing specification, own MEID; K4's air engine). The Air Transportation Micro Engine computes an air leg from the itinerary — origin and destination airports resolved to coordinates (from a ticket or booking found by the invoice crawler and a flight lookup) — as follows:
- great-circle distance between the airports by the Haversine formula (mean Earth radius 6,371 km);
- routing-deviation adjustment for taxiing, air-traffic routing, restricted airspace and approach patterns, by one of two administered methods: a linear scaling in which short flights receive a higher percentage uplift and long flights a lower one, interpolated between the administered bounds
atme.linear.uplift_pct_shortestandatme.linear.uplift_pct_longestoveratme.linear.distance_km_shortest…atme.linear.distance_km_longest; or a Monte Carlo model in which the adjusted distance is the great-circle distance multiplied by sampled route, no-fly-zone and airport-approach factors, each drawn from its administered distribution (atme.mc.route_factor,atme.mc.no_fly_zone_factor,atme.mc.approach_factor) overatme.mc.sample_countiterations, returning the most probable uplift and its distribution summary; - allocation to the passenger or the consignment (this is transport-method allocation inside the leg, not category allocation): for passengers, one over seat capacity × passenger load factor for the aircraft type and period; for cargo, by consignment weight against the aircraft's payload basis;
- emission factors per gas per kilometre for the aircraft type, with the radiative-forcing uplift applied only when
atme.radiative_forcing_enabledis true, and well-to-tank included per the kernel's factor selector.
Distributions, bounds, load-factor tables, aircraft specifications and the simulation count are governed datasets per D8 (
KRNL-001); the Monte Carlo variant returns underKRNL-005and replays asEXACTfrom the recorded seed. ATME's flight-lookup dependency is a connector concern (MICE typeCONN) declared in the ATME specification; connector responses used in a calculation are retained or immutably referenced for replay. ATME's scientific procedure, parameter authority and connector dependencies stay under ATME's own contract; K4 adds the journey around it, never a second version of its method. The ATME specification is regenerated from its functionality description through the PDF-to-MDX pipeline and adapted as K4's air engine in build step 4. -
K5 waste treatment (new; uses
WST-CLASS). Mass per treatment route × treatment factor; route resolved by the existing Waste Treatment Classification engine. -
K6 use-phase (new). Direct use-phase (energy-using products: lifetime × usage profile × grid or fuel factor; fuels and feedstocks; GHG-containing products) and indirect use-phase; product profiles are inputs, not kernel constants.
-
K7 PCAF (new). Attribution factor (by PCAF asset class: outstanding amount over EVIC, total equity plus debt, property value, and so on) × investee emissions; investee emissions may themselves be ZAYAZ inventories retrieved through ESGX. Carries the PCAF data-quality score through unchanged.
-
K8 entity proxy (existing
S1-CON,S2-CON). Invoked by controllers 8, 13 and 14 under a delegated entity context; no new engine.
7.3. K4 journey contract (Normative)
This section holds K4's contract until the K4 specification is written (build step 4); the K4 specification then becomes its home and this section is reduced to a reference.
Inputs. A journey consists of identified legs connected through identified locations. Each leg declares its mode, endpoints, time context and available activity observations. Locations MAY carry coordinates and facility identifiers; coordinates SHALL declare their coordinate reference system, and quantities SHALL declare units. Transported items or passenger groups are distinct from legs: participation records state which legs each item traverses and its quantity on each leg, so cargo joining, leaving or splitting is never covered by one journey-wide quantity. A leg MAY provide measured distance, fuel or energy consumption, route geometry or a route reference; otherwise an authorized mode-appropriate resolver MAY derive distance from the endpoints. The transport policy SHALL specify precedence, admissibility and conflict handling between these sources. A journey-total distance is a reconciliation input, never permission to spread distance across legs. Calculation context comprises time, requested output basis, emissions boundary, authorized method policy, factor selectors and governed parameter references. Missing inputs are handled by an authorized fallback or an explicit PARTIAL or FAILED outcome.
Execution.
- Validate locations, units, leg connectivity, item participation and required activity data.
- Resolve a permitted mode engine and method for each leg and record the selection reason.
- Resolve distance or route evidence where required, through declared dependencies.
- Execute the mode calculations with pinned factors and parameters.
- Verify that the outputs share a compatible aggregation basis, or apply an explicitly governed conversion.
- Combine under the declared rule, retaining leg and item attribution.
- Emit results, completeness and linked execution evidence.
Distance resolution is not route optimization. K4 evaluates the journey it is given; discovering or optimizing alternative journeys needs a separately authorized capability.
Outputs. Per-leg and journey results; mode and gas breakdowns where supported; activity and distance actually used, with estimated-versus-measured provenance; methods and component versions; uncertainty; unresolved items; root and child execution references. No missing leg is zero-filled. A partial journey SHALL NOT appear complete. Totals SHALL combine only compatible emissions boundaries, characterization bases and units; otherwise K4 normalizes under governance, rejects, or returns separate subtotals. Uncertainty combination SHALL account for declared dependencies and correlations, such as shared factors; adding confidence-interval bounds is not a default rule.
Two allocation stages. Allocating a vehicle's, vessel's or aircraft's emissions to a passenger, payload or consignment is part of the transport method and happens inside K4's mode engines. Allocating a journey result to the reporting company or to a Scope 3 category is a controller-decided operation executed separately (6.1 step 5). Evidence SHALL identify each stage so neither is applied twice.
Release and governance.
- Mode engines keep independent ownership and version lines. A new ATME release does not replace the ATME version in a released K4 configuration.
- Upgrading a K4 dependency creates a new immutable composition release or dependency-lock revision, with conformance evidence and an impact assessment.
- Reference-data changes keep their own dataset versions. Replays use the recorded versions; recalculation with updated data is a new execution linked to the original.
- Transport policies authorize K4's internal selection and fallback; category profiles authorize K4's use for their category. K4 never infers a Scope 3 category from a route.
- Route and connector responses used in a calculation are retained or immutably referenced for replay, subject to access and retention requirements.
8. The Summary Engine (S3-SUM)
8.1. Purpose and position
S3-SUM is the seventeenth engine and the only place where Scope 3 is "put together". It answers two questions that the withdrawn specifications answered separately — what do we have by category? and what is our reported Scope 3, and how complete is it? — in two stages of one engine, and adds the disclosure object an auditor and ESRS E1-6 need.
It is a MICE type AGGR engine. It never classifies and never calculates an emission value; it rolls up, applies policy, checks and discloses.
Inputs: category results from the fifteen controllers (ARTIF-ADENGINE-SCOPE3-CATEGORY-RESULT), exclusion records, the quarantine residual for the period, period and entity context, client inclusion policy.
Outputs: the category series, the Scope 3 total and the disclosure object, persisted as ARTIF-ADENGINE-SCOPE3-INVENTORY.
The ZAR schema addresses declared by the withdrawn specifications (schema.compute.ghg.scope3.cat.inputs.v1_0_0, .cat.options.v1_0_0, .cat.output.v1_0_0, schema.compute.ghg.scope3.inputs.v1_0_0, .options.v1_0_0, .output.v1_0_0) are inherited by S3-SUM as its stage A and stage B contract addresses, so that nothing downstream that resolves them breaks; the S3-SUM child specification re-issues them at v2_0_0 with the disclosure object added.
8.2. Stage A — category roll-up (Normative)
Inherited from the withdrawn Scope 3 Category Aggregation specification, with the governed-category simplification.
Canonical category identifiers. Category keys are cat1 … cat15 (lowercase, unpadded) — the form fixed by the inherited v1 contracts and by the Share calculator (GHG-SCC), which normalises Cat6, CAT6 and cat06 to cat6. Case and zero-padding variants are accepted on input and normalised; output keys MUST use the canonical form. Two-digit numbering appears only in document IDs and MEIDs (S3-C04, MEID_GHG_CALC_UPSTREAM_TRANSPORT), never in category keys.
Category resolution ladder. In the new family every category result already carries a governed category from the Post Office, so resolution is trivial. Where an item arrives with a sub-category only (legacy or external inputs), the engine resolves sub-category → category by: (1) an explicit mapping in the item, else (2) the referenced canonical mapping dataset (category_map_ref), else (3) the unknown-category policy.
Unknown-category policy (unknown_category_policy): ERROR fails the computation; DROP omits the item and records it in metadata; ASSIGN_OTHER places it in an other bucket. For regulated runs the policy is ERROR; DROP and ASSIGN_OTHER are permitted for internal analytics only and are recorded in metadata when used.
Duplicate policy (duplicate_item_policy): ALLOW, DEDUPE_BY_ID (items sharing the same source identity and period are counted once; dedupe actions recorded in metadata) or ERROR.
Negative values (negative_values_policy): ERROR by default; ALLOW_WITH_FLAG records each negative item in metadata.
Compute semantics. All inputs are normalised to a map of period → category → value (with an optional sub-category dimension). For each period t and category c:
S3_CAT(c, t) = Σ value(item_i) for all items mapped to category c in period t
All items are converted to tCO2e before accumulation; output values are in tCO2e.
Contribution rule. An item is a root contribution of a category result (S3C-004). Child execution references — K4 leg results, mode-engine executions, allocation executions — are lineage, not items: S3-SUM sums root contributions only and never adds a root total and its components. A PARTIAL contribution is summed at its computed value and carried into the disclosure object as partial (8.4).
Structural completeness metadata. Stage A emits categories_present, expected_categories (from options, default cat1–cat15), the structural coverage_ratio (categories present ∩ expected, over expected — a presence signal, not a magnitude signal), unknown_items_count, negative_items_count and the dedupe actions taken.
Alignment. BY_YEAR (items carry a period key; output keyed by period) is the norm; BY_INDEX is permitted only for already-shaped time series and is discouraged for regulated reporting.
8.3. Stage B — inclusion policy, total and coverage (Normative)
Inherited from the withdrawn Scope 3 Consolidation specification.
Inclusion policy (category_policy): SUM_ALL includes every category present; INCLUDE_LIST includes only the listed categories; EXCLUDE_LIST includes all except the listed categories. Categories excluded by policy MUST carry a governed exclusion code and justification (6.5) and MUST be reported; a missing category MUST remain distinguishable from an excluded one. A missing category is absent, never zero, unless the schema explicitly allows zero-fill.
Scope 3 total. For each period t:
SCOPE3_TOTAL(t) = Σ S3_CAT(c, t) for all included categories c
Coverage. The structural coverage ratio from stage A is carried forward. If require_minimum_coverage is set and the ratio is below s3sum.minimum_coverage_ratio (resolved from the parameter set; the withdrawn specification's default of 0.67 is its seed value), the computation MUST fail with S3_SUM_COVERAGE_BELOW_THRESHOLD. Metadata MUST include categories_present, categories_expected, categories_excluded, coverage_ratio and coverage_passed.
Alignment. All category series MUST align on the same period keys (BY_YEAR); BY_INDEX ordered aggregation is discouraged for regulatory reporting.
8.4. Stage C — disclosure object (Normative, new in this family)
Beyond total and coverage, S3-SUM SHALL produce:
| Element | Content | Why |
|---|---|---|
| per-category method and data quality | method(s) used, share by method, GHG Protocol DQ indicators, PCAF score, primary-data share | ESRS E1-6 methodology and primary-data disclosure; auditor scoping |
| exclusions | per excluded category: exclusion code and justification text reference | ESRS E1-6 and GHG Protocol require justified exclusions |
| screening status | per category: computed / excluded / not screened | a silent gap is not an exclusion |
| magnitude coverage | share of relevant spend reached by any method; share of suppliers by spend with primary data | completeness narrative; procurement engagement targets; complements the structural ratio |
| partial contributions | per category: count and computed value of PARTIAL contributions, with their unresolved items (e.g. a journey leg without activity data) | an incomplete calculation is visible, never silently smaller |
| unclassified residual | count and, where known, spend value of envelopes still HOLD in quarantine at cut-off, by adapter | the inventory is only as complete as the Post Office; this makes it visible |
| double-count checks | results of the governed checks: cat 1 vs 2 (capitalisation), cat 3 vs Scope 1/2 (S3C-006 base equality), cat 4 vs 9 (payer rule), cat 5 vs 12 (own waste vs sold products), cat 8/13/14 vs consolidated Scope 1/2 | assurance findings in advance |
| restatement log | assignments or results superseded since the last cut-off, with cause (ruleset re-version, factor re-version, override) | restatement propagation to ESGX consumers |
8.5. Validation and error model
Invariants: category keys canonical; values finite; no negative values unless the policy allows them with a flag; category mapping deterministic; all series aligned; each root execution counted once and no child execution counted as a contribution.
Error codes (the withdrawn specifications' codes, re-homed under one prefix):
S3_SUM_CAT_MAPPING_NOT_FOUND S3_SUM_INVALID_CATEGORY_CODE
S3_SUM_UNKNOWN_CATEGORY_POLICY S3_SUM_DUPLICATE_ITEM
S3_SUM_NON_FINITE_VALUE S3_SUM_NO_CATEGORIES_PROVIDED
S3_SUM_COVERAGE_BELOW_THRESHOLD S3_SUM_ALIGNMENT_MISMATCH
S3_SUM_EXCLUSION_WITHOUT_CODE S3_SUM_DOUBLE_COUNT_CHECK_FAILED
S3_SUM_LINEAGE_DOUBLE_COUNT
Every error MUST carry the engine cmi_short_code, the offending item or category reference (index and source identity where available) and the period.
8.6. Federation and audit requirements
To reproduce a Scope 3 inventory externally, the export MUST include: engine identity (CMI) and build proof (execution_ref, build_hash); the input, options and output schemas used; the category results (or the category series) with their assignment identities; the mapping dataset reference and proof where stage A mapping was used; the inclusion policy, exclusion records, coverage ratio and thresholds applied; the dedupe policy and evidence fields; and the assignment artifacts for the period, because the category is the first thing an assurer will challenge. The provenance chain MUST show … → MEID_GHG_AGGR_SCOPE3 → … with the CMI short code in the USO tail.
8.7. Performance notes
Stage A is linear in the number of items; stage B and C are linear in periods × categories. Suitable for batch reporting; stage A can be streamed when items arrive sorted by period.
8.8. Methods served and consumers
Methods: GHG.scope3.cat.abs (category series, from stage A), GHG.scope3.cat.share (via SRC on the category series), GHG.scope3.abs and GHG.scope3.reported.abs (from stage B). Downstream consumers, unchanged from the withdrawn specification: MEID_GHG_AGGR_AGGREGATION, MEID_GHG_NORMALIZE_INTENSITY, MEID_GHG_CALC_TARGET_GAP, MEID_GHG_PROJECT_ALIGNMENT; new consumers: the ESGX/PCAF output profile, Watchtower and the Carbon Passport engine.
8.9. GHG-AGGR (existing, unchanged)
Consumes the Scope 3 total from S3-SUM together with Scope 1 and 2 and produces the standard rollups. Not part of the family; listed for completeness of the chain.
9. Signals, Routing and Identifiers
9.1. CSI signal families (header form)
Child specifications SHALL declare the following families (unversioned header form; runtime bindings are versioned in zar.signal_csi_binding). Signal names follow the Canonical Identifier Architecture (CIA): UPPER_SNAKE, kind EVENT for events:
comp.S3-PO.INPUT.ENVELOPE
comp.S3-PO.OUTPUT.CATEGORY_ASSIGNMENT
comp.S3-PO.EVENT.ASSIGNMENT_DELTA
comp.S3-C01.INPUT.CATEGORY_ENVELOPE … comp.S3-C15.INPUT.CATEGORY_ENVELOPE
comp.S3-C01.OUTPUT.CATEGORY_RESULT … comp.S3-C15.OUTPUT.CATEGORY_RESULT
comp.S3-SUM.INPUT.CATEGORY_RESULT
comp.S3-SUM.OUTPUT.CATEGORY_SERIES
comp.S3-SUM.OUTPUT.SCOPE3_ABS (Scope 3 total consumed by GHG-AGGR; successor of comp.S3-CON.OUTPUT.SCOPE3_ABS)
comp.S3-SUM.OUTPUT.SCOPE3_INVENTORY
Kernel families follow the same pattern under their own component identifiers (e.g. comp.GHG-NACE.OUTPUT.ESTIMATE, comp.ATME.OUTPUT.ESTIMATE). K4's journey input and its leg and journey results are declared in the K4 specification under K4's component identifier once registered (section 14), and bound through zar.signal_csi_binding like every other family; this document does not pre-name them.
9.2. ZSSR routing obligations
A governed ruleset keyed on comp.S3-PO.OUTPUT.CATEGORY_ASSIGNMENT SHALL resolve:
| assignment.outcome | assignment.category | next engine |
|---|---|---|
ASSIGNED | catN (N = 1 … 15) | S3-C + N zero-padded to two digits (e.g. cat4 → S3-C04) |
SPLIT | per child envelope | per child envelope |
REROUTE_SCOPE1 | — | S1-CON |
REROUTE_SCOPE2 | — | S2-CON |
NOT_APPLICABLE | — | terminal (ledger note) |
HOLD | — | TG-QUARANTINE-MANAGER |
Resolution of a HOLD in quarantine re-enters the Post Office as a HUMAN_OVERRIDE tier envelope; it does not bypass the Post Office.
9.3. Artifacts (ADENGINE domain, owned by Computation Hub)
| Artifact type (proposed) | Produced by | Runtime identifier (proposed) | Transport |
|---|---|---|---|
ARTIF-ADENGINE-SCOPE3-CATEGORY-ASSIGNMENT | S3-PO | S3AID | comp.S3-PO.OUTPUT.CATEGORY_ASSIGNMENT |
ARTIF-ADENGINE-SCOPE3-CATEGORY-RESULT | S3-C01 … S3-C15 | S3CRID | comp.S3-CNN.OUTPUT.CATEGORY_RESULT |
ARTIF-ADENGINE-SCOPE3-INVENTORY | S3-SUM | S3IVID | comp.S3-SUM.OUTPUT.SCOPE3_INVENTORY |
Each artifact type requires, per the artifact-naming rules: the ARTIF type, the runtime identifier type, the CSI transport contract, the producing engine and the owning specification. The owning specification for all three is the respective child engine specification; this document is the governing parent.
9.4. MEID grammar
All MEIDs follow MEID_STANDARD: MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>, every segment registered in its §16 vocabulary, and the capability allowed for the engine's MICE type (§16.4). The family uses domain GHG with capabilities CLASSIFY (Post Office, META), CALC (controllers and kernels, CALC) and AGGR (Summary, AGGR). Existing engines are referenced by their canonical MEIDs from tools/mice-contracts/catalogue/mice-members.yaml; the function codes introduced by this family are listed in section 14 and registered in MEID_STANDARD §16.3.
10. Evidence, Replay and Assurance
| Stage | Replay semantics (per TG-RP) | Evidence anchored |
|---|---|---|
Post Office — EXPLICIT, RULE, MAP tiers | EXACT (same envelope, ruleset and mapping versions reproduce the outcome) | assignment evidence object |
Post Office — AI_PROPOSED tier | RECORDED (proposal stored; not required to reproduce) | proposal record via AI-DIAL |
Post Office — HUMAN_OVERRIDE | EXACT (recorded decision) | override record |
| Controller | EXACT on method selection and allocation | category result evidence |
| Kernel, atomic (K1–K3, K5–K8) | EXACT for deterministic factors; BANDED where a factor dataset declares a tolerance from governed replay policy | factor provenance from EFDER |
| K4, composite | one declared profile per released composition, no stronger than the weakest dependency that composition may invoke (KISMET §8); each execution records the profile realized by its graph. A route or connector response replays from its recorded copy; recomputing the external service is not claimed | realized execution graph, per-leg child references, combination evidence, route evidence |
| Mode engines (road, rail, sea, inland waterway) | declared in each engine's specification | distance or fuel basis, parameters and factor provenance |
| ATME (as K4's air engine), linear deviation method | EXACT | distance, parameters and factor provenance |
| ATME (as K4's air engine), Monte Carlo deviation method | EXACT — same seed, generator algorithm, sample count and parameter-set version reproduce the samples and the point estimate; the confidence interval is reported as uncertainty and is never used as a replay tolerance | distribution summary, seed, generator algorithm, parameter-set version |
S3-SUM | EXACT | inventory object |
Every stage writes its lineage into the USO tail with its CMI short code, so an auditor can walk from a Scope 3 total to a category result, to a kernel execution and its child executions (for transport: journey → leg → mode engine), factors and allocations, to an assignment, to the originating ledger line — and back. A weaker child guarantee is propagated to the parent explicitly; a composite never claims more than its children support.
11. Governance of Change
| What changes | Where it lives | Cadence | Effect |
|---|---|---|---|
| category mapping (NACE, UNSPSC, CN, treatment codes → category) | ZAR mapping datasets | frequent | Post Office re-classifies affected envelopes; delta event; no engine version change |
| classification rules | ZRR ruleset for S3-PO | occasional | as above |
| administered parameters (AI cap, thresholds, coverage minimum, ATME distributions and bounds, simulation count) | ZAR-governed datasets and policies, administered in the ZAYAZ administration dashboard | as needed | no engine version change; parameter version recorded in evidence |
| category boundary or permitted methods | category profile in config/system/scope3/category-profiles/ | framework-driven (GHG Protocol Scope 3 revisions, ESRS amendments) | controller regenerated from template; controller version bump |
| controller contract | controller template | rare | all fifteen regenerated; family minor version bump |
| calculation method | kernel or mode engine (incl. ATME) | rare, method-specific | that engine's version bump; released K4 configurations keep the old version until a new composition release adopts the new one |
| K4 composition or dependency upgrade | K4 composition release / dependency lock | as needed | new immutable composition release with conformance evidence and impact assessment; old configuration stays replayable under retention policy |
| transport policy (per-leg selection, precedence, fallback) | governed transport policy | occasional | new policy version; distinguishable execution configuration; no kernel version change |
| factor data | EFDER datasets | provider-driven | factor re-version; BANDED replay where declared; restatement log |
| disclosure shape | S3-SUM output schema | regulatory | S3-SUM version bump |
Nothing in this table requires touching more than one place for one kind of change. That is the test the structure was designed to pass.
12. Worked Examples
12.1. Inbound freight invoice
A carrier invoice of NOK 12,400 is posted to NS 4102 account 6100 (Frakt og transportkostnad), supplier NACE 49.41 (Rev. 2, freight transport by road), on the client's verified chart mapping. (Freight posted inside cost of goods, NS 4060 Frakt, toll og spedisjon, is first split to exclude customs duties — S3-PO 13.1.)
TACemits atransactionenvelope. Normaliser and Structure Validation pass.- Post Office,
RULEtier: account classfreight_purchased(verified mapping, confidence 1.0) → ruleR-TX-FREIGHT→ASSIGNED cat4, upstream, confidence 0.97. Evidence: ruleset CRID and content hash, rule id, account-class resolution, discriminators used. - ZSSR resolves
ASSIGNED cat4→S3-C04. - S3-C04: boundary check passes (payer rule). Method selection: no carrier-reported emissions (K3 unavailable); no shipment-level mode/distance/weight (K4 unavailable); spend and NACE present → K1 spend-based via
GHG-NACE. DQ: reliability and completeness scored as secondary data; primary-data flag false; PCAF score 5. - Category result: value, method
spend_based, kernelGHG-NACEv-pinned, factor provenance fromEFDER, assignmentS3AIDreferenced. S3-SUMrolls it into cat4 for the period (stage A), records cat4 as computed, spend-based share, secondary data (stage C), and runs the cat 4 vs cat 9 check.
12.2. Split invoice
A municipal invoice of NOK 10,000 on NS 4102 account 6320 (Renovasjon, vann, avløp) carries two lines: water supply (6,200) and wastewater (3,800).
- Post Office: account class
premises_services_combined; split ruleSPLIT-PREMISES-01classifies each line →SPLITinto two child envelopes,ASSIGNED cat1(0.62) andASSIGNED cat5(0.38), each carrying the split rule, line references and shares. - Both controllers compute independently. Without invoice lines the envelope is held (
HOLD-SPLIT-NO-LINES), never guessed.
Freight is deliberately not a split example: freight the reporting company pays for is cat 4 whether inbound or outbound (GHG Protocol Scope 3 Standard); cat 9 covers only distribution of sold products that the reporting company does not pay for, and is classified from activity or product data, never from the company's own ledger.
12.3. Misposted own-fleet fuel
Diesel for company-owned vans is posted to the freight account 6100; the supplier is a fuel retailer (NACE 47.30, Rev. 2).
- Post Office,
RULEtier: the guard ruleR-TX-FREIGHT-FUEL-SUPPLIERfires beforeR-TX-FREIGHT— a fuel supplier on a freight account is a conflict →HOLDwithHOLD-CONFLICTING-SIGNALS. Nothing is assigned to cat 4. - The accountant resolves with
OVR-REROUTE; the override envelope re-enters →REROUTE_SCOPE1→S1-CON. Had the diesel been posted to the fuel account 7000 with the vans registered in UOM (OWNS),R-TX-FUEL-VEH-OWNEDwould have rerouted it directly.
12.4. Unclassifiable line
A 3,000 EUR line with the description "consulting Q3" on a mixed services account, supplier without NACE.
RULEandMAPtiers fail the threshold.AI_PROPOSEDtier proposes cat1 at 0.55 with rationale. Because the administered cap (s3po.ai_confidence_cap, seed 0.60) is below every auto-accept threshold →HOLD, proposal attached. ZSSR routes toTG-QUARANTINE-MANAGER. At cut-off,S3-SUMreports it in the unclassified residual. On review, the accountant accepts cat1 →HUMAN_OVERRIDEenvelope re-enters the Post Office →ASSIGNED cat1with the override record →S3-C01.
12.5. Business-travel flight
An airline ticket Warsaw → Rome is found by the invoice crawler; the itinerary resolves to the two airports.
- Post Office,
RULEtier on theactivityadapter: activity type = air travel, traveller = employee, payer = reporting company →ASSIGNED cat6, confidence 1.00. - S3-C06 selects K4 with the business-travel transport policy and invokes it with a one-leg journey (WAW → FCO, mode air, one passenger).
- K4 validates the journey and resolves the air leg to ATME. ATME: great-circle distance 1,315.5 km; the administered linear deviation method uplifts it to about 1,690 km; per-passenger allocation from the aircraft type's seat capacity and the period's load factor; per-gas factors per kilometre; radiative-forcing uplift only if the administered policy flag is on. K4 returns the leg and journey result,
COMPLETE. - The category result references the K4 root execution and the ATME child execution, the K4 composition release, the ATME version, the parameter-set version (bounds, load-factor table, aircraft specification) and the factor provenance. DQ: activity-based, secondary factors; PCAF score 3. Had the Monte Carlo method been administered, the ATME child would carry the point estimate, the confidence interval as uncertainty, the seed and the generator algorithm, and replay as
EXACT.
12.6. Multimodal freight
A consignment of 8 t travels A → B by road, B → C by sea and C → D by air; a second consignment of 2 t joins at B and leaves at C.
- The
activityenvelope (logistics shipment) isASSIGNED cat4(reporting company pays) →S3-C04. No carrier-reported emissions, so K3 is unavailable; the journey, leg modes and participation are present, so the profile selects K4 with the freight policy. - K4 runs one execution with three child legs: road engine (8 t), sea engine (10 t: both consignments participate), ATME for the air leg (8 t; the 2 t consignment is not attributed to it). Each leg uses its declared mode engine; the compatible leg results combine once into the journey total, with leg and consignment attribution kept.
- The category result counts the journey total once as one root contribution; the three leg results are its children (
S3C-004). If the reporting company shares the journey with another shipper, the controller's allocation is a separateSPTexecution on the journey result, distinct from the per-consignment allocation already inside the mode engines.
12.7. Incomplete leg
As 12.6, but the sea leg has neither distance nor fuel data and the freight policy does not authorize endpoint-derived distance for sea legs.
- K4 executes the road and air legs and returns
PARTIAL, listing the sea leg as unresolved. The sea leg is not zero-filled and the journey is not shown as complete. S3-C04carries the contribution asPARTIAL. Switching to spend-based estimation for the missing part is a controller decision underS3C-003, never a silent K4 fallback.S3-SUMreports the partial contribution in the disclosure object (8.4).
13. Build Sequence
The child specifications are written in this order; each step is one Jira epic.
| Step | Deliverable | Depends on |
|---|---|---|
| 1 | S3-PO Scope 3 Post Office specification (envelope contract, adapters, chart-agnostic account classification, decision ladder, rulesets, evidence, delta events) — delivered v0.1.0 | this document |
| 2 | Controller template (revised S3C-001, S3C-003, S3C-004) + fifteen category profiles in config/system/scope3/category-profiles/ with capability and policy bindings; generation script; identification of the data-quality scoring capability | step 1 (envelope contract) |
| 3 | S3-C01 … S3-C15 generated specifications | step 2 |
| 4 | Kernel specifications under KISMET: K2, K3, K5, K6, K7; K4 (journey, participation, policy, result and evidence schemas; first composition release; authorized transport policies); road, rail, sea and inland-waterway mode-engine specifications; contract alignment of K1 (GHG-NACE) and adaptation of ATME as K4's air engine (regenerated from its functionality description, identity kept, Monte Carlo and linear methods parameterised per D8) | step 2 (profiles fix which kernels each category needs) |
| 5 | S3-SUM specification (stages A–C, schemas re-issued at v2_0_0) | steps 3–4 |
| 6 | ZSSR routing ruleset for S3-PO outcomes; ZRR classification ruleset; mapping datasets | step 1 |
| 7 | Registrations and retirements (section 14); zar.signal_csi_binding entries; replay profiles | all |
| 8 | End-to-end tests: one signal chain (ESRS E1-6 cat 4 from a SIE/Xledger ledger line); one air leg (cat 6 via K4 → ATME); one multimodal journey with a joining consignment (12.6); one incomplete leg (12.7); the K4 acceptance scenarios (15, decision 9) | all |
14. Proposed Identifiers Requiring Registration
Per the repository operating rules, none of the following may be used as a reference until registered. This list is the registration request.
Document IDs — new: S3-ARCH (this document), S3-PO, S3-C01 … S3-C15, S3-SUM, plus one per new kernel (proposed: S3-K2-ACTF, S3-K3-SUPP, S3-K4-TRNS, S3-K5-WSTE, S3-K6-USEP, S3-K7-PCAF) and one per new mode engine (road, rail, sea, inland waterway; IDs to be proposed in their specifications). Open question: under KISMET kernels are platform capabilities reusable outside Scope 3, so the S3- prefix in the proposed kernel IDs may mislead; the IDs stay unregistered until this is decided. KISMET itself is registered with this change set.
Document IDs — withdrawn: S3-CAT and S3-CON. Their source files are removed with this document; the generated document-ID and component registries are regenerated accordingly. Jira epics ZYZ-745 (S3-CAT) and ZYZ-748 (S3-CON) should be closed or re-pointed to the S3-SUM epic.
MEIDs — new: MEID_GHG_CLASSIFY_SCOPE3 (Post Office); MEID_GHG_CALC_PURCHASED_GOODS, _CAPITAL_GOODS, _FUEL_ENERGY_ACTIVITIES, _UPSTREAM_TRANSPORT, _OPERATIONAL_WASTE, _BUSINESS_TRAVEL, _EMPLOYEE_COMMUTING, _UPSTREAM_LEASED_ASSETS, _DOWNSTREAM_TRANSPORT, _PRODUCT_PROCESSING, _PRODUCT_USE, _END_OF_LIFE, _DOWNSTREAM_LEASED_ASSETS, _FRANCHISES, _INVESTMENTS (controllers 1–15); MEID_GHG_CALC_ACTIVITY_FACTOR, _SUPPLIER_SPECIFIC, _TRANSPORT, _WASTE_TREATMENT, _USE_PHASE, _FINANCED_EMISSIONS (kernels K2–K7; K4's function code TRANSPORT replaces the earlier SURFACE_TRANSPORT now that K4 covers all modes). Their 21 function codes are registered in MEID_STANDARD §16.3; each MEID enters zar.meid_registry and mice-members.yaml when its engine document is written. Mode-engine MEIDs are not proposed here; each is proposed in its specification. ATME (MEID_GHG_CALC_AIR_TRANSPORT) and GHG-NACE (MEID_GHG_CALC_SPEND) already carry canonical MEIDs.
MEIDs — inherited and retired: MEID_GHG_AGGR_SCOPE3 passes from S3-CON to S3-SUM; MEID_GHG_AGGR_SCOPE3_CATEGORY (legacy MEID_CALC_GHG_SCOPE3_CAT) is retired in the same change set: its catalogue entry is removed from mice-members.yaml, the Computation Hub inventory in config/system/omr.modules.json drops it, the generated registries are regenerated, and the compute-method row GHG.scope3.cat.abs (MID-00006) is re-bound to the Summary engine in dev/excel/compute_method_registry.xlsx and the API contracts document (those two still use legacy _v1 engine references across the whole table, pending their own MEID migration). The method itself stays active; only its implementing engine changes (S3-SUM stage A, 8.2).
MICE types: none new. The family uses the registered types META, CALC and AGGR (3.2).
CSI families: as listed in 9.1, in zar.signal_csi_binding.
Artifact types: ARTIF-ADENGINE-SCOPE3-CATEGORY-ASSIGNMENT, ARTIF-ADENGINE-SCOPE3-CATEGORY-RESULT, ARTIF-ADENGINE-SCOPE3-INVENTORY in config/system/artifact-types.json.
Identifier types: S3AID, S3CRID, S3IVID in config/system/identifier-types.json.
Missing concepts: a reusable route / distance resolution service (4.3); a governed data-quality scoring capability (6.4); a reusable transport parameter namespace for the mode engines (D8); a registered home for transport policies. Each needs a specification and registration before use.
Registry paths: config/system/scope3/category-profiles/ as a new governed registry family under the Constitutional System Registry, to be declared in config/system/registry-manifest.json.
Rulesets and datasets: ZRR classification ruleset for S3-PO; ZSSR routing ruleset keyed on comp.S3-PO.OUTPUT.CATEGORY_ASSIGNMENT; mapping datasets NACE→category, UNSPSC→category, CN→category, treatment-code→category; ATME reference datasets (load-factor tables, aircraft specifications); the governed parameter set config/system/scope3/parameters.json with its JSON Schema (keys and seed values in D8), registered in config/system/registry-manifest.json together with config/system/scope3/category-profiles/.
Jira: one epic for this document and one per build step in section 13.
15. Decision Log
Decisions 1–7 were taken by the CTO on 2026-10-13 against the open questions of v0.1.0; decisions 8–10 on 2026-10-14 with the adoption of KISMET (KISMET alignment and transport redesign). Each is normative in the section cited.
| # | Question | Decision | Normative in |
|---|---|---|---|
| 1 | Does ATME keep its own MEID inside the transport kernel family, or is it retired into K4? | Keeps its own MEID. ATME is an advanced, self-contained method. Superseded in part by decision 9 (2026-10-14): the surface-and-sea-only K4 boundary no longer holds; ATME's own identity stands. | 4.2, 7.2, 14 |
| 2 | Data-quality scheme on every result: GHG Protocol indicators only, or always also the PCAF score? | Both, on every result | 6.4 |
| 3 | Category 3 inputs: raw fuel/electricity envelopes, or the validated activity data already consumed by S1-CON / S2-CON? | The validated Scope 1/2 activity data | S3C-006, 6.3 |
| 4 | AI-tier confidence cap | Parameter s3po.ai_confidence_cap, seed value 0.60; adjustable by ZAYAZ administrators in the administration dashboard, never client- or user-defined; always below the lowest auto-accept threshold | D8, 5.3 |
| 5 | Hold destination | TG-QUARANTINE-MANAGER | D5, 9.2 |
| 6 | Where category profiles live | config/system/scope3/category-profiles/ as governed JSON | 6.3, 14 |
| 7 | Fate of the first-pass specifications S3-CAT and S3-CON | Withdrawn; surviving normative content absorbed into the single Summary engine S3-SUM, which inherits MEID_GHG_AGGR_SCOPE3 | 1.3, 8, 14 |
| 8 | Common framework for kernels | KISMET governs every reusable executable kernel, atomic or composite. Kernels expose coherent capabilities with declared methods; S3-ARCH stays authoritative for Scope 3 boundaries and profiles and adds the Scope 3 result profile | D3, 7.1 |
| 9 | Transport | K4 is the all-mode transport kernel (air, road, rail, sea, inland waterway), a composite over independently governed mode engines; ATME is its air engine with its identity and lifecycle intact; K4 takes journeys of explicit legs and participation and returns leg results, journey results and evidence. Acceptance: single air leg through ATME; road → sea → air combined once; joining cargo attributed only to its legs; missing leg never zero-filled; distance conflicts resolved by governed precedence; mixed emission boundaries never silently summed; ATME upgrade yields a new configuration with the old one replayable; seeded Monte Carlo replays EXACT; category allocation separate from transport allocation; unauthorized fallback rejected | D3, 4.2, 7.2, 7.3, 12.5–12.7 |
| 10 | Controllers and calculation | Controllers decide; governed capabilities calculate — including numerical allocation, uncertainty propagation and data-quality scores (S3C-001, S3C-003, S3C-004). The rule identifiers stay S3C-: CTRL- would collide with RULE-CTRL-001…006 of the CTRL MICE type | D2, 6.1, 6.4 |
16. Related Documents
KISMET— Kernel Interoperability, Shared Methods & Execution Trust (kernel framework)MICE— Micro Engines, general informationMICE-EX— MICE Execution ModelCMPS-001— Component Metadata Profile SpecificationCIA— Canonical Identifier ArchitectureZSSR— ZAYAZ Smart System RouterSSSR— Smart Searchable Signal RegistryTG-RP— TrustGate Replay ProfilesREPLAY-CONSTITUTION— Replay ConstitutionZARM— ZAR Methodology RegistryTG-QUARANTINE-MANAGER— TrustGate Quarantine Manager EngineGHG-AGGR,S1-CON,S2-CON,GHG-NACE,ATME,EFDER,NORM-UNIT,SPT,SRC,WST-CLASSAI-DIAL— EPAM AI DIAL, governed AI execution gatewaySUPP-ONBOARD— Supplier Onboarding and Data AcquisitionESGX-FIN— ESGX for Financial Institutions (PCAF channel)ZX-WTWR-01— Watchtower Governance ArchitectureCaPE— Carbon Passport Engine