A data standard enabling environment

I’ve spent a lot of time over the past couple of years working on data standards for planning permissions.

We’re* trying to define what information must exist in a planning application and its decision, in a consistent, reusable form that any system can work with.

It’s important work. And I’ve come to believe that getting the standard right is, on its own, not enough.

Here’s why.

Think about water.

Gemini created illustration to show leaky ill fitting pipes and ‘data’ slopping around

A water quality standard tells you what safe water looks like. The right pH. The acceptable levels of contaminants. The definition of “clean.”

But a water quality standard doesn’t clean the water. For that, you need pipes. You need pumping stations with enough pressure to move water through the system. You need filtration. You need people who understand how the system works and can maintain it. And you need someone with the authority, and the funding, to keep it all running.

Without those conditions, the standard is just a document. The water is still unsafe.

Data standards work the same way.

The instinct when data doesn’t work is to reach for a better standard.

More fields. Tighter definitions. Clearer rules. And sometimes that helps. But it often treats the symptom rather than the cause.

Consider planning data. Two organisations, working from the same public sources, can legitimately produce different outputs. Not because either is wrong. But because there are no shared definitions of what a “development” is, no agreed rules for how to handle amendments, no governance over what happens when the source information changes.

The pipes are different sizes. The filtration rules differ. Nobody is minding the pumping station.

Writing a better, or another, standard doesn’t fix that.

In my experience, a data standard needs five things around it to do its job.

These aren’t new ideas. I wrote about the enabling environment for data sharing back in 2022. But I’ve come to think the argument applies even more sharply to data standards specifically, because standards carry an implicit promise: implement this and things will work. That promise is only kept if the conditions are right.

Infrastructure — the pipes.

The systems that carry data from one place to another. If those systems can’t accept structured data, or if every council’s system is a different pipe size, the standard can’t flow through them.

Policy environment — the pumping station.

Someone has to have the authority to say: this standard applies, and here’s what happens if it doesn’t. Without that mandate, compliance is optional. And optional standards tend to produce optional results.

Expertise — filtration.

You need people who understand both the domain and the data. Without that combination, standards get implemented inconsistently, edge cases get handled differently, and the outputs vary anyway.

Funding — the investment to build and maintain the infrastructure.

Standards don’t implement themselves, and keeping them current as policy changes is ongoing work, not a one-off cost.

Coordination — the pressure gauges and maintenance schedules.

The conversations that have to happen between councils, suppliers, central government, and the wider community to keep the whole system aligned. Without coordination, each actor optimises locally and the system as a whole doesn’t work.

Get Mike Rose’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

But these five components aren’t just a checklist. They’re a shared language.

One that lets everyone involved, councils, suppliers, policy teams, programme leads, ask the same question from their different positions: are we doing our bit to make the water drinkable?

The standard is what defines “drinkable.”

This is where I think the water metaphor works

Gemini created illustration to show much better fitting pipes, with attention being paid, and ‘data’ flowing more smoothly

A water quality standard doesn’t just describe what good water looks like. It anchors the whole system. The test of compliance isn’t whether the pumping station is working, or whether the pipes are the right size, or whether the filtration chemicals were procured correctly. The test is whether the water coming out of the tap is safe to drink.

That single definition, applied at the tap, pulls the entire system upstream toward it. The pipes have to work. The filtration has to work. The pumping station has to work. Not because each has been regulated separately, but because none of them can claim success unless the water is actually drinkable.

For planning permissions, this is precisely why the decision stage standard matters so much. A planning decision is the tap. If we define clearly what data a valid planning decision must contain, and make that definition enforceable, then everything upstream, how applications are submitted, how software handles the data, how councils record outcomes, has to align with it. The submission standard gets pulled through the system by the weight of the decision standard.

Compliance isn’t about testing each component. It’s about whether the water is drinkable at the end.

When adoption is slow, the natural response is to add more.

More mandating. More technical specifications. More layers of requirements, each one a response to the previous layer not delivering quite enough.

This is understandable. But it risks testing the pipes and the pumping station in isolation, rather than asking whether the water is actually drinkable. You can mandate a data format, tick that box, mandate a software schema, tick that box, mandate an API layer, tick that box, and still have data that nobody can reliably use if people are not complying with the standard.

Worse, each additional layer can obscure the question that matters. The goal isn’t compliant pipes. It’s drinkable water.

My enabling environment framework helps here, not just as analysis but as a practical tool. If all the actors involved share a language for the five conditions, they can orient their individual efforts toward the same outcome, rather than each optimising their own section of pipe and assuming the rest will follow.

So what does this mean in practice?

For planning permissions, it means that writing a good specification is the necessary start but not the finish line.

The standard has to be anchored at the right point in the process, with the conditions that allow it to pull the system toward it: tools that make compliance testable at the outcome level, procurement requirements that embed the obligation in contracts, expertise in the market to implement it, and a clear governance model for what happens when it needs to change.

That’s a harder argument to make than “here is the standard, now comply.” It doesn’t produce a single deliverable. It requires sustained effort across a community that doesn’t always talk to each other, using a shared language to ask a shared question.

Gemini created illustration to show the focus being the ‘data’ at the point of drinking.

But the question is simple enough. Is the water drinkable?

*Also listen to an interview of Colm Britton and myself by Gavin Freeguard discussing this work