2. Project description#
Any Life Cycle Oriented study must be accompanied by a report of the project’s characteristics.
For this, the following guidelines can be used by the PRACTITIONER to generate a reproducible report.
The protocol does not prefer a particular format for reporting (e.g., .docx, .tex, .md, .rst, etc.) as long as the following four subsections are considered.
2.1. Purpose#
The arguments of Grimm et al.[1] can be adapted to say that every Life Cycle study has to start from a clear question, problem, or hypothesis; readers cannot understand the study unless they understand its purpose.
In this sense, the PRACTITIONER should provide a clear statement of the reason why the different models and pipelines in this project were developed.
Note
The purpose description goes beyond the LCA Goal and Scope step found in ISO14040 because the LCA could be just one stage of a high-level Life Cycle Oriented study. For instance, some studies may use the LCA stage to calculation impact factors that will be later fed into an Material Flow Analysis (MFA) model. In this case, the high-level purpose is more related to the MFA stage than to the LCA.
Based on the recommendations of Grimm et al.[1], the purpose has these characteristics:
It is precise and specific, avoiding vague terms like “explore” or “study”.
It describes the current study avoiding to include future studies or follow-ups.
It does NOT describe the models since they will be described in following sections.
It is COMPLETELY independent and self contained since it does not require to be linked to any document or section of the protocol to be fully understood.
2.2. Inputs metadata#
TODO: This section mentiones the recomended metadata properties that data files should include. Considering relying on README files for this.
2.3. Life Cycle Inventory model overview#
TODO: This section gives guidelines to describe the multiple LCI models in terms of LCI construction model and supply network characteristics.
2.4. Submodels overview#
TODO: This section gives guidelines to describe the different NON-Life Cycle models that will provide inputs or consume outputs during the computational pipeline.