Docs

Brightway Flows

Every life cycle inventory database names its substances differently. ecoinvent calls it Carbon dioxide, fossil; EF 3.1 calls it Carbon dioxide (fossil); SimaPro has its own spelling again — and each attaches it to a differently-named compartment. Nothing in those names tells you whether two entries mean the same thing, and nothing tells you when two entries that look the same are actually different substances.

This project builds a consensus elementary flow list: one identity per substance, one controlled vocabulary of contexts, and an explicit, traceable link from every source list's flow back to that shared identity.

What you get

For each substance in the consensus list:

• One preferred name per language, drawn from the source data but cleaned, normalised, or replaced where a clearly better-established name exists.
• Synonyms from ChEBI and CAS Common Chemistry, filtered to remove names that belong to a different substance.
• Chemical identity: CAS, EC, KEGG and Gmelin numbers; molecular formula, mass, charge; InChI, InChIKey, SMILES, IUPAC name.
• Semantic typing — Nickel(2+) is recorded as a MonoatomicIon whose Atom is nickel.
• A definition and links out to chemical, biomedical, and physical databases, and to Wikidata.
• Provenance for every value — which source asserted it, and which processing step wrote it.
• Cross-list links, so a flow in EF 3.1 can be translated to its counterpart in SimaPro or ecoinvent.

Who this documentation is for

It is written for engineers and analysts who work with inventory data — people who know what an elementary flow, a compartment, and a characterisation factor are, but who do not need to read Python to use this project.

Three pages assume you are modifying the code and say so at the top: Architecture, Conventions and Data model. Nothing else does — including Harmonisation steps, which describes what the pipeline decides rather than the code that runs it.

Where to start

"What is this project claiming, and can I trust it?"

Why this exists → Flow objects and elementary flows → How a flow is decided → Known limitations

"How does a row in a source list become a flow in this one?"

How a flow is decided — one substance followed from the row a vendor shipped to the flow this list publishes, every decision on the way linked to the page that answers it

"What has this actually found in the published lists?"

What we have found — the errors in the source data, grouped by kind, each with a worked example and a count per source list

"I know one of the source lists. What did you change in it?"

What was changed in each source — one page per input list: the rows one name was split over, the ions given a charge, the rows merged into one flow, and the registry numbers corrected, each with the source's own identifier and the reason

"What is still open, for the list I care about?"

Open questions, by source list and by topic — one link per source list and per topic into the issue tracker, always current

"I have the output files and want to use them."

Which output do I need? → Recipes → File schemas

**"I have a flow list of my own and want to know which consensus flows its rows

are."**

Matching your own list — ask about a row, or a whole list, against a build that has already happened

"I need to run or re-run the pipeline."

Installation → Running a transform → Choosing sources → The review application

"I am reviewing the harmonisation decisions."

The review application → How a flow is decided → Harmonisation steps

If a term is unfamiliar, check the Glossary.

Project status

This is active research software. The consensus context taxonomy and the harmonisation rules both still change as they meet more real-world data. The Known limitations page lists what is currently unresolved, including cases where the output is known to be wrong — read it before depending on the data for anything consequential.