Skip to main content

Tool Verification & Constraints

EPD tools (sometimes called generators or models) let a manufacturer produce many product-specific declarations from one verified modeling setup instead of commissioning a full, independent LCA study for every product. That efficiency is only trustworthy if the tool itself has been verified and if every declaration it emits stays inside the boundaries that verification established. Constraints are the mechanism that holds declarations inside those boundaries.

This page explains why EPD tools are verified, the two-part verification model the industry has converged on, and how Smart EPD's constraint envelope operationalizes that model — from both the LCA side and the Smart EPD verification side. It then covers the two topics that make tool verification scale: statistics (outlier detection) and AI gating (advisory, human-in-the-loop review).

This page is the "why"; the mechanics live elsewhere

The concrete mechanics of constraints — the range / statistical / formula (and other) types, severities, and conditional application — are documented in EPD Templating and Reference EPDs & Constraints. This page is the conceptual layer above them: it explains what tool verification is and why constraints are the load-bearing part of it. It links out for the field-level detail rather than repeating it.

Why EPD tools are verified​

A traditional EPD is the output of a bespoke LCA study, reviewed end-to-end by an independent verifier. That does not scale to a manufacturer with hundreds of mix designs or plant configurations — verifying each one from scratch would be slow and expensive. An EPD tool solves this by encoding the LCA model, background data, manufacturing facilities, and reporting logic once, so individual products can be declared by supplying only their product-specific inputs.

The risk this introduces is obvious: if the tool is wrong, every EPD it produces is wrong, at scale. The industry's answer is to move the verification effort up a level — verify the tool (and the model behind it) rigorously one time, then allow individual declarations produced within the tool's verified scope to follow a much lighter path. Industry guidance is explicit that an unverified tool is not an acceptable basis for an EPD at all.

This pattern is most mature in a few categories — concrete and asphalt — because both are high-volume, plant- and mix-specific, and therefore poorly served by one-EPD-at-a-time verification:

  • Asphalt — NAPA's Emerald Eco-Label is a verified EPD tool for asphalt mixtures. The tool and its underlying LCA are third-party verified, after which producers publish mix-specific, plant-specific EPDs from it.
  • Concrete — verified concrete EPD generators (e.g. the NRMCA-compliant One Click LCA generator, the GCCA EPD Tool) pre-verify the tool's data and calculation method so that per-product and per-plant declarations are dramatically faster to verify — in some programs cutting third-party verification effort by roughly half.

In Smart EPD terms, an EPD Tool (Model) is owned by a tool-provider organization; the underlying LCA software or LCA Platform is whitelisted by default (legacy software) or through a one-time platform pre-verification. See Terminology for those definitions.

The two-part verification model​

Tool-based EPD programs split verification into two phases with very different cost profiles. The published ECO Platform tool-verification guidance and the ongoing TEWOG work both describe a model of this shape, and Smart EPD implements it directly:

Phase 1 — Extended initial verification (once per tool). The verifier reviews the tool's calculation framework, its background data, and one or more fully populated Reference EPD (also known as a "Pilot" EPD) together. A modeling envelope cannot be verified in the abstract — there is nothing concrete to check until real values exist — so the template and its Reference/Pilot EPD(s) are approved in a single pass. This is the expensive, rigorous step.

Phase 2 — Simplified per-EPD verification (every product thereafter). Once the envelope is verified, each new product (a variant in Smart EPD) only has to be checked for one thing: do its inputs stay inside the verified envelope? The methodology, background data, and locked fields are inherited from the verified reference and are not re-litigated.

The envelope is what makes Phase 2 cost-effective

Phase 2 is only defensible because the envelope precisely bounds what a conformant product can look like. Constraints are that envelope. Without enforceable constraints, "simplified verification" would just be unverified publishing.

This ordering is enforced operationally in Smart EPD: the Reference/Pilot EPD(s) must be approved before any variant can be approved. See the Verification Workflow approval gates.

Holding Phase 2 to the model verified in Phase 1​

