DPI education should help readers examine decisions: what to reuse, who can participate, what evidence can be trusted and how people remain protected. This page translates recognised sources into practical questions and provides a reading path for further work.
After reading this page, you should be able to examine a proposed use case and choose the right reference for its technical, institutional and safeguarding questions.
Where the principles come from
CDPI identifies five technical architecture principles: interoperability, small reusable building blocks, inclusive ecosystem innovation, a preference for federation and decentralisation, and security and privacy by design. This is CDPI's technical framing, not a universal list covering every aspect of DPI. CDPI architecture principles
The UN Universal DPI Safeguards initiative adds guidance on individual and societal risks across the lifecycle. Its current website identifies Framework version 2.0 and links to the framework and implementation guide. Universal DPI Safeguards
The seven practices below are a proposed MOSAIC wiki teaching synthesis. They combine architecture, safeguards and implementation questions. They require MOSAIC review before being described as the alliance's formal principles.
Seven practices to use in discussion
1 Start from the service outcome
Describe what someone needs to complete. Measure the current time, cost and failure points. For a business support programme, the desired improvement might be fewer visits and a faster, accurate decision. An increase in app downloads is a different measure. CDPI's execution guidance also starts with the underlying societal problem. CDPI implementation guidance
Ask: Which part of the person's journey improves, and how will we know?
2 Agree how systems and organisations work together
Document interfaces, data meanings, versions, permissions and responsibilities. Test whether independent providers can exchange and correctly use the same information. Standards provide an important basis; implementation still needs common interpretation and testing.
Ask: Could a second provider participate without redesigning the whole service?
3 Reuse a capability where it fits
Look for an existing identity check, payment connection or evidence verification capability before commissioning another one. Keep the shared function focused enough to serve several applications. GovStack's building block specifications provide a practical reference for modular capabilities and their interfaces. GovStack building blocks
Ask: What should be shared, and what belongs in each service's own workflow?
4 Make participation rules clear
Explain which institutions may issue evidence, operate interfaces or verify information. Define the conditions for joining and the process for suspending a participant. A common credential format needs agreement about whose claims are accepted and for which purpose.
Ask: Why should one institution rely on evidence produced by another?
5 Protect information throughout the journey
Collect and disclose what the service needs. Specify access, retention, logs and incident response. Consider whether data can remain with its responsible custodian; choose the architecture using the actual requirements and threat model. Distributed storage still needs access controls, secure key management and recovery arrangements.
Ask: What information reaches each party, for what purpose, and for how long?
This is a design recommendation, not a legal opinion. Consent must be handled appropriately for the context; it is not a blanket substitute for a valid authority or other applicable duties.
6 Provide a workable route when the digital path fails
Test limited connectivity, inaccessible interfaces, lost phones, mismatched records and unsuccessful authentication. Define assisted access and correction routes. For an essential service, discuss how a failure is resolved without leaving the person with no way forward.
Ask: Can someone complete the journey if they cannot use the preferred digital channel?
7 Assign responsibility and measure results
Name the service owner, operator and parties responsible for evidence, decisions and complaints. Plan operating costs and support beyond the pilot. Compare results with a baseline and examine which groups experience failures. These are proposed practices for turning safeguards into operational responsibilities.
Ask: Who fixes an incorrect decision, and what evidence would justify expansion?
Apply the practices to a credential pilot
Proposed teaching scenario: an authorised institution issues evidence that a business meets one stated programme condition. A participating programme verifies that evidence during an application.
Before a pilot, write down the condition, issuer authority, evidence used, date checked, validity period and update or revocation process. Agree what the verifier receives and how it reaches the final decision. Test an expired credential, an untrusted issuer, an incorrect record and an unavailable digital channel.
A successful signature check is one input. The programme remains responsible for the eligibility rules and decision. Measure completion time, applicant effort, verification failures and correction outcomes against the current process. Use dummy data for educational demonstrations.
Choose resources by the question you need to answer
| Question | Resource | How to use it |
|---|---|---|
| What is DPI and how does it relate to development? | World Bank DPI and services | Start with the foundational capabilities and public-service context. |
| How does CDPI distinguish infrastructure from digitisation? | CDPI DPI Wiki | Read the definition, architecture and assessment pages; compare their framing with other sources. |
| What safeguards belong in design and operations? | UN Universal DPI Safeguards | Follow the current framework and guide links; record the version used in a review. |
| How can capabilities be specified as reusable components? | GovStack specifications | Examine the relevant building block and its interfaces. |
| Is a reusable solution recognised as a digital public good? | DPG Standard | Review the core solution's requirements. Recognition does not evaluate a local deployment. |
| How are verifiable credential roles and claims represented? | W3C VC Data Model 2.0 | Read the issuer, holder and verifier model; then decide the trust and exchange arrangements separately. |
| What does IKD currently offer? | Official IKD application | Use developer instructions for capabilities and activation; use dated government reports for adoption. |
| How does Indonesian health data exchange work? | SATUSEHAT introduction and FHIR documentation | Connect the service use case to the relevant data model and integration guidance. |
| How does Indonesian payment interoperability work? | Bank Indonesia QRIS | Study participating providers and the shared standard; check dated BI releases for progress. |
| How can a use case enter MOSAIC discussions? | MOSAIC website | Explore the alliance's published use-case and participation information. |
These are learning references, not a procurement shortlist. A standard describes agreed requirements; a framework guides decisions; a product implements selected capabilities; a deployment applies them in a particular institutional setting.
A practical reading path
For a newcomer: read What is DPI, DPI in Indonesia, then select one service journey to discuss using the seven practices.
For a programme owner: read the safeguards framework and implementation guidance. Produce a one-page brief defining the problem, accountable parties, baseline, proposed improvement and correction route.
For a technical team: start with the service brief, then consult the applicable specification and national documentation. Record versions, trust rules and interoperability test results. Format compatibility alone is insufficient evidence that providers can work together.
For a research or civil-society team: examine participation, access barriers, failure cases and correction outcomes. Compare institutional progress claims with evidence from users.