How Great Britain publishes its distribution grid model, and what the May 2026 derogation changed

The LTDS as the first foundation of the GB energy digitalisation vision

The Energy Digitalisation Framework, published jointly by DESNZ and Ofgem, sets out the vision as "An energy system built on secure, interoperable and informed sharing of data, driving efficient system planning, real-time responsiveness, and innovation in new and improved services for consumers."¹⁰ That sets the direction. Digitalisation is a continuing capability rather than a fixed end point: each foundation moves the system closer to that vision and the bar moves with it.

A vision at that scale is not delivered by one project. It is delivered foundation by foundation. The LTDS is the first of those foundations to become a live, regulated, machine-readable data product. It brings together a clear licence basis, a common information model, phased delivery, shared technical artefacts, version control, stakeholder validation and proportionate change control. That combination is what turns fragmented network information into reusable digital infrastructure, which is why the LTDS is best read as a credible pathfinder for the wider digitalisation programme rather than the whole of it.

It is also concrete about where it sits. In the framework's data map (EDF Figure 4), the LTDS grid model and the Capacity Heatmap sit in the core energy system data domain coordinated by NESO. Three further domain coordinators are named alongside: Elexon for behind-the-meter asset data, RECCo for consumer data, and Elexon again for metering data on a provisional basis. Two cross-cutting bodies sit below the coordinators: NESO leads the Data Sharing Infrastructure, and RECCo leads the Consumer Consent Service. So the work below is not only a network-planning exercise. It is the first proof that regulatory direction, common data models, technical governance and proportionate change control can convert a complex operational domain into governed, reusable data.

An enterprise-architecture lens makes the shape of the work clearer. In TOGAF terms, the vision in the Energy Digitalisation Framework is the direction of travel; each release of the LTDS is a transition between a current state and a target state, narrowing the gap that is otherwise carried as technical and architectural debt. The Direction, the Form of Statement, the SHACL profiles and the Engagement Hub work as guardrails rather than gates: DNOs can deliver on time without losing interoperability across the ecosystem. Seen this way, the LTDS does more than publish one data product. It is the first transition architecture in a continuing capability. Clear licence basis, a shared model, dated artefacts, stakeholder governance and proportionate change control form a reusable pattern. If the next data product across the system reuses that pattern instead of inventing its own, the cost of digitalisation falls and the integration risk falls with it.

Where the LTDS sits in the ED3 and digitalisation timeline

One timeline ties three threads together: the electricity distribution price control, the published digitalisation policy, and the LTDS delivery stages. The next price control, RIIO-ED3, runs from 1 April 2028 to 31 March 2033 and follows RIIO-ED2 (1 April 2023 to 31 March 2028).¹¹

Why this matters

Every electricity connection in Great Britain rests on a quiet act of publication. Each of the fourteen distribution licence areas publishes a forward-looking description of its network twice a year. The duty has existed since 2002. The format changed in 2024.

Until 2024 the publication was a stack of PDFs and spreadsheets. From 2024 it is structured, validated, machine-readable grid model data. The shift unlocks faster connection decisions, software that vendors can actually build, and whole-system planning at distribution scale.

What the May 2026 derogation changed

The Long Term Development Statement is the twice-yearly, forward-looking grid model that every one of the 14 Great Britain distribution licence areas publishes. On 13 May 2026 Ofgem approved a third derogation. It moved no publication date: Stage 2 still publishes 29 May 2026, Stage 3 still publishes 30 November 2026. What it reshaped is the content. Stage 2 now carries one future-year model instead of five, with years 2 to 5 deferred to Stage 3. Short-circuit results move into a new dedicated SCR profile. Connections activity moves into the Capacity Heatmap. Stage 3 production moves from 15 August to 15 October 2026. The same letter confirms the BSI Engagement Hub as the location of record for the technical artefacts; Ofgem keeps the Direction, the Form of Statement and the derogation letters.⁹

What this enables a reader to do

• 1Explain what the LTDS is and which legal instrument creates it.
• 2Name the fourteen licence areas and the six DNO groups that hold them.
• 3Describe the five-layer architecture from foundational tech to legal duty.
• 4Read a CIM XML snippet and follow a Substation through to its ConnectivityNode.
• 5Identify the ten profiles in the v2.1.0 release and what each carries.
• 6Explain why CGMES v3 plus CDPSM was chosen, and what was rejected.
• 7Describe the GB CIM Advisory Group's three swim lanes and four objectives.
• 8Walk through the issue and release lifecycles operated through the Engagement Hub.
• 9Read a SHACL constraint and understand what it validates.
• 10Explain the three derogations and the 28-day notification clause that made them possible.
• 11Connect GC0139 to LTDS as the transmission counterpart.
• 12Distinguish DBP Principle 9 (Security) from Principle 11 (Presumed Open) accurately.
• 13Recognise the common modelling, tooling, and data-reading pitfalls, and how to avoid them.
• 14Find the right place to engage or escalate for any LTDS issue, and the route between them.
• 15Trace any factual claim back to its primary source on Ofgem or BSI.

What the LTDS is

The Long Term Development Statement is a regulated publication. It is required by paragraph 25.2 of the Distribution Licence, and it is read by connection applicants, network planners, software vendors, the National Energy System Operator, journalists and academics who all need a description of how the distribution network is shaped today and how it is forecast to be shaped over the next five years.

The LTDS is a weather forecast for the electricity grid. It publishes where the network is today and where it is expected to be in each of the next five years, and refreshes twice a year. Observation and prediction sit in the same data.

It is also an A to Z for connections. Attaching a five-megawatt solar farm in Devon starts with the LTDS as the first map to check. It shows which substations are near, what voltage they sit at, what capacity remains, and what planned development might shift that picture next year.

