The Witness Problem

Last issue I ended on a question I wanted to sit with: if a working reference is what the flexibility market eventually needs, what does it actually have to do?

Not the technology. The properties.

I’ve been reading a lot since then — network codes, settlement methodologies, a handful of vendor specifications — and the thing that struck me is how much of the argument about “neutral verification” gets stuck at the wrong altitude. People jump straight to the implementation layer: blockchain, or a central registry, or a standard data model. But before any of that is useful, there’s a more basic question nobody seems to have written down plainly: what does a flexibility settlement record have to prove, and to whom?

That’s what I want to try in this issue. Not a proposal. A specification of the question.

I should say upfront — I’m not a grid engineer. I’m writing this from the outside, drawing on how verifiable records work in other domains and trying to map the constraints honestly. If parts of this land wrong for people closer to the operational detail, I’d genuinely like to know where.

Who the record has to convince

The mistake I think is easy to make is to design a record for a single audience. The DSO wants one thing, the aggregator another, the regulator a third. A record that satisfies only one of them is a private log, not infrastructure.

The three parties who all have to be able to trust the same number are, roughly:

A regulator or market operator, who needs the record to be auditable after the fact — months or years later, by a party who wasn’t present at the time and can’t be expected to take anyone’s word for anything.

A disputing aggregator, who needs to be able to reconstruct how a specific settlement was calculated, down to the version of the baseline methodology and the measurement inputs that fed it, without having to ask the counterparty whose number they are disputing.

A sceptical industrial customer — the end party whose flexibility is being dispatched and whose payment depends on the result — who needs to believe the settlement is honest without having the engineering capacity to audit the whole chain themselves.

The test for any property below is: does it hold for all three, or does it privilege one of them over the others.

Property 1 — Provenance

Every number in the record has to answer the question: who produced this, when, and from what inputs.

That sounds trivial. It isn’t. Flexibility settlements today are built from chains of derived values — a measured meter reading becomes a delta against a calculated baseline, which becomes a delivered quantity, which becomes a settlement amount. Each step is a transformation. Each transformation has an author, a timestamp, and a set of inputs. Most systems today record the final number. Some record the inputs. Very few record the chain.

For a record to be trusted by a party who wasn’t there, the chain has to be part of the record — not an attachment, not a log file somewhere, but a first-class property of the thing being verified.

This is the bit that looks most familiar from financial services. A trade confirmation isn’t just the price — it’s the price, the venue, the counterparty, the time, the reference data version, and the signature of the party asserting it. You can argue about any of those pieces, but you can’t argue about what was asserted at the time.

Property 2 — Reproducibility

Given the inputs and the ruleset, a third party should be able to re-derive the output and get the same answer.

This is the property that most flexibility settlements quietly fail. Baseline calculations use methodologies that are documented but not always fully specified — “ten working days, excluding event days, weather-normalised” can mean half a dozen things depending on which weather dataset, which normalisation curve, and which definition of “excluded” is applied. The TSO runs the calculation internally and publishes the result. The aggregator can approximate it, but can’t reproduce it exactly, because the exact implementation isn’t part of the record.

Reproducibility doesn’t require everyone to use the same software. It requires the methodology, the parameters, and the inputs to be specified tightly enough that independent implementations converge on the same number — or surface the disagreement cleanly when they don’t.

Property 3 — Ruleset versioning

The rules change. That’s not a bug — market design evolves, baseline methodologies get refined, codes get updated. But a settlement dispute months or years later is about which rules were in effect at the moment of the event, not which rules are in effect now.

The record has to name its own ruleset version. Not in a footnote. As a mandatory field.

This is the property I see most commonly assumed rather than implemented. Internal systems know which version of the rules they ran under. That knowledge rarely makes it into the data that counterparties see. Which means a dispute two years later becomes an archaeology exercise — what version of what methodology was live on 14 March 2026 — rather than a clean reference to an explicit identifier.

Property 4 — Tamper-evidence

Records can be wrong. That’s fine — corrections are part of any serious system. What can’t happen is silent rewriting.

The record has to be structured so that any change after publication leaves a visible trace. Not prevented — visible. A correction is legitimate. A silent amendment is not.

The cryptographic primitives for this are decades old — signed records, append-only logs, Merkle-style commitments. None of them require novel infrastructure. What they require is that the record be treated as immutable at the representation layer, with corrections modelled as new records that reference the ones they supersede.

Most energy settlement systems today are built on databases that are happy to let you update a row in place. That’s the gap. It’s not technical; it’s architectural.

Property 5 — Independent verifiability

A regulator auditing a dispute three years later should be able to take the record, the signatures, and the published ruleset version, and verify the result without calling anyone.

This is the property that separates infrastructure from middleware. Middleware says “ask us, we’ll check it for you.” Infrastructure says “here is what you need to check it yourself.”

The industries that built durable market infrastructure — securities settlement, interbank payments, certificate authorities — all ended up here eventually. Not because anyone wanted it, but because asking-the-issuer didn’t scale. Once you have millions of counterparties and billions of events, the only verification model that works is one where any party can check any record on their own.

Flexibility markets aren’t there yet in volume. But they will be, probably faster than the current architecture expects.

The hard edges

Four tensions the spec has to handle honestly:

Privacy vs. verifiability. Dispatch profiles are commercially sensitive. Verifiable ≠ public. Selective disclosure and hashed commitments exist — but designed in, not bolted on.

Measured vs. modelled. A meter reading is a fact. A baseline is a prediction. Stop treating them as the same kind of number.

Real-time vs. auditable. Settlement needs speed. Audit needs permanence. Different layers, same underlying facts.

What stays off the record. Regulatory discretion belongs in the record as a reference to the decision, not the decision itself. Don’t try to compute judgement.

The combination is the point

None of these properties are new. Each one already exists somewhere — financial messaging, certificate transparency, supply-chain attestations. What’s missing is the specific combination, written plainly enough that a regulator, an aggregator, and an industrial customer can argue about the same document.

That’s the gap worth naming before anyone argues about implementation.

What’s next

Next issue (#006): hold the five properties up against a real dispute or baseline methodology and see where they break. If you’ve lived through one you’d talk through anonymously — I’d like to hear it.

I’d rather be wrong in public than approximately right in private.

Sources and further reading

- ACER Framework Guideline on Demand Response and consultations — ACER proposal, March 2025

- Baseline methodology comparisons — smartEn Market Monitor for Demand Side Flexibility 2024

- Certificate Transparency as a model for tamper-evident public records — RFC 9162

- Software supply-chain attestations (analogous pattern for signed, reproducible records) — SLSA framework

- Selective disclosure primitives — W3C Verifiable Credentials Data Model 2.0

---

Grid Signal covers the intersection of grid modernisation, distributed trust, and digital infrastructure for energy. No hype — just structural insight for practitioners.

If a colleague would find this useful, forward it.