What Kind of Data Qualifies as Compliant with the ILCD System?

Recently, we have frequently received questions such as: "What exactly is ILCD? Is it simply a different file format? Why do databases constantly emphasise the need to be 'ILCD-compliant'?"

The answer is that ILCD is not merely a technical matter of exporting data into a particular file format. Rather, it is a systematic set of requirements designed to ensure that data are comparable, reviewable, exchangeable, and traceable. This article aims to clarify the misconception that ILCD is simply a file format, explain its components, scope, and value, and outline a practical pathway from basic compliance to excellence.

01. What Is ILCD and Why Does It Matter?

ILCD (International Reference Life Cycle Data System) was developed under the leadership of the European Commission's Joint Research Centre (JRC), with the aim of establishing unified international standards for LCA data modelling, storage, and exchange. It is not a database itself, but a comprehensive framework encompassing methodologies, data specifications, and technical tools.

The ILCD framework consists of three main components

• Methodological guidelines: There are 13 volumes in total. Eight provide guidance on specific LCA modelling and calculation procedures, while the remaining five establish the IT technical specifications for the Life Cycle Data Network (LCDN).
• Dataset specifications: The ILCD database comprises eight types of datasets, including: process, flow, flow property, unit group, LCIA method, life cycle model (LCM), source, and contact. All data must be stored in structured XML format to ensure consistent parsing and interoperability across different platforms and tools.
• Software tools: ILCD provides supporting technical tools, such as the Soda4LCA data network platform and the ILCD SDK (Software Development Kit), for dataset editing, validation, and management.

From a value perspective, the ILCD framework functions like a universal grammar, ensuring that different organisations, software applications, and databases can exchange and compare data within the same framework. For databases seeking to enter the European market and integrate with mainstream LCA software ecosystems, this is an essential "passport".

Therefore, the ILCD framework is far more than a simple file format. It involves extensive technical requirements spanning both methodology and IT specifications, complex data structures with multiple layers of nesting and referencing, and registration procedures that lack clear and transparent operational guidance. These factors present considerable challenges for companies and research institutions.

02. Basic Requirements for ILCD Compliance

ILCD compliance can be understood at two levels: Syntax Compliance and Semantic Compliance.

Syntax compliance requires XML files generated by a database to strictly conform to the schemas defined by ILCD, ensuring that file structures, element names, and mandatory modules are complete. Semantic compliance requires data to follow the specifications set out in the ILCD guidelines in terms of methodology, content, and background information, so that the data can be understood, compared, and mutually recognised on international platforms.

1) Dataset Structure and XML Schema

The ILCD framework defines dataset structures through a strict set of XML Schemas (XSD files). Each dataset type, such as unit processes, aggregated processes, and LCI results, must contain specific root elements and mandatory modules.

• Dataset types and classification: Distinguishes between unit processes, aggregated processes, LCI results, etc., ensuring that the functional purpose of each dataset is clearly defined.
• Metadata completeness: Includes geographical, temporal, and technological representativeness, providing a basis for data interpretation and comparability.
• Data Quality Indicators (DQI): Records data sources, methodological transparency, and verification status to ensure traceability and credibility.
• Standardised XML structure: Data must be stored and exchanged in standardised formats to ensure interoperability across software applications and databases.

2) Compliance Validation Tools

After generating ILCD files, specialised tools must be used for validation to ensure syntactic and logical consistency.

The validation scope covers several core dimensions:

Schema Conformance, Metrological Closure, Semantic/Ontology Alignment, Referential Integrity, and Audit-grade Reproducibility & Lineage.

Commonly used tools include:

• ILCD Validation Tool (official JRC tool): Performs strict validation of ZIP or XML files and generates detailed error and warning reports.
• openLCA/SimaPro/jimuLCA: Automatically trigger validation during data import and calculation processes.

03. Common Misconceptions

In practice, there are several common misconceptions about what it means to be "ILCD-compliant".

1) Focusing only on format while ignoring data quality

Forcing data into ILCD XML format may make them appear compliant, while overlooking whether methodological requirements and modelling principles have actually been followed. Even if the file structure is complete, the data may still lack practical value if representativeness, system boundaries, or modelling logic are flawed.

—Example:

Suppose a database takes an outdated dataset with an unclear source, such as "China's electricity grid data from 2005", and forces it into an ILCD XML template. Although the file passes Schema validation, the following issues remain:

• timeRepresentativeness/startYear (temporal representativeness) is left blank.
• dataSources/description (data source description) contains only "industry average".
• completeness/completenessProductModel (product model completeness) has not been declared.

