> 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/education-publications/education-dpi-publications/charter-for-public-digital-learning-platforms/principle-5-open.md).

# Principle 5: Open

Connected and interoperable, modular in architecture, openly licensed, and open by design.

### 5.1 Connected and interoperable systems

PDLPs should function as connected and interoperable systems where different services within a platform link with and reinforce other services. Systems used for assessments should, for example, help teachers locate relevant content and lesson plans to address areas of strength and weakness. Today, many platforms consist of stand-alone applications that rarely 'talk to' each other, forcing learners, teachers, and school leaders to enter and locate redundant information across multiple systems. PDLPs should prioritize interconnections that enable secure data exchange and create a seamless experience for users.

### 5.2 Modular architecture

PDLPs should be built from modular digital components that are standards-based and secure by design. These building blocks can include services such as identity systems, content repositories, or credentialing platforms that support multiple education services. A modular architecture allows individual components of larger systems and platforms to be improved or replaced over time without rebuilding entire systems. This approach reduces duplication and costs, minimizes vendor lock-in, and helps governments maintain long-term control over their digital education infrastructure. Procurement policies should prioritize compliance with modular and interoperable architecture to ensure that platforms can evolve, link, integrate new services, and avoid dependency on proprietary solutions.

### 5.3 Open licensing

PDLPs should apply open licenses to content and software, following the principles set out in UNESCO's Recommendation on Open Educational Resources. This enables resources to be reused, adapted, and shared across institutions and, if desired, countries. Open licenses help reduce costs and simplify integration. When learning content on PDLPs is openly licensed, it can be shared, reused, and remixed by teachers and others, according to their needs. Governments should encourage educational institutions and teachers to develop, adapt, and share open educational resources.

### 5.4 Open by design

PDLPs should be open to as many users as possible, including users who may decline to establish profiles with email addresses, phone numbers, birthdays, national identification numbers, passwords, or other identifying information. Logging-in to an educational platform can enhance personalization options, enable interactions with other users, and offer expanded functionality, but this action should not be required to access learning content. One of the great strengths of PDLPs is the ability to accommodate large numbers of users at a relatively low cost and without limiting content to users with certain credentials. The doors to PDLPs should be wide open. An education system with platforms that reach large numbers of teachers, learners, and parents is an education system with wider reach. PDLPs will always have to balance safety and security with openness, but an ethic of openness should be a default stance.


---

# 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/education-publications/education-dpi-publications/charter-for-public-digital-learning-platforms/principle-5-open.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.