What Makes an EPD “Digital” and Why It Matters

Everyone agrees EPDs should be digital. The disagreement is about what that actually means, and the answer comes down to one thing: whether there is a schema underneath.

The term “digital EPD” gets used loosely. While mostly everyone agrees that the EPDs should be digital, there is a lot of disagreement of what a truly digital EPD entails. There are really four rungs on the ladder.

1. A PDF. A document.
2. A PDF plus a web landing page. Findable, still not readable by software.
3. A structured record. Machine-readable fields with stable identifiers.
4. Served, versioned, queryable data. It enables API access, update propagation, downstream subscription.

Most of the market sits on the first two rungs. Only the top one delivers what the term promises: discoverability, reliability, usability.

What separates the bottom of that ladder from the top is not the file format. It is whether there is a schema underneath: an agreed structure that says this number is GWP-total, in kg CO₂ eq, for modules A1–A3, measured against this declared unit, produced with this software in this data year. Without a schema, an EPD is free-flowing data summary that a person has to read and retype. With the schema, it is the data product.

EPDs are already consumed digitally

Nearly every downstream use of an EPD already reads data, not pages. EC3 and procurement platforms aggregate declarations to compare products by embodied carbon. Whole-building LCA tools pull EPDs automatically to calculate project-level impacts. BIM models link materials to their declarations. Agencies that implement Buy Clean policies pull EPD data directly into their databases to inform procurement decisions. Under LEED v5, embodied carbon quantification entails multiplication of GWP per declared unit out of every EPD by the specified material quantity for hundreds of items — digitization makes this effort streamlined and reliable.

Considering already well established pathways for digital EPD uses, they should be also be created, verified, and transferred digitally. Where this isn’t the case, the gap gets filled by hand and the value of EPDs leaks out.

What the PDF-only actually costs

A PDF is genuinely good at one thing: presenting results to a human reader, with the context, caveats, and interpretation that make them meaningful. The problem isn’t the PDF. The problem is the PDF being the only artifact: the place the data lives rather than the place it is displayed. When there is no schema underneath it:

• Every hand-typed value is a chance for a transcription error
• Multiple PDF versions can circulate without a single source of truth
• Changes after publication can’t be tracked or audited reliably
• A verifier has to read every field by hand and the review queue grows linearly with the number of EPDs
• Two products in the same category can’t be compared without someone opening both documents and lining up the tables
• The declaration is harder to find in the first place: specifiers and procurement teams search registries against structured fields, so an EPD without them never surfaces in the search. An EPD only counts where it can be found.
• Nobody can query the data, so the insights sitting inside it are never collected.

The alternative: a record with a schema underneath

A digital EPD carries the same information the PDF does. What changes is that every value sits in a named field with a defined unit and a defined meaning, agreed in advance by everyone who will read it.

What the structure lets you do

Publish once, appear everywhere. A verified record moves directly into EC3, procurement databases, whole-building LCA tools, and BIM models. Nobody re-keys a value, so nobody introduces an error.

Update once, and let it propagate. Background datasets get refreshed and PCRs get revised. A versioned record can be reissued under the same identifier, and downstream references follow it instead of quietly going stale.

Scale from one product to a portfolio. When every EPD is bespoke, the hundredth product costs roughly what the first one did. When the structure is fixed, consistency across hundreds of SKUs is the default.

Verify by exception. When requirements from PCRs and underlying standards are encoded as machine-checkable constraints, the routine failures (e.g. a missing indicator, a unit that doesn’t match the declared unit, a reversed sign convention on biogenic carbon) get flagged early. Verifiers spend their time on judgment instead of arithmetic and checking boxes.

From data to insights. Which products sit above the category average? Which declarations expire next quarter? Which facility drives A1–A3 across the portfolio? These are ordinary queries against structured records, and they are unanswerable against a folder of PDFs.

Stay comparable. Same fields, same units, same module breakdown — a structure facilitates informed comparisons.

The PDF is still valuable and should be developed and used for marketing, context, caveats, interpretation. It just stops being the key data artifact.

A shared language, built in the open

Structure only pays off if everyone agrees on it. That is why Smart EPD joined the steering group for the Product Transparency schemas, the open, cross-sector schemas introduced by Building Transparency and product impact by ERG alongside BuiltCold, C.Scale, and Sustainable Minds. They are designed to work with existing schemas including ILCD+EPD, openEPD, and PACT, so data flows seamlessly between the systems.

Governance matters as much as format. A schema maintained by a small group inevitably reflects its blind spots, and when the people implementing it have no way to identify and address the edge cases, the market invents workarounds. Open review, public meetings, and a real contribution path let implementation experience feed back into the schema. This is how a format evolves into the infrastructure the whole ecosystem can build upon.

Where we stand

Smart EPD publishes every EPD in digital format.

In practice that means every declaration we publish is available as structured data and moves into EC3 and other downstream tools without anyone retyping a value. When a manufacturer updates a declaration, the record is versioned rather than overwritten, so a specifier who referenced it last quarter can see exactly what changed. And because the requirements are encoded rather than remembered, the same checks run on every EPD.

For a manufacturer, the practical difference is this: your numbers show up where buyers are actually looking and they stay current as your products and your data change.

Questions about how we can support your verification and disclosure pathway? That’s the conversation we’re here for at sales@smartepd.com.