And it is a shared vocabulary for grid equipment. Every transformer is a cim:PowerTransformer. Every overhead line segment is a cim:ACLineSegment. Every switch is a cim:Switch or one of its subtypes. Same names everywhere. No local conventions to translate.

The formal definition

Each holder of an Electricity Distribution Licence is directed under paragraph 25.2 of the standard conditions¹ to publish an LTDS in a form consistent with Ofgem's Form of Long Term Development Statement.² The duty itself dates from 2002.³ The format that is current today comes from the Direction issued on 30 April 2024.

The 2024 reform

The duty did not change. The data layer did, completely.

The Direction Letter that accompanied the 2024 instrument resolved nine themes raised at formal consultation: data security and confidentiality, vendor readiness, GB CIM governance and interoperability, the implementation plan, the publication of additional data, the retirement of previous tables, transmission system visibility, capacity heatmap data, and curtailment information.⁵ The implementation plan theme is the one that mattered most operationally. Some DNOs raised a concern about milestones they could not control, particularly software vendor readiness. Ofgem's response, copied verbatim from the Direction Letter, was that whilst the assessed risk was extremely low, "we would not want these circumstances to lead to a failure to adhere to the terms of the direction". Wording was therefore introduced into the Direction itself, setting out a 28-day notification clause for any unmet deadline. That clause was invoked in October 2024 by the DNOs through the Energy Networks Association, and Ofgem granted a one-year extension on 25 November 2024.⁶

The fourteen licence areas, the six DNO groups, the one System Operator.

Each LTDS is published by a holder of an Electricity Distribution Licence. There are fourteen of those. They are owned by six corporate groups. The National Energy System Operator, NESO, sits across all of them and consumes their LTDS data alongside its own transmission models.

The fourteen is the column total, not a figure from memory: ENWL 1 + NGED 4 + NPG 2 + SPEN 2 + SSEN 2 + UKPN 3 = 14 licence areas across the six groups. Each area holds one Electricity Distribution Licence and publishes one LTDS, which is why "14 licence areas", "14 licensees" and "14 LTDS publications per cycle" are the same count seen from three sides.⁶

The full list of licensees, taken verbatim from the Energy Networks Association letter that accompanied the 25 November 2024 derogation request,⁶ is: Electricity North West Limited; Northern Powergrid (Northeast) plc; Northern Powergrid (Yorkshire) plc; SP Distribution plc; SP Manweb plc; Scottish Hydro Electric Power Distribution plc; Southern Electric Power Distribution plc; Eastern Power Networks plc; London Power Networks plc; South Eastern Power Networks plc; National Grid Electricity Distribution (East Midlands) plc; National Grid Electricity Distribution (West Midlands) plc; National Grid Electricity Distribution (South West) plc; National Grid Electricity Distribution (South Wales) plc.

The two-decade reform story.

This section is background, not a prerequisite. Nothing later on the page depends on reading it. It is here for the reader who wants to know why the regime looks the way it does, not as a gate in front of the current position.

This was not a sudden standards drop. It was a 24-year refinement.

Two anchor dates carry most of the weight. 10 January 2022 is when Ofgem committed to CIM as the GB data standard.⁷ 30 April 2024 is when the Direction made that commitment legally binding.¹ Everything else fits between or around those two.

Why CIM, and why this CIM.

The shape to hold in mind: CGMES is an international rulebook, and the GB extension is a national annex to it. The annex adds clauses for things the rulebook deliberately left to local choice, and departs from a handful on purpose. It never rewrites the rulebook, which is what keeps a GB file readable by international CGMES tooling.

The Common Information Model is not a single standard. It is a family of IEC standards plus profile specifications that select subsets for specific exchanges. Ofgem's 10 January 2022 open letter made three decisions explicit.⁷

Alternatives considered, and rejected

Annex 2 of the 2022 letter is unusually candid about why other options were not chosen. Two alternatives are named.

The thirty-year arc

The 2022 letter sets this commitment in a thirty-year arc. CIM was developed in the 1990s by the Electric Power Research Institute (EPRI) in North America as an open standard for power system data.⁷ ERCOT adopted it in 2009 to run its nodal market in Texas. ENTSO-E then adopted it for European transmission exchange, where it became CGMES. By 2022, two Horizon 2020 demonstrator projects, Flexiciency and TDX-Assist, plus the EU Bridge initiative, had extended CIM into the distribution and flexibility space. GB picks up where that track record leaves off, not from a blank sheet.

How the LTDS is legally bound.

A lawyer will recognise the shape immediately. It is delegated authority: primary legislation creates a power, a licence granted under it carries standard conditions, one condition confers a power to direct, the direction sets the obligation, and the schedule to the direction is the document that must actually be filed. Each tier has force only because the tier beneath it grants it, exactly like an Act, regulations, a licence condition, and a determination made under that condition.

Reading bottom up, every link is enforceable. Parliament authorises the Authority to license, the licence carries SLC 25.2, the SLC empowers the Direction, the Direction names the Form of Statement that defines the deliverable.

There is one further clause of operational importance. The Direction includes a 28-day notification mechanism: "If the Licensee becomes aware that it will not be able to meet one or more of the publication dates… it must notify the Authority in writing as soon as is reasonably practicable and in any case no later than 28 days before the relevant publication date/Deadline." That clause is what made both the November 2024 derogation and the March 2025 Heatmap derogation possible.⁶

Where the LTDS regime stands in May 2026

Six stages, with the original and the revised deadlines, and where each one stands as of May 2026.

How many days each deadline moved, recomputed from the dated letters

Rather than settle for "about a year", the days are counted exactly. The method is the same each time: take the day-of-year of the original date, add the days left in that year, then add the day-of-year of the revised date. 2024 is a leap year, but every span here starts after 30 November 2024 and crosses only the 2025 and 2026 Februaries, both non-leap, so each whole year in this table is exactly 365 days, never 366.

