Digital public infrastructure is not DPG, DPF, or DPS: why confusing these terms is costing governments billions

UNDP describes Digital Public Infrastructure as foundational digital systems that form the backbone of modern societies and enable secure, seamless interactions between people, businesses, and governments.

The World Bank uses a similar baseline and explains DPI through three commonly repeated foundations: identification, payments, and data exchange.

The United Nations frames Digital Public Goods as open source software, open data, open AI models, open standards, and open content that should adhere to privacy and other applicable laws and best practices, do no harm, and help attain the SDGs.

Those baselines are useful, but they are not procurement-grade. They do not, by themselves, resolve who is authorised to act, who is compellable to correct and explain outcomes, what evidence must exist, and how remedy reaches all affected relying parties. The recurring failure pattern is a category error: plumbing is funded and delivered as if it were authority, so delivery accelerates early and becomes expensive later when accountability, mandate-based access, evidence-grade decision records, and remedy must be retrofitted under live reliance.

DPI vs DPG vs DPF vs DPS: a procurement-grade taxonomy

Digital Public Infrastructure is a governed capability foundation. Its unit of value is cross-domain reuse under stable governance conditions, not a feature list and not a vendor platform.

Digital Public Goods are reusable open assets. Their unit of value is reuse and composability, often accelerating implementation and reducing duplication, but they do not establish lawful authority, institutional mandate, or remedy duties in any specific jurisdiction by default. The United Nations and UN Office for Digital and Emerging Technologies use the same core DPG framing and emphasise expectations such as privacy, do no harm, and responsible governance.

Digital Public Functions are procedure-bound acts that can contribute to legally attributable outcomes, such as determinations of status, eligibility, registration, certification, enforcement, or access. This category is useful precisely because it forces decision attribution, evidence duties, and contestability to be designed explicitly rather than buried in platform configuration.

Digital Public Services are end-to-end outcome deliveries experienced by people and organisations. They orchestrate one or more functions and consume infrastructure capabilities. They must remain contestable and correctable under reliance, with evidence-grade receipting and clear duty holders.

Canonical comparison

Dimension	Digital Public Infrastructure, DPI	Digital Public Good, DPG	Digital Public Function, DPF	Digital Public Service, DPS
Core object	Governed, cross-domain capability foundation reused by many services and functions	Reusable open asset, adopted and composed	Procedure-bound decision or act that can contribute to legally attributable outcomes	End-to-end public-facing delivery of outcomes
Primary ownership	Mandated duty holders and custodial institutions with preserved decision rights	Steward or maintainer community, plus adopters in each jurisdiction	Named accountable institution exercising competence within procedure	Named accountable institution accountable for outcomes
Default legal effect	None by default; enables lawful execution elsewhere when authority and procedure exist	None by default	Frequently contributes to legal effect where outcomes change status or entitlements	Frequently produces attributable outcomes under procedure
Evidence expectation	Evidence pathways across institutions that remain usable under inspection and dispute	Typically low unless embedded in governed acts	High, including provenance, decision traceability, contestability	High, including receipting, traceability, contestation and correction
Remedy expectation	Remedy reach must be operable across dependencies, not informal escalation	Maintenance and defect handling	Procedural remedy and correction propagation where required	Procedural remedy and correction propagation where required
Procurement unit	Governance scope plus shared capability operations	Adoption, integration, support	Procedure-aligned functional capability with evidence duties	Service operating model and outcome delivery capability

Why the DPI vs DPG vs DPF vs DPS confusion creates avoidable cost

When DPI is treated as a synonym for software or a platform, accountability often migrates to the platform operator, even when the operator cannot legitimately hold decision rights. When a dispute occurs, the programme discovers it has built execution surfaces without a defensible chain from competence and mandate to reviewable evidence. The fix is expensive because it is not an interface change; it is a redesign of decision attribution, evidence bundles, oversight access, and operational remedy.

When a DPF is treated as a reusable module, public authority becomes embedded in releases and configuration rather than in procedure and mandate. This creates authority drift: outcomes change through technical deployment without a clearly attributable accountable institution and without stable evidence expectations. The later correction requires re-anchoring the function to authorised procedure, rebuilding decision records, and establishing contestation pathways that work at scale.

When a portfolio of services is treated as DPI, app proliferation follows. Identity, registries, and evidence handling are duplicated across services, creating inconsistent outcomes, reconciliation overhead, and fractured remedy. The cost is not the build alone; it is the long-run operating burden of multiple inconsistent decision paths that cannot be inspected or corrected end-to-end.

Classification test before funding or procurement

Decision question	If the answer is yes	You are looking at
Does it deliver a public-facing outcome to a person or organisation, where the receipt must stand up under contestation and audit	It must be governed as outcome delivery with explicit contestability and correction under reliance	DPS
Does it execute procedure-bound decisions affecting status, eligibility, registration, certification, enforcement, or access	It requires lawful authority, safeguards, evidence duties, and a mandated, compellable duty holder	DPF
Does it primarily provide shared capabilities reused by many functions and services, such as interoperability, registries, mandate-based access gating, consent enforcement, or evidence-grade logging	It is infrastructure only if it is governed as such with preserved decision rights and operable oversight and remedy	DPI
Is it primarily a reusable artefact such as a module, standard, specification, dataset, or reference implementation	It is an input to governed systems, not public authority	DPG

What to do differently, without slowing delivery

Treat DPI, DPG, DPF, and DPS as different procurement objects with different owners, evidence burdens, and remedy expectations. This simple separation allows reuse to scale without collapsing accountability: shared capabilities reduce duplication, functions remain attributable and contestable, services remain correctable under reliance, and reusable assets can be adopted without pretending they carry public authority.

If you want this article to sit inside an integrated topical cluster, link its governance claims to your deeper posts on enforceability, authority, and mandate gating: plumbing does not grant authority, mandate gating, and enforceable governance.