> 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/infrastructure-dependencies-in-digital-education.md).
# Infrastructure Dependencies in Digital Education
The six-layer infrastructure model, the three concentric zones of the digital education ecosystem, and the dependency table mapping education digital systems to their regulatory prerequisites.
This chapter continues directly from [The Education Sector and Digital Public Infrastructure](/experience-digital-transformation/regulations/component-5/the-education-sector-and-digital-public-infrastructure.md).
A functioning digital education ecosystem comprises multiple interconnected systems, each depending on others being in place and each enabling others to function. Governments that attempt to deploy these systems simultaneously — or in the wrong sequence — typically produce expensive failures: systems that cannot interoperate, registers that cannot be verified, credentials whose legal standing is uncertain, and platforms that process student data without adequate governance.
Understanding why sequencing matters requires looking at the infrastructure before looking at the systems built on top of it. Two analytical frameworks help here, and together they explain the structure of the dependency table below.
## The Six-Layer Infrastructure Model
| Layer | What it is |
| -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Layer 1 — Main connectivity** | The national backbone — mobile networks, fibre routes, or satellite capacity — that brings the internet to a school's locality. Created by national telecommunications policy and investment; sits largely outside the education sector's direct control. |
| **Layer 2 — Last-mile connectivity** | The distribution of that connection to and within the school, potentially extending to neighbouring community facilities. This is the layer school connectivity programmes such as Giga target, and where aggregating demand across schools can change the economics of deployment. |
| **Layer 3 — Electrification** | Reliable power for network equipment and devices. In many rural contexts this, rather than connectivity, is the binding constraint, and energy solutions — including solar — must be planned jointly with the network rollout. |
| **Layer 4 — In-school infrastructure** | The devices, local networks, and physical equipment that teachers and students use. The most visible and politically attractive layer, but it delivers value only when the three layers beneath it are in place. |
| **Layer 5 — Cloud infrastructure** | The hosting and computing capacity on which sector-level systems run. Its location and governance determine the [data residency and sovereignty questions](/experience-digital-transformation/regulations/component-3-comparative-analysis-of-regulations/cloud-and-digital-infrastructure-regulations-sovereignty-trust-and-best-practice.md) that surface later in regulatory design. |
| **Layer 6 — Sector-level DPI** | The content repository, teacher training systems, registries, and assessment platforms that operate at the level of the whole education system rather than the individual school. |
The critical insight this model provides is asymmetric: systems at the school level (Layer 4 — devices, LMS, school management platforms) require all four lower layers to be in place before they can deliver value. But systems at the sector DPI level (Layers 5–6 — content repository, teacher training, registries) require only basic connectivity and cloud access. A school with minimal connectivity and no classroom devices can still benefit from a centrally maintained content repository that teachers download and use — professional development, curriculum materials, lesson planning — without waiting for the full school-level infrastructure stack. The same holds for education management information systems: data analytics that inform decision-making and resource allocation deliver value at ministry and school-leadership level even where classrooms remain offline. This asymmetry has a direct implication for sequencing: many countries have invested heavily in Layer 4 (device distribution programmes) before securing Layers 1–3, producing expensive and fragile deployments. The more resilient sequencing invests first in connectivity and simultaneously in the sector-level content and data infrastructure that empowers teachers even when classroom devices are limited or absent.
Two truths must be held together here, and the layer model is what reconciles them. Connectivity remains the foundational equaliser: the direction of travel is not negotiable, because digital skills cannot be taught on a blackboard, and children in unconnected schools are cut off from the knowledge and ways of working that their connected peers absorb as everyday habit. At the same time, the teacher — not the device — is the primary early recipient of digital value: sector-level content, training, and data systems deliver returns at even minimal connectivity, while the device-intensive school-level layer is where the largest investments, the greatest fragility, and the most acute risks — screen time, cyberbullying, stranded assets — concentrate. Serving partially connected schools through the sector-level layer is therefore a transitional strategy to be designed deliberately, not a steady state to be accepted.
## The Three Concentric Zones
The second framework maps the systems and actors of the digital education ecosystem onto three concentric zones.
**The inner zone — the school-level layer** — contains the systems that teachers and students interact with directly: the learning management system, school management platform, EdTech applications, and teacher-parent communication tools. These systems are deployed and managed across thousands of individual schools, typically involve private sector providers, and require substantial investment in teacher training to deliver educational value.
**The middle zone — the sector-wide DPI layer** — contains the systems that operate at the level of the whole education system: learner registries, national assessment platforms, content repositories, teacher training systems, certification infrastructure, and education management information systems. These systems are strategic, require high compliance and security standards, and call for strong government control to protect data sovereignty.
**The outer zone** is the national DPI layer that education shares with other sectors: digital identity, payment infrastructure, cloud exchange, consent management.
Across all three zones, **AI functions as a cross-cutting capability** — embedded in tutoring tools at the school level, in analytics and content generation at the sector level, and in identity and fraud detection at the DPI level — rather than as a separate system residing in any one zone.
These two frameworks together show where regulatory concerns enter the picture. In the **outer zone**, education is a user of national DPI infrastructure it does not govern — the regulatory instruments here are horizontal (digital identity legislation, data protection law, electronic signatures framework), and education sector regulation can only specify the conditions of use, not the design of the infrastructure itself. In the **middle zone**, education-specific regulation is most critical and most tractable: enabling legislation for the learner registry, data governance rules for sector-wide systems, interoperability obligations between the registry and civil registration, and procurement standards for the content repository — this is where a ministry of education has both the authority and the responsibility to act. In the **inner zone**, the operative regulatory instruments are EdTech procurement standards, data protection requirements for processors of student data, and school-level governance obligations — the framework that ensures commercial providers handling student data do so under conditions the public interest requires. The AI cross-cutting layer introduces regulatory requirements spanning all three zones: algorithmic transparency and human oversight obligations that apply whether AI is deployed in a classroom tool, a national assessment system, or an identity verification process.
## The Education Digital System Dependency Table
The table below maps these regulatory entry points onto the specific digital education systems, their dependencies, and the prerequisites that become binding at each stage.
| Education Digital System | Depends on | Enables | Primary regulatory prerequisites |
| ------------------------------------------ | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| School connectivity infrastructure | Telecommunications regulation; physical infrastructure policy | All other digital education services | Telecoms regulation (Cat. 1); universal service obligations; school connectivity targets |
| Teacher and staff digital identity | National digital identity framework (Cat. 7) | Authenticated access to all school systems; digital signing of records | Digital identity legislation; authentication standards; professional registry linkage |
| Learner registry | Civil registration / birth registry; school connectivity; staff digital identity | Assessment systems; credentials; EdTech access management; statistical reporting | Enabling legislation for registry; data protection for minors (Cat. 2); interoperability framework (Cat. 5) |
| School administration platform | School connectivity; staff digital identity; basic learner registry | Digital communication with families; attendance and grade management; timetabling | Data protection (Cat. 2); enabling legislation for digital administrative records (Cat. 6) |
| National assessment and examination system | Learner registry; school connectivity; digital identity for exam candidates | Digital credentials and certificates; higher education admissions; labour market data | Data protection (Cat. 2); legal standing of digital assessment results (Cat. 6); interoperability (Cat. 5) |
| Digital credentials and certification | Learner registry; national assessment system; digital identity; trust services | Cross-border qualification recognition; employer verification; lifelong learning records | Trust services / e-signature legislation (Cat. 7); credentials legal framework (Cat. 9); sectoral education law |
| EdTech and digital learning platforms | School connectivity; learner identity management; data protection framework | Personalised learning; AI-assisted instruction; learning analytics | Data protection for minors (Cat. 2); platform regulation (Cat. 4); AI governance for learning algorithms (Cat. 5); procurement regulation (Cat. 8) |
| Education data exchange and statistics | Learner registry; assessment system; school administration platform | Ministry planning; international reporting (UNESCO, SDG4); research | Interoperability framework (Cat. 5); open data regulation (Cat. 8); statistical legislation |
{% hint style="warning" %}
**Editorial note.** The dependency table above is reproduced exactly as it appears in the source draft, including its category citations. Those citations are internally inconsistent: three rows cite "Cat. 5" for the **interoperability framework** (learner registry, national assessment system, and education data exchange rows), while the EdTech row cites "Cat. 5" for **AI governance for learning algorithms** — and AI Governance is Category 5 in Component 1's Track A numbering (interoperability is not a standalone numbered category there; Component 3 profiles it as a split-out of Track B Category 6). Rather than silently resolve which citation is the typo, this has been preserved as written for the team's manual QA pass. The Category 1, 2, 4, 6, 7, 8, and 9 citations in the table are consistent with [Component 1's](/experience-digital-transformation/regulations/component-1-the-landscape-of-digital-transformation-regulations.md) ten-category numbering and have not been altered.
{% endhint %}
Why these dependencies matter for regulatory design: a government that legislates a digital credentials framework before the learner registry and national assessment system it depends on are operating will produce a legal instrument with nothing reliable to certify. A government that deploys an EdTech procurement standard before basic data protection coverage exists will be unable to enforce the very conditions the standard sets out. The dependency table is therefore a sequencing tool as much as a technical map — how that sequencing plays out in practice is the subject of [Sequencing Digital Education Systems](/experience-digital-transformation/regulations/component-5/sequencing-digital-education-systems.md).
---
# 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/infrastructure-dependencies-in-digital-education.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.
