A follow-up to "Data Validation / Example of Energy Data" (September 2023)
In 2023 I argued that data validation is the practical route to technical interoperability in data spaces, and that operations would eventually need a semantic layer with generative AI on top. Three years later the context has changed. The EU Data Act
has applied since September 2025, energy data spaces have moved from EU research projects into pilots, and LLMs are good enough to be part of a data pipeline. The core problem hasn't changed. Energy data still arrives in different formats, with
different CIM/CGMES versions and different national conventions, and most of it can't be trusted until it has been checked.
This post updates the idea with one principle: the LLM proposes, SHACL decides.
Why not just let the LLM validate?
LLMs are not validators. They are non-deterministic, they can't be audited the way a rule can, and they sometimes accept broken data with confidence. In a regulated sector, "the model thought it looked fine" can't be the reason a meter reading entered a settlement process.
Deterministic rules, meaning SHACL shapes over RDF, are auditable, versionable and repeatable. They are also expensive to write, hard to keep up to date across standard versions, and they produce reports only a specialist can read. That gap is where an LLM helps.
Four jobs for the LLM
1. Mapping source data to the model. Every energy community exports data differently: CSV from one inverter vendor, JSON from a smart-meter platform, Excel from a DSO. The LLM reads a sample and suggests mappings to the target vocabulary, for example "kwh_imp → ec:energyKWh with ec:direction "import"". A human approves each mapping once, and it then runs as ordinary deterministic code.
2. Drafting SHACL shapes. The LLM reads a standard, a national implementation guide or a data-sharing agreement written in prose, and drafts candidate shapes. A domain expert reviews them, and they're version-controlled like code.
3. Explaining validation reports. A SHACL report says sh:MinInclusiveConstraintComponent failed on focus node _:r42. The LLM translates that for the data owner: "Reading 42 has a negative energy value. This usually means a PV prosumer's export was recorded with the wrong sign." It also proposes a fix. The fix is never applied to source data automatically.
4. Checking plausibility where rules can't reach. Some problems are syntactically valid but make no sense in context. The LLM flags them for review. A flag that proves useful is turned into a new deterministic rule.
A worked example Here is a simplified interval reading from an energy-community member. The vocabulary (ec:) is a simplified stand-in, not the full CIM metering model:
json
{ "@context": { "ec": "https://example.org/energy-community#", "xsd": "http://www.w3.org/2001/XMLSchema#" }, "@id": "ec:reading-42", "@type": "ec:IntervalReading", "ec:meter": { "@id": "ec:meter-GR-0117" }, "ec:timestamp": { "@value": "2026-03-29T03:15:00", "@type": "xsd:dateTime" }, "ec:interval": "PT15M", "ec:energyKWh": { "@value": "-3.2", "@type": "xsd:decimal" } }
The SHACL shape:
turtle ec:IntervalReadingShape a sh:NodeShape ; sh:targetClass ec:IntervalReading ; sh:property [ sh:path ec:meter ; sh:minCount 1 ; sh:class ec:Meter ] ; sh:property [ sh:path ec:timestamp ; sh:minCount 1 ; sh:datatype xsd:dateTime ] ; sh:property [ sh:path ec:interval ; sh:in ( "PT15M" ) ] ; sh:property [ sh:path ec:energyKWh ; sh:datatype xsd:decimal ; sh:minInclusive 0 ] .What SHACL catches: ec:energyKWh is negative, so the record fails. The LLM explains the failure and suggests the likely cause: an export reading from a prosumer, which should be mapped with ec:direction "export" and a positive value, not dropped.
What SHACL misses: the timestamp is a valid xsd:dateTime, so it passes. But it has no time-zone offset. And 29 March 2026 is the day daylight saving time starts in Europe, when Greek clocks jump from 03:00 to 04:00, so 03:15 local time did not exist in Greece that day. The reading is ambiguous at best and corrupted at worst. The LLM's plausibility pass flags it and proposes a new rule:
turtle sh:property [ sh:path ec:timestamp ; sh:pattern "(Z|[+-]\\d{2}:\\d{2})$" ] .
A reviewer approves the rule and it joins the shape library. From then on the problem is caught by a deterministic rule, not by the model. Over time, the LLM turns its own findings into rules, and the system gets stricter and more auditable instead of more dependent on AI.
The architecture
>
Neo4j holds the governance graph: shapes and their versions, which rule was approved by whom, which dataset passed which shape version, and the provenance of each fix. A vector database indexes standards, implementation guides and past validation cases, so the LLM's suggestions draw on precedent (retrieval-augmented generation). DCAT still describes what's in the data space. It only lists data that passed validation.>
>
>
Guardrails that matter in energy Keep data on your own infrastructure. Metering data is personal data under GDPR. Open-weight models running on-premise (including Greek-language models) remove the need to send it to an external API.>
The LLM never changes source data. It writes suggestions. Changes go through a reviewed, logged step. Version everything. CGMES 2.4.15 and 3.0 will run side by side for years. Shapes, mappings and prompts are versioned together, so every validation result can be reproduced.>
Measure the assistant. Track the share of LLM mapping suggestions that are accepted, false-positive plausibility flags, and how many flags became permanent rules. If those numbers aren't improving, the LLM isn't earning its place.>
Conclusion>
In 2023 I wrote that data which isn't used loses its value, and that all of it has to be validated as part of DevOps/DataOps/DataSecOps. That still holds. What has changed is the cost of doing it well. LLMs make the costly human parts cheaper: mapping new sources, writing rules, explaining failures. The part that must be trustworthy stays deterministic. The semantic layer I proposed then is still needed. It now has an assistant that helps maintain it but never overrides it.
0 Comments