Phase 2 checks a variant's inputs against the envelope. That is only meaningful if the variant was also produced by the model verified in Phase 1. Smart EPD therefore records, at every Reference and variant submission, which model the EPD was made with: the EPD tool and its version, the PCR spec version, and the template's constraints and external inputs. Approving the Reference EPD locks that record. Each variant is then compared with the lock, and one produced by a different tool or tool version, PCR spec version or template definition is flagged as drift and routed to a verifier instead of being approved automatically. Blocking drifted variants outright is available behind a feature flag. The records are an internal, tamper-evident audit trail: canonical JSON with a sha256 digest, whose contents the database will not let anyone change or delete. See Submission snapshots and the model lock.

Two lenses on the same verification​

Tool verification is reviewed from two complementary perspectives. They look at the same tool but ask different questions.

LCA sideSmart EPD verification side
Core questionDoes the model produce correct LCA results for any product within its declared scope?Is each declaration a conformant EPD, and does it stay inside the verified envelope?
What's reviewedCalculation framework, system boundaries, background datasets, allocation rules, data qualityThe populated Reference EPD, locked/inherited fields, input bounds, per-variant inputs
WhenPhase 1, as part of extended initial verificationPhase 1 (the reference/pilot(s)) and Phase 2 (each variant)
Failure mode it catchesA systematically wrong model — every output biasedA specific product whose inputs fall outside the verified envelope
In Smart EPDLCA report review (verifier reviews the LCA alongside the EPD)Reference + variant constraint checks; EPD approval is gated on LCA approval

The two are deliberately coupled. In Smart EPD, EPD approval is gated on the LCA being approved — you cannot sign off the declaration side while the calculation side is unresolved. The LCA lens proves the engine is sound; the verification lens proves each declaration the engine emits is in-bounds.

How constraints enforce the envelope​

The bridge between "the tool is verified" and "this specific EPD is trustworthy" is the constraint envelope: the set of locked fields and input bounds resolved onto the template and inherited by every variant. Constraints come in four kinds; the full mechanics (parameters, inclusivity modes, conditional rules, and the safe formula engine) are documented in EPD Templating.

Each constraint carries a severity that determines what happens when it is violated:

  • error — always blocks variant approve / auto-approve. When the template enforces constraints, it also blocks a Reference EPD's submission unless the author explicitly acknowledges the failure, in which case the verifier decides. When enforcement is off, the Reference EPD's violation is recorded for the verifier instead of blocking.
  • warning — surfaced to the verifier but does not block
  • info — informational only

So the chain from a verified tool to a trustworthy product EPD is: verified envelope → variant supplies inputs → inputs checked against the envelope → error-severity violations block, warnings flag for human review. That check is what "simplified per-EPD verification" actually consists of.

Where the rules live

Constraints are properties of the template (the resolved output of the specification inheritance chain), not of any individual EPD. The Reference/Pilot EPD(s) instantiates the envelope with real numbers and is the first instance validated against it; variants inherit it. See Reference EPDs & Constraints for the ownership model and the validation endpoints.

Statistics: outlier detection at scale​

Range and formula constraints encode known rules. But a tool that publishes hundreds of EPDs across a mature product category also needs to catch declarations that are individually plausible yet anomalous relative to their peers — the kind of error a fixed min/max won't see. That is what statistical constraints are for.

A statistical constraint compares an input against a distribution using a z-score (distance from the mean in standard deviations), supporting both normal and lognormal distributions. The distribution parameters (mean and std_dev for normal, geometric_mean and geometric_std_dev for lognormal, plus the z-score threshold) are configured on the template from category data — they are not auto-derived by a live population scan at submission time. A value beyond the configured threshold fails the statistical constraint — which, like any constraint, blocks auto-approval at error severity or is stored non-blocking at warning/info. Separately, a verifier can manually record outlier flags against a product's indicator values (a verifier action, not automatic) so deviating products in a family are captured with their magnitude.

This is most valuable in exactly the tool-heavy categories above. Concrete and asphalt have many existing declarations, so the category distribution is well-characterized and a z-score is meaningful — a flagged outlier is a genuine signal that a mix or plant configuration warrants a closer look, not noise. For a brand-new category with few declarations, statistical constraints are weaker and range/formula constraints carry more of the load.

