CIM Is Not Enough — The Commercial Ontology Layer for the Energy Industry
An ontology layer is the missing piece between raw operational data and any AI system you want to put on top of it. Palantir made the concept famous with AIP; the principle predates the brand. The ontology sits between source systems and applications and models the business in three building blocks: Objects (customer, order, plant, contract), Relationships (operator owns plant, plant is on a market location), and Actions (place a forward, cancel an order, hedge a balancing group). Every object references the canonical record in the underlying systems; actions write changes back, with a full audit trail.
For the energy industry the layer is the difference between an AI demo that talks about your data and an AI system that operates on your data. Without an ontology, an LLM agent on top of SAP, the trading system and the metering hub hallucinates joins and confuses entities. With one, it can only see what exists, only act through declared actions, and every step is logged.
The five generic benefits of an ontology layer apply to any data-heavy organisation. They're worth listing before we get to the energy specifics, because they are the reason this conversation is happening at all.
What an Ontology Layer Does
Five concrete benefits, observable in production, independent of the industry on top.
One Language for Business and IT No more six-table SQL joins for a business question
The ontology knows the terms "contract" and "remaining term" directly. Business users build their own reports against semantic objects instead of joining tables they don't understand. The historical bottleneck of "the analyst is on holiday, no one else can write that SQL" disappears.
Apps Get 10× Faster to Build A new application doesn't build a new data model
Each new application reads and writes against the existing ontology. There's no per-app data model to align, no per-app integration to maintain. The compounding effect is what makes ontology-platform organisations look "fast" — the slow part was the schema work, and the ontology has already done it.
A Semantic Frame for AI LLM agents hallucinate on raw tables; they don't on ontologies
When an agent operates on raw SQL it invents columns that don't exist, mistakes one entity for another, and writes plausible-looking nonsense. On an ontology the agent can only access objects that actually exist, only call actions that are declared, and the audit trail shows every step. The semantic frame is the guardrail that makes agents safe enough to deploy.
Governance Built In Rights attach to objects, not rows
Object-level rights replace per-table permissions. A role-based access policy attached to the contract object propagates to every app, query and agent on top. Compliance auditors trace authorisation through the policy, not through stitched-together application logs.
Lineage Becomes Natural Every value traces back: source, timestamp, actor
The ontology records, per write, which system it came from, when, and which user or agent performed the change. Lineage is not bolted on — it falls out of the ontology's design. For energy, where the operator might be asked by BNetzA or by an internal audit to reconstruct the chain that led to a regulatory submission, this matters.
The Energy Industry Already Has a Starting Point
The good news: for the energy industry you don't have to invent the ontology from scratch. There is an international standard that does most of the work — the IEC Common Information Model, IEC 61970 / 61968 / 62325, usually just called CIM. It defines classes like PowerSystemResource, GeneratingUnit, ConductingEquipment, MeasurementPoint, SwitchingDevice. Transmission system operators and large distribution system operators have been using it for years. If you are building an ontology for the energy sector, you should anchor on CIM rather than building a parallel model — running two models over the same data is an operational nightmare.
The bad news: CIM was designed by the grid-operator world. It models the physics — the network, the assets, the topology, the measurements. It does not model the commercial side, the regulatory side, or the time-series-as-first-class character of energy data. For a Direktvermarkter, a Stadtwerk on the supply side, or a trader, those are exactly the layers where the value sits.
Four extensions on top of CIM make the ontology useful for the commercial energy world.
What CIM Doesn't Cover
The four extensions on top of CIM that turn an electrical-engineering ontology into a commercial-energy ontology.
Commercial Objects The contracts, portfolios and hedging instruments CIM doesn't model
The commercial layer adds objects CIM doesn't have because it didn't need them: Anlagenbetreiber (plant operator), Vermarktungsvertrag (marketing contract), Portfolio, HedgingPosition, Termingeschäft (forward), Rückkauf (buyback), Mindestpreis (floor price), EEG-Förderung with the anzulegender Wert (applicable value) logic, Bilanzkreis (balancing group), Bilanzkreisvertrag. These are the entities Direktvermarkter actually live in — they play commercially, not physically.
Regulatory Objects The market-roles, market-locations and message types that anchor MaKo
The regulatory layer adds Marktlokation (MaLo), Messlokation (MeLo), Lieferantenwechsel-Vorgang (supplier-change process), the EDIFACT message types (UTILMD, MSCONS, ORDERS, INVOIC), Marktrolle (market role: LF, NB, MSB, ÜNB), and the Marktstammdatenregister entry. These are the anchors every MaKo process attaches to. An ontology that doesn't carry them cannot serve as the single source for compliance and market-communication workflows.
Time Series as First-Class Citizens Not a property on an object — a class with operations
Unlike defense or supply-chain ontologies where objects are mostly "things", in energy the substance lives in flows over time: half-hourly generation measurements, quarter-hourly market prices, hourly weather forecasts, settlement-period imbalance volumes. The ontology needs an elegant model for "plant X has generation time series Y at granularity Z" — not as a property of the plant but as its own class with operations: interpolate, aggregate, forecast, validate against a tariff. Without this, the ontology stays a static catalogue while the business runs on dynamics.
Actions That Move Money Place a forward, execute a buyback, adjust a floor price, onboard a plant
The action layer is where the ontology stops being a model and becomes a system. Place a forward (with floor-price validation against the EEG anzulegender Wert). Execute a buyback (with a profitability check against current spot). Onboard a new plant (cascades into marketing contract, balancing-group assignment, Marktstammdaten notification). Process an EDIFACT message (parse, validate, respond with the right MaKo answer). Compensate a balancing-group deviation. Generate the committee report. Each action writes back through the ontology with the full audit trail, so a compliance officer or an AI agent can trace any state change end-to-end.
The Relationships That Bind It Together
Objects only become useful through the edges between them. The most load-bearing relationships in a commercial energy ontology are predictable:
An Anlagenbetreiber owns one or more Anlagen. Each Anlage is registered at a Marktlokation and is part of one or more Portfolios. A Vermarktungsvertrag connects the Anlagenbetreiber with the Direktvermarkter and references the affected plants. An Anlage may draw EEG-Förderung with a specific floor-price logic. A Portfolio holds HedgingPositions per delivery quarter, each consisting of Termingeschäfte and Rückkäufe. A Marktlokation generates MSCONS time series. Every Anlage has weather-forecast time series attached.
These eight relationships carry roughly 80% of the queries a commercial energy organisation runs every day. If the ontology gets them right, the rest is composable.
Why This Matters Now
The conversation about ontology in the energy industry isn't new. What's new is the agentic-AI layer that sits on top. An LLM agent can be plugged into a raw operational database and will produce a convincing-looking demo. It will also drift, invent entities, miss regulatory constraints, and write nonsense back into production systems given enough autonomy.
An ontology layer is the structural answer to that risk. The agent reads through the ontology — so it only sees what is real. The agent writes through declared actions — so it can only do what is allowed. Every step is in the audit trail. This is not the answer to "should we use AI"; it is the precondition for being allowed to.
The reason Palantir's AIP works in regulated environments and most competitors stall isn't the model. It's that everything the model can touch sits behind an ontology layer with a contract.
For the European energy industry the recipe is now visible: take IEC CIM as the physical anchor, add the four commercial and regulatory extensions on top, model time series as their own class with operations, and define the actions that actually move money or trigger regulatory reporting. The result is a substrate on which Direktvermarkter, Stadtwerke and traders can run AI agents the same way they currently run their best human analysts — with full visibility, full audit, full reversal of every change.
The five-layer architecture we describe elsewhere has Ontology as the second layer; this article zooms in on what that one layer needs to contain for an energy-industry deployment. The other four layers — Connect, Apps, Agents, Trust — sit on top of this one. They only work if the ontology is real.
Read Next
The broader five-layer stack in which the Ontology layer sits:
Thought Leadership The Five Layers of the Energy AI Stack Connect · Ontology · Apps · Agents · TrustBuilding the Ontology Layer in Your Organisation?
We help energy companies design the CIM-anchored commercial ontology — and the agents that run on top of it.
Get in touch