Part 1 of this series asked whether your LCA model makes physical sense. Part 2 asked whether the modelling system that populated it can be trusted at the speed and scale AI now operates. Both assumed the underlying data was sound.

That assumption is the next gate.

This piece is about Data Integrity, the trust check that asks whether the inputs feeding every model are sound enough to support the precision being claimed in the result. And it has to start by naming something most LCA discourse will not.

Almost every conversation about LCA quality eventually arrives at the same complaint. The data isn't good enough.Suppliers don't disclose. Databases are out of date. Primary measurements don't exist where they're needed. Secondary data is generic. The conversation then drifts into either despair (we can't do this properly) or false confidence (we'll use the best available data and hope it holds up).

Both responses are versions of the same mistake. They assume the discipline cannot move forward until the data is good enough.

It can. And it has to. Because the data is not going to become perfect in any timeframe that matters. Supplier disclosure is improving but uneven. Database coverage is wide in some sectors and thin in others, and will stay that way. Primary measurement is expensive and rarely commissioned for upstream tiers. Verification fixes a slice for a period and then the world moves on.

If trust depends on perfect data, trust is permanently postponed. In a regulatory environment where CBAM is live, ESPR is rolling, and DPP requirements are landing, postponement is no longer an option.

The question stops being how do we get perfect data? and becomes a sharper one. How do we run a trustworthy LCA practice on the data we actually have, while the discipline of getting better data catches up?

It is worth saying this clearly, because the data-quality conversation is often framed as if nothing is being done. That is not true.

The standards already mandate primary data where it matters. ISO 14067, EN 15804, GHG Protocol, EPD PCRs; all require primary data for foreground processes and increasingly for high-contribution upstream tiers. The floor is set, even if compliance is uneven.

Consultancy data collection processes have matured. Most credible practitioners run standardised supplier questionnaires, structured data request templates, and document-collection workflows that have iterated over years. The bottleneck is supplier responsiveness, not practitioner discipline.

APIs are emerging at the enterprise tier. Makersite, Ecochain, and others are building bridges into ERP, PLM, and procurement systems so material flows can be pulled rather than chased. This is the most visible scaling lever in the last few years.

Existing operational data structures are being recognised as foundational. BIM in construction. BOM, SOP and routing data in ERP and MRP systems. Logistics tracking platforms. Production-line data. The data is already in the business, the discipline is in connecting LCA practice to data that already exists for non-LCA reasons.

This is real work, done by serious people, and it has moved the field forward. The intent is right. The problem is the gap between intent and execution. Saying we want primary data for every input is the easy part. Actually getting it, for every node, for every project, at the pace the work now has to be delivered; that is the harder part, and it is where most LCA practice gets stuck.

The field's existing good practice was built for a manual era. It works at the pace and project size a human practitioner could sustain. AI-enabled production changes the volume and velocity of the work, and the data discipline has to scale with it. Four additional operating principles describe what that scaling discipline looks like.

Don't fight the perfect-data fight. Accept that data quality varies across inputs, varies across projects, and improves on a trajectory rather than arriving in finished form. The system has to be built to function with the data that exists today and improve as better data arrives. Waiting for perfect inputs has cost the discipline a decade of work that should have been commissioned.

Treat traceability and governance as the discipline. Every input the system uses should be traceable to the source it came from; a supplier sheet, a meter reading, a dataset entry with version and vintage, a published EPD. Not in the methodology section of the final report. At the line-item level, accessible to the practitioner and the verifier on demand. What financial accounting takes for granted is that every number traces to an evidence document. That discipline, a governed chain from input to result that anyone can audit, is what Data Integrity at scale now requires from LCA. We are not borrowing the uncertainty profile. A pound is a pound everywhere; an emission factor is not, and LCA is structurally more contested than finance. We are borrowing the traceability and governance, and we need it more, not less, because our underlying data is more variable.

Use uncertainty as the bridge. The discipline already mandates uncertainty characterisation. The GHG Protocol pedigree matrix exists. ISO 14044 requires sensitivity analysis. EPDs require quality indicators. In practice these are applied intermittently and often conservatively, partly because the field has had to learn how to use them properly. Honest characterisation of uncertainty is the bridge between the data we have and the data we wish we had. Error bars are not weakness. They are the practitioner showing their working. Use uncertainty as your friend, not your apology.

Don't let perfection disrupt process. Most LCA work that should have been commissioned in the last five years was not, because someone in the chain decided the data wasn't good enough yet. This was the wrong call. Imperfect, honestly-characterised, evidence-linked work beats no work, and beats the parallel work being done with hidden assumptions and no traceability. The discipline starts where the data is, documents what it has, and improves on a trajectory that is itself visible.

These four sit on top of the four already established. They don't replace them. They scale them.

Take the carbon fibre composite bracket from Part 2; 480 grams, on a structural assembly. The practitioner needs to model it, which means knowing what is in it.

The customer tells us the bracket is a carbon fibre composite at roughly 25% resin content, but they aren't sure which resin chemistry. That single ambiguity flows downstream into everything. The decomposition Part 2 of this series walked through, splitting the bracket into fibre, resin matrix, moulding process, cure energy, is now operating on an input where one of the two main material fractions is unknown. The fancy decomposition the modelling stage produces is only as good as the data feeding it.

The old approach. The practitioner makes a reasonable assumption, perhaps an epoxy, perhaps a generic thermoset, applies the modelling, and reports a result. The number lands around 14 kg CO₂e per bracket with a pedigree-matrix-derived uncertainty range. The standards have been satisfied. But the assumption sits in the practitioner's working notes, not in the model. The uncertainty range absorbs the resin ambiguity in a single combined score, with no separable trail showing what was actually unknown versus what was confidently known. Six months later, no-one can tell which part of the uncertainty was the resin assumption and which was something else.

