The first of four pieces on what trust in AI-enabled LCA actually requires.

When buyers commission an LCA, the question they ask is can I trust the number? It's the right question, asked at the wrong layer.

A headline carbon figure is the top of a stack. Beneath it sits emission factor selection, beneath that sits the input data, and beneath all of those sits the most fundamental layer; whether the modelled system has been defined and constructed in a way that obeys physics. Most discussions about LCA quality skip past this layer and start at the data. That's like signing off the inspection report without inspecting the part.

The AI conversation has, helpfully, forced the question out into the open. If AI is producing parts of an LCA, what exactly are we trusting, and how would we check it? The answer is the same answer it's always been, the four checks haven't changed. What's changed is the production system underneath, and the discipline now needed to make those checks visible at the right gates.

This is the first piece in a four-part series on what trust in AI-enabled LCA actually requires. We start with the most fundamental layer: the physical system itself.

There is a question I get asked constantly: how can you trust an LCA produced with AI?

The question is shaped wrongly. It assumes that trust in AI-enabled work depends on trusting the AI itself, that the path to confidence runs through validating the model, auditing the training, evaluating the system. That work matters. We run evaluation layers as a redundancy on the AI itself, and quality assurance (QA) of the production system should continue to develop. But QA of the system has never been where production trust ultimately comes from. It works alongside something else, not instead of it.

Production systems earn trust through quality control (QC) of the artefact at the gates that matter, with the inspection regime stratified by what matters most. An aircraft is not trusted because someone made a single decision about whether to trust the production line. It is trusted because the line is audited, every flight-critical component is inspected at defined gates, less critical components are sampled or covered by certified supplier processes, and the inspection regime itself is stratified by stakes. QA and QC working together. Practitioner judgement deciding where rigour applies most heavily.

AI-enabled LCA works the same way. The AI produces an artefact, a defined system, a populated model, a calculated result, together with a log of how it got there. The practitioner's job is to set the gates, audit both the artefact and the reasoning trail, and reject anything that does not pass. The AI's job is to produce work that is checkable. How that checking actually works in practice, what the artefact and the reasoning trail look like, and how a practitioner audits both, is the subject of Part 2.

That reframes the question. Trust in AI-enabled LCA is not a question about AI. It is a question about whether QA and QC are genuinely in place, whether the gates exist, whether they are rigorous, and whether the practitioner has the framework to decide where rigour applies most heavily.

That framework currently has four gates in our system. They correspond to four orthogonal ways an LCA can be wrong. An LCA that passes all four can reasonably be called trustworthy. One that passes three and fails one is not. We refine the framework as practice and the standards landscape evolve.

This series walks through them in order, starting with the most fundamental: the physical system itself.

If trust lives in the artefact, and the practitioner's job is to check it at the right gates, the practical question becomes obvious. What are the gates?

There are four, because there are four orthogonal ways an LCA can be wrong. Each gate addresses one. An LCA that passes all four can reasonably be called trustworthy. An LCA that passes three and fails one is not.

System Integrity — does the modelled system make physical sense? This is the most fundamental gate. It covers the act of defining the system in the first place; the boundary, the functional unit, the included flows, the allocation rules, and then checks whether the system as defined is complete and whether it obeys the laws of physics. Scoping decisions live here. So does mass, energy, and biogenic carbon balance. Both are physical statements about what the model represents.

Emissions Integrity — are the emission factors and impact methods correctly chosen, traceable, and scientifically defensible? Are the right datasets being used, mapped to the right flows, with the right scope and unit conventions?

Data Integrity — is the underlying input data sound, current, complete, and traceable? Where is each number from, when was it collected, how representative is it of the actual product or process?

Outcome Integrity — can the results actually be used for the decision they were commissioned to support? Are uncertainty and sensitivity properly characterised? Is the result comparable, defensible, fit for the intended purpose?

Each gate catches a different class of failure. A model can balance perfectly and still use the wrong emission factors. The right factors applied to bad data still produce bad results. Sound results that don't address the buyer's actual question are still useless. All four gates have to hold.

This series walks through them in order. We start with System Integrity, because everything else is built on top of it.

System Integrity asks three questions of any LCA, in this order.

Have we defined the right system? This is the scoping question. It is the most consequential decision a practitioner makes, and it cannot be made without first answering two prior questions: what is the goal of this study, and who is the intended audience for the result?

The same product can be legitimately scoped three different ways for three different purposes; a construction EPD to EN 15804, a CBAM declaration, an internal procurement comparison. Same product, different goals, different audiences, different correct scopes. Scoping decisions only make sense in the context of what the LCA is for and who will use it. Inside that context, the practitioner declares the functional unit, the boundary, the included and excluded flows, the allocation rules where allocation is needed. Get this wrong and everything downstream is the right answer to the wrong question.

Have we drawn the system completely? This is the completeness question. Within the boundary we have set, have all the relevant material, energy, and emission flows been included? A model can be scoped correctly and still be wrong because flows that should have been there were missed.

