> 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/learner-registry/verification-status-and-audit-trail.md). # Verification, Status and Audit Trail How learner data is checked, who can verify it, and how every change stays traceable. ## What Verification Means in the Learner Registry Context Verification is the process of confirming that submitted information is accurate, complete, and supported by appropriate evidence before it becomes part of a registry record. Unlike data entry, which focuses on collecting information, verification determines whether the submitted information can be trusted and accepted. Within GovStack, verification supports the creation and maintenance of trusted registries: information that will be reused across services and organisations should be reviewed against defined requirements before it becomes part of an authoritative source. In this PoC, verification takes place before a learner profile is created — the applicant submits an application with supporting information and documents, the School Registration Officer performs the initial review, and successful applications are then sent to the MoE Registrar for final approval. Only after both review stages are completed successfully is the learner profile created in the registry. ## Which Data May Need Verification Certain data elements require verification because they establish identity, support eligibility decisions, or may become part of an authoritative registry record. Verification may involve checking completeness, consistency, supporting evidence, and alignment with defined requirements. In general, verifiers should be provided with all information required to make a decision: relevant applicant identification data, application details, selected educational institution, and attached documents. {% hint style="info" %} In a full production implementation, authorised officers may also have access to other government registries or trusted data sources, allowing them to cross-check submitted information, confirm identity or eligibility, and reduce the risk of incorrect or fraudulent data entering the registry. Within this PoC, verification is based on the information submitted in the application and the attached supporting documents. {% endhint %} In this PoC, verification focuses on the information required to approve learner registration — the learner's identity, National ID number, selected educational institution, supporting documents, previous education history, and any information related to special support requirements. ## Who Can Verify Learner Data Verification should be performed only by authorised users, because verification decisions affect the quality and reliability of registry data. In the Student Registration & Enrolment process, verification includes both automated checks and manual review: 1. The system first checks the National Learner Registry to ensure a learner with the same National ID number is not already registered. If a duplicate is found, the application cannot be submitted. 2. The School Registration Officer reviews the application and supporting documents. If valid, it is sent to the MoE Registrar for final approval. 3. Only after final approval can the learner profile be created in the National Learner Registry. ## Manual Verification Steps Manual verification is the review of submitted information by an authorised user, rather than relying only on automated validation rules — used when a decision requires human judgement, document review, or confirmation that the submitted information meets organisational requirements. Within GovStack-based workflows, manual verification is usually combined with automated checks: automated rules identify missing or invalid data, while authorised reviewers assess the application content, uploaded documents, and supporting evidence before making a decision. Manual verification takes place in two stages. First, the School Registration Officer reviews the submitted application, learner information, and supporting documents, and can either **Validate** the application or **Reject** it with a reason. If validated, it proceeds to the MoE Registrar for final review, who checks the application and records the final decision — **Approve** or **Reject**. Only after approval can the learner information be used to create a record in the National Learner Registry. Manual verification therefore provides both control and traceability: it ensures authorised users review the data before it enters the registry, and that each decision is recorded as part of the process. ## Application Statuses Statuses provide a structured way to show the current state of an application within the verification process — where the application is in its lifecycle, which steps have already been completed, and what actions may happen next. {% hint style="success" %} Within this PoC, statuses reflect the progress of the application through validation and approval stages. After submission, the application may receive the status **Under Validation**. If a reviewer rejects the application, the status becomes **Rejected**, the verifier specifies the reason, and the application is returned to the applicant for correction and resubmission. After final approval, the application moves to **Awaiting QR Code Generation**, and once the learner profile credential is generated, the process reaches **Successful**. {% endhint %} Statuses make the verification process transparent for applicants, operational users, administrators, and connected systems by showing the current state and outcome of the application. ## Audit Trail and Traceability of Changes An audit trail is a chronological record of actions performed within a system. Traceability is the ability to understand how information, decisions, and changes are connected throughout a process. Together, these capabilities show who performed an action, when it happened, what was changed, and what outcome was produced. GovStack treats auditability, accountability, governance, and non-repudiation as essential characteristics of trusted digital services. In this PoC, traceability covers the full lifecycle of a registration application: submission, verification decisions, approval activities, document signing, learner profile creation, registry updates, and status changes — providing evidence of how learner information entered the National Learner Registry. Audit information is captured through workflow execution history (task assignments, user actions, decisions, events, and timestamps) and registry change history (changes to stored records). Together, these mechanisms provide a complete view of both process execution and registry operations, supporting transparency, accountability, and long-term trust in the registry data. --- # 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/learner-registry/verification-status-and-audit-trail.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.