The most revealing sentence in the Department for Education’s Single Unique Identifier programme is not in a ministerial speech. It sits in an architecture decision record deep inside a public government GitHub repository. DfE had designed a way to give different organisations distinct identifiers for the same child so that those organisations could not simply correlate their records using one shared number. That design was then marked rejected and superseded by a decision to use the NHS number “in the clear”.
That choice matters because this was never merely a debate about whether one database field should contain one number or another. DfE’s own rejected design said distributing the raw NHS number more widely would increase privacy risk, expand the impact of a breach and allow records held by separate organisations to be correlated more easily. The proposed alternative — custodian-scoped encrypted identifiers — was designed specifically to prevent that uncontrolled correlation.
The programme chose the other path. A later architecture decision says the preferred approach is to use the NHS number itself as the Single Unique Identifier. The rationale is straightforward: a raw NHS number makes direct joins easier, improves interoperability and allows historic records that already contain the number to be linked without first translating it into a new identifier.
The privacy problem was not discovered after the architecture was built. It was identified in advance, designed around — and then the design intended to contain it was superseded.DfE architecture decision trail, Single Unique Identifier programme
This is the government’s stated direction
The broader policy is no longer hidden behind prototype code. The government’s own roadmap for joining up children’s data says the goal is for practitioners across children’s social care, health, police and education to have access to relevant, timely and joined-up information. It says the post-April 2026 pilots are likely to involve API connectivity between systems holding child-level safeguarding and welfare data, a “source of the truth” for identifiers, automated identifier lookup, improved linking between organisations and, potentially, further digital services to help practitioners find and access information relevant to decisions.
The government’s response to the national audit on group-based child sexual exploitation is more explicit about the identifier itself. It says pilots are using the NHS number as the proposed consistent identifier, beginning in Wigan, with additional local authorities being explored so they can test connectivity to the NHS Personal Demographics Service and automatically access NHS numbers for children known to social care.
That same government response states that police information systems should be able to process the new child reference numbers, and that the government will work with police forces and suppliers to make that possible. Then, on 16 June 2026, a ministerial statement to Parliament disclosed that DfE and the Home Office had already conducted a “deep-dive” into policing systems to establish how an identifier for children would work inside them.
There is an important boundary here. That statement also mentions the Home Office’s National Data Integration and Exploitation Service, but the public record does not establish that SUI is currently flowing into NDIES, the Police National Database or the Law Enforcement Data Service. The evidence supports intended compatibility with policing systems. It does not support inventing a live integration that has not been demonstrated.
The timeline is no longer vague either. A cross-government action plan published in July 2026 gives DfE a target of Autumn 2028 to introduce the Single Unique Identifier for children, while the new multi-agency information-sharing duty is scheduled for Autumn 2026.
The safeguard DfE designed — then abandoned
To understand the significance of “in the clear”, it helps to look at what DfE had proposed instead. Architecture Decision Record 0006 proposed custodian-scoped identifiers: the same child would not present the same reusable raw identifier to every organisation.
The logic was explicit. If the NHS number were handed directly to systems that did not otherwise require it, the number could become a universal join key. If one custodian were compromised, the leaked identifier could be reused against data held elsewhere. A custodian-scoped design would make correlation across organisations dependent on the national service instead of allowing each participant to perform it independently.
That is a classic privacy-preserving architecture: not preventing authorised information sharing, but limiting what each participant can infer or join by itself. Yet the record now labels that option rejected. The architecture moved towards the raw NHS number.
The companion decision, ADR 0010, acknowledges essentially the inverse trade-off. Using the NHS number simplifies interoperability and direct joins. It also means that compromising a custodian can expose identifiers reusable elsewhere, and that organisations can correlate records immediately where they possess the same number.
Status trail
The individual ADR file still carries a “Proposed” label, but a historical architecture index in the same repository was already listing the NHS-number decision as Accepted by at least 5 February 2026, while the privacy-preserving alternative was listed as superseded.
The current code follows the decision
This is not simply an old design document describing an abandoned idea. The post-pivot Get an Identifier application is built around resolving a person’s demographic details against NHS PDS and returning the matching identifier.
The identifier model validates a ten-digit NHS number. The matching service sends demographic information to PDS and, when it considers the match sufficiently confident, returns that NHS number. The API response model carries it back as the matched person identifier.
The minimum demographic set accepted by the visible validator is given name, family name and date of birth. Gender, postcode, phone and email can be supplied as additional matching information.
No, this is not an anonymous child-search website
It is important not to sensationalise the technical surface. The Azure function’s platform trigger is declared AuthorizationLevel.Anonymous, but that does not mean anyone can query it anonymously. DfE implements its own application-layer authentication on top.
The current lookup function expects an authorised caller context and a separate x-api-key. The JWT middleware validates a signed bearer token, including issuer, audience, signing keys, lifetime and the required get-an-identifier.read scope. The separate API key is generated and stored through DfE’s Terraform and Azure Key Vault configuration.
Nor can we responsibly say the present post-pivot endpoint is confirmed live on the public internet. The public GitHub Actions history shows successful infrastructure applies for the d01 environment, including after the August API-key changes, but the ordinary application deployment job in the Get an Identifier build-and-deploy workflow is commented out. Infrastructure is proven. A current public production service is not.
What the evidence does not show
It does not show that the public can search children by name and date of birth.
It does not show that a police force or housing provider currently possesses live credentials.
It does not show that SUI currently feeds NDIES, PND or LEDS.
It does not show one giant central database containing every underlying child record.
It does not prove the current post-pivot API has been deployed through DfE’s public API gateway.
Then why does a number resolver still carry record metadata?
This is where the surviving post-pivot code becomes especially interesting.
The current Get an Identifier request can include metadata describing a record type, a source system and a source record ID. DfE’s example uses a health record type with a system identifier and a record identifier.
Those values are not necessary to ask PDS which NHS number matches a set of demographics, and the visible current matching method does not use them to perform the PDS lookup. Yet they survived the July pivot.
Before that pivot, DfE had accepted an architecture for a central custodian knowledge register. Its function was not to centralise every underlying record, but to know which custodian and system held which type of record for a person. Its fields included the SUI, custodian, system, record type, subject identifier and provenance information.
The old Find and Single View applications were subsequently removed. The newer resolver nevertheless still carries record/system metadata. That does not prove the old knowledge register remains operational. It does create an obvious architectural question: why does a supposedly narrow NHS-number resolver still accept the vocabulary required to describe where records about that person exist?
Crime, justice, police — and housing — remain in the prototype vocabulary
The post-pivot repository’s current README defines record categories including children’s services, crime and justice, education, health and personal details. It describes information about children as distributed across education, health, social care, police, youth justice, early years and other services.
More strikingly, the repository’s current prototype inbound-authorisation fixture contains enabled client categories for Local Authority, Education, Health, Police and Housing, each modelled with get-an-identifier.read permission.
That is not evidence that actual police or housing organisations are presently querying children’s NHS numbers. The fixture is prototype data. But it is equally wrong to dismiss the categories as unrelated historical debris: the current Get an Identifier project packages the fixture and uses the prototype authorisation store to map authenticated client IDs to enabled organisations and scopes.
Police, in particular, are not an inference invented from that JSON file. The government has separately said it will work with police forces and suppliers so police systems can process the new identifier, and Parliament has been told that DfE and the Home Office conducted a specific deep-dive on how a child identifier would work in policing systems.
The programme pivot did not end the identifier
The Git history is unusually revealing. On 16 June 2026, PR #678 warned that “the scope of the programme is changing”. The very same calendar day, the Home Office statement disclosed the policing deep-dive. That coincidence is noteworthy, but the public evidence does not prove that policing requirements caused the engineering pivot.
16 June 2026 - DfE developers say programme scope is changing. Parliament is separately told DfE and the Home Office have examined how the identifier would work in policing systems.
14–15 July - PR #714 removes Transfer, Single View, Find and stub-custodian components after what the developer describes as the most recent pivot.
28–29 July - PR #722 implements the direct Get an Identifier adapter to PDS, replacing the earlier DfE matching approach.
5 August - PR #725 removes old Find/Match references and updates documentation around Get an Identifier, including its separate API key.
The policy survived the deletion of the applications. The government still gives the national identifier an Autumn 2028 target. What changed was the implementation shape: instead of treating “Single View” as the necessary centre of the system, the public architecture increasingly points towards existing sectoral systems connected through common identifiers, APIs and standards.
A second question: why fuzzy-first?
The current code creates another, narrower accountability question. DfE’s visible PDS adapter sets fuzzy matching to true and exact matching to false. It accepts the result only when PDS returns exactly one person and the score reaches the 0.95 threshold in the current code.
NHS England’s own PDS FHIR specification says fuzzy searches are more likely than non-fuzzy searches to include multiple matches and false positives, and says that for privacy reasons it is better to use fuzzy matching only after a non-fuzzy match has failed. The NHS specification defaults _fuzzy-match to false.
That does not prove DfE is violating NHS rules. NHS also permits application-restricted back-end processes to retrieve NHS numbers, and requires software to complete onboarding, demonstrate a valid use case and technical conformance before going live. The missing public document is the assurance record showing what search profile DfE proposed, what testing supported the 0.95 threshold and what NHS approved.
The real story is the architecture of correlation
There is an easy way to overstate this investigation: call it a database of every child, imply the public can query it, or claim the police are already plugged directly into NHS data. None of that is necessary, and none of it is what the evidence presently proves.
The evidence points to something more specific.
DfE and partner departments are building an interoperability regime in which child-level information remains distributed across different operational systems, while a common authoritative identifier allows records to be linked more reliably across organisations and over time. Government policy explicitly includes social care, health, police and education. Police systems are being prepared to process the child identifier. DfE’s own current prototype vocabulary extends into crime/justice and models police and housing callers.
And at the centre of that model sits an architectural decision with unusually clear provenance: officials considered protecting the underlying NHS number from becoming the universal join key. They documented why. They then moved to the NHS number itself.
The public-interest question is no longer whether government wants to join children’s records. Government says that openly. The question is why the architecture chose the most reusable identifier after explicitly documenting the privacy value of not doing so.
That deserves a direct answer from DfE: who approved the change, what privacy and security advice they received, what safeguards replace the abandoned custodian-scoped approach, how police and other non-health consumers are intended to be governed, and what prevents a common identifier designed for safeguarding from becoming a de facto cross-government correlation key.
The identifiers are meant to stop children falling through cracks between services. That is a legitimate safeguarding objective. But precisely because the system is being built for vulnerable children, the standard should be higher than “the number makes integration easier”. The government’s own engineers recognised the competing risk. The record now shows which side of that trade-off the architecture chose.
Support This Work
If you would like to support my work and help keep me safe, all support is greatly appreciated.
Bitcoin (BTC) - bc1qevvy4y7ph5nxhsux0j6llfjepn239r52rakgcy
Ethereum (ETH) - 0x26F16D2D4d3dE1ab332deeE9d7DECA6B90654717
XRP - r4UDiUq5U8cQv5gq2zBdimtoMVxxjqzcYH
Solana (SOL) - 22SruEARKvXAKn8TzZZ1dBogQXRYyWkuYA4KYZWa4vAS
Dogecoin (DOGE) - DBjnCWtW1r7bnTorAocE5ypsgA1h7kQ1PD
Cardano (ADA) - addr1q8u5ld73yzv0ep9vguaz2zepdlv3ldpdr23ytukpk7lt9r8ef7mazgycljz2c3e6y59jzm7er76z6x4zghevrda7k2xq43ad8d
Primary sources
All central claims above are grounded in government, Parliament, NHS England or DfE’s own public source-code and architecture records.
DfE — Single Unique Identifier public repository. DFE-Digital/single-unique-identifier.
DfE — Roadmap for modern digital government. Delivering better care for children by joining up data across services.
DfE architecture decision 0006. Custodian-scoped identifiers to hide the underlying NHS number.
DfE architecture decision 0010. Use of NHS number as the Single Unique Identifier.
DfE architecture index — historical version. Architecture decision index showing ADR 0010 as accepted.
DfE architecture decision 0009. Central custodian knowledge register for identity and discovery.
DfE — current Get an Identifier lookup function. GetAnIdentifierFunction.cs.
DfE — current authentication middleware. JwtAuthMiddleware.cs.
DfE — current PDS matching service. GetAnIdentifierService.cs.
DfE — NHS-number model and match threshold. NhsPersonId.cs and MatchScoreConstants.cs.
DfE — demographics validator and request metadata. PersonSpecificationValidation.cs and GetAnIdentifierRequestMetadata.cs.
DfE — current programme README and prototype inbound clients. README.md and auth-clients-inbound.json.
UK Government — response to National Audit on Group-based Child Sexual Exploitation and Abuse. Recommendations 6 and 7: SUI pilots and police-system compatibility.
UK Parliament — Written Ministerial Statement, 16 June 2026. DfE/Home Office policing-system deep-dive and SUI update.
UK Government — Unpaid Carers Action Plan, July 2026. Autumn 2028 target for introduction of the Single Unique Identifier.
DfE — programme pivot PRs. PR #678, PR #714, PR #722, and PR #725.
DfE — Get an Identifier Terraform workflow history. Public workflow runs and Terraform configuration.
NHS England — Personal Demographics Service FHIR API. PDS FHIR API product documentation.
NHS England — PDS OpenAPI specification. Search behaviour, fuzzy-match guidance, application-restricted access, onboarding and network model.