Proofs, Not Data

Grid Signal — Issue #013 · October 2026

One cable, three resources

At 13:20 a fault takes one of two cables out of service in a distribution grid. Both carried power out of the area, towards the transmission grid. Now everything flows through the remaining one. Three flexible resources sit behind it: a battery that can add 3 MW, small combined heat and power (CHP) units that can add 2.5 MW, and a biogas plant that can add 4 MW. Together that is 9.5 MW of extra export. Under the assessed conditions, the cable has room for 6 MW more.

At 14:00 the transmission operator (TSO) plans to activate reserve from exactly these three. Each one is fine on its own. Together, today, they are not.

The TSO cannot see the cable. The distribution operator (DSO) can, but it does not know which bids the TSO is about to call. Each side holds half the answer.

Today this gap is closed with limits agreed in advance, a phone call, or an operational data exchange. Standing limits are blunt, so useful flexibility can be blocked on normal days. Calls and system logs exist, but each side keeps its own. When something goes wrong, it takes work to reconstruct who knew what, and when — and the two sides may not reach the same answer.

(The scene and all numbers in this issue are illustrative.)

Don't send the model. Send the answer.

A lot of data already flows between operators, and it helps. But for this decision the TSO does not need the DSO's grid model. It needs an answer.

So I would design it the other way round. At 13:28 the TSO's dispatch system sends a short question: "Can these three resources deliver 9.5 MW together between 14:00 and 14:15? Please answer by 13:40."

At 13:30 the DSO's system replies: "Together, at most 6 MW. Valid until 14:15. Based on the grid as switched at 13:20."

In this example the biogas bid is all-or-nothing. So the TSO plans the battery and the CHP units — 5.5 MW — and leaves the biogas plant out. It confirms that it received the answer. The grid model never left the DSO.

Three properties make this more than an email:

• The answer is signed. Anyone can check later that it came from the DSO and was not changed.
• The answer belongs to one question. It cannot be reused for another.
• The answer expires. It is valid for one time window and one known state of the grid. When either changes, it stops being an answer.

That is the whole idea: proofs, not data. "Proof" in a narrow sense — of what was asked, what was answered, by whom, on which grid state and until when. Not proof that the physics was right. The DSO still runs its own security assessment; the signature makes it traceable.

The legal basis already exists: the EU System Operation Guideline lets a DSO, in cooperation with the TSO, set temporary limits before reserves are activated, under procedures both agree (Art. 182). Parts of the picture are also running already: UK Power Networks shares data with the system operator in real time, Australian network operators publish export limits per connection instead of their models, and the joint ENTSO-E / DSO Entity report names both temporary limits on bids and audit trails for data exchange. What I would add is a common form for the answer itself: one record that both sides can check in the same way.

You use this pattern every day

When you pay by card, the shop terminal does not get your bank balance. It asks your bank one question: can this card pay €40, now? The bank returns yes or no and an approval code. The approval belongs to that one payment and lapses if unused. In a dispute, everyone refers to that code.

Systems between companies work the same way: short-lived, signed permissions, not copies of each other's databases. The grid case has higher stakes.

How I would build it

Both operators keep their core systems. Three new pieces sit between them. None of them is exotic, but the integration is real work.

On the DSO side: an answering service. It sits in front of the tool the DSO already uses to check its grid. It checks that the question really comes from the TSO and is one of the agreed questions. Before the tool runs, it saves a snapshot of the inputs — switching state, forecasts — in the DSO's own archive. The answer carries a fingerprint of that snapshot and names the tool version and settings used. With both, the DSO can re-run the check later and show the same result. The check also counts the answers the DSO has already given for the same cable that are still valid. An answer says what is feasible; it does not reserve the cable. Then it signs the answer, with a key held in dedicated key hardware. And it keeps watching the grid while an answer is valid.

On the TSO side: a gate. Before dispatch uses a limit, the gate checks it. Is the signature valid? Is the key still valid? Is this DSO allowed to answer for this area and this product? Does the answer belong to our question? Is it still inside its window? Has a newer answer replaced it? Has the DSO confirmed recently that it still stands? Only then does the limit go into dispatch. If any check fails, the answer counts as missing.

Between them: an agreement that machines can read. The two operators already have a procedure. I would write the parts that matter into a small document both sign: which DSO service may answer, for which area and products, how long an answer may stay valid, which questions the TSO may ask. Each side keeps its own keys and they exchange the public half once. No central platform, no new party in the middle. The signature shows who said what; who pays if it was wrong is still settled in the agreement.

The agreed questions need standardising. "Can this set of bids deliver this much of this product in this window?" covers a lot. So does what sits around them: shared names for resources and connection points, which power direction counts as positive, what a product means, how updates are ordered, how keys are replaced and withdrawn. That is real work — but a much smaller job than agreeing a shared grid data model.

Both sides store the question, the answer and the confirmation. They do this next to dispatch, not in its way: if the archive is slow or down, dispatch does not wait, and the signed messages wait in a local buffer until the archive is back. One step further, both could publish a fingerprint of each answer, within minutes, to a log neither of them controls. That cannot prove a record was complete or true. It does prove that nobody changed it after it was published — not one side, and not both together.