Take Stage 2 publication. 30 May 2025 is day 150 of 2025 (31 + 28 + 31 + 30 + 30). That leaves 365 - 150 = 215 days in 2025. 29 May 2026 is day 149 of 2026 (31 + 28 + 31 + 30 + 29). So the gap is 215 + 149 = 364 days: one day short of a full calendar year, because the revised publication date is 29 May, not 30 May.

Two numbers carry the story. Stage 3 production moved 426 days, the largest single shift, because two derogations stack on it: the 25 November 2024 letter moved it a year to 15 August 2026, then the 13 May 2026 letter moved it a further 61 days to 15 October 2026.⁶⁹ Stage 3 publication moved exactly 365 days and no more, because the 13 May 2026 letter explicitly held it at 30 November 2026 while letting production slip. The gap between the two, 426 − 365 = 61 days, is the compression the DNOs absorbed between producing Stage 3 and publishing it.

The five-layer architecture.

The LTDS stack has five layers, each independent of the others, each governed by a different body.

A useful sanity check: when something changes at one layer, what changes at the others? A new W3C SHACL release (L1) does not change the LTDS deliverable. A new IEC 61970-301 amendment (L2) might propagate up through L3 to L4 and create work for the GB CIM Advisory Group. A new gb: class (L4) does not change the regulatory instrument. A new Direction (L5) typically points to a specific Form of LTDS version which can name updated artefacts at L3 or L4.

The four activity layers, and where the AG sits.

BSI's Activity Layers diagram is the governance picture worth knowing best. It shows where each kind of CIM activity actually happens, and what the GB CIM Advisory Group does at each layer.

The lesson the diagram teaches is operational. Ideation lives at ENA in L4, governance at BSI in L3, standards at IEC and PEL in L2, and the regulatory framework in the wider ecosystem at L1. The AG's job is to hold these four layers coherent, not to do work in any one of them in isolation.

How CIM describes connectivity.

The everyday picture first. Equipment never wires straight into other equipment, the way two roads do not just merge into one another: they meet at a named junction. A ConnectivityNode is that junction. A Terminal is the slip-road that takes one piece of equipment onto it.

Now the precise version. Equipment never connects directly to other equipment in CIM. Equipment connects through Terminals to ConnectivityNodes. A ConnectivityNode is the junction. Two pieces of equipment are connected to each other when both have a Terminal that references the same ConnectivityNode. This is the concept the rest of CIM stands on.

Worked example: a Substation in CIM XML

Here is a small, anonymised CIM XML snippet showing what a Substation actually looks like in an LTDS publication. mRID is the Master Resource Identifier, every CIM object has one, and it is what makes models diffable across cycles.

<cim:Substation rdf:ID="_a3e7d2f1-6c41-4d83-9b27-e0815c9a1b48">
  <cim:IdentifiedObject.mRID>a3e7d2f1-6c41-4d83-9b27-e0815c9a1b48</cim:IdentifiedObject.mRID>
  <cim:IdentifiedObject.name>OSPREY Primary</cim:IdentifiedObject.name>
  <cim:Substation.Region rdf:resource="#_subregion-east-midlands"/>
  <cim:PowerSystemResource.PSRType rdf:resource="#_psrtype-primary"/>
</cim:Substation>

<cim:VoltageLevel rdf:ID="_vl-osprey-33kv">
  <cim:IdentifiedObject.mRID>vl-osprey-33kv</cim:IdentifiedObject.mRID>
  <cim:VoltageLevel.Substation rdf:resource="#_a3e7d2f1-6c41-4d83-9b27-e0815c9a1b48"/>
  <cim:VoltageLevel.BaseVoltage rdf:resource="#_bv-33kv"/>
</cim:VoltageLevel>

<cim:BusbarSection rdf:ID="_bb-osprey-33-A">
  <cim:IdentifiedObject.mRID>bb-osprey-33-A</cim:IdentifiedObject.mRID>
  <cim:IdentifiedObject.name>OSPREY 33kV Bus A</cim:IdentifiedObject.name>
  <cim:Equipment.EquipmentContainer rdf:resource="#_vl-osprey-33kv"/>
</cim:BusbarSection>

A few things to notice. Every object carries an mRID. Every reference is an IRI, never a name. Containment is explicit: Substation contains VoltageLevel contains BusbarSection, never the other way around. PSRType is mandatory in v2.1.1, and the value must be one of the named tokens (GSP, BSP, Primary, SwitchingStation) or a locally meaningful equivalent.

Worked example: resolving the OSPREY mRID chain by hand

The plain idea first: an mRID is a permanent name tag. A reference is a label that says "see the thing whose tag is this". Resolving a reference is just following the tag, the way a library reference number leads from a footnote to the exact book on the shelf. Nothing in CIM connects by position or by display name; everything connects by tag, which is why two cycles of the same network are diffable.

The BusbarSection above resolves all the way up to its Substation using only the snippet.

Step 1  Start at the BusbarSection.
        <cim:Equipment.EquipmentContainer rdf:resource="#_vl-osprey-33kv"/>

Step 2  Take the reference IRI, strip the leading '#':
        "#_vl-osprey-33kv"   ->   local id  "_vl-osprey-33kv"

Step 3  Find the object whose rdf:ID equals that id:
        <cim:VoltageLevel rdf:ID="_vl-osprey-33kv">  ->  RESOLVED

Step 4  That VoltageLevel itself references a Substation:
        <cim:VoltageLevel.Substation rdf:resource="#_a3e7d2f1-6c41-4d83-9b27-e0815c9a1b48"/>
        strip '#'  ->  "_a3e7d2f1-6c41-4d83-9b27-e0815c9a1b48"