Statistics flag; they don't decide

A statistical outlier is a prompt for review, not an automatic rejection. Depending on its configured severity it either blocks (error) or simply surfaces to the verifier (warning/info). The human verifier decides whether an outlier reflects a real product difference or a data error.

AI gating: advisory, human-in-the-loop​

Verifying every per-product declaration is still a lot of review. Smart EPD uses AI to assist that review, never to replace human judgment. For eligible submissions, an AI conformance pre-pass produces advisory signals (likely conformance issues, each with a confidence level) surfaced to the verifier as a starting point. Where a submission is routed to a verifier, the human — not the AI — makes the final call.

Concretely, the pre-pass checks whether each required section contains the expected information and whether the narrative matches the data, emitting a per-requirement suggested status (Conformant / OFI / Non-Conformant) with a confidence level — always advisory.

This design is deliberate and aligns with where industry tool-verification guidance is heading. Forthcoming tool-verification standards will likely be explicit that AI must not autonomously generate the substance of an EPD — it must not invent emission factors, fill in missing bill-of-materials data, select background datasets, build the process model, or fabricate numeric results. Smart EPD's AI usage stays on the safe side of that line: it is assistive and reviewial (flagging, classifying, summarizing for a human), not generative of LCA results.

The division of labor is the point: constraints and statistics handle the deterministic, numeric envelope checks; AI handles the fuzzy, language-level checks (is the documentation complete? does the narrative match the data?) — and a human owns the decision in both cases.

Worked examples​

Asphalt — NAPA Emerald Eco-Label​

The Emerald Eco-Label tool and its underlying LCA are third-party verified (Phase 1). Producers then generate mix-specific, plant-specific EPDs from the verified tool (Phase 2). Mapped onto Smart EPD: the verified tool + model is the verified template + Reference EPD; each published mix is a variant whose plant and mix inputs are checked against the verified envelope.

Concrete — verified EPD generators​

NRMCA-compliant concrete generators pre-verify the tool's data and calculation method once, after which per-product and per-site declarations are streamlined — each manufacturing site is verified against the already-verified tool rather than from scratch. This is the two-part model exactly: an expensive one-time tool/model verification, then cheap, bounded per-product verification. Smart EPD's reference→constraint→variant flow is the same shape expressed as data.

Industry direction: machine-readable EPDs​

Tool verification is converging with a second industry push: digital, machine-readable EPDs. The goal is that a verified tool emits not just a PDF but structured data an LCA application can consume directly (the ECO Portal datahub is the European example; the draft digital-data requirements push "one digital dataset per product variant"). Smart EPD already models each EPD as structured data rather than a document-first artifact, which positions it for this direction. Cryptographic signing and end-to-end dataset provenance are partly required now as part of broader industry requirements, but Smart EPD has already implemented much of these modern practices.

caution

Upcoming TEWOG digital-data and tool-verification drafts referenced in this article are works in progress (with pilots planned), paraphrased at a conceptual level. Where a hard requirement matters, rely on the published sources in the References below and on each program's own current documentation, not on this overview.

References​

Core EPD standards:

  • ISO 14025 — Environmental labels and declarations
  • ISO 21930 — Core rules for EPDs of construction products and services
  • EN 15804+A2 — Core PCR for construction products
  • EN 16757:2022 — PCR for concrete and concrete elements (a c-PCR used with EN 15804+A2)

Tool verification — programs and guidance:

  • Reference EPDs & Constraints — the constraint envelope, ownership model, and validation endpoints (the mechanics behind this page)
  • EPD Templating — constraint types, severities, and out-of-bounds handling in detail
  • Variant EPDs — how per-product declarations are derived and validated against the envelope
  • Terminology — LCA Platform, EPD Tool (Model), platform pre-verification, tool/model verification, and the Type 0/1/2 tool-update model
  • Verification Workflow — the submittal package and the reference-before-variants approval gate
  • Specifications & Validation — how the specification inheritance chain resolves into a template