In the terms of Issue #007, these are the five primitives applied to one operational answer. On the wire, the answer is small:

ANSWER
to question     Q-0912 (+ its fingerprint)
from            DSO answering service, key K7
allowed by      agreement version 3
says            at most 6.0 MW, the three together, upward
valid           13:30 – 14:15
grid state      as switched at 13:20
inputs          fingerprint of the saved snapshot
signature       over all of the above

When a valid answer is wrong

At 13:50 the DSO has to switch again. The room on the remaining cable falls from 6 MW to 4 MW. The 13:30 answer still checks out perfectly: valid signature, valid key, inside its window. It is correctly signed — and now unsafe. If the TSO activates 5.5 MW at 14:00, the cable is overloaded.

This is the hardest part of the design. Normally the TSO asks and the DSO answers. But only the DSO knows when its own answer has gone stale, so here it speaks without being asked. So its service sends an update on its own: "Replaces the 13:30 answer. Grid switched again at 13:50. The three together: at most 4 MW." The TSO's gate drops the old answer as soon as the update passes its checks. The TSO re-plans and activates only the battery, 3 MW.

But an update only helps if it arrives. The gate cannot drop an answer when it does not know a newer one exists. So silence must never count as "nothing changed". While an answer is live, the DSO's service also sends a short signed heartbeat every few minutes: still valid, grid unchanged. Before the TSO uses an answer, the gate checks that the last heartbeat is recent. If it is not, the answer counts as stale. Signed permissions in IT have the same weakness — a withdrawal takes time to reach everyone — and the same fix: short lifetimes plus a regular sign of life.

Behind short windows, updates and heartbeats sits a fallback agreed in advance: if no answer arrives by the deadline, no heartbeat is fresh, or no confirmation comes back, nobody relies on the message and the existing agreed procedure applies — the standing limit, the phone call. The agreement also has to say when each side treats a message as missing, and how both compare notes afterwards.

Elsewhere this is normal. In South Australia, home solar systems on flexible exports "ramp back down to 1.5kW or 0kW" when their internet connection fails. Very different scale, same habit.

What the record can show later

After 14:15, the operators link the messages to what actually happened. I would keep three things apart:

• Delivery: what the battery actually delivered.
• The grid: what the DSO measured on the shared cable.
• Open questions: what nobody can know. The CHP units and the biogas plant were not called, so nobody knows if the cable would have held them. The 4 MW limit was never tested at its edge.

The third part matters most. A successful activation does not prove the limit was right. A blocked resource leaves no evidence either way. And a DSO that always answers very cautiously would look perfect while blocking useful flexibility. So the record must also show what was left out: here, 6.5 MW of offered flexibility.

Over time, these records become a track record: what each operator said, and what then happened. A reader of an earlier issue put it well: the constraint is trust, not power — flexibility that nobody can verify is much less useful to the grid. The record is what makes it verifiable. That is already a lot.

Where I would start

Not with a platform. With one DSO and the TSO it already exchanges limits with today.

Run it in shadow mode first: every limit that flows today is also asked for, signed, confirmed and stored, but nobody acts on the new messages yet. Then measure four things:

• How often an answer would have been stale at the moment it was used.
• How often both sides had the same view of which limits were active.
• Whether the DSO can re-run an old answer from its snapshot and get the same result.
• How long one disputed case takes to investigate, before and after.

Only when those numbers are good and the rules are agreed does dispatch rely on the answers.

Ownership stays simple. The DSO owns its answering service and its keys. The TSO owns its gate. Both own the agreement. The first benefit is concrete: fewer disputes, and faster answers when one happens. The bigger one is what the pilot should measure: whether current, signed limits let automated coordination use flexibility that blunt standing limits block today.

The same pattern, one level down

The same shape fits other questions. A DSO could tell its TSO: "In this area, 94 % of 312 MW of rooftop solar and battery capacity is verified against protection settings version 3, as of 1 October." But a firmware version alone does not prove what is actually set in the device. That chain — from the device up to the area statement — is the next issue.

The decision travels

In Issue #012, a depot kept a signed power envelope that the grid operator could check. This is the same kind of record, from the other side of the connection point. Nobody hands over their model.

The data stays home. The decision travels — with an expiry date.

Sources

• Regulation (EU) 2017/1485 (System Operation Guideline), Article 182 — https://www.legislation.gov.uk/eur/2017/1485/article/182
• UK Power Networks, MW Dispatch — https://dso.ukpowernetworks.co.uk/mw-dispatch
• SA Power Networks, Flexible Exports eligibility — https://www.sapowernetworks.com.au/your-power/smarter-energy/flexible-exports-eligibility
• ENTSO-E / DSO Entity, Joint Progress Report on Use Cases & Digital Twin Solutions (30 January 2026) — https://eepublicdownloads.blob.core.windows.net/public-cdn-container/clean-documents/Reports/2026/260130_JTF_TSO-DSO_Technical_Report_Use_cases_digital_twin_solutions_v3.pdf
• Grid Signal #007, Five Primitives No One Assembled — https://gridsignals.de/five-primitives-no-one-assembled/
• Grid Signal #012, The Robotaxi Depot Has a Second Job — https://gridsignals.de/the-robotaxi-depot-has-a-second-job/