The new approach. The same ambiguity is present, but it is handled differently. The customer's incomplete statement; "approximately 25% resin, chemistry unspecified", is logged as the input, with the gap flagged. The pedigree matrix score reflects this honestly: high uncertainty on the resin chemistry, lower uncertainty on the resin fraction, much lower uncertainty on the fibre. The result might be reported as 14 ± 4 kg CO₂e per bracket, with the resin assumption identified as the single largest contributor to the uncertainty range.

Then the practitioner does something the old approach couldn't easily support. They ask the customer to attach the supplier data sheet for the composite. The data sheet arrives, gets parsed into the model, and is linked at the input level. The resin is now identified, say, a bisphenol-A epoxy with a documented cure schedule. The pedigree matrix scores are recalculated. The model is restated automatically. The result might tighten to 14 ± 2 kg CO₂e per bracket, with the documented sheet sitting behind the input for any verifier to inspect.

The same number. A different position. And critically, the journey from "we don't know" to "we know, here is the document" is now visible in the model itself. Future practitioners revisiting the bracket can see exactly where the uncertainty narrowed and why.

So what does this actually change?

For the practitioner, the model is no longer a black box six months after delivery. When the supplier provides the data sheet, when better dataset entries become available, when a primary measurement is commissioned, the affected nodes can be restated and the difference shown. Models stop being one-off deliverables. They become living assets.

For the verifier, every line can be audited on demand without a phone call. The data picture is inspectable, the uncertainty is traceable to its actual cause, and the practitioner's judgement is recorded. Verification time drops because the evidence chain is already in the model rather than scattered across emails and spreadsheets.

For the buyer commissioning the work, the number on the report is no longer a single point. It is a position the practitioner can defend in a stakeholder meeting, restate when conditions change, and improve on a known trajectory. The result becomes evidence in a regulatory submission rather than a snapshot that ages out within a year. And the buyer can now see exactly which data gaps in their own supply chain are driving uncertainty, making it actionable.

For the consumer scanning a Digital Product Passport, and this is where it really lands, the carbon number on a product comes with a verifiable chain back to the data behind it. Not "we estimate 14 kg CO₂e" but 14 kg CO₂e, sources inspectable, uncertainty characterised, last reviewed [date], restateable when better data exists. A consumer making a purchasing decision can trust the number because the trust system is visible behind it. A regulator enforcing disclosure can audit the number because the trail exists. The DPP becomes credible because the data layer underneath it is governed.

The pedigree matrix is not the failure here. The lack of governance behind the pedigree matrix is. Honest uncertainty characterisation is already mandated by the standards. The community has been learning how to apply it for a decade, sometimes well, sometimes intermittently, sometimes too conservatively. None of that is a reason to abandon it. It is a reason to make every uncertainty score inspectable, traceable to its cause, and improvable as the underlying data improves. The next decade's work can compound rather than start over.

The documentation overlay was, until recently, infeasible to operate at scale. A practitioner building a model by hand could not realistically attach a referenced evidence document to every line of every node and still finish the project on budget. The discipline existed in principle and broke down in practice.

That is what has changed. AI-enabled production attaches evidence references as part of the production cycle itself, not as a separate documentation task done afterwards. Every match the system makes carries the source it matched against. Every supplier input the system processes is linked back to the document it came from. Every pedigree matrix score is calculated against the source's own quality indicators and logged with the reasoning. The documentation overlay is not added to the model. It is part of the model from the moment the model is built.

The practitioner's role shifts. They are not entering source references by hand. They are auditing the references the system attached, checking that the data quality characterisation is honest, flagging where a source is too thin to support the precision being claimed, and signing off the overall data picture as fairly representing what the model rests on. The same human judgement, applied at a different point in the production cycle.

This is what makes Data Integrity newly achievable at scale. Not because AI knows what good data looks like, it doesn't, and it doesn't have to. Because AI removes the marginal cost of documenting every input, every source, every uncertainty, at the granularity the discipline has always needed but could never economically deliver.

For anyone commissioning or relying on an LCA, the question at this gate is no longer how good is your data? That question has no useful answer in isolation, because good is contextual and data is not a single thing. The question is sharper:

Can you show me, for any line in this model, the source the number came from, the uncertainty characterised against that source, and the audit trail of how the data has been documented?

Three things to look for.

Evidence linking at the line level. Not a methodology paragraph in the report. A live, inspectable reference for every input, accessible to anyone auditing the model. If the evidence layer doesn't exist, the data picture cannot be audited.

Uncertainty reported, not hidden. A result that arrives with no uncertainty range is reporting a precision the data cannot support. A result that arrives with a characterised range is reporting honestly. The presence of error bars is a trust signal, not a credibility risk.

A continuous improvement trajectory. The data picture six months from now should be better than the data picture today, and the system should be capable of restating prior models when better inputs become available. If the data picture is treated as final at the point of first publication, the practice is not honestly characterising what it knows.

If these three are in place, the speed and scale of AI-enabled LCA is a foundation the discipline can build on. If they are missing, the speed is amplifying the documentation gap that has always limited the field.

Data Integrity sits above Modelling Integrity in the trust stack. A well-modelled system built on poorly-documented data is not a trustworthy model. A well-modelled system built on honestly-documented, uncertainty-characterised data is. The difference is not always in the numbers. The difference is in whether the work can be audited and improved.

The next and final part of this series tackles Outcome Integrity; whether the results, once produced, can actually be used for the decision they were commissioned to support.

If you want to talk through what evidence-linked LCA data looks like in practice, or how to commission work that meets this standard, that's what we do at LCA Factory.

— Roger