HiQ Cortex
中文 Open Chat

Solutions · Product carbon footprint

From BOM to LCIA results. Every assumption on record.

Cortex Cowork runs the full product carbon footprint workflow inside your local openLCA instance — dataset matching, product system construction, LCIA calculation — and writes every modeling decision into an append-only project log.

The workflow

§ I

Four stages. One project log.

A product carbon footprint study involves a fixed sequence of decisions. Cortex Cowork handles the mechanical work at each stage; the practitioner retains control at every point where a judgment call determines the answer.

01

BOM → background data

Upload the BOM. Cortex matches each row to the closest background dataset across fourteen LCA databases — HiQLCD, Ecoinvent, EF, CarbonMinds, and more. Proxy substitutions are named, their bias direction documented. Rows without a defensible match are flagged for practitioner review before the model is built.

02

Product system construction

Cortex drives openLCA directly: creates flows, assembles the product system, connects foreground to background processes. The practitioner specifies functional unit, system boundary, and LCIA method once — Cowork carries those decisions forward across every session for the life of the project.

03

LCIA calculation

Cortex runs the impact assessment inside the user's local openLCA instance. Default method: IPCC 2021 GWP100. Additional categories — acidification, eutrophication, water scarcity — available on request. Results are returned as a contribution analysis: top contributors by process and by flow, not just a single number.

04

Export and documentation

Results export as a structured report: modeling scope, data sources per process, full assumptions list, LCIA results by impact category, DQI summary. Sensitive analysis runs where specified. The export is reproducible from the parameters recorded — a verifier can follow the chain without re-running the model.

openLCA integration

§ II

Cortex drives openLCA. You keep the model.

Cortex Cowork does not replace openLCA. It operates it. The user's local openLCA instance remains the model — Cortex is the operator, working within openLCA to create flows, build process connections, and run calculations.

On macOS, Cortex can interact directly with the openLCA interface — navigating dialogs, reading result windows, confirming dataset selections. On Windows and Linux, Cortex connects to openLCA through its built-in server interface.

The model stays in the practitioner's openLCA database. Cortex does not hold a copy. When the session ends, the product system, processes, and flows remain where openLCA keeps them — accessible, editable, and version-controllable by the practitioner.

Direct GUI interaction is available on macOS. The connection to openLCA works on all three platforms.

Mandatory checkpoints

§ III

Five situations where Cortex stops and asks.

A carbon footprint model is only as defensible as its assumptions. Cortex is configured to pause at every point where a silent default would introduce an unresolvable question in review. These are not interruptions — they are the moments a verifier would later ask about.

  1. § 01

    Data substitution

    Target dataset not found. Cortex names the substitute, explains the gap (region, production route, DQI), and asks for confirmation before proceeding.

  2. § 02

    Boundary simplification

    Upstream process cut-off requires a criterion — mass < 1%, environmental relevance < 1%. Cortex states the criterion and asks. The practitioner decides.

  3. § 03

    Allocation method

    Co-products require allocation. Cortex explains the effect of economic, mass, and energy allocation on the result — and asks the practitioner to choose before the model is built.

  4. § 04

    Magnitude check

    LCIA result differs from comparable studies by an order of magnitude. Cortex pauses, lists possible causes (unit conversion, functional unit mismatch, boundary error), and asks before exporting.

  5. § 05

    openLCA connection

    openLCA is not running or the connection cannot be established. Cortex identifies the cause and gives the fix — rather than retrying silently.

Every assumption is confirmed. Every confirmation is recorded.

The deliverable

§ IV

A report a verifier can follow without re-running the model.

The final report from a product carbon footprint session contains: modeling scope (product, functional unit, reference flow, system boundary, geographic and temporal scope); data sources (database, version, and region for each process); a complete assumptions list covering every data substitution, boundary simplification, and allocation choice; LCIA results by impact category with a contribution analysis showing the top five contributors; and a DQI summary identifying datasets with low reliability scores.

Where sensitivity analysis is requested, Cortex runs it and includes the results. The standard cases: substituting a proxy with a higher-DQI alternative, changing the allocation method, and shifting the system boundary at a specified cut-off criterion. The report records both the base-case result and the sensitivity range, with the assumption changed identified by name.

The project log (progress.md) accumulates every decision across all sessions — decisions made in session one are still visible in session ten. A verifier arriving at the final report can trace any result back to the session in which the underlying choice was made.

Cross-session continuity

§ V

The project remembers what was decided.

A product carbon footprint study rarely completes in one session. Functional unit, system boundary, LCIA method, and allocation rules are decided in early sessions and must carry through to the final calculation without being re-litigated.

Cowork records these four modeling essentials in the project at the close of the session in which they are decided. Every subsequent session reads them first and treats their contents as binding constraints. A practitioner who specified "cradle-to-gate, cut-off system model, IPCC 2021 GWP100, mass allocation" in session two does not need to re-specify them in session seven.

Data substitution decisions accumulate the same way: if session three established that "IGBT module" maps to the electric vehicle application dataset in HiQLCD, session eight does not re-run that lookup. The mapping is on record. The session starts from where the project left off.

The model is yours. The audit trail is built in.

Cortex Cowork runs locally. openLCA stays on your machine. Every session's decisions accumulate in a project log that travels with the project folder.