Network model governance: what changes when the operator does not own the grid

A system operator sits in an unusual position in the power sector. It runs the grid, but it neither owns nor builds it. Every element of its physical model comes from somewhere else: a transmission owner, a concessionaire, or a neighboring operator. A transmission utility can always fall back on records of what it has built and use that as its reference point. A system operator has no such anchor.

At first glance, this may seem like an administrative difference, but it is not. For a transmission utility, governing model data improves an existing process. For a system operator, governing the data is the process.

What this looks like in practice 

Anyone who has worked within a system operator will recognize the symptoms without needing them explained.

Real-time operations, operational planning, and expansion planning often maintain their own versions of the same substation. Between the equipment registration base and the CIM files consumed by analysis tools sits a chain of in-house converters, scripts, and spreadsheets built up over years. It functions, but only a handful of people fully understand it; and those individuals eventually move on or retire.

Then come the less visible consequences. Reproducing the model exactly as it existed at the moment of a disturbance is slow and, in practice, approximate. Changes (who made them, when, and under authority) are rarely recorded at the level of individual objects. Meanwhile, the queue of updates grows faster than the team can handle: new transmission concessions, utility-scale renewables, storage, HVDC links, and distributed resources all arrive as model changes with firm deadlines attached.

Before: Each integration path becomes a separate agreement on format, timing, and quality.

Why is this not an engineering failure 

It is worth stating this clearly, as the diagnosis is often mistaken for criticism of technical teams.

None of these challenges arise from a lack of rigor. They emerge when model data is integrated path by path rather than governed centrally. Each path was a reasonable decision at the time, made within the constraints of budget and schedule. The accumulation of those decisions over fifteen or twenty years is what ultimately becomes the constraint.

That is why the solution is not to ask teams to be more careful. It is to change where the reference point resides.

System of record and system of action 

One of the clearest ways to explain this, particularly in discussions with leadership, is through the distinction between two roles.

The system of record holds the model. The system of action operates the grid. These are fundamentally different functions, with different lifecycles and selection criteria.

When both reside within the same platform, the model becomes tied to the control system. Replacing the platform then requires moving the model as well, turning a routine technology upgrade into a major transformation project. When the two are separated, the model remains with the operator, and the operational platform becomes replaceable.

After: a single governed repository sits between data sources and consuming systems.

This approach is not new. EPRI’s collaborative requirements work, developed with transmission utilities, system operators, and software vendors, defines eight capability families that a Network Model Manager should cover and organizes modelling processes into five groups. One consistent theme stands out: governance is not an overlay but a core capability, embedded in how the model is created, maintained, and used across the organization.

“We already have a database manager” 

This is the most common objection; and a fair one. Most operators already run a database or model manager delivered with their control platform. These tools are real, and they do their job.

The question is not whether something manages the model. It is what that system was designed to do. A manager delivered with the control platform is typically optimized for the “as-operated” state required in real-time, and it primarily serves the vendor’s own application suite.

Rather than debating this in the abstract, two practical questions are worth asking of any candidate system, including the one already in place.

Can it hold a future-dated project alongside the as-built model, and assemble a case from either?

Can a third-party application consume the model independently of the platform vendor?

If the answer to both is yes, the tool is probably not the issue. If either answer is no, that is where the conversation begins.

Download the full brochure 

We have put together an eight-page brochure that explores the topic in more depth than this article allows. It includes:

• A before-and-after view of the full architecture, showing the five typical data sources and eight consuming applications, with EPRI’s five process groups mapped across the flows.
• A breakdown of EPRI’s eight capability families, mapped directly to IPS® NMM.
• A comparison between a platform-delivered model manager and an independent CIM-based system of record across six dimensions, including five key evaluation questions for your current solution.
• A phased adoption approach, starting with a proof of concept on a subset of the topology, without requiring wholesale replacement.
• The impact on each function, from control room operations to executive oversight, including a reference from a national transmission system operator that has already implemented this approach.