Basics

In LCA as Code, you express the objects of study (processes, products, substances and impact indicators) and the relationships between those objects by writing in a structured language, close to natural language but with additional constraints and guards to help catch errors and enforce structure.

Here is a first, trivial example of a model describing bread making:

process bake {
    products {
        1 kg bread
    }
    inputs {
        1   kg wood
        1   kg flour
        0.3 l  water
        20  g  yeast
    }
}

The process is described using the word process, and an easy to read and write list of inputs from the technosphere and products to the technosphere is provided.

This approach enables several benefits compared to traditional tools:

  • The ability to separate the data and model from the assessment engine. This implies that the assessment of a model is:

    • Reproducible: two individuals get exactly the same results from the same model
    • Auditable: one can easily explain and understand where given results come from
    • Trackable: one can change the model, or the backing data, observe the change in the results.
  • Ease of proofreading: since the models are represented as structured text, by humans and for humans, it is much easier to share, document and keep track of the models and datasets written across teams or a company. Also, because the details of computation are separate from the model, errors are much easier to detect and understand.

  • Error correcting: LCA as Code prevents you from writing inconsistent models.

    • Every quantity has a unit, and the coherence of these units is checked: one cannot add a volume and a mass without being notified.
    • Exchanges referring to unknown products or substances are highlighted. You can spot the dependencies of your model in the blink of an eye. You won't have to struggle anymore with NaN and NULL results!
    • LCA as Code warns you when a typographic mistake is detected.
  • Parametrized processes: often with traditional tools, a generic « process » (e.g. baking, but with ovens of different sizes, or in different countries) has to be rewritten as many times as there are instances of that process. With our language, it is possible to parametrize a process, hence abiding by the don't repeat yourself (DRY) principle.

  • Executable documentation: documentation plays an important role in LCA. Every input data, formulae, external references must be explicit and correctly sourced. In LCA as Code, you can augment your model with any kind of metadata, but there is more to that. By separating the computation concerns from the modeling concerns, the model description as code literally becomes the documentation. Therefore, it is up-to-date and aligned with the computations by design.