The entry form of the Dutch algorithm register runs to dozens of fields. Purpose and impact, data used, technical operation, human intervention, start date, supplier. Anyone filling it in for the first time goes looking for answers that sit inside running software and were rarely written down anywhere.
That turns the register into a requirement for your application. It asks questions your system has to answer again and again, including after a release that changes the decision rules.
Below you'll read what the register asks for, which fields come out of your own application, how to log and version them, how to keep the public explanation current, and how to automate publication. We've built business software where decision rules and traceability meet for more than 30 years.
What the Dutch algorithm register asks for
The algorithm register of the Dutch government collects descriptions of algorithms that public bodies use in their processes. Citizens, journalists, and supervisors can see in one place what runs and why. The register currently holds 1,564 algorithm descriptions. On 1 January 2025 it held 675.
It matters outside the Netherlands too. Dutch public bodies stay responsible for algorithms they buy, so suppliers abroad are increasingly asked to deliver the information that fills these fields.
What you supply is set out in the publication standard. Version 1.0.0 defines 32 fields in four groups: general information, responsible use, operation, and metadata. Each description gets a publication category: high risk AI, impactful algorithms, or other algorithms. The Ministry of the Interior and Kingdom Relations runs the register together with ICTU, a Dutch public sector IT organisation.
Supplying descriptions is not yet a statutory duty for public bodies. The organisation that uses the algorithm stays responsible for the description and its accuracy, including when the algorithm comes from a purchased package. For teams building software for government, the work therefore moves into the build phase. The system has to be able to describe itself.
Which register fields come out of your own application
Some of the 32 fields come from documents that live beside the software: the legal basis, the impact assessments carried out, and the reference to the processing register. These fields come from the application:
- Status, start date, and end date. In development, in use, or out of use, with the month it happened. That is release data.
- Purpose and impact. What the rule set was built for and how citizens or companies encounter it.
- Data. An overview of the input the algorithm uses.
- Technical operation. Input, processing, and output, stating at minimum whether the algorithm is self learning.
- Human intervention. How a staff member uses, checks, and adjusts the outcome.
- Risk management. How you handle the risks you identified, including the monitoring you built.
- Supplier. The name of the external party, or a note that it was developed in house.
- Link to source code. The page where the code sits, when it is public.
- Your own source identifier. The reference to the algorithm in your own database.
That last field is small and worth the attention. Once your system holds its own key per rule set and that key sits in the register, you can look up either direction without keeping a spreadsheet in sync.
Record purpose, decision rules, and the decider in your data model
Most applications store the outcome of a decision and let the reasoning behind it evaporate. The register needs that reasoning, in a form that survives a developer moving code around.
So make the rule set a first class object in your data model, with a name, a purpose in plain language, an owner, a status, and a start date. Store the rules themselves as data instead of scattering them through the code. An administrator can then see which rules apply, and the technical operation field draws on the same source as the execution.
Record per decision what made it: which rule fired, which value tipped the outcome, and whether a staff member took over. That fills the human intervention field with a description that holds up. If the process runs fully automatically, the register expects you to say so as well.
We built a subsidy administration platform where applications are assessed against fixed rules. In systems like that, traceability is part of the design. You want to see for every assessment which rule applied and where someone stepped in, and that data only exists if you store it from the first release onward.
Data sources: which input the algorithm uses
The data field asks for an overview of what the algorithm uses. For an application that reads from five systems, that isn't a sentence someone writes from memory.
Declare the input per rule set inside your application: which field, from which source system, through which integration, and how fresh the value is. That declaration produces the overview the register asks for, and it pays a second dividend. When a supplier changes an API, you can see immediately which rule sets depend on it.
Much of this knowledge already exists. The mapping table you keep for an integration, with field names on both sides and the agreements for values that don't fit, is exactly the source for this field. We record those tables on every systems integration we build, because you need them for error handling and maintenance anyway.
Versioning and logging: which version made this decision
An algorithm description goes stale the moment the rules change. The register asks for information that stays current, and that only works when your application knows its own versions.
Give every rule set and every model a version number and a validity period. Store with each decision which version made it. A citizen's question about a letter from March then becomes a one minute query. Keep old versions readable even after they stop running. The register itself supports several versions of the standard side by side, so existing descriptions need not all be converted at once.
Log how often the algorithm runs as well. A scheduler, a queue, or a call from a form gives a different picture than the word "daily". A counter per period fills the technical operation field with real figures, and it shows you straight away when an integration fails.
We know that principle from maintenance software for aviation, where for every part it has to be traceable which procedure and which version applied. Software that keeps that record answers the register's questions almost by itself.
Plain language for citizens next to the technical explanation
The register serves two groups of readers: people with little knowledge of algorithms and people who want to see the mechanics. For the broad group the target is B1, the Dutch plain language level, and that applies to the fields people read most.
In practice that means two texts per rule set: a short explanation in plain language and a technical description. Keep them with the rules themselves, in the same repository, and tie them to the version. The explanation then changes when the rules change.
Put that link in your working agreements too. A change to a decision rule only ships in a release once the public explanation has been updated and read by someone who didn't write the rule. That costs 15 minutes per change and stops the register from showing a description that trails three releases behind.
Automating publication to the algorithm register
There are two ways to supply a description: the web form or the API. The web form works well for the first few descriptions. Once you have ten rule sets that change a few times a year, manual updating becomes the weakest link.
The register's supply API is described with OpenAPI and lives at algoritmes.overheid.nl/aanleverapi. The path carries the version of the publication standard, followed by the organisation you supply on behalf of. You fetch a token, send it in the header, and post the description as JSON. A new algorithm returns its own code, the lars_code, which you store next to your internal key. The session expires after a few minutes, so fetch a token per run.
Publication then becomes a step in your release process. On every release a small script collects the fields from your database, validates them against the schema, and sends them in. What remains is a diff for someone to approve.
Onboarding follows a set route. You register with the register team, ICTU makes contact within three working days, and after an online session you get an account. API publication is arranged afterward between your developers and theirs. Every release is checked by hand and goes live within one working day. If your organisation also publishes a register on its own website, that need not become a second administration: the standard has a field for the link to that source registration.
We build this layer as part of custom software development and as an addition to a system already in production, with 30+ engineers in Nijmegen and Sarajevo, working to ISO 9001 and ISO 27001. Our cases show how we approached it elsewhere, and our integration work sits on the API development page. Start with an inventory: which rule sets, which input, which versions, and what you already record. Book a call and we'll walk that list with you.
Frequently asked questions
What information does the Dutch algorithm register ask for?
Publication standard 1.0.0 defines 32 fields in four groups: general information, responsible use, operation, and metadata. They include name, organisation, status, publication category, purpose and impact, human intervention, risk management, the data used, the technical operation, and the supplier. Some come from the organisation's documentation, the rest from the application that runs the algorithm.
Is publishing in the Dutch algorithm register mandatory?
For public bodies, supplying descriptions is not a statutory duty at this point. The register focuses on impactful algorithms, including high risk AI. The organisation that uses the algorithm is responsible for the description and for keeping it current.
Can publication to the algorithm register be automated?
Yes. Alongside the web form there is an API that takes descriptions as JSON. You log in, fetch a token, and post the description on behalf of your organisation. Each algorithm returns its own code, which you store in your own database next to your internal key. Once released, a change is live within one working day.
What if the algorithm comes from a supplier?
The organisation using the algorithm remains responsible for the description. The standard has a supplier field, and the register's guidance advises including transparency requirements in procurement terms. In practice the supplier provides the technical operation and the organisation writes the purpose and impact itself.
