Skip to main content
Every emission value in a Real-Time LCA project is traceable to a specific source — a verified EPD, a generic dataset, or an explicit user assumption. This page explains how the platform records that provenance, how data is versioned over time, and how reports produced today remain reproducible when the underlying data changes.

​
Provenance per material mapping

Each row in the Building Component Inventory is linked to exactly one of:
  • A verified EPD — published by an EN 15804-compliant programme operator (see EN 15804+A2 for the list of supported programmes).
  • A generic dataset — non-product-specific average data maintained inside Real-Time LCA.
  • A custom material — user-defined, either as a verified EPD upload by the tenant or as a non-verified assumption.
The Building Component Inventory and the project’s Material Mapping view show which of these is in use for each inventory item, so an auditor can trace any calculated emission back to its source in a single click. See Browse materials and Material mapping in the project dashboard for the platform views.

​
Alignment with EN 15941

EN 15941 sets out data-quality and data-exchange requirements for construction-product environmental data. Real-Time LCA’s datasource layer follows EN 15941 principles in:
  • Programme transparency — every linked EPD records its programme operator and verification status.
  • Temporal coverage — issue and expiry dates are stored per EPD.
  • Geographical coverage — the EPD’s declared geography is preserved and surfaced to users selecting between alternatives.
  • Technological coverage — EPDs declare the technology they represent (e.g. average vs. specific-process), and this is filterable in the material library.

​
Versioning of EPD data

EPDs are revised over their five-year typical validity window. Real-Time LCA stores each EPD as a versioned record:
  • Active version — the version currently selectable for new material mappings.
  • Superseded versions — older versions retained for reproducibility of past reports.
When a project links to an EPD, the link captures the specific version of that EPD at link time. Subsequent EPD revisions do not silently re-write the project’s emissions; the project keeps using the version it was originally linked to until a user explicitly upgrades the mapping.

​
Reproducibility of historical reports

A report generated and locked in Real-Time LCA carries:
  • The version of every EPD or generic dataset used in the calculation.
  • The default factors in effect at calculation time (transport, waste, end-of-life — see Assumptions and defaults).
  • The calculation type and threshold values in effect at calculation time.
If any of those inputs change in the platform after the report is produced (an EPD is updated, a default factor is revised, a regulator changes a threshold), the historical report continues to reflect the inputs as they were when it was generated. Re-running the calculation against current inputs produces a separate, dated report.

​
EPD expiry handling

EPDs typically expire 5 years after issue. The issue and expiry dates are stored per EPD and are visible in the material library. Users are responsible for reviewing EPD validity before finalising a report — an expired EPD may no longer reflect current manufacturing data or meet regulatory requirements. Past reports that were built with an EPD that has since expired continue to reference the version that was linked at the time the report was produced, so historical results remain reproducible regardless of subsequent expiry.

​
Limitations

  • Data-quality flags (DQR scores) per EPD are not currently surfaced uniformly across all datasources — work to align this with the EN 15941 DQR framework is ongoing.
  • For generic datasets, the underlying methodology document and reference year are recorded; granular per-process data-quality scores are not.
  • Tenant-private EPDs uploaded by an organisation are versioned the same as public EPDs but are visible only within the uploading tenant.