Step 5  Find that rdf:ID:
        <cim:Substation rdf:ID="_a3e7d2f1-6c41-4d83-9b27-e0815c9a1b48">
        cim:IdentifiedObject.name = "OSPREY Primary"   ->  RESOLVED TARGET

The chain resolves: BusbarSection "OSPREY 33kV Bus A" -> VoltageLevel "_vl-osprey-33kv" -> Substation "OSPREY Primary". Notice the mRID and the rdf:ID carry the same value (a3e7d2f1-6c41-4d83-9b27-e0815c9a1b48) with only the leading underscore differing: the underscore is an XML constraint, an NCName cannot start with a digit, so the serialisation prefixes _ on the ID while the mRID stays bare. An importer that treats #_a3e7d2f1... and a3e7d2f1... as different identifiers is the single most common reason a model "loses" its containment, and it is avoidable by always normalising the leading #_ before comparison.

Worked example: one SHACL constraint on OSPREY, passing then failing

Plain idea: SHACL is a checklist the data must satisfy. Each shape is one line of the checklist. Running it is ticking the boxes against a real file. Here is the Substation PSRType shape, in the same form the LTDS pack uses, written from Issue 039 (PSRType mandatory on every Substation):

gb:Substation.PSRType-minCount
  rdf:type        sh:PropertyShape ;
  sh:description  "Every Substation must declare exactly one PSRType." ;
  sh:path         cim:PowerSystemResource.PSRType ;
  sh:minCount     1 ;
  sh:nodeKind     sh:IRI ;
  sh:message      "A Substation has no PSRType reference." ;
  sh:severity     sh:Violation .

Run it against the OSPREY Substation exactly as written above. The Substation carries <cim:PowerSystemResource.PSRType rdf:resource="#_psrtype-primary"/>, so the path has one IRI value, minCount 1 is met, nodeKind sh:IRI is met, and the report is:

Conforms: True
  Validation report: 0 results, 0 sh:Violation

Now mutate one field: delete the single line <cim:PowerSystemResource.PSRType rdf:resource="#_psrtype-primary"/> from the Substation and re-run the same shape. The path now has zero values, minCount 1 is not met, and the report names the constraint that did not hold:

Conforms: False
  Result 1
    sh:focusNode        _a3e7d2f1-6c41-4d83-9b27-e0815c9a1b48
    sh:resultPath       cim:PowerSystemResource.PSRType
    sh:sourceShape      gb:Substation.PSRType-minCount
    sh:constraintComponent  sh:MinCountConstraintComponent
    sh:resultSeverity   sh:Violation
    sh:resultMessage    "A Substation has no PSRType reference."

One removed line moves the file from conforming to non-conforming, and the report points at the exact node, the exact path, and the exact shape (gb:Substation.PSRType-minCount) so the fix is unambiguous. This is the whole value of the validation layer: a reader never has to guess why a publication was rejected, the report says so in machine-readable terms.⁸

The profile catalogue.

The analogy a lawyer would use: the full CIM is the entire statute book, and a profile is one specific statutory form. The form does not restate the whole law, it gives exactly the boxes a particular filing needs. EQ is the "what physically exists" form; SV is the "what the power-flow study solved to" form. One filing never requires filling in the whole book.

Precisely, a profile is a non-overlapping subset of CIM classes, attributes, and associations defined to organise grid model data and support its exchange. The count is composed, not remembered: the seven CGMES v3.0 profiles the LTDS inherits unchanged (EQ, SC, GL, SSH, TP, SV, DL) plus the three GB-specific ones (SYSCAP, SCR, Header) give 7 + 3 = 10 profiles in the v2.1.0 release.⁸

One concept underneath the next figure is worth saying in plain words first. A Full Model is the clean, complete document: every Substation, Line, Switch and Transformer as the network stands. A Difference Model is the tracked-changes layer over it: the redline that adds some objects and removes others. There is no need to retype the document to show a future state: the clean copy goes out once, then the redlines follow. Applying a redline to the clean copy gives the projected grid. That is exactly how Stage 3 ships firm development projects without republishing the whole network each time.

Of the ten profiles, SCR and Header are new in v2.1.0. SCR carries the fault-level results that the April 2024 baseline kept inside SYSCAP. Header is the LTDS-specific metadata profile that deviates from the CGMES Header in four specific ways.⁸

Two precisions for the expert reader. First, "inherited from CGMES" is not "identical to CGMES": of the seven CGMES-derived profiles, EQ in particular carries GB extension classes such as gb:SwitchDisconnector and gb:GridSupplyPoint, while SC, SSH, TP, SV, DL and GL stay close to stock CGMES v3.0. An importer that maps the LTDS EQ profile to a pure CGMES EQ schema will silently drop the GB classes. Second, v2.1.0 Theme H moved thirteen cardinality constraints out of SHACL into the RDFS and UML. The consequence is that a tool which validates only by running the SHACL files will no longer see those thirteen; from v2.1.0 they are enforced at the schema layer, not the validation layer, so conformance checking has to consult the RDFS as well as run the shapes.⁸

The one equation the SCR profile rests on, worked at 33 kV

In one sentence: the SCR profile reports, at each bus and each branch, how much current would flow if a short circuit happened right there, and the matching short-circuit power. The everyday version: it is the difference between asking "how hard could the tap run if the pipe burst here?" rather than "how much is flowing now?". The number is the network's strength at that point, and it sets what switchgear has to survive.

The precise relationship, for the balanced three-phase case, is the one from IEC 60909-0, the international standard for short-circuit currents in three-phase a.c. systems:

S"k  =  √3 . Un . I"k

  Un    nominal line-to-line voltage   (kV)
  I"k   initial symmetrical short-circuit current, r.m.s.  (kA)
  S"k   initial symmetrical short-circuit power            (MVA)

