More Light Doesn't Mean Better Navigation: The Case of Mandatory EPDs
The shortest night of the year was last night. We’ve just passed the solstice - up here, the middle of the weeks with no stars at all, the sky never dark enough to see the points you’d navigate by. EPDs are at their own turning point: voluntary is becoming mandatory, and a flood of data is close behind. The concern is simple. More light does not mean better navigation.
Mandatory EPDs are arriving across the EU: environmental product declarations are moving from something manufacturers chose to do into something they will have to do. The Construction Products Regulation (CPR) is pulling environmental data into the mandatory column. The Digital Product Passport will eventually carry that data into every layer of the supply chain. On paper this reads like progress: more declarations, more transparency, more pressure toward lower-impact products.
I am not convinced it is progress yet. Not because the direction is wrong, but because of what usually happens when something becomes mandatory.
What mandatory does to quality
When an activity is voluntary, the people doing it mostly want to. That self-selection quietly protects quality. The manufacturers and consultants producing EPDs in the voluntary phase were, on average, the ones who cared about the result.
Mandatory changes the incentive. Once everyone has to produce an EPD, little in the system prevents business-as-usual quality from settling at the lowest acceptable bar. Not because people are careless, but because nothing in the system rewards going past the requirement. Demand becomes mandated. Quality stays invisible. And when the buyer cannot see quality, market stops paying for it.
There is a name for this pattern. When quality is hidden and buyers cannot tell good from bad, the better work tends to get driven out, because there is little reason to pay a premium for quality no one can verify. That is the trap EPDs are walking into. Mandated demand, with no shared way to see whether the data underneath is any good.
So the real risk of mandatory EPDs is not that they fail. It is that they succeed on paper. We end up with large volume of data, a large amount of bureaucracy, and very little of it actually moving anyone toward lower impact.
If we want to avoid that, we have to be honest about why the system is not currently built to protect quality.
Most of the people holding the data cannot judge it
Start with a quiet but serious problem. The average EPD owner and the average material specifier do not understand the quality of the EPDs they hold and use.
This is not true everywhere, and not in every case. There are excellent manufacturers and sharp specifiers. But on average, the manufacturer whose name sits on the declaration often cannot independently tell whether it is solid, and the specifier comparing two EPDs often cannot tell whether the comparison is even valid. The people carrying the liability and making decisions on the data are often among the least equipped in the chain to assess it.
Quality cannot be protected by people who cannot see it.
The standard exists. Consistent data collection does not.
Underneath the declaration sits the data collection, and this is where the real inconsistency lives. Standard does describe how inventory data should be gathered. The problem is what happens in practice, where almost every organisation does it differently.
For most manufacturers, developing an EPD is the first time they have ever had to gather this kind of data in this format. It is not a routine process they already run. It is something they assemble, often for the first time, because a declaration now requires it. In my own consultancy work it is not unusual for a manufacturer to arrive with two plausible numbers for the same input, and for the real task to be helping them decide which one makes more sense to use. The baseline is not clean, systematic data. The baseline is a best effort under a new requirement.
There are also no common templates tied directly to the cPCRs, so each consultant brings their own. A handful of companies have started to work on this problem, but the underlying issue remains: the way the data was collected is rarely written down.
That matters more than it sounds. An EPD is valid for five years. When it expires and has to be redone, the person who gathered the original data may have moved on. Sometimes it is the same person, but they never recorded how they did it. Either way, the manufacturer often ends up with a different result the second time, with no clear explanation for the change.
And here is the part that should worry whole industry. Quite often the new number is the more accurate one, because the second time the processes were covered more comprehensively. So the manufacturer who does the more thorough job gets the worse-looking result. Better work, higher impact on paper. As long as that holds, we are quietly punishing the exact behaviour we say we want.
Pre-verified tools are today’s security blanket
The verifier, in the end, has to believe that the data is correct. The closest the industry has come to that kind of security is pre-verified tools and some EPD generators, and they do real work. The issue is usually not that the LCA modelling choices inside them are wrong. More often, the issue is that those choices are not transparent. You are trusting an output without being able to inspect the reasoning behind it.
That same trust is what makes the next problem serious. If there is a mistake in the model behind the tool, it does not stay contained in one EPD. It is repeated in every EPD the tool produces. A mistake in an individually modelled declaration affects one product, and a reviewer looking at that single document has a chance of catching it. A mistake inside a pre-verified tool is reproduced across an entire product category at once, and the very thing meant to make the tool safe, its pre-verified status, is what stops anyone from looking again. Because the tool is pre-verified, scrutiny of the number tends to fall away.
The scale is the danger. One flawed assumption no longer affects one EPD. It quietly shifts the reported impact of every product run through that tool, which means it can distort the comparison between products across a whole category, and the procurement decisions made on those comparisons. And because the error is now spread across many published declarations, correcting it is not a single fix. It means reissuing all of them, which the industry has almost no process for. So the mistake tends to stay where it is.
None of this means pre-verified tools are usually wrong. Many produce perfectly sound results. The point is narrower: when a flaw is present, pre-verification does not shrink it, it scales it, and hides it behind the very status meant to make the tool safe.
There is a second, quieter issue, and it is about trust rather than error. A lot of what happens inside a pre-verified tool runs on trust. Just as a verifier has to trust that nothing was altered in the parts of the background report they did not rebuild, they have to trust that the tool was used exactly as its pre-verified status assumes. Not every programme operator runs a system rigid enough to close off the room for that. I am not suggesting everyone sets out to manipulate the result. But where it is easy to bend the inputs, it will happen with at least some manufacturers or consultants.
Digital data is an opportunity, but the order matters
The Digital Product Passport is where a lot of hope is being placed, and the opportunity is real. But digital data also hides a trap that standardisation has to close first.
Here is the trap. An EPD is already a compression. The real work sits in the background report, which often runs to seventy or a hundred pages, and the EPD itself is only a summary of it. A digital system then compresses that summary again, down to a series of numbers that can be sorted and compared automatically. Each step strips away context. And context is exactly what tells you whether two products can be compared at all: what was included, what was assumed, where the boundaries were drawn. By the time you are looking at two numbers side by side, most of the information needed to know whether that comparison is even valid has been left behind. The numbers look comparable. Whether they actually are is a question the digital format no longer puts in front of you.
There is a second illusion sitting underneath the first. In principle, comparability is supposed to be guaranteed by the rules themselves. Product category rules exist for exactly this reason, and the product-specific part of them, the cPCR, is meant to ensure that products in the same category are calculated the same way and can be compared. In practice, that guarantee leaks. Different programme operators publish different cPCRs for what is essentially the same product category. Different markets run on different cPCRs again. I have seen programme operators’ PCRs grant exceptions that override the EPD standards. So two EPDs can both be valid, both verified, and still rest on rules that do not fully agree with each other. Market often treats EPD data as far more comparable than it really is.
I am not against digitisation. Coming from Estonia, where digital infrastructure is close to second nature, I see real value in digital data. But digital only pays off when it sits on systematic investment in the layers beneath it, and there is no central body guarding that this happens. There is also a shift worth naming. With AI, we can now read and process data in non-digital, unstructured formats quickly - which inevitably reduces the urgency of digitisation as an end in itself. The end point can be digital, but if the system underneath it is not, the win from that single digital output is small. It is the infrastructure, not the format of the final number, that makes digital worthwhile.
So the order is what matters. Fix the rules and the systems that feed them first, and a digital layer turns good data into something genuinely useful. Put the digital layer first, and all we have done is make unreliable numbers easier to compare.
We treat the published EPD as the end. It should not be.
Once an EPD is published, it tends to be treated as final. But there is no industry-standard process for fixing a mistake in a published EPD. There have been attempts, but no market standard for going back and correcting the data.
So in practice, mistakes only get fixed when someone downstream cares enough about a specific number to push. More often than not, that someone is a competitor who lost a bid. That is not a quality mechanism. It is an accident that occasionally produces a correction.
And here is the part that worries me most. When people do take quality seriously, the energy too often goes into the wrong place. Instead of a constructive correction, it becomes finger-pointing - or marketing, where a weakness in someone else’s EPD becomes a competitive talking point rather than a fix. Even the people who care end up feeding the blame cycle instead of the repair process, because the repair process does not really exist.
A mature system would treat a published EPD the way good engineering treats any published figure: as something that can be questioned, checked, and corrected through a known process. We are not there.
What this looks like in the data
Some context for how widespread this is. Of the EPDs we have reviewed at Lodestellar, effectively all have contained at least one error, and roughly half have contained an error serious enough to potentially affect the declared result - though we often cannot confirm the severity without the background report.
That is not a statement about bad actors. It is a statement about a system that was never built to catch these things before they reach the market.
What would actually move quality
The fix is not more rules layered on top of a foundation nobody can see. It is making quality legible. Two things have to happen together.
Tools have to exist that let anyone in the chain check the quality of an EPD they have been handed, not only the specialists who built it. And the market has to be educated enough to want that check in the first place. Without accessible tools and a more EPD-literate market, average quality of EPDs stays exactly where it is, mandatory or not.
But there is a catch in who provides those tools. Some programme operators and tool providers have started adding quality layers of their own, and some verifiers have built internal checking tools. That is a good sign. The problem is that a check is only as trustworthy as its independence. A tool provider checking output from its own tool is grading its own work. A programme operator checking EPDs inside its own programme has a stake in the result. And a verifier, however careful, is working under real time pressure, which is its own kind of constraint on how deeply anything gets checked. None of these parties is fully independent of the thing being checked. So none of them can be the whole answer. For a quality layer to mean much, at least part of it has to come from outside, from providers with no stake in the result.
This is the gap I built Lodestellar to work on. Not to replace verifiers, and not to make an EPD automatically compliant, but to make the quality of the data visible to the people who carry the risk and make the decisions - a fixed point to steer by. That is one example of the kind of quality layer the market is missing. There will need to be more.
What I would ask you to do
If you take one thing from this, let it be this. Do not wait for the regulation to define your floor.
If you are a manufacturer, ask your consultant and your programme operator harder questions about the quality of your data, because your name is on the declaration. If you specify materials, treat EPD quality as something to be checked, not assumed. And if you work anywhere in this chain, push the response to a quality problem toward correction rather than blame.
Mandatory EPDs are coming either way. Whether they actually lower impact, or just generate paperwork, depends on whether the industry decides that quality matters before the market decides it does not.
Related reading