Match Your BOM to Emission Factors Without Averaging

A 100-row BOM is not a number. It is 100 separate claims, each one an auditor can ask you to defend. Average them into a single product carbon footprint and you bury every claim under a figure nobody can walk back. Auditors rarely ask “what is the number.” They ask “where did this row come from.”

That question is where most BOM-row matching for Scope 3 Category 1 — Purchased goods and services — falls apart today. A row says “aluminum sheet.” A tool returns one factor. The factor goes into the model, the model returns a footprint, and somewhere along that chain the spread between databases got collapsed, a proxy got picked for you, and the reasoning behind both vanished. You file. The auditor asks. You can’t answer, because the answer was thrown away three steps upstream.

There is a way to match a BOM to emission factors that neither averages nor fabricates. It begins by refusing to return a single number.

Top-k, not top-1

Cortex matches your BOM across fourteen LCA databases — HiQLCD, Ecoinvent, EF, CarbonMinds, and others — and returns the top candidates per row rather than the top one. Each candidate carries what you need to choose between them: a GWP100 value, its unit, the geographic region, the system model (cut-off, APOS, or consequential), the source URL, and a DQI score across five dimensions — Temporal, Geographic, Technology, Completeness, Reliability — a normalized read on the Pedigree-Matrix lineage practitioners already know.

That is the whole argument. One returned factor hides the decision; a ranked list exposes it. When “aluminum sheet, China” pulls one Ecoinvent cut-off record at one GWP100 value and an EF record at more than twice that, the gap is not noise to average away. It is information. The two databases disagree about this material, and you — not a model — get to decide which one your study can defend.

Averaging destroys exactly that. Take a genuine disagreement between two datasets built on different system boundaries, average it, and you get a third number that describes no dataset at all. The auditor can’t trace it. There is nothing to trace.

How the matching narrows

The match is tiered, and the tier is visible. Cortex looks first for the same item, then the close family, then equivalent use, then a generic entry. A 304 stainless steel row that lands on a 304 stainless steel dataset is a same-item match. A 316 grade resolved against a 304 record is a close-family proxy — and the DQI delta and region deviation are named, not buried.

The tier is the honest measure of how confident the match is. A generic-entry match and a same-item match are not the same claim, and copy that flattens both into “one factor” lies by omission. So the tier travels with the candidate. So does the DQI score. So does the source URL. When you export, the full provenance rides along: the practitioner who opens the file in three weeks, or the verifier who opens it in three months, can see which row was an exact match, which was a proxy, and why.

The speed, to make it concrete: a 100-row BOM, matched by parallel cross-database search with DQI-scored candidates per row, typically resolves in about 10 minutes. Speed isn’t the point. The point is that none of those 10 minutes is silent.

Average two datasets and you describe neither. The auditor cannot trace a number that came from nowhere.

Where Cortex stops

Most of a BOM resolves cleanly. The rows that don’t are the rows your auditor will circle — and those are the rows Cortex refuses to wave through on its own.

Cortex pauses where automation would break an audit. Coverage drops below 80%, too many rows without a confident match: it stops and hands the decision back. The closest dataset isn’t an exact fit and a proxy is required: it stops. The same material returns a cross-database spread above 2×: it surfaces the spread and asks rather than picking a side. A restricted dataset has no GWP because you lack access: it marks the row instead of quietly slotting in a literature value.

These aren’t numbered gates, and the list isn’t exhaustive. They are the points where a model continuing on its own would manufacture a claim you’d later have to retract. At each one the practitioner decides, and the decision lands in the reasoning chain. The export carries the choice and its justification, so the file you hand a verifier answers “why this proxy” before the question is asked.

This is the line between a tool that drives an audit-grade workflow and one that just produces a number. Cortex does not replace your judgment about a proxy. It scales it: finds the candidates, scores them, names the deviation, and hands you the call.

What you file

Cortex produces a reasoning chain. You file. Nothing auto-submits a CBAM declaration or an EPD, and there is no certification claim — the output is built for alignment with ISO 14067 and the GHG Protocol Product Life Cycle Accounting and Reporting Standard, but verification is the verifier’s act and the filing is yours.

Category 1 — Purchased goods and services — is where this bites hardest: BOM-row-level factor matching is what the whole tiered, top-k, DQI-scored pipeline exists for. Other Scope 3 categories run on different methods and data, and this doesn’t claim to cover them. And when the calculation has to run in your modeling tool, Cortex connects to and operates the engine — openLCA, brightway, 积木LCA — building the product system and running the calculation inside the tool you already use. It does not replace the engine. It drives it.

The result is a BOM matched to emission factors with no averaging and no fabricated single number. You see the spread. You see the tier. You see the DQI. Where automation would break the audit, Cortex stops and hands the decision back. Every row you file, you can defend — line by line, back to a source URL.

The trail is the product

A footprint is one number. An audit is the path to it. Match your BOM without averaging and the path holds: every row traceable to a dataset, every proxy named, every disagreement preserved instead of dissolved.

Upload a BOM at cortex.hiq.earth/chat, or talk to us at lizj@hiqlcd.com.