Does the system behave? This is the closure question. The defined and populated system has to obey conservation laws. Mass in equals mass out. Energy in equals energy out. Carbon in equals carbon out. If the books don't close within tolerance, the model is physically invalid.

Three checks. All three have to hold. The next three sections take them in order.

Scoping is where most LCA work goes wrong, and it goes wrong before a single calculation has been made. The error is almost never in the maths. It's in the question.

A practitioner cannot scope a study until two things are clear. What is this LCA for? And who will use the result? A whole-life carbon assessment for a building tender under EN 15978 has a different functional unit, system boundary, and module set from a product carbon footprint for a CBAM filing. Both can be correct. Neither can substitute for the other.

This is where practitioner judgement is most visible and least replaceable. AI can propose candidate scopes against a stated goal, flag inconsistencies, compare against standards, draft the scope statement. What AI does not do is decide what the goal of the study should be, given the buyer's actual commercial decision. That requires context, conversation, and a willingness to push back on the buyer's first articulation of what they want.

Inside that context, scoping becomes a series of physical declarations: the functional unit, the system boundary, the allocation rules, the cut-off criteria. These declarations are the system. They're not a prelude to it.

A buyer who wants to know whether their LCA can be trusted should start by asking to see the scope statement.

A scope can be defined correctly and the model can still be wrong, because flows that should have been included weren't. Completeness is the second physical check.

Within the declared boundary, every relevant input and output has to be in the model: material flows, energy carriers, emissions sources, waste streams, ancillary inputs. The dangerous failure mode is a perfectly closed model of an incomplete system. The maths works. The answer is wrong.

There's no automatic test for completeness. It depends on practitioner judgement against a defined boundary, which is why the boundary needs to be defended explicitly. AI can populate flows quickly and flag obvious omissions against reference systems. The practitioner has to confirm that the populated system actually matches the real one.

Once the system is scoped and populated, it has to obey conservation laws.

Mass closes. Energy closes. Carbon closes — and increasingly, carbon closure has to be resolved by source. Biogenic and fossil carbon need to be tracked separately. Primary energy demand is now an explicit reporting requirement under updated EPD standards. Where the books don't close within tolerance, something is wrong: a missing flow, a unit error, a double count, a misattributed source.

A model that closes proves nothing about whether it's the right model. A model that doesn't close proves it isn't physically valid. Closure is necessary, not sufficient — but without it, nothing else matters.

This is where AI-enabled production materially changes what's possible. Closure that was occasional and manual becomes continuous and visible, checked at every iteration, across every flow, with tolerances declared.

System Integrity has always been the standard for serious LCA work. The problem has never been that practitioners didn't know what to check. The problem has been that doing all of these checks rigorously, on every iteration of every model, has been prohibitively expensive; which is why most LCA work has historically run them once at the end, if at all.

Here is what actually happens in an AI-enabled production cycle.

The practitioner provides the inputs the work needs: bill of materials, production information, supplier data, the contextual text describing what is being modelled and what it is for. The AI parses that input, makes the best judgement it can against it, and runs the production work ;proposing the scope, populating the model, executing the calculations.

Two things come out at the other end. The first is the artefacts themselves: the scope statement, the populated model, the closure figures, the calculated result. The second is the log, the reasoning trail showing how the AI got there. Which inputs it used, which assumptions it made, which alternatives it considered and why it chose what it chose. Both are produced together.

The artefacts arrive at known gates. At each gate, the practitioner can audit two things: the artefact itself (does the answer hold up?) and the reasoning trail (was the path to the answer sound?). A closure check that fails surfaces the gap as an exception. A scope statement that conflicts with the declared regulatory context flags itself for review. A flow that should be in the model but isn't is marked for practitioner attention.

The practitioner does what only the practitioner can do — interrogate the goal, decide whether a flagged gap is a real problem or a legitimate exception, sign off the work with a logged justification. The audit trail captures every decision: what the AI proposed, what the practitioner approved or overrode, why. The result is a model that is not just calculated but defensible; every step traceable, every judgement visible, every gate checkable.

This is what trust in AI-enabled LCA actually looks like at this layer. Not faith in the AI. Production discipline made visible, practitioner judgement applied where it matters, AI doing the work that previously made rigour at scale impossible, and the audit trail proving both.

For buyers commissioning LCA work, System Integrity is the first question to ask, before any discussion of emission factors, data quality, or results.

Three things to look for in any LCA you commission or rely on:

Practitioners producing this routinely are doing serious LCA. Practitioners who can't are doing something else.

System Integrity is the foundation of trust in any LCA, AI-enabled or not. The next three layers, Emissions Integrity, Data Integrity, Outcome Integrity, sit on top of it. Get this layer wrong and everything above it is built on sand.

The next piece in this series will tackle layer two: Emissions Integrity, and the question of whether the right impact factors and methods are being applied to the right flows.

If you want to talk through what good looks like for the LCA work you're commissioning, that's what we do at LCA Factory.

— Roger