Take a 33 kV busbar where the SCR profile reports an initial symmetrical short-circuit current of I"k = 13.1 kA. Then

S"k = √3 . 33 . 13.1
    = 1.7320508 . 33 . 13.1
    = 1.7320508 . 432.3
    = 748.8 MVA   (to one decimal place)

The check that it is one fact in two units, not two facts: divide back. S"k / (√3 . Un) = 748.8 / (1.7320508 . 33) = 748.8 / 57.158 = 13.10 kA, which is the current the calculation started from. That round-trip is why a reader can take either the current or the power from SCR and recover the other, and why an importer that drops one of them has lost nothing if it kept the voltage. One edge case worth stating for the expert: the figure above is the initial symmetrical three-phase value (the IEC 60909-0 I"k). It is not the peak current i_p or the symmetrical breaking current I_b, which the asymmetry factor and the generator decay would change; SCR carries the symmetrical bus and branch results, and a single-phase column alongside the three-phase one, so the column in use must always be read before comparing to switchgear ratings.⁸

What each LTDS stage publishes, profile by profile

Each stage delivers a different combination of profiles. The combinations matter because they determine what a reader can do with each cycle's data.

Stage 2 (publishes 29 May 2026)

The 13 May 2026 derogation kept this publication date but reshaped its contents: one future-year model instead of five, short-circuit results carried in a dedicated SCR profile, and connections activity moved out of System Capacity into the Capacity Heatmap.⁹

• Existing Fault Level "case", EQ.xml + SC.xml + SCR.xml. Short-circuit results now sit in the SCR profile, not SYSCAP.
• Existing System Capacity "case", EQ.xml + SYSCAP.xml. Connections activity reporting has moved to the Capacity Heatmap.
• Future Year 1 System Capacity "case" (×1), EQ.xml + SYSCAP.xml. Future years 2 to 5 are deferred to Stage 3.
• Zero or more Development Project zips, each containing a Difference Model conforming to EQ + SC + GL

After publication, the DNOs must run at least two rounds of stakeholder engagement to test the assumptions behind these changes, surface any unintended consequences, and feed the outcome into Stage 3.⁹

Stage 3 (production 15 October 2026, publishes 30 November 2026)

Nine fixed zip files, plus the future-year models deferred from Stage 2, plus variable Development Project zips. The production deadline moved from 15 August to 15 October 2026; the publication date is unchanged.⁹

• NETS Maximum Demand "solved case", 7 Full Models (EQ + SC + GL + SSH + TP + SV + DL)
• NETS Minimum Demand "solved case", 7 Full Models
• Existing Fault Level "case", EQ + SC + SCR
• Existing System Capacity "case", EQ + SYSCAP
• Future Year n System Capacity "case" (×5), EQ + SYSCAP each. Years 2 to 5 were deferred here from Stage 2.

NETS stands for National Electricity Transmission System.

Governance: BSI, Advisory Group, Engagement Hub.

The 2022 letter left governance as the open question. It resolved on 28 November 2025, when the GB CIM technical artefacts moved from the Energy Networks Association's GitHub to the BSI Engagement Hub. The Hub is at cim.bsigroup.com. Ofgem then formally confirmed this split in the 13 May 2026 derogation letter: the Engagement Hub is the official location of record for the data-exchange definition artefacts, while the Form of Statement, the Direction and the derogation letters stay with Ofgem.⁹

Three structures sit on top of the Hub, named explicitly in the front matter of every v2.1.1 document:

• PEL/57/1, Common Information Model. A formal BSI subcommittee under PEL/57. PEL/57 is the BSI national mirror committee for IEC TC 57. So GB CIM governance now sits inside the same institutional structure that participates internationally in IEC standards-making.
• The GB CIM Advisory Group. A multi-stakeholder consensus body. Convened by BSI Standards Limited. Decisions are taken by AG consensus.
• The GB CIM Engagement Hub. The public-facing website that hosts artefacts, issues, releases, and the weekly digest mechanism.

Three Swim Lanes.

The AG cannot debate everything. The Swim Lanes model triages every issue submitted to the Hub into one of three categories before any AG meeting time is spent on it.

Lane A items are typically things that propose or materially affect GB CIM standards, profiles, extensions, or deviations; affect alignment with IEC CIM, CGMES, or TC 57; or are linked to imminent regulatory or data exchange deadlines. Lane B is for system-wide or cross-industry relevance, emerging use cases, or AG input needed for direction-setting. Lane C is for tool-specific or vendor-specific implementation questions, detailed testing or conformance, or matters better handled by other technical or industry forums.

Four guiding objectives.

The Swim Lanes are the operational filter. The Guiding Objectives are the strategic anchor. Both come from the same BSI Objectives and Swim Lanes document.

1. Maintain GB CIM Governance Integrity. Ensure GB CIM profiles, extensions, and deviations are coherent, consensus-based, and aligned with international CIM standards and IEC governance processes.
2. Enable Timely Regulatory and Data Exchange Readiness. Prioritise issues that directly affect regulated data exchanges, Ofgem-managed documents, and upcoming data submission or compliance deadlines.
3. Provide Strategic Direction and Prioritisation. Guide where collective effort should be invested based on system-wide value rather than individual stakeholder or organisational interests.
4. Act as a Consensus Interface Between Stakeholders. Synthesise stakeholder input into clear, balanced positions while maintaining the AG's role as a decision-making body rather than a general discussion forum.

Issue and Release lifecycles.

Two processes run in parallel and converge at the Engagement Hub. The Issue Management Process handles individual technical issues from submission to closure. The Release Creation Process bundles resolved issues into versioned releases.

Issue Management Process: six steps

