> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/national-learner-registry/why-this-matters.md). # Why This Matters This chapter sets out why a national learner registry and a digital credential capability matter, what problem they solve, and what this Knowledge Product is intended to deliver. ## The Education Context [Giga](https://giga.global/) is a joint initiative of the International Telecommunication Union (ITU) and UNICEF whose goal is to connect every school to the internet and every young person to information, opportunity, and choice. Connecting schools is a necessary first step, but connectivity on its own does not deliver educational value. Once a school is online, the value depends on the digital services that run on top of that connection — services that let a learner be reliably identified, let their progress be recorded, and let their achievements be recognised wherever they go next. This is where foundational digital systems enter the picture. A learner registry provides a trusted record of who each learner is and where they study. A digital credential capability turns the results of that learning — a completed grade, a course, a qualification — into a portable, verifiable proof. Together they convert connectivity into something a ministry, a school, and a learner can actually use. The relationship is sequential: connectivity enables platforms, platforms host services, and services such as the registry and credentials produce the outcomes that education systems and learners care about. {% hint style="info" %} Without these foundations, the benefits of connectivity remain partial. Learner data stays trapped in individual schools, achievements are hard to verify, and learners who move between institutions or regions must repeatedly re-prove who they are and what they have completed. The registry and credential use cases are the layer that lets connectivity translate into recognition, mobility, and trust. {% endhint %} ## Education Digital Public Infrastructure Digital Public Infrastructure (DPI) refers to the foundational digital systems — digital identity, digital payments, and data exchange — that a country builds once and reuses across sectors, in the same way physical infrastructure like roads or utilities underpins multiple services at once. [Education DPI](https://experience-digital-transform.gitbook.io/experience-digital-transformation/dpi-for-education/) applies this model to education: instead of each school or programme operating its own isolated system, shared digital building blocks let learner data and credentials flow securely and consistently across the entire education ecosystem. Framing the work as DPI has a practical consequence: the components are designed to be reusable and interoperable from the outset, following open standards rather than a single vendor's conventions. That is what allows the same registry and credential pattern to be adopted by another ministry, another region, or another country, with local configuration rather than a rebuild. ## The Credential Recognition Problem In many education systems today, learner records and credentials are fragmented across institutions, often held on paper or in disconnected databases that do not talk to one another. This creates concrete problems. **Verification is slow and manual:** confirming that a certificate is genuine can require contacting the issuing institution directly, which is costly and does not scale. **Recognition is inconsistent**, because different institutions record achievements in different ways. And **portability is poor**: when a learner moves between schools, regions, or countries, their history does not move cleanly with them. A registry-backed, standards-based credential model addresses each of these gaps. Because credentials are issued as verifiable digital objects, a verifier can check authenticity cryptographically, without contacting the issuer. Because they follow a common data model, achievements are recorded consistently and can be understood across institutions. And because the learner holds their own credentials, their record travels with them. The registry provides the trusted source data behind each credential, and the credential makes that data portable. ## Objective of the Knowledge Product The objective of this Knowledge Product is threefold: 1. To produce **implementation-oriented technical guidance** for the National Learner Registry and Digital Credential use cases - documentation detailed enough to guide a real delivery team, not only to describe concepts. 2. To build a working **Proof-of-Concept (PoC)** that demonstrates how to build the use case and shows the core flows working end to end. 3. To deliver [**video learning materials**](/experience-digital-transformation/national-learner-registry/video-learning-path.md) that explain how the solution is designed, built, and deployed, so that others can understand and reproduce it. {% hint style="warning" %} The scope of the PoC is deliberately bounded. It is deployed in a sandbox environment to demonstrate feasibility, interoperability, and the core functional flows of a learner registry and credential ecosystem. It is not production-ready, it is not hardened or sized for national-scale data volumes, and it is not intended for live national deployment. Its purpose is to prove the approach and to serve as the concrete reference behind the Knowledge Product. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/national-learner-registry/why-this-matters.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.