3. Our approach

Our hypothesis is that the solution to the problem lies in a shift in the way we ask for information.

From documents to data
Instead of asking users to provide information by uploading documents (forms, reports, statements and drawings) that can only be read by humans, wherever possible, planning services should ask for information in the form of structured data that can be read by humans or machines.

How will this help reduce invalid planning applications?

This allows us to do a few key things.

Data automations
It allows data to be pulled in from external sources, so users don’t have to look-up (or even know about) planning constraints that apply to their property, make a location plan, or calculate the correct fee for themselves
Dynamic forms
It allows forms to respond immediately to the information already given, so users are only asked for information that is relevant to their project.
Web form validations
It allows omissions to be prevented from happening before the user can click submit, in the same way that many online forms do (eg when you buy insurance online).
Rules as code
Knowledge of specific policies and their implications for the user’s application can be coded into the service, so users don’t need to be experts.

There are also some important, more general aspects to our approach:

APIs as a service

We expect the service to be used not just by human users, but also by third party software applications via a REST API. This will allow others to build complementary software applications that send data to, or fetch data from the service. (Note need for appropriate security measures.)

Modular, extendable and updateable

We will break down the service pattern into modules, allowing it to be easily understood, maintained, improved and extended by domain experts (eg planning officers, internal consultees, service designers and content designers) across different parts of government (local and national), ideally without knowing how to code. 

Standardise data

Use the same data strucures as other services and registers, to maximise interoperability.


We can’t solve everything in one go. Instead we aim to develop a version of the service pattern that works (a ‘minimum viable product’), and then expand it later. You can read more about our scope here.