Circular economy

Circular Economy Software Engineering

Life cycle assessment data, EPR reporting and material flow systems built to survive an audit.

We build the software behind circularity programmes: life cycle assessment data models, versioned emission factor management, Extended Producer Responsibility reporting automation and material flow tracking. The defining requirement is audit-grade lineage — every published figure must be traceable to the source record that produced it.

The problem this solves

Circularity programmes almost always begin in spreadsheets, and for the first report that is entirely reasonable. The problem arrives two years later, when there are forty spreadsheets, three inconsistent emission factor sets, no version history, and an auditor asking how a specific published number was derived. Nobody can answer, because the calculation existed in a formula that has since been edited.

The engineering response is not exotic. It is disciplined data engineering applied to a domain with unusually strict evidence requirements: modelled activity data, emission factor sets treated as versioned dated artefacts, calculations expressed as tested code rather than spreadsheet formulas, and immutable records that let anyone reconstruct exactly how a figure was produced years after the fact.

What we build

  • Life cycle assessment data models aligned to ISO 14040 and ISO 14044 concepts
  • Emission factor management with explicit versioning, dating and provenance
  • EPR reporting automation across differing national scheme requirements
  • Material flow and mass balance modelling with reconciliation
  • Scope 3 calculation pipelines with documented methodology and disclosed uncertainty
  • Audit lineage: immutable calculation records traceable to source data
  • Supplier data collection with validation and explicit proxy handling

How we approach it

  1. Model activity data first

    Before any calculation, we model what actually happened — quantities, materials, movements. Most reporting problems are activity data problems wearing a calculation costume.

  2. Version the factors

    Emission factor sets become dated, versioned artefacts with recorded provenance. This single change is what makes historical figures reproducible.

  3. Express calculations as tested code

    Methodology moves out of spreadsheets into version-controlled, tested transformations, so a change to a method is reviewable and its effect is measurable.

  4. Record lineage immutably

    Every published figure stores the inputs and factor versions that produced it. Re-running the pipeline is not evidence; the stored record is.

  5. Handle gaps honestly

    Missing supplier data gets a documented proxy methodology and a disclosed uncertainty range, never a silent estimate that later looks like a measurement.

Frequently asked questions

What does circular economy software actually do?

It manages the data behind circularity and sustainability reporting: activity data, life cycle assessment models, versioned emission factors, EPR submissions, material flows, and the lineage that allows any published figure to be traced back to its source.

Why not use an off-the-shelf sustainability platform?

Many organisations should, especially early on. Custom engineering becomes worthwhile when you need product-level granularity, unusual material flows, deep integration with internal systems, or evidence-grade lineage that a general tool does not provide.

What makes this different from ordinary data engineering?

The audit requirement. A figure published today may be challenged in three years, and you must be able to reconstruct the exact calculation, inputs and factor versions used. That constraint drives immutability and versioning decisions throughout the architecture.

How do you handle missing supplier data?

With a documented proxy methodology and a disclosed uncertainty range, recorded as such. The failure mode we design against is a proxy value that silently becomes indistinguishable from measured data in a later report.

How does this connect to Digital Product Passports?

Directly. Passports increasingly require product-level environmental data, and that data comes from exactly these pipelines. Organisations facing ESPR obligations usually need both capabilities, and building them separately duplicates work.