A Common Language for the Grid Is Only the Beginning

What is OpenGrid attempting to construct?

At the Open Source Summit Europe on 7 October the Linux Foundation launched OpenGrid. This is an open initiative designed to introduce a common data layer for grid planning, enabling both commercial and open source tools to use the same data rather than each having its own version. The plan involves open standards and data schemas, programmable APIs, a first application for transferring data and models between platforms which is due in 2027, and later on open solvers and standardised workflows, with the aim of ensuring that every country has access to good planning tools by the year 2030. My co-founder Bartek Staszkiewicz stated that open standards create a common language while data engineering is what enables that language to function in day-to-day operations, and I agree with him. What struck me, though, was a smaller aspect: the proposal for a central hub containing "validated, model-ready datasets", followed by AI-assisted data preparation.

Why is the term "model-ready" more important than it may at first appear?

It has the character of a technical footnote, yet in my view it establishes a standard which most organisations have never taken the time to formulate for themselves. A dataset doesn't become model-ready just because it exists or because it was exported from the correct system on the correct day; in my opinion it only becomes model-ready when someone is able to state what it describes, where it came from, whether it is complete, which version was used in a particular calculation, and who is to be held accountable if it turns out to be wrong.

In all the companies I've worked at, each of those answers can usually be found somewhere, typically in the mind of an experienced engineer or analyst who has been with the company for fifteen years and knows which source to rely on for a particular purpose. It is rare, however, to find all the answers together in a form that another team, a regulator or an investor could examine without having that person present. So long as the data remains within the company, this arrangement works rather well. But as soon as the data has to be provided in a common format, the knowledge that exists in someone's head must be recorded directly into the data, and that is a completely different kind of task from simply adopting a new standard.

What are the five questions that determine if data is ready to be used by a model?

Before carrying out any modelling or use of AI, when evaluating a client's data we ask five simple questions and I think that these questions can be applied to grid planning as well as to any other field.

Has the dataset actually been made complete? Does it include every asset, every feeder, and every time interval that it says it includes, and are any gaps explicitly noted rather than being quietly filled in with averages or standard profiles?

Does it conform to the system of record? In the case where the network topology used for planning differs from that in the GIS, or where the measured load differs from that recorded by the metering system, then which one takes precedence and is the rule for this stated anywhere?

Is the data versioned? Or does each study make use of whatever version was current that morning?

Can the process be traced? Is it possible to go back through each transformation and identify the original source of each figure without having to ask the person who carried out the calculation?

Is there an owner? Specifically, is there a named individual or group who is in charge of defining key values—such as the available capacity at a substation—and who makes sure that these values are corrected when they deviate?

There is no need for any new technology in order to answer these questions, and as I have found in practice this is exactly the reason why they are so frequently overlooked, since they are questions of responsibility not of tools and responsibility is far more difficult to acquire than software.

What makes reproducibility the true test?

A straightforward method of determining whether a planning process is based on model-ready data comes not from the field of engineering but from finance. Since each figure in an audited annual report can be traced back to the ledger, an auditor is able to recreate it months later from the same records, which is precisely the reason why people trust it. I believe that grid planning is following a similar path. The need for investment is increasing rapidly, with Poland alone now having about 11 million remote-reading meters generating a great deal more measured data than planners have ever had before, and network and connection decisions are being questioned more and more by developers, regulators and the public. In such a situation, a planning outcome that cannot be reproduced six months later from the same data and the same assumptions becomes very difficult to defend, no matter how good the model behind it was.

In my opinion, it is here that an open standard is of most assistance: not as a substitute for internal discipline, but as a motivation to establish that discipline. When data leaves the company in a common format, the questions concerning which version it is, where it comes from and who owns it cease to be internal matters, and organisations that have already dealt with these issues will see the new standard as a benefit rather than a risk.

In what location is the actual integration work carried out?

Bartek gave a concrete account of the layer that lies between open standards and day-to-day operations: by connecting the existing source systems directly to the planning workflows, by validating and versioning the datasets before a model is run, by keeping the transformations traceable so that the results can be reproduced, by turning one-off analyses into automated pipelines, and by feeding the model's outputs back into the applications where decisions are made. Since LF Energy already has operational tools for grid modelling and forecasting, such as PowSyBl and OpenSTEF, and data platforms such as Snowflake or ClickHouse, a modelling layer like dbt can provide these tools with governed data that is trusted by multiple teams at the same time. In my view, the technological aspect is the easier part of the job; the more difficult part consists in agreeing on the five points mentioned above and in maintaining them week after week, a decision that has to be made from a managerial point of view long before it becomes a technical one.

What is the way to test your own data this month?

I recommend a test which will take a few days and require nothing new. Select one of the planning or connection studies that your team carried out last year and attempt to reproduce it from scratch, using the same inputs and the same assumptions. Record how long it takes you to locate the data that was actually used, how many of the five questions you are able to answer as you go, and whether the result turns out to be the same. If it does, then you are in a better position than most of the market when it comes to having model-ready data; if it doesn't, you will then have a clear and honest list of what needs to be corrected, and a year or so in which to make the necessary corrections before the shared standards cause the gaps to become apparent to all the people with whom you exchange data. We have discussed this same principle in The Market Moved to Fifteen Minutes. Has Your Data?: the rules of the market change on a fixed date, but the data underneath only changes when someone decides to change it.

Then the question I should ask each and every grid planning team today is a straightforward one: if someone asked you tomorrow to reproduce a study from last year, how long would you think it would take?

Sources: Linux Foundation, Linux Foundation Launches OpenGrid to Build Open, Shared Infrastructure for the World's Electric Grid, 7 October 2026; e-magazyny.pl / PTPiREE on smart meter rollout, September 2026

‍