Such data may formally comply with ILCD, but are essentially of no practical value because their quality cannot be assessed and they cannot be responsibly adopted in research.

In fact, ILCD goes far beyond a set of file formats. It is a comprehensive framework covering methodology, modelling details, and review requirements. What truly determines data quality is whether the principles and detailed requirements in the methodological guidelines have been followed. In international review processes, the first areas examined are often methodology and modelling compliance, while file format validation is merely the final step.

2) Treating ILCD as the "highest standard"

ILCD is not the highest standard for life cycle data. Rather, it represents a baseline for entering the global compliance framework. It ensures that data structures are clear, semantics are consistent, and datasets are comparable and reviewable, but this represents only a general threshold, not the ultimate requirement.

Industry standards such as EN 15804 and PEF impose more stringent requirements on system boundaries, calculation methods, and disclosure rules on this basis, addressing compliance and disclosure needs in specific application scenarios.

In other words, ILCD addresses whether data can be understood, while industry standards address whether data can be recognised. Together, they form the foundation for the long-term value of a database.

3) Assuming that a one-time conversion to ILCD format ensures permanent compliance

In reality, ILCD compliance is an ongoing process. Whenever a database is updated, expanded, or upgraded, methodological consistency, model relationships, and data governance must be continuously maintained to ensure that data representativeness, completeness, and traceability are not compromised.

Neglecting ongoing maintenance can result in a situation where data remain formally compliant but become substantively invalid. Even if the file structure continues to conform to the ILCD format, data quality may have deteriorated to the point where it can no longer support scientific analysis or decision-making.

In other words, compliance with the ILCD framework is not a one-time task, but a long-term responsibility in database management.

4) Assuming that converting project data into ILCD format makes a database ILCD-compliant

In fact, ILCD provides a standardised representation of datasets. The true value of a database lies in the relationships between datasets, reproducible system models, and long-term management and maintenance.

Without these elements, even if each dataset formally complies with ILCD, they remain isolated datasets rather than a database capable of supporting scientific analysis, decision-making, or cross-project applications.

04. ILCD Compliance is not the Destination, but the Starting Point

Because of the misconceptions described above, many databases, despite being formally ILCD-compliant, struggle to deliver long-term value.

The value of a database does not lie in isolated figures, but in its underlying structure and the relationships between datasets. Only when different datasets are interconnected within a unified framework to form reproducible system models can a database deliver long-term value and genuinely support decision-making and mutual recognition.

Therefore, achieving ILCD compliance should be regarded only as an "entry ticket", not the final destination.

ILCD compliance means that a database is qualified in terms of format and methodology and can be exchanged and mutually recognised on international platforms. However, this represents more of a baseline for usability than the upper limit of its value.

If a database remains at the level of formal compliance, it may still face challenges such as insufficient representativeness, fragmented modelling logic, inconsistent version management, and a lack of dynamic updates. Ultimately, it may fail to accurately reflect the full industrial landscape or serve as a reliable foundation for long-term decision-making and cross-regional mutual recognition.

A truly excellent database requires continuous investment in methodological alignment, transparency, version management, dynamic updates, interoperability, and tool support, transforming "formal compliance" into "substantive usability".

These extended capabilities include:

• In-depth representativeness: Data should not only meet ILCD requirements regarding scope and system boundaries, but also accurately reflect regional, industrial, and temporal characteristics, ensuring that analytical results are more closely aligned with actual industrial conditions.
• Transparency and interpretability: Go beyond basic traceability to enable users to understand the underlying logic and assumptions behind each dataset, ensuring reliability and interpretability throughout the data application process.
• Version management: Ensure that different datasets and modelling stages follow consistent rules, preventing internal contradictions and fragmentation while improving the overall analytical stability of the database.
• Scalability and interoperability: Within the framework defined by ILCD, support interoperability with other databases, software applications, and localised systems, thereby expanding the range of data applications.
• Dynamic updating capabilities: Continuously incorporate new industrial chain data and methodologies, not only maintaining ILCD compliance but also ensuring that the database can adapt to industrial development and policy changes over the long term.
• Tools and service support: Provide visualisation, querying, and modelling tools to enable users to apply ILCD data efficiently and fully realise their value in decision-making.

Only by combining these capabilities with ILCD compliance can a database move beyond being merely "compliant" to becoming genuinely "usable", delivering long-term value in scientific analysis, industrial decision-making, and international mutual recognition.