1. Submission. Raised on the Hub by any member.
2. Categorisation. CIM Subject Matter Experts tag the activity area.
3. Resolution formulation. The relevant ENA Workstream drafts the approach.
4. Package preparation. Proposed resolution overview compiled.
5. AG review. Weekly digest emailed. Members respond "OK" or "Wait, discuss". Silence is treated as No Objection.
6. Implementation. Artefacts updated. Issue closed.

Release Creation Process: five steps

1. Package preparation. List of artefact versions and resolved issues.
2. Proposed release shared with the AG ahead of the next meeting.
3. Review and approval at the AG meeting.
4. Release creation. Versioned bundle published via the Hub.
5. Released. Vendors and DNOs implement against the new version.

The v2.1.0 release.

v2.1.0 is the first major maintenance release after the April 2024 baseline. Document publication date is 22 February 2026. The release addresses 40 distinct issues organised into eight themes.

Theme A carries the most weight. In the original April 2024 release, fault-level results were modelled inside the SYSCAP profile. Issue 101 noted that this was not a natural fit: "fault level data is typically created from the execution of short circuit calculations… it is more natural to report fault current data directly against objects contained in the EQ profile." The v2.1.0 resolution created a new first-class SCR profile with its own RDFS, its own SHACL, and its own UML diagrams. SCR's branch faults link to all six switch subtypes: cim:Breaker, cim:DisconnectingCircuitBreaker, gb:SwitchDisconnector, cim:LoadBreakSwitch, cim:Disconnector, and cim:Fuse.

Schema changes from v1 to v2.1.0

Eight themes resolve into a smaller number of practical changes a vendor or modeller actually feels. The ten below are the ones that break v1 importers if not handled.

An importer built against v1 and not updated to v2.1.0 will fail silently on at least three of these: missing DemandGroup, retained representative-feeder-breaker, and the 24-to-3 fuel-type roll-up. The common pitfalls section walks through each.

Header: four deviations from the CGMES Header

The new LTDS Header profile (Issue 084) is based on the CGMES v3.0 Header, which itself uses IEC 61970-552 for serialisation. The deviations are explicit, not accidental.

The licence-area codes sit inside the LTDS namespace as a gb:LicenceAreaKind enumeration. A reader who opens an LTDS package can validate the modelingAuthoritySet against that enumeration before doing anything else. If it fails, the file is not from a recognised licensee.

SHACL validation, and what it actually says.

SHACL is the W3C Shapes Constraint Language. It is the validation layer on top of the RDFS-defined profiles. SHACL v1.0 was a W3C Recommendation on 20 July 2017. The LTDS v2.1.0 SHACL files are licensed Apache 2.0, published by Ofgem, and dated 22 February 2026.

What a SHACL constraint looks like in the LTDS pack

Here is one constraint from the SCR SHACL file, verbatim. It says: a ShortCircuitResultBranch must reference exactly one Switch, and that Switch must be one of the six allowed subtypes.

scr:ShortCircuitResultBranch.Switch-valueType
  rdf:type        sh:PropertyShape ;
  sh:description  "This constraint validates the value of the association at the used direction." ;
  sh:group        scr:AssociationsGroup ;
  sh:in           ( cim:Breaker
                    cim:DisconnectingCircuitBreaker
                    gb:SwitchDisconnector
                    cim:LoadBreakSwitch
                    cim:Disconnector
                    cim:Fuse ) ;
  sh:message      "One of the following occurs: 1) The value is not IRI;
                   2) The value is not the right class." ;
  sh:nodeKind     sh:IRI ;
  sh:path         ( gb:ShortCircuitResultBranch.Switch rdf:type ) ;
  sh:severity     sh:Violation .

Each constraint has a description, a group, a message, a severity, and a path. Severity is one of sh:Violation (must fix), sh:Warning (review), or sh:Info (informational). Groups partition the validation report. A tool can be told to run only datatype checks, or only cardinality, or only associations.

The three derogations.

The 28-day notification clause built into the Direction has been invoked three times. Each letter is short and worth reading verbatim.

What a derogation is here, precisely, and what it cannot do

The mechanism matters as much as the dates. The power is Standard Licence Condition 25.2 of the Distribution Licence. The Direction OFG1164 of 30 April 2024 is made under that power. A derogation is the Authority exercising the same SLC 25.2 power to vary the publication deadlines the Direction sets (and, on 13 May 2026, the Stage 2 contents), on the licensee notifying under the Direction's own 28-day clause. It is an administrative decision communicated by letter, not a statutory instrument and not an amendment to the Electricity Act 1989 or to the licence. Section 6(1)(c) of the Act and SLC 25.2 are untouched; the Form of LTDS itself is untouched; only the Direction's Table 7 deadlines, and in May 2026 the Stage 2 contents, are varied.¹⁹

Two edges worth holding. First, the Direction's obligation on dates is a best-endeavours obligation, "must use best endeavours to meet the publication dates", while the deliverable the Form of LTDS defines is absolute; the 28-day clause is the procedural valve that turns an anticipated best-endeavours shortfall into a formally varied deadline before the date passes rather than after it. Second, the 13 May 2026 letter is the unusual one: it used the same SLC 25.2 power not only to move the Stage 3 production deadline but to reshape what Stage 2 delivers (one future-year model rather than five, short-circuit results into the SCR profile, connections activity into the Capacity Heatmap). A derogation is therefore not only a timing instrument; within the Form of LTDS it can vary what is delivered, provided the duty to publish under SLC 25.2 is preserved.⁹

25 November 2024: the main derogation

The DNOs collectively requested a one-year extension. The reasons given were absence of formal governance mechanisms, unreadiness of required software tools, and technical challenges. Ofgem's response: "having considered the evidence submitted, our assessment is that this extension best balances the genuine challenges being faced with the timely delivery of the obligations set out in the LTDS Direction."⁶ Stage 1.3, 2, and 3 each shifted by one year.

