Methodology

How Hemera works.

Audit-grade carbon accounting. Every figure traces back to its source: to the row, to the factor version, to the analyst who approved it.

Last updated 9 May 2026Methodology corpus v1.0-provisional30 sections, signed module-by-module

The full corpus is in our private repository. Available to clients on request.

Section 1

The four-tier data hierarchy

For every activity record we assign the highest tier the evidence supports. The evaluation runs top to bottom; the first tier whose evidence requirements are satisfied wins. Tier downgrades are typed events with a documented reason. The platform will not let an analyst claim Tier 1 when the evidence supports Tier 4.

Each tier carries an explicit data-quality score derived from a five-axis pedigree matrix: reliability, completeness, temporal correlation, geographical correlation, and technological correlation. Those scores feed directly into a per-row geometric standard deviation (GSD), which propagates upward into the workspace-level confidence interval.

Tier
Method
Data quality
1
Primary measured
Direct measurement attributable to the record: meter reading, verified PCF certificate, audited sub-meter. Highest pedigree.
100
2
DEFRA activity-based
Activity quantity (kWh, litres, t·km) × the appropriate DEFRA factor for geography, fuel, or activity type. The default for UK organisational footprints.
75
3
Exiobase MRIO spend-based
Monetary spend × a UK sector intensity from Exiobase, deflated to the factor's reference year. Used when activity quantity is unavailable but spend is. Carries a structural uncertainty floor.
45
4
Proxy / estimated
A Hemera-curated proxy with explicit documented basis and annual review date. Used only when the alternative is omitting a material category.
20

Section 2

Supplier research: the eight-layer method

Choosing the right tier for a supplier line item is the single largest source of pedigree improvement in a typical workspace. Hemera runs a structured eight-layer research method on every supplier the first time we encounter them, and reuses the resulting profile for subsequent encounters until its annual review date.

The layers are evaluated in order. The first layer that yields data above the workspace’s configured tier threshold ends the search; subsequent layers are skipped unless the analyst explicitly continues for a higher-confidence answer.

  1. Supplier name and spend.Normalise the row’s supplier string to a working identifier; preserve the original for traceability.
  2. Entity resolution. Look up the supplier in Companies House (UK) or the equivalent registry; attach a stable entity id. Resolution failures flag for admin review, never silent defaults.
  3. Sector and sub-sector classification. Assign a NACE sector and Hemera sub-sector. Drives the Tier 3 Exiobase factor and informs the DEFRA match.
  4. Primary-data probe. Search for a verified PCF, a CDP response, or comparable third-party-assured emissions disclosure. A verified PCF unlocks Tier 1.
  5. Parent and group identification.Establish the supplier’s corporate group; a subsidiary may inherit the parent’s PCF only when the parent attests to subsidiary inclusion.
  6. Country of origin.Determine where the goods or services are actually produced. For trading entities, that’s the production country, not the invoicing country.
  7. DEFRA category match. With sector, sub-sector, and country in hand, attempt a DEFRA factor match. Success moves the line from Tier 3 to Tier 2.
  8. Exiobase fallback. Apply the UK sector intensity from Exiobase at Tier 3. Always available; the default when none of layers 4 to 7 yield a higher answer.

The output of the eight layers is a usable supplier profile: sector, country, evidence trail, and a recommended tier, which the platform feeds back into the four-tier data hierarchy above.

Section 3

The Footprint Ledger

Every figure in a Hemera workspace is anchored to four things, and only the platform can write any of them:

  • A versioned emission factor: the factor library version that was current at calculation time is pinned to the row, so historical periods reproduce exactly.
  • A hash-chained audit event: every write is signed against the prior event hash. Mutating any row deterministically breaks the chain. The platform refuses UPDATE and DELETE against audit-tracked tables outside the sanctioned service layer.
  • The analyst who approved it, tagged with a typed provenance_actor: analyst, ai_manual, ai_automated, or rule_based.
  • Speciated greenhouse gases at row level: CO2, CH4, N2O, HFCs, PFCs, SF6, NF3 separately, not just CO2e. Frameworks that ask for speciation get the real numbers.

A re-run of last year’s report next year produces the identical figure, to the gram. Verifiers can re-execute the audit pack and confirm that replay independently, on their own machine.

Section 4

Frameworks we project to

One canonical inventory; many disclosure shapes. Each framework is a projection of the same underlying ledger, not a parallel calculation. Here’s what we ship today:

