Governments in the AI era

Deploying a Government Registry in Days, Not Months

Cari · 2026-10-08 · 6 min read

TL;DR: Most government registries share the same underlying skeleton, so a platform that has built that skeleton once can stand up a new register through configuration instead of a multi-year software project. Here is what that looks like in practice, and what still takes real time.

If you have worked in government long enough, you have lived through at least one registry project that took years. Maybe it was a business register, maybe a licensing system, maybe a permit database for a single ministry. The pattern is familiar enough to hurt: eighteen months of requirements documents, a procurement cycle, a vendor building something custom, integration battles with systems that were never designed to talk to each other, and a launch date that keeps sliding. By the time the system goes live, the requirements have changed, the champion who sponsored it has moved on, and the software is already showing its age.

The problem was never that governments are bad at technology. The problem is that every registry was treated as a construction project when it is actually a configuration problem.

Every register is the same register

Strip away the domain language and look at what a registry actually does. A business register holds records about companies, tracks who applied for them, routes applications through an approval chain, handles renewals on a schedule, and lets third parties verify that a record is genuine. A permit system for agricultural imports does exactly the same thing with different nouns. So does a professional licensing board, a vehicle register, a land-use permit office, and a dozen other standard registers that every functioning state keeps.

Records. Applicants. Approvals. Renewals. Verification. That is the skeleton, and it repeats across nearly every register a government operates.

The traditional approach rebuilds that skeleton from scratch every single time, which is why every project takes years and why no two systems in the same government can talk to each other. The alternative is to build the skeleton once, properly, and then treat each new register as a set of decisions layered on top: which fields a record carries, which steps an application passes through, who signs off at each step, what the fees are, and how long an approval remains valid.

That is what registry-as-configuration means. When we say 13 registry types are deployable in minutes, we do not mean the software writes itself. We mean the software already exists, and what remains is telling it what your register is called, what it collects, and how it decides.

A deployment week, day by day

To make this concrete, here is what a deployment week can look like. This is an illustration of the process, not an account of a specific customer, and your week will differ in the details.

Day one: configure the register and the workflow. A registrar and a platform engineer sit together and define the register itself. What is being registered, what fields each record needs, which documents an applicant must attach, and what the approval chain looks like: who reviews first, who can reject, who signs. None of this is code. It is a sequence of decisions the registrar already knows how to make, captured in configuration.

Day two: load reference data. A register is only as useful as the vocabulary it speaks. Because the platform is standards-native from the start, this day is mostly review rather than data entry. Ports of entry come from UN/LOCODE, all 24,789 of them, so a permit can reference any recognised port on earth on day two rather than a hand-typed list of the five someone remembered. Commodity classifications come from the Harmonised System, 6,939 commodity codes, so what your officers approve matches what customs systems everywhere else already understand. The team's job is to mark which subsets matter locally, not to build the lists.

Day three: connect fees and test with real officers. The fee schedule from the existing legal instrument gets wired to the workflow: application fees, inspection fees, renewal fees, whatever the statute prescribes. Then the most important part of the whole week: the officers who will actually run the register sit down and push test applications through it. They find the awkward step, the missing field, the approval that is routed to the wrong desk. Because these are configuration changes, they are fixed the same afternoon, not logged as change requests for a future release.

Day four: issue the first permits. The register goes live in parallel with the existing paper process, not as a hard cutover. The first approvals are issued as W3C verifiable credentials alongside the paper certificate, which means any third party, a bank, a customs officer, a foreign counterpart, can verify the permit cryptographically without calling your office. Paper continues for as long as the law and comfort require. Nothing breaks if the new system needs a pause.

Day five: measure and adjust. With real applications moving, the team looks at where they slow down. Which step takes longest, which documents get rejected most, where applicants abandon. Then they adjust the configuration and watch again. This loop never really ends, which is the point: a register defined in configuration can keep improving weekly, instead of freezing on launch day and decaying.

What still takes longer than days

It would be dishonest to pretend the whole problem compresses into a week, so here is the honest list.

The statute behind the register takes as long as your legislative process takes. Software cannot shorten a parliamentary calendar, and a register with no legal instrument behind it is just a database.

Data migration from legacy records takes as long as the records are messy. Decades of paper files and half-maintained spreadsheets have to be cleaned, deduplicated, and validated before they belong in a system people will trust.

Officer training and change management take as long as people need. A register is a working habit as much as a system, and habits move at human speed.

Notice what these three have in common: they are decision problems and people problems, not software problems. The old model buried them inside a multi-year IT project where they were invisible until they exploded. The new model surfaces them in week one, because the software is no longer in the way.

Common questions

Does configuration mean the register cannot handle our specific rules? Configuration covers fields, workflow steps, approval chains, fee schedules, renewal periods, and document requirements, which is where the genuine variation between registers lives. If a register truly needs logic no other register has, that is built once and becomes available to every register after it.

What happens to our existing paper process? It continues alongside the digital register for as long as you choose. Verifiable credentials are issued in parallel with paper certificates, and the pace of any transition away from paper is a policy decision that stays in your hands.

Who controls the data? The government does. The register is the government's legal record, the platform is the machinery that runs it, and verification by third parties never requires handing them the underlying database.

The registries themselves are ready in days. If you want to see which of the 13 registry types fit your situation, the place to start is the country onboarding overview.