4 March 2025: the Heatmap correction

The November 2024 letter inadvertently omitted the Capacity Heatmap deadline. The March 2025 letter remedied that, citing the same reasons and maintaining a six-month gap between EQ profile publication and Heatmap publication. The new dates are 15 April 2026 (draft) and 29 May 2026 (publication).

13 May 2026: the Stage 2 and Stage 3 extension

The Energy Networks Association, on behalf of all DNOs, requested a third derogation on 23 April 2026. Ofgem approved it on 13 May 2026 under the same Standard Licence Condition 25.2 power.⁹ This one moves no publication date. It approves four changes: one future-year Equipment and System Capacity model at Stage 2 instead of five, with years 2 to 5 deferred to Stage 3; short-circuit results moved from System Capacity to a new dedicated SCR profile; connections activity reporting moved from System Capacity to the Capacity Heatmap; and the Stage 3 production deadline deferred from 15 August 2026 to 15 October 2026. Ofgem explicitly held the Stage 3 publication deadline at 30 November 2026, limiting its approval to the production deadline. Following Stage 2 publication, the DNOs must run at least two rounds of stakeholder engagement to validate the changes and inform Stage 3. The same letter formally confirms that the GB CIM Engagement Hub, hosted by BSI, is the official location of record for the LTDS data-exchange definition artefacts, while the Form of Statement, the Direction and the derogation letters remain with Ofgem.

The 13 May 2026 letter also reshaped Stage 2 content without moving a date: five future-year models became one, with years 2 to 5 deferred to Stage 3; short-circuit results moved to the SCR profile; and connections activity moved to the Capacity Heatmap.

GC0139, the sister modification.

The LTDS describes the distribution side. GC0139 describes the transmission side. Together they form a bidirectional CIM-based exchange between NESO and the DNOs.

GC0139 is a Grid Code modification, raised at the Modifications Panel on 27 February 2020 by Ian Povey of Electricity North West Limited. The first Workgroup Consultation ran 6 December 2024 to 10 January 2025. The Workgroup Report was published on 3 December 2025, the Code Administrator Consultation ran 6 January to 6 February 2026, and the Final Modification Report was issued to Ofgem on 6 April 2026. The modification is with the Authority for decision as of May 2026. The proposed implementation is "within 10 working days following approval by the Authority".

The proposed solution introduces three new Planning Code sections:

• PC.9, information sub-mission provided by a Network Operator to NESO
• PC.10, information sub-mission provided by NESO to a Distribution Network Operator
• PC.G, appendix specifying detail of power system models in CIM format

The submission cadence is weeks 2 and 28 for Network Operators to NESO, and weeks 12 and 38 for NESO back to Network Operators. The required scenarios are maximum fault level, peak demand, summer minimum demand, solar peak / daytime minimum, national high-power transfer dispatch, and national low-power transfer dispatch. The data exchange option chosen is "Option 4, Minimum number of CIM files Augmented with BSP Schedules". Both proposer and Workgroup members showed preference for Option 4. Open Grid Systems (OGS) was the contracted delivery partner via the ENA's Data and Digitalisation Steering Group's CIM subgroup, "having supported Ofgem with their CIM work on the LTDS, so this provided useful background experience."

ENTSO-E Conformity, and what it does not guarantee.

The CGMES Conformity Assessment Scheme is what tells a buyer whether a vendor's tool can actually exchange CGMES models. The current version is CAS v3.0.2, approved by the ENTSO-E CIM Working Group on 25 August 2024. The previous v3.0 was approved by ENTSO-E SOC on 29 September 2021.

The Conformity Registry is a public list of vendor self-declarations. Example: "DIgSILENT GmbH · PowerFactory 2024 SP5 (x64) · CGMES 3.0 / Scheme 3.0.2 · Declaration dated 18/02/2025."

A separate artefact worth knowing about: the ENTSO-E Application Profiles Library, hosted on GitHub at github.com/entsoe/application-profiles-library, Apache 2.0 licensed. Latest patch v1.1.1 approved by the CIM Working Group on 7 October 2025; v1.1.0 was ICTC-approved on 11 September 2025. The library contains the CGMES and Network Codes RDFS and SHACL artefacts. It does not contain GB-specific profiles. Those live separately on the BSI Engagement Hub.

Data Best Practice Principles 9 and 11.

Section 8 of the Form of LTDS cross-references "Principles 9 & 11 of the DBP Guidance and Supporting Information". These two principles together govern the security and openness of LTDS data. There is widespread confusion about what they actually say, including in summaries circulating online. Here are the actual titles, taken verbatim from Ofgem's Data Best Practice Guidance v3.0 (April 2024, the version current at the LTDS Direction date).

The 11 Principles, in full

1. Identify the roles of stakeholders of Data Assets
2. Use common terms within Data Assets, Metadata, and supporting information
3. Describe data accurately using industry standard Metadata
4. Enable potential Data Users to understand Data Assets by providing supporting information
5. Make Data Assets discoverable for potential Data Users
6. Learn and deliver to the needs of current and prospective Data Users
7. Ensure data quality maintenance and improvement is prioritised by Data User needs
8. Ensure Data Assets are interoperable with Data Assets from other data and digital services
9. Protect Data Assets and systems in accordance with Security, Privacy and Resilience (SPaR) best practice
10. Store, archive and provide access to Data Assets in ways that ensure sustained benefits
11. Treat all Data Assets, their associated Metadata and Software Scripts used to process Data Assets as Presumed Open

Section 8 of the FoS asks DNOs to apply Principle 11 (Presumed Open, with Open Data Triage as its implementation process) constrained by Principle 9 (Security, Privacy and Resilience). Open Data Triage is not Principle 9. It is the procedure the Data Custodian runs under Principle 11 to decide what is safe to publish. Plenty of summaries online get this round the wrong way. The actual DBP Guidance does not.

