Nine design principles for open digital ecosystems

Guides · Published 2026-09-10

A cyan blueprint showing the elevation and plan of a bascule bridge with towers — Blueprint for the University Bridge, Seattle, 1915. Photo: Seattle Municipal Archives, CC BY 2.0, via Wikimedia Commons.

Almost every framework on digital public infrastructure lists principles. They overlap heavily, and they are easy to recite and hard to apply. Here are nine, in our own words, each with what it looks like when a team actually builds something, and the failure it is meant to prevent.

These principles are a synthesis written for this magazine. Similar ideas appear, in different words and groupings, in the G20 Framework for Systems of Digital Public Infrastructure (2023), the Universal DPI Safeguards Framework coordinated by the UN Tech Envoy's office and UNDP (2024), the World Bank's Principles on Identification for Sustainable Development (2017) and the European Interoperability Framework (2017). Links are at the end.

1. Keep the core minimal

In practice: the shared platform does a few generic things well (authenticate a person, route a payment, pass a signed message between two systems) and stops there. Everything that varies by use case is built on top, by public or private actors.

Prevents: the "mega-platform" that tries to be the one app for everything, becomes slow to change, and crowds out the services that would have been built around it.

2. Publish the interfaces

In practice: APIs, data formats and message schemas are documented publicly, versioned, and free to implement. A developer who has never met the operator can read the specification and build a compliant integration in a test environment.

Prevents: lock-in through undocumented integrations, and ecosystems where only a handful of insiders can participate. See interoperability and open standards.

3. Federate data rather than pool it

In practice: each authority keeps the records it is responsible for, and systems ask each other for what they need, when they need it, with a log of every request. Estonia's X-Road is the best-known example: there is no central database of everything, only a secure way for databases to talk.

Prevents: single points of failure, honeypots for attackers, and the temptation to repurpose a giant database for purposes nobody consented to.

4. Design for privacy and security from the first sprint

In practice: collect the minimum data needed; use tokens or sector-specific identifiers instead of exposing a universal number everywhere; encrypt in transit and at rest; give people a way to see who accessed their data. Threat modelling happens before launch, not after the first breach.

Prevents: function creep and surveillance by design. Our guide to digital ID privacy safeguards goes into the techniques.

5. Build for the person with the least

In practice: services work on basic phones and low bandwidth, offer assisted channels (counters, agents, call centres), support local languages and accessibility standards, and never make a digital credential the only route to an essential entitlement.

Prevents: exclusion errors, where the people who most need a service are the ones the system fails to recognise: manual workers with worn fingerprints, people without stable connectivity, those without documents to enrol.

6. Keep the rails neutral

In practice: participation rules are published and applied evenly; the operator does not favour its own applications; fees, where they exist, are transparent. Where market concentration appears on top of the rails, the rule-setter can respond.

Prevents: a public network that ends up serving as the moat for one or two dominant private apps, which is a live debate in instant payments (see UPI and instant payments).

7. Ground it in law, with someone accountable

In practice: a statute or regulation defines what the system may do, who operates it, how disputes are resolved and what penalties apply for misuse. There is an independent body (a data protection authority, an ombudsman, a court) that people can turn to.

Prevents: systems that rest only on a project order and change purpose without debate. Governance options are covered in DPI governance and safeguards.

8. Make it observable

In practice: publish usage statistics, uptime, error and failure rates (including authentication failures), grievance volumes and resolution times. Invite independent audits and research access under clear conditions.

Prevents: success measured only in transaction counts, while failures stay invisible. We discuss metrics in measuring DPI impact.

9. Plan for evolution and exit

In practice: modular components that can be replaced one at a time; contracts that give the state the right to the code, data and documentation it needs to change suppliers; a technology roadmap that assumes standards will move.

Prevents: systems frozen around a vendor or an obsolete standard. This is where the choice between open source and proprietary software matters most.

How the principles fit together

The nine principles are not a menu. Minimal cores (1) only work if interfaces are published (2); federation (3) only protects people if access is logged and reviewable (8); inclusion (5) depends on accountability (7), because excluded people need somewhere to complain. Teams that pick the easy principles and skip the hard ones tend to end up with a familiar result: a technically elegant platform that people do not trust.

Principle	Typical evidence that it is real
Minimal core	A short, stable list of platform functions; many third-party services built on top.
Published interfaces	Public API documentation, a sandbox, a change log.
Federated data	No central copy of sector databases; per-request logging.
Privacy and security	Data protection impact assessment; access logs visible to the person.
Inclusion	Assisted channels; published failure and exception rates.
Neutral rails	Published participation rules and fees; open onboarding.
Legal basis	A statute, an independent oversight body, a grievance route.
Observability	Regular public statistics and independent audits.
Evolution and exit	Rights to code and data; modular architecture.