# DPG and DPI

Digital Public Goods (DPG) and Digital Public Infrastructure (DPI) are two distinct yet complementary concepts.

As described in the [UN Secretary General’s Roadmap for Digital Cooperation](https://www.un.org/en/content/digital-cooperation-roadmap/assets/pdf/Roadmap_for_Digital_Cooperation_EN.pdf), digital public goods are:

<figure><img src="/files/SRFdlO1angJEHM9hjxzW" alt=""><figcaption><p>For more information on DPGs, please visit <a href="https://digitalpublicgoods.net/standard/">https://digitalpublicgoods.net/standard/</a></p></figcaption></figure>

However, not all Digital Public Goods can be used as building blocks for DPI.&#x20;

DPI can be built through open-source or private solutions, as long as they adhere to open specifications, generate network effects, and trigger both public and private innovation.&#x20;

<figure><img src="/files/mTtzR0T9CBCDzkEYknxw" alt=""><figcaption></figcaption></figure>

DPGs having their own lifecycle and governance means that DPGs are set up by independent institutions that can predate or outlast country-specific DPI. They have their own governing bodies and mechanisms to update their infrastructure outside the country’s context. &#x20;

A stack of DPGs that are interoperable and scalable can come together to build a DPI infrastructure in countries, such as through [G2P Connect](https://g2pconnect.cdpi.dev/) for social benefit programs.

Using open-source components can help ensure that best practices are incorporated, rapid deployment and scale are achieved, dependency or lock-ins are avoided, and minimum efforts can unlock maximum gains. OpenG2P, OpenSPP, or CoreMIS for government benefits or MOSIP for identity projects are examples of DPGs used to help build DPI infrastructure in countries.

However, DPI can also be built without DPGs or any Open Source components, although it may require more time, money, and expertise. Governments can choose to build their own DPI from scratch by using proprietary software, and private vendors, as long as they follow the principles of minimalism, interoperability driven by shared specifications, federation, inclusion, privacy, and security.

Even if a country is using proprietary software, it should still use open specifications. For example, regardless of the software used, it would incorporate ISO standards for payments or G2P connect specifications for G2P service delivery to ensure interoperability or choice for users, and avoid vendor lock-in for institutions.&#x20;

At CDPI, we respect the autonomy of countries to choose whichever path (open source, private, hybrid) that suits their unique needs, and work with countries that opt for any path.

Our suggestion is that even if a country wants to build their own infrastructure from scratch, please always review the open source components available, and ask the private TSPs to ensure that all best-practice features available in open-source are incorporated into the private systems built. Open source is a useful benchmark, even if not used directly. This ensures that country designers get the best of both worlds, and keep up with the latest developments in the community.&#x20;

For suggestions on which open specifications and open source you can reuse to build different DPI, please [see here](/references/home.md).&#x20;

<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.cdpi.dev/the-dpi-wiki/dpg-and-dpi.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
