A person can stand at a government counter with a passport, a history and a legal right—and still be treated as absent. The official progress review of the UK’s Windrush scandal records that people who could not produce documentary proof of their status lost access to work, housing, driving licences and healthcare. When some tried to establish their status, the Home Office had no record of them; in some cases, that absence triggered enforcement action.
This showed what happens when an institution treats its records as the limits of reality. A humane digital public service must keep four questions separate: who a person is, whether they can authenticate, which facts are recorded about them, and whether those facts satisfy a rule. When systems collapse those questions into one answer, a missing field can become a missing person.
Four questions that look like one
Identity proofing is the process of establishing that a claimed identity belongs to a real person. It may involve official documents, trusted records or an in-person check. Authentication comes later: it tests whether someone returning to a service controls an accepted credential, such as a passkey, identity card or one-time code. The distinction is central to the current NIST Digital Identity Guidelines, which treat identity proofing, authentication and federation as related but separate functions.
Attributes are facts associated with the person: date of birth, address, residency status, family relationship, educational qualification or registered disability. Eligibility is a conclusion reached by applying a legal or administrative rule to selected attributes. A person may authenticate successfully and still be refused because an attribute is missing, stale or attached to another record. Equally, a database match may identify the right person while the eligibility rule is applied incorrectly.
Consider an illustrative benefit that requires residence in a municipality and an age below a defined threshold. The service may accept a national electronic identity for authentication, obtain the birth date from one register and request the current address from another. The decision engine then applies the scheme’s rule. “Not eligible” could mean the address register returned an old municipality, the identity could not be matched across systems, the query timed out, or the person genuinely falls outside the rule. Those are different events requiring different remedies.
How an error travels through federated registers
Public administrations rarely hold everything in one database. A source register may be legally authoritative for one category of data, while other agencies query it or receive updates. This creates a chain in which an error can travel.
The chain begins with matching. Two systems need a reliable way to determine that their records concern the same person. A stable identifier can help, but cross-border or older records may use different identifiers. Names can change, dates can be entered incorrectly and transliteration can produce several spellings. A cautious system may reject an uncertain match. A careless one may attach another person’s attributes.
Next comes retrieval. The source may return a value, no result or a technical error. These must not be translated into the same administrative conclusion. “The register has no current address for this identifier” is not equivalent to “this person has no address”, and neither proves “this person is ineligible”. Yet a downstream service often needs a simple value, so uncertainty is compressed into an empty field or a false flag.
Finally comes propagation. Some services query the source live; others use local copies, caches or event-driven updates. A correction may therefore take time to reach every consumer. An update can fail because a message was not delivered, a schema changed, the receiving record could not be matched or the local service rejected the new value. The source becomes correct while the consequence remains wrong elsewhere.
The European Union’s once-only technical system illustrates how much machinery sits behind an apparently simple exchange. Its technical and operational regulation distinguishes evidence requesters, evidence providers, intermediary platforms, identity matching and secure delivery. It also provides, for most covered procedures, a way for users to preview evidence before it is returned. That preview is not decorative interface design. It gives the person a chance to notice that the system has found the wrong document or an outdated fact before it shapes a decision.
An audit trail must explain the consequence
A conventional technical log may show that a request reached a server and received a response. That helps an operator diagnose downtime, but it is not enough for someone contesting a refusal. A useful administrative audit trail must connect the human consequence to the data and rule that produced it.
For a disputed decision, an authorised reviewer should be able to determine which identity was matched, which source supplied each decisive attribute, when it was retrieved, which version of the rule was applied and whether any query failed or fell back to cached data. The record should also preserve later corrections without silently rewriting what happened. Otherwise the administration can see today’s correct data but cannot reconstruct yesterday’s harmful decision.
This does not require exposing every security detail. It requires enough provenance to distinguish an adverse legal conclusion from a technical absence. The citizen-facing explanation can be simpler than the internal trace, but it should name the disputed fact, its source and the route to correction.
Correction has two journeys
The first journey is correction at the authoritative source. If a residence register owns the address, changing a copy inside the benefits service may provide temporary relief but leaves the same error available to other agencies. The person needs a clear route to the body able to amend the source, along with a receipt, a case reference and a way to supply evidence.
The second journey is propagation. Once the source changes, every relevant recipient or dependent decision must be reconsidered. Under the EU General Data Protection Regulation, people have a right to rectification of inaccurate personal data. Article 19 also requires controllers to communicate certain rectifications to recipients to whom the data were disclosed, unless doing so is impossible or involves disproportionate effort. The legal scope depends on the processing context, but the engineering lesson is broader: a correction is unfinished while known downstream consequences remain untouched.
A robust system therefore records where decisive data went and can send a correction event or trigger a fresh query. The receiving service must process that change, identify affected cases and decide whether past outcomes require review. Simply overwriting a local field may make the screen look correct while leaving a suspended payment or rejected application in place.
Why human review cannot be a decorative escape hatch
Human review is necessary when identity matching is uncertain, evidence conflicts or an administrative consequence is serious. But a button marked “contact us” does not create meaningful review. The reviewer needs authority to pause the consequence, inspect the provenance, accept alternative evidence and correct or escalate the source record.
The person also needs protection while facts are disputed. Depending on the law and service, that may mean restricting use of the contested data, preserving an existing entitlement temporarily or separating an urgent decision from a slower data-cleaning process. The GDPR expressly recognises restriction of processing while data accuracy is being verified in applicable cases. The practical principle is that uncertainty should not automatically be charged to the person least able to diagnose the system.
Review quality can be measured. An administration can track how often refusals are overturned, how long source correction and downstream propagation take, how many people must resubmit the same evidence, and whether particular groups encounter more failed matches. These measures reveal whether the nominal appeal route restores agency or merely transfers debugging work to citizens.
The database is evidence, not existence
Federated registers can make services faster and reduce repetitive form filling. They can also improve data quality by giving each fact an accountable source. The strongest case for integration is therefore real. A person should not have to carry the same certificate from office to office when authorised systems can exchange it safely.
But “once only” must not become “one error, everywhere”. The same connectivity that propagates a useful fact can amplify a mistake. Human-centred administration requires systems to preserve uncertainty, show provenance, support correction at source and trace the consequences downstream.
Continue exploring
Alkemata’s article on event-driven public services examines how register changes can initiate help without another application. The mechanism described here is its necessary counterpart: every automated update needs an observable path for correction and contest.
If you want more practical examinations of how public technology changes people’s ability to act, you can subscribe to Alkemata for future explainers and deep dives.
The remaining design question is not whether government should trust data. It must. The question is what the system does when the record and the person disagree. A credible public service must be able to answer not only “which database said no?” but “who can correct it, where will the correction travel, and what happens to the decision in the meantime?”