ESG Architecture & Specifications

Aeion ESG is fundamentally designed around background automation rather than manual data entry. It wires directly into the platform's real-time event bus. - Scope 2 (Energy): Intercepts live energy-usage readings from connected facilities. Extracts consumption and location to instantly calculate facility electricity impact. - Scope 3 (Logistics): Intercepts shipment-dispatch events. Weight, distance, and transit method (air/ocean/ground) resolve the precise ton-mile emissions. - Scope 3 (Procurement): Intercepts purchase-order receipt events and estimates embodied carbon from a spend-based emission factor (kg CO2e per dollar spent), posted straight to the ledger with no manual entry. Vendor sustainability-score compliance checks on PO drafting are logged today; blocking PO creation on a failing vendor score is on the roadmap.

The core of the module is a carbon ledger modeled on the same emission/offset transaction shape as the platform's financial billing ledgers. - Emission/Offset Records: Every event is written as an emission or an offset, each carrying the calculation details (factors and inputs used) needed for third-party audit review. The intended workflow is append-only — post a new entry to correct a prior one rather than editing it — though this isn't yet enforced at the database level the way Aeion Finance's ledger is. - High-Performance Aggregation: Reports don't pull thousands of individual records into application memory — the database handles the grouping and summation natively, enabling instantaneous generation of annual corporate reports even over years of ledger history. - Why a ledger and not a spreadsheet: Because each entry records the exact emission factor and the inputs that produced it, an auditor can re-derive any number in the annual report back to the operational event that generated it. A total isn't a cell a consultant typed — it's a query that sums signed entries, so the report is reproducible from the underlying transactions rather than trusted on faith.

The Carbon Calculation Engine never invents a number — it resolves each intercepted event against a library of emission factors and multiplies through by the event's own inputs. - Configurable factors: Factors are drawn from published references (EPA, DEFRA, IEA grid tables) and are configurable per tenant, so a facility on a cleaner regional grid isn't charged the national-average carbon intensity. A factor is a stored coefficient — e.g., kg CO₂e per kWh, per ton-mile, or per dollar of spend — applied at calculation time. - Spend-based and activity-based, hybrid by design: Procurement events without activity data fall back to a spend-based estimate (kg CO₂e per dollar spent by category). Where an event carries real activity data — specific fuel volumes, freight distance and mode, kWh drawn — that activity figure overrides the spend estimate for higher accuracy. The record stores which method was used, so audit review can see exactly how each line was derived. - Scope tagging at the source: Every calculated entry is tagged to the GHG Protocol scope (1 direct, 2 electricity, 3 supply chain) implied by the event that produced it, so scope subtotals in the report are a grouping of real entries, not a manual allocation after the fact.