Solutions · ILCD validation and conversion
Cortex Cowork validates ILCD data packages against schema requirements and converts between ILCD and JSON-LD — reporting every error by location and severity, and documenting every mapping choice before any field is changed.
What Cortex does
ILCD packages fail in predictable ways: missing required fields, incorrect unit references, schema version mismatches, and structural issues that only appear during conversion to another format. Cortex surfaces these systematically — not as a pass/fail verdict, but as a structured list a practitioner can act on.
Cortex runs schema validation against the ILCD package and returns a structured report: Error, Warning, and Info counts with the location (file name + XPath or JSON path), description, and a fix suggestion for each entry. The summary states plainly whether the package is publishable, needs fixes, or has warnings but is usable.
Cortex converts between ILCD and JSON-LD in either direction. The delivery includes the mapping rules used, every field that was dropped, merged, or default-filled, and the result of validating the converted output against the target schema. Where feasible, a round-trip check (A → B → A) confirms losslessness.
Validation report
The validation report organizes findings by severity. Errors are hard failures — schema requirements that the package violates. Warnings are issues that affect interoperability or signal incomplete data. Info entries are observations that do not require action but may be relevant for submission context.
Each finding includes the file name and the XPath or JSON path where the issue occurs, a plain-language description of what is wrong, and a specific fix suggestion. The report closes with a summary verdict: whether the package can be submitted as-is, requires fixes before submission, or has warnings that are acceptable for the intended use.
Pitfalls that appear in one package tend to recur in packages from the same source. At the end of a validation session, Cortex identifies any systematic patterns — fields that are consistently missing, values that are consistently mis-formatted — and writes them to the project record so the next package from the same vendor can skip the discovery pass.
Conversion
ILCD and JSON-LD are structurally different. A conversion that succeeds without errors may still have dropped or altered fields that were present in the source — multilingual label handling, inherited flow property references, and extension fields are common sites of information loss.
Cortex documents the mapping rules used for each field group, lists every field where a choice was made (kept as-is, merged, default-filled, or dropped), and explains the consequence of that choice. Where the consequence is significant — a field required by the target registry that the source format encodes differently — Cortex pauses and asks before proceeding.
After conversion, the output is validated against the target schema. Where feasible, a round-trip check runs: the converted output is converted back and diffed against the original. Fields that survive the round trip without change are lossless; fields that do not are flagged for manual review.
Mandatory checkpoints
Silent repair is the failure mode that causes the most downstream damage — a package that appears valid but has had fields quietly altered or dropped. Cortex does not silently repair. It stops, names the issue, and returns the decision to the practitioner.
Hard errors — no auto-fix
When validation finds an Error, Cortex stops and presents each one: location, severity, and a suggested fix. The user decides whether to fix or accept the risk. No silent repair.
Warnings — split by consequence
Warnings are presented in two groups: those that affect interoperability with other systems (fix recommended) and those that are style issues (optional). The distinction matters — a practitioner accepting a risk needs to know what the risk actually is.
Structural mismatch during conversion
Some ILCD constructs do not map cleanly to JSON-LD — multilingual fields, inherited flow properties, and schema-version-specific extensions are common sources. When a mismatch occurs, Cortex names the field, explains the mapping choice, and describes the information that would be lost. No field is silently dropped.
Schema version specificity
ILCD 1.1 and EF 3.0 use different mapping rules. When the target version matters — for submission to a specific registry or validator — Cortex asks before applying the conversion rules.
Every error located. Every mapping choice documented.
Cortex Cowork runs locally. ILCD packages stay on your machine. Known pitfalls from each validation session accumulate in the project record.