> 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/use-case-scope.md). # Use Case Scope This chapter defines the boundaries of the National Learner Registry & Digital Credential use case: what it comprises, who takes part in it, and what it assumes to already be in place. {% embed url="" %} ## Two Business Processes The National Learner Registry & Digital Credential ecosystem is built from two business processes, connected by a single identifier that flows from the first into the second. {% hint style="success" %} **Student Registration & Enrolment** registers a learner and, in doing so, generates their **ULID** — a Unique Learner Identifier assigned automatically the moment the application is approved. This process creates the learner's official Learner Profile in the National Learner Registry, the authoritative record that everything else in the ecosystem eventually points back to. **Certificate & Diploma Issuance** issues a certificate or diploma as a signed Verifiable Credential, delivered to the learner as a QR code that can be scanned into a digital wallet or downloaded directly. The learner can then present this credential to third parties, such as employers or other institutions, for verification. {% endhint %} This second process cannot run for a learner who does not already have a ULID: the system cannot issue a credential to a learner it does not recognise. Student Registration & Enrolment must therefore always happen first — the ULID it produces is what connects the two processes.

Both processes run through a single platform that supports low-code and no-code configuration of forms and workflows, multi-channel access for learners and institutions, digital documents and e-signatures, and open APIs for integration with external systems. This shared foundation is what allows the two processes to be described as one coherent use case rather than two separate systems. ## Key Actors Several actors take part across the use case as a whole, each with a distinct responsibility at a specific point in one of the two business processes.

Actor	Responsibility
Learner	Initiates the journey: authenticates, submits the registration and enrolment application, and later selects and pays for a certificate or diploma once one becomes available. At no point does the learner have standing access to a registry — they interact only with the forms they submit and the credentials they are given, which they then hold and present themselves.
School Registration Officer	Performs the first review within Student Registration & Enrolment: checking documents, verifying details, and deciding whether an application moves forward or is sent back.
MoE Registrar	Performs the final review of that application. It is this actor's signature that creates the learner's official Learner Profile and assigns their ULID.
Institution Officer	Plays the equivalent first-review role within Certificate & Diploma Issuance: initiating a request, selecting the learner by ULID, and recording the programme, level, and final outcome.
MoE Credential Validation Unit	Performs the final review of that request at the ministry level, mirroring the role the MoE Registrar plays earlier in the use case.
National Identity Provider	Authenticates learners and officials before they can act, and supplies the verified identity attributes used to pre-fill an application, reducing what a learner has to type in by hand.
Verifier	A third party to whom the learner later presents their credential — checking its signature and status directly, without ever needing an account on the platform itself.

## Preconditions {% hint style="warning" %} This Knowledge Product and the Proof-of-Concept behind it are deliberately bounded. The PoC is deployed in a sandbox environment to demonstrate feasibility, interoperability, and the core functional flows described above, including genuine digital signing of every credential issued. **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.** Any future development, scaling, or operational deployment of the solution is treated as a separate undertaking, subject to its own procurement and design process. {% endhint %} This bounded scope extends to the tooling choice as well. This PoC uses a low-code platform to configure the workflows and forms described in this ecosystem. That choice reflects this implementation, not a requirement — any comparable low-code platform could be used instead, though each platform comes with its own set of built-in features, so some functionality shown here may need to be configured differently or added as a custom extension elsewhere. ## What This Proof of Concept Does Not Attempt to Solve Within the bounded scope above, this documentation distinguishes confirmed design decisions from ones still open, and notes explicitly where the PoC demonstrates a capability without yet hardening it for production use. This mirrors a common approach in Digital Public Infrastructure work: prove the approach at a manageable scale before committing to a full production build. --- # 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/use-case-scope.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.