Common pitfalls when working with LTDS data, and how to get it right

Three kinds of mistake show up most often. Knowing them is the difference between reliable data and data that cannot be trusted.

Pitfalls when building the model, and how to get it right

Pitfalls when building or choosing tooling, and how to get it right

Pitfalls and how to avoid them

Tools, sample data, and five workflows.

Reading the LTDS is one thing. Doing something with it is another. The tools below are the ones in active use across LTDS work. Each entry gives what it costs, why it matters for an LTDS reader, and one thing it can do inside five minutes.

Sample data and reference profiles

SHACL and RDFS tooling

Power system analysis software

The first three are the commercial extractors and importers most likely to be in a DNO procurement list. The last two are open source.

The GB public artefacts

Each of the six DNO groups publishes its own LTDS landing page. Four of them now route readers through dedicated open-data portals; ENWL and SPEN still publish from their corporate pages. The Capacity Heatmap publishes alongside the LTDS, on the same portal.

Plus the regulatory and governance routes already named in the sourcing block above: the Ofgem decision page, the BSI Engagement Hub, and the ENTSO-E Conformity Registry at entsoe.eu/data/cim/cim-conformity-and-interoperability/.

Five things to do with the published LTDS data

1. Open a real DNO LTDS package. Download the latest CIM zip from any of the landing pages above. Unzip. The result is an EQ XML, an SC XML if Stage 2 onward, a SYSCAP XML, and a Header. Open them in a plain text editor first; a modelling tool can come once the file structure is clear.
2. Validate against SHACL with pySHACL. Install pySHACL with pip, point it at the EQ SHACL file from the BSI Hub and the EQ XML from the DNO. The report severity sh:Violation is non-compliance; sh:Warning is review; sh:Info is informational.
3. Trace an mRID across files. Pick any cim:Substation in the EQ file and copy its mRID. grep for that mRID across every other file in the publication. Every reference is a relationship the model declares.
4. Apply a Difference Model. Take a Stage 3 publication. Open the Full Model and a Development Project Difference Model side by side. The forward-difference list adds objects; the reverse-difference list removes objects. Each delta is glued by mRID.
5. Find a substation in the Heatmap. Open the relevant DNO's Capacity Heatmap. Search for any substation by name. The Heatmap returns the firm capacity and the constraint flags. Cross-reference the same substation in the LTDS by mRID. The picture only makes sense when both layers are open.

If a workflow stalls, the right place to ask is on the BSI Engagement Hub, not on a vendor support line. The Hub's weekly digest is where workgroup-level questions get answered fastest.

Where to engage.

There are three public update routes. The regulatory documents move at one speed. The technical artefacts move at another. International escalation moves at a third.

DNO modellers raise issues on the Hub. Software vendors publish their Declaration of Conformity on the ENTSO-E Conformity Registry. Connection applicants start with their DNO's licence-area page. Researchers and journalists go to the Ofgem decision page at ofgem.gov.uk/decision/long-term-development-statement-direction for the legal instruments. Most readers will use more than one of these at different points.

Validate a CIM pack against the official v2.1.1 SHACL

The validator below loads an illustrative sample, or takes a pasted or uploaded CIM XML, and runs it against the official LTDS v2.1.1 SHACL shapes. The report groups findings by severity and can be downloaded.

What to hold onto, and what to do next

The duty to publish a forward-looking grid model has not changed since 2002. It sits on a single chain: the Electricity Act 1989 s.6(1)(c) to the Distribution Licence to SLC 25.2 to the Direction OFG1164 to the Form of LTDS. What changed in 2024 was the data layer, from documents to a validated CIM model. What changed on 13 May 2026 was the shape of Stage 2 and the timing of Stage 3 production, with both publication dates held. Governance of the technical artefacts now sits with BSI on the Engagement Hub; the regulatory instruments stay with Ofgem.

In practice: cite the instrument chain rather than a summary, check the "last verified" date here against the current Ofgem decision page, validate any DNO file against the v2.1.1 SHACL shapes before relying on it, and consult the LTDS together with the Capacity Heatmap so observed and forecast figures are not confused.

What follows below is reference material: a numbered source register every claim above traces to, and a scoped list of what is not covered here. Inline definitions are available throughout, on the underlined terms.

Appendix A · reference, not argument

Source register.

Every numbered citation here points to one of the following primary sources. The regulatory instruments are on the Ofgem decision page. All BSI Engagement Hub technical artefacts (Annexes, Appendices, RDFS and SHACL profile shapes, the issues-addressed changelog, the GB CIM Advisory Group materials, and the GB CIM governance documents) are cited collectively under cim.bsigroup.com. Third-party standards (IEC, ENTSO-E, W3C, IETF, DCMI) keep their original sources.

Other sources drawn on while writing these notes: ENTSO-E CGMES Conformity and Interoperability page (CAS v3.0.2 approved 25 August 2024 by the CIM Working Group; CAS v3.0 approved 29 September 2021 by ENTSO-E SOC); ENTSO-E Application Profiles Library v1.1.1 (7 October 2025, Apache 2.0); W3C SHACL Recommendation (20 July 2017); IETF RFC 7946 GeoJSON (August 2016, Standards Track); DCMI Metadata Terms (Recommendation, 20 January 2020); Ofgem Data Best Practice Guidance v3.0 (April 2024) and v3.5 consultation draft (June 2025); NESO GC0139 Workgroup Consultation (December 2024 to May 2025); the joint DESNZ and Ofgem Connections Action Plan (22 November 2023, 108 pages).

Appendix B · reference, not argument

What these notes deliberately leave out, and why

To make the scope of what is here clear, the following is what these notes do not cover, and the reason.