> 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/regulations/component-5/the-education-sector-and-digital-public-infrastructure.md).

# The Education Sector and Digital Public Infrastructure

Why digital public infrastructure starts with schools, the Tiger Leap and Kenya NEMIS case studies, and domain legislation as a diagnostic tool before digital regulation is designed.

## 1.1 Why DPI Is the Starting Point

The education sector is one of the most consequential sites for digital public infrastructure deployment. Schools are present in virtually every community, including those otherwise remote from government services. The school is often the first point of contact between a child and a formal institution, and frequently one of the densest concentrations of young people in a given locality. These characteristics make schools both a priority target for connectivity deployment and a natural anchor for broader digital infrastructure development — an investment in the future of communities, since today's children are tomorrow's workforce.

The Giga initiative — the joint ITU and UNICEF programme to connect every school to the internet — reflects this logic. Connectivity is the foundational DPI building block: without it, no digital education service is accessible to teachers and learners in the school. But connectivity is not sufficient on its own. Equipment, content, and the skills to use them are all needed. A functioning digital education ecosystem requires a digital identity infrastructure to authenticate students, a data governance framework to protect their records, and the administrative systems to manage their enrolment and progress. The regulatory architecture that transforms connectivity into a platform for digital education services is what this chapter addresses.

The [Greek temple framework introduced in Component 1](/experience-digital-transformation/regulations/component-1-the-landscape-of-digital-transformation-regulations/diagnostic-framework-the-greek-temple.md) helps situate the education sector's regulatory needs. The two horizontal foundation slabs — governance and legislation — support four vertical columns: access and connectivity, digital data and registries, interoperability and data exchange, and digital identity. The education sector has dependencies on all four columns, but the dependency on connectivity is the most fundamental and the first in the sequencing logic. Without the connectivity column in place, the others cannot deliver value to schools.

The sequencing principle: build connectivity and initial information systems first. Then look to digital identity arrangements, then the registries and data exchange infrastructure that connects education services to the rest of government, then the service delivery layer. Regulatory development follows the same sequence.

{% hint style="info" %}
**CASE STUDY — Tiger Leap, Estonia, 1996–2000** *School connectivity before national digital government existed*

The Tiger Leap Foundation (Tiigrihüpe) was established in 1996 to connect every Estonian school to the internet and equip classrooms with computers. Within three years, essentially all Estonian schools had internet connectivity and computer classes — a remarkable achievement for a country that had regained independence only five years earlier and was still constructing its public administration on the ruins of Soviet-era bureaucracy. At the time, average teacher salary was about US$100 a month and an average computer cost about US$1,000, so many teachers were reluctant to touch such expensive technology — "why not repair our school roof or raise our salaries" was a common objection. But political will carried the day and helped prepare Estonia to become the digital nation it is known as today.

What makes Tiger Leap analytically important is its timing. The programme began before Estonia had enacted its Digital Signatures Act (2000), before the Public Information Act (1999) was in force, and before the national digital identity infrastructure was operational. Connectivity was not preceded by a comprehensive regulatory framework — it was preceded by political will and a pragmatic decision to begin with what was possible.

The programme's teacher training and content development dimensions were inseparable from the infrastructure investment. Connectivity without digital literacy in the teaching workforce produces underutilised infrastructure. Tiger Leap's systematic teacher retraining programme — reaching tens of thousands of teachers across all schools — was as important as the hardware and network deployment.

The lesson for developing countries is not that regulation is unimportant, but that the absence of a comprehensive regulatory framework should not be treated as a reason to delay connectivity investment. Connectivity infrastructure, once deployed, creates the conditions under which regulatory needs become concrete and pressing — and under which the political will to address them is generated.
{% endhint %}

{% hint style="info" %}
**CASE STUDY — Connectivity Meets the Learner Registry: Kenya, 2016–present** *A Giga-era school connectivity and registry story*

Kenya illustrates the sequencing question in its contemporary, Giga-era form. The Digital Literacy Programme, launched in 2016, distributed over a million devices to primary schools — a classic Layer 4 investment that immediately encountered the constraints of the layers beneath it: uneven electrification, limited last-mile connectivity, and variable teacher preparedness.

The corrective moves came at the sector-DPI level. The National Education Management Information System (NEMIS), launched in 2018, assigns every learner a Unique Personal Identifier linked to birth registration — making Kenya one of the clearest examples of a learner registry driving civil registration coverage rather than merely depending on it. In parallel, Kenya became one of the first countries to work with the Giga initiative on mapping schools and their connectivity status, turning the connectivity gap from an estimate into an address list against which universal service resources could be deployed.

The lesson complements the Tiger Leap story from a different starting point: political will and visible investment can begin at any layer, but value is unlocked in the order the dependency model predicts — mapping and connectivity, the registry, and only then the full potential of the device layer. The regulatory instruments that mattered most were the universal service arrangements that could finance school connectivity and the administrative basis for NEMIS and its learner identifier.
{% endhint %}

## 1.2 The Education Sector's Place in the DPI Architecture

The education sector is both a user of shared public infrastructure and a producer of sector-specific infrastructure within the DPI framework.

As a **user**, education systems depend on three core DPI building blocks: digital identity (to authenticate learners, teachers, and administrators), payment infrastructure (for school fees, teacher salaries, and procurement), and data exchange platforms (to connect education records with civil registration, health, social protection, and labour market systems). As a **producer**, the education sector develops its own registries — of learners, teachers, schools, and qualifications — that themselves become foundational infrastructure for other government systems.

The **learner registry** is the most important education-sector contribution to the national DPI architecture. It enables the state to track progress against whatever compulsory education commitment a given society has stipulated. An authoritative, continuously maintained registry of enrolled learners — linked to civil registration records and to the national digital identity system — is the infrastructure that enables all subsequent digital education services to operate reliably. It is the equivalent of the population register in the general digital government context: the authoritative reference dataset that gives other systems their accuracy and interoperability.

The dependency runs in both directions. The learner registry depends on the civil registration system to verify identities at enrolment. But the national statistical system, the social protection system (for means-tested education benefits), the health system (for school health records), and eventually the labour market (for credential verification) all depend on the learner registry. This bidirectional dependency is characteristic of DPI: infrastructure is simultaneously dependent on other systems and depended upon by other systems — which is why its governance, including who can access it, under what conditions, and with what oversight, matters so much.

## 1.3 Domain Legislation — Understanding Who Does What Before Designing Digital Regulation

Every country has a body of domain legislation that governs education before any question of digital transformation arises. The Education Act or School Act — and often a set of subsidiary regulations — establishes the institutional architecture of the education system: which level of government is responsible for what, how schools are owned and operated, how teachers are employed and paid, how curricula are set, and how accountability flows between schools, local authorities, and the central ministry. This domain legislation is not primarily a digital governance instrument, but it is the foundation on which any digital education project must be built.

The most consequential dimension of domain legislation for digital education projects is the distribution of responsibilities between central and local government. In many countries, the ministry of education sets standards, curricula, and national policy, while municipalities or local governments are the legal owners and operators of schools — responsible for physical infrastructure, maintenance, and in some cases teacher employment. This creates a structural challenge for connectivity and school digitalisation projects: the central ministry cannot simply direct municipalities to deploy connectivity infrastructure or adopt digital systems, because the legal authority and the budget both sit at the local level. A national digitalisation programme not designed around this split will find that it has policy without implementation capacity.

The institutional mapping that domain legislation provides is therefore a prerequisite for Step 1 of the [Component 4 methodology](/experience-digital-transformation/regulations/component-4/navigation-pathways-and-the-five-step-methodology.md) — the regulatory landscape assessment. Before identifying gaps in digital regulation, a policymaker needs to know: which institution has the legal authority to establish a national learner registry? Which level of government controls the school buildings into which connectivity infrastructure will be deployed? Who employs the teachers who will be required to use digital platforms? Who procures the EdTech systems that schools use? These questions are answered by domain legislation, not by digital regulation — and getting the answers wrong at the design stage is one of the most common causes of expensive implementation failure in digital education projects.

Domain legislation also identifies the collaborators and co-funders that a digital education project requires. A project financed and designed entirely at the central level, without municipalities as co-owners of the infrastructure, is unlikely to secure the local political support and budget contributions that make school-level deployment sustainable. The Tiger Leap programme succeeded in part because it engaged schools, local governments, municipalities, and the private sector — not only because the central government willed it. The legal framework that defines the roles of each actor also defines who must be brought to the table.

For the regulatory design process, the implication is that domain legislation typically needs **amendment — not replacement** — as digital education systems mature. At early stages, an existing Education Act that is silent on digital systems is not a blocking obstacle; schools can use digital tools without explicit statutory authorisation. But as digital services move from information provision to transactions and integration — issuing legally valid credentials, maintaining authoritative enrolment records, enabling data exchange with other government systems — domain legislation needs to be brought into alignment. The most common amendments required are:

* establishing the legal basis for the national learner registry within the Education Act;
* clarifying the legal standing of digital grades and certificates;
* defining the data governance obligations of schools as data controllers; and
* establishing the conditions under which school data can be shared with the central ministry and other government systems.

These amendments are politically complex because they touch resource allocation between levels of government and the autonomy of schools and municipalities. Engaging stakeholders from the domain legislation side — municipal associations, school director organisations, teacher unions — is as important as engaging the digital governance community.

<figure><img src="https://1872054583-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxBsOoon9rxB6MLrQR5ec%2Fuploads%2FSHgx1EYICqzJ0bjfvzqA%2FStakeholders%20of%20reg%20process.png?alt=media&amp;token=65ac72e6-ad97-4426-bf2d-868a3defa62a" alt=""><figcaption></figcaption></figure>

{% hint style="success" %}
**Domain legislation as a diagnostic tool.** Before beginning a digital education regulatory design process, map the domain legislation landscape by answering five questions: (1) Which institution has the legal authority and budget to deploy connectivity to schools? (2) Who legally owns and operates the schools that will use digital systems? (3) Which institution is the legal controller of student data — the school, the municipality, or the central ministry? (4) What does existing education law say about the legal form of certificates and grades, and does it need to be amended to permit digital equivalents? (5) What consultation and co-decision rights do municipalities and schools have over national digitalisation mandates? The answers determine the institutional design of the digital education programme before any regulatory drafting begins.
{% endhint %}

This chapter continues with [Infrastructure Dependencies in Digital Education](/experience-digital-transformation/regulations/component-5/infrastructure-dependencies-in-digital-education.md), which sets out the layer and zone models that explain why digital education systems must be sequenced deliberately.


---

# 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/regulations/component-5/the-education-sector-and-digital-public-infrastructure.md?ask=<question>&goal=<user_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.
