The brief usually arrives in one line: make this application fit Common Ground. Then the search starts for what that means for the code, the database, and the integrations already in place.
Common Ground is the information architecture vision that Dutch municipalities and the Association of Netherlands Municipalities (VNG) use to rebuild the way they handle data. Data is separated from the applications and processes that use it, and data is used many times over at its source. A five layer model, published as part of the Dutch municipal reference architecture GEMMA, turns that vision into architecture.
Below you'll read what those five layers mean for the software you commission or change: where your data lives, how you expose it through APIs, what happens to an existing custom application, how you connect to Open Zaak, and which questions to put to your vendor.
What Common Ground is and why it has five layers
Municipalities, chain partners, software vendors, and the VNG work on Common Ground together. Two principles carry the whole thing. Data is separated from the applications and processes that use it, and data is used many times over at its source.
Four working agreements follow from those two principles. Parties standardize information models per domain. They make data sources available through standardized APIs. They agree on one standardized exchange mechanism. And data stays at the source, where the source holder remains the owner of the records.
The five layer model is the tool that writes those agreements down as architecture. VNG Realisatie describes it as an aid for describing the information architecture needed to realize the vision. Grouping functions into layers shows which ones belong to running a process and which ones belong to recording and supplying data. For a build team, that is the point: for every piece of functionality you know which layer it belongs in and which layer it talks to.
The five layers of Common Ground in order
From the bottom up, the five layer model looks like this.
- Data sources. Generic functions for recording and disclosing data, preferably in a standardized way and within the limits the law sets. This is where the data itself lives.
- Services. Generic functions for delivering services to consumers. GEMMA distinguishes system services, process services, and convenience services. This layer makes data from the sources usable for others.
- Connectivity. Generic functions that let consumers use the services offered by providers. In practice this layer is also called the integration layer.
- Process. Generic functions for driving processes and analyzing data. The logic behind an application, a check, or a decision sits here.
- Interaction. Generic functions that give users responsible access to municipal information. Think of employee screens and portals for residents and businesses.
The layers work independently and stay closely connected at the same time. A service consumer supplies the interaction and the process layers. A service provider supplies the services that let the consumer reach the data. That split also decides what you ask of which vendor.
Where your data lives and how you expose it
The first question for any application is which role it plays. If your application is the source of certain data, it belongs in the bottom two layers and has to make that data available through a standardized API. If it uses data that another system owns, it is a consumer, and what sits in a local table today becomes a call to that source.
For your database, that means three things. Copies of data owned elsewhere either disappear or become a cache with a clear expiry. Data you do own gets its own information model and a matching API. And every piece of data gets one place where it is created and changed.
The API itself follows the NLGov REST API Design Rules, maintained by Logius. They sit on the list of mandatory open standards kept by Forum Standaardisatie, so your build team designs to those rules rather than to house style. How an integration works technically, with endpoints, notifications, and error handling, is covered in our article on API integration. Our approach to design and documentation is described on the API development page.
The third layer covers how you reach services at other organizations. Since 2025 the standard there is Federated Service Connectivity, or FSC. The Programmeringsraad GDI designated FSC as a standard in December 2024. It succeeds NLX and is maintained by Logius, Stichting RINIS, and the VNG. Version 2.0 was picked up in the Digikoppeling release of 21 April 2026. For your own application it means connections to other organizations run through one uniform mechanism instead of a separate arrangement per counterparty.
What the layers mean for an existing custom application
Most applications running at municipalities today fill all five layers at once. The screens, the process rules, the integrations, and the storage sit in one codebase, and the data lives in tables only that application understands. Such an application does not have to go before you start with Common Ground.
The practical route runs from the bottom up. Start with exposure: build an API for the data your application owns, using an information model that matches the standard for that domain. Then lift the process rules out of the screens, so the logic can be called without anyone pressing a button. Replace the interaction layer last, for example with a portal that runs on the same APIs as the employee screens.
That order exists for a reason. As long as data and logic are tangled, every change to a screen moves business rules along with it. Once the bottom layers can be called, you retire parts of the old application without service delivery stopping. We use the same approach when modernizing legacy systems outside government: make the data and the logic reachable first, replace the outside afterward.
Connecting to Open Zaak and the case handling standards
Dutch case handling, known as zaakgericht werken, has its own standard from VNG Realisatie: the APIs for zaakgericht werken, abbreviated to ZGW. Version 1.7 was released on 9 June 2026. Version 1.8.0 is out for consultation as a draft until 23 September 2026. The standard covers six APIs:
- Catalogi API for case types and their metadata
- Zaken API for cases and their progress
- Documenten API for documents and information objects
- Besluiten API for formal decisions
- Autorisaties API for permissions across all the APIs
- Notificaties API for events that other components react to
Open Zaak is a widely used implementation of the bottom two layers: a data and services layer that follows this standard. It is open source under the EUPL, was built by Maykin Media for a group of municipalities led by Dimpact, and is maintained by the Open Zaak community with support from the Codebase Stewards of the Foundation for Public Code. Open Zaak offers the Zaken, Documenten, Catalogi, Besluiten, and Autorisaties APIs; the Notificaties API runs through the separate Open Notificaties package.
Two properties surprise teams working with this for the first time. Permissions are granted per case type, information object type, and decision type, so your application gets targeted access to exactly the types it needs. On top of that, the Notificaties API asks for event driven thinking: your application subscribes to changes instead of polling the source on a timer. Both choices belong in the design before the first line of code is written.
What to ask your vendor
Ask for concrete build requirements rather than a statement that a package is ready for Common Ground. These questions produce usable answers:
- Which layer of the five layer model does this product fill, and which layers does it leave open for others?
- Is all the data the product holds reachable through a documented API that follows the NLGov REST API Design Rules?
- Which version of the APIs for zaakgericht werken does the product support, and how quickly does it follow a new release of the standard?
- Does the product support FSC for connections with other organizations?
- Does data stay behind in the product that really belongs at a source, and what happens to it on replacement?
- How much work is it to replace the product without losing data?
That last question tells you the most. A product that sits neatly in one layer can be replaced. A product that quietly fills all five ties you to the vendor that built it.
We have been building custom software and integrations for more than 30 years, with 30+ engineers in Nijmegen and Sarajevo and 100+ projects delivered, working to ISO 9001 and ISO 27001. That work includes a grant administration platform, MRO software for aviation, and RFID in the supply chain. Different domains from Dutch municipal practice, with the same engineering question: keep data at its source, expose it through APIs, and untangle an existing application step by step. Our approach to integrations is on the software integration page, and the government page shows the environments we work in. Book a call if you want a second opinion on which layer to tackle first.
Frequently asked questions
What is Common Ground?
Common Ground is the information architecture vision that Dutch municipalities and the VNG use to rebuild their information provision. Its two principles are that data is separated from the applications and processes that use it, and that data is used many times over at its source. The five layer model in the GEMMA reference architecture describes the architecture that goes with it.
What are the five layers of Common Ground?
From the bottom up: data sources, services, connectivity, process, and interaction. The bottom two layers record data and expose it through APIs. The connectivity layer links consumers to providers. The top two layers drive processes and give users screens and portals.
Do you have to replace an existing custom application for Common Ground?
Rarely in one move. The common route starts by exposing the data the application owns through a standardized API. After that you make the process rules callable, and you replace the screens last. Service delivery keeps running while the application comes apart into layers.
What is the difference between Open Zaak and the APIs for zaakgericht werken?
The APIs for zaakgericht werken are the standard from VNG Realisatie: a set of specifications for cases, documents, catalogs, decisions, permissions, and notifications. Open Zaak is software that implements that standard, open source under the EUPL, and it fills the data sources and services layers of the five layer model.