FrameworkStatusWhat you get
GHG Protocol Corporate StandardProductionScope 1 / 2 / 3 disclosure aligned to the six principles
UK SECRProductionUK-format SECR statement with director sign-off block
PPN 006ProductionCarbon Reduction Plan format for UK government contracts
ISO 14064-1ProductionOrganisational GHG inventory report
CSRD ESRS E1ProductionE1-4 / E1-5 / E1-6 projection, Markdown and PDF export
EU CBAMProductionPer-product rollup, quarterly declaration, verifier handoff
UK CBAMPre-launchSame engine; UK regime support shipping ahead of 2027-01-01

Section 5

Uncertainty as a first-class output

The five-axis pedigree score on each record maps to a per-row GSD via a published lookup. Independent rows propagate variances in quadrature; non-linear aggregations (intensity ratios, percentages of varying denominators) are run through a Monte Carlo with a deterministic, methodology-pinned seed for reproducibility.

Every workspace headline figure carries a 95% confidence interval (lower bound, point estimate, upper bound), surfaced on the cover of the methodology report and on every framework projection. Most platforms hide uncertainty. We don’t. Decisions calibrated against the wrong number are worse than slow decisions.

Section 6

Carbon accountant sign-off

Every published methodology report is signed by a carbon accountant on the Hemera team. They attest that the method is consistent with recognised standards (GHG Protocol, ISO 14064, ISO 14067, the relevant regulatory regime) and that the human-in-the-loop gate on AI-assisted steps is sufficient.

The sign-off snapshot captures the accountant’s credentials at the moment of signing. The historical signature remains valid even if their professional memberships later change, because the snapshot is immutable. The signature log itself is append-only.

Note on terminology: the carbon accountant signing each report has completed ISEP’s TACA (Technical Assessment of Carbon Accounting) training. The wider Hemera team are carbon accountants and specialists.

Section 7

The audit pack

For every published report Hemera generates a locked-format ZIP. It is everything an external verifier needs: on disk, offline, with no Hemera dependency.

File
Contents
manifest.json
SHA-256 of every other file plus expected hash_of_inputs
methodology_report.json
Full versioned schema with calculation traces per headline figure
methodology_report.pdf
Server-rendered, brand-aligned PDF
input_snapshot.json
Canonical snapshot of activity records, factors, overrides
overrides.json
Every typed override with rationale and actor
boundary_decisions.json
Consolidation approach, scope boundaries, framework pin
emission_factors.json
Pinned factor library version (factor_id + version per row)
audit_chain.json
Hash-chained event log; prev_hash linkage walkable end-to-end
version_pins.json
Methodology version, factor library version, engine version
verify_pack.py
Stdlib-only Python verifier, no pip install required

CBAM-regulated workspaces also receive per-product embedded-emissions files in the same pack.

The bundled verify_pack.py is stdlib-only Python. It runs on any machine without pip install. It performs three independent checks:

  1. SHA-256 of every file in the pack against the manifest.
  2. Replay of hash_of_inputsfrom the input snapshot, matching the manifest’s expected hash.
  3. Audit-chain prev_hashlinkage walk: the chain holds end-to-end or it doesn’t.

Exit code 0 prints OK with the format version, artifact id, and hash prefix.

Section 8

What we don’t do (yet)

An honest list. If a buyer asks “does Hemera do X?” and X is below the line, the answer is “not yet” or “not in the next 90 days”.

  • Full SAP, Oracle, NetSuite ERP integrations. They land as customer demand pulls them in. CSV upload + AI utility-bill extraction cover the interim.
  • Direct utility API connectors. Octopus, British Gas, etc. The AI utility-bill extractor (analyst-confirmed before any write) is the path today.
  • Monte Carlo over the supplier graph. Per-row GSD propagates to workspace level today; correlated supplier-graph rollup is research, not a production feature.
  • Abatement cost modelling. What-if reduction scenarios (cut a category, switch a supplier or factor source) are built in and computed against your current inventory, alongside SBTi-aligned targets. We do not yet model time-phased intervention pathways or marginal abatement cost curves.
  • Auditor multi-workspace portfolio view. One workspace at a time today.

Methodology corpus available to clients

30 sections, signed module-by-module by a carbon accountant, pinned per workspace at creation. Bumping a workspace’s version is a restatement event, never a silent change.

Request the corpus →
methodology v1.0-provisional
30 sections · published 2026-05-09