> 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/dpi-for-education/learning-content/specifications/key-digital-functionalities.md).

# Key Digital Functionalities

This section describes what the Building Block provides to the outside world, treating the repository as a black box. Functionalities 1 to 10 are core; functionality 11 is OPTIONAL in its entirety. Requirements realising them are in Functional Requirements.

1. **Content ingestion and registration.** Accepts content and metadata from authorised providers into a managed intake, with validation applied at submission rather than after it. An authority gains one controlled door through which content enters the public asset and knows the provenance of everything that came through it; providers get immediate machine-readable feedback rather than discovering problems at review. The Building Block accepts submissions; it does not provide the environment in which content is authored.
2. **Metadata management.** Creates, validates, stores and maintains the standardised descriptive profile held for every item. Metadata is what makes content findable by software rather than only by people, and is retrievable independently of the content it describes, so a consuming system can evaluate an item before deciding to retrieve it.
3. **Curriculum and competency mapping.** Associates content with curriculum nodes and learning outcomes as independently addressable, queryable records. This is what distinguishes a learning content repository from a general content store. Because alignment is recorded rather than assumed — with assertor, framework version and review status — an authority can answer what content exists for an outcome, who says so, and what happens to those assertions when the curriculum is revised. The same content can serve several curricula without duplication. The Building Block records that content addresses a node; it does not sequence content for delivery, nor author the framework.
4. **Cataloguing and semantic classification.** Codes content against standardised ontologies and controlled vocabularies — subject, education level, resource type, pedagogical role, accessibility, language and rights. Shared vocabularies allow two systems, and two countries, to mean the same thing by the same term. Classification may be machine-suggested but is confirmed by an accountable person before publication.
5. **Search and discovery.** Allows authorised systems to query across any combination of metadata, curriculum node, competency, level, subject, language, resource type, rights and accessibility. Filtering by accessibility feature is what makes inclusive delivery achievable rather than aspirational. Search returns metadata records with resolvable references, never embedded copies of content.
6. **Content retrieval and access.** Serves content references, manifests and metadata to authorised consuming systems through documented APIs. The API is the product: any capability not reachable through the documented surface does not exist for the ecosystem. Retrieval is specified to work under constrained connectivity — bulk retrieval, changed-since synchronisation and offline-friendly packaging are part of the interface, not implementation courtesies. The repository authorises the consuming system, not the individual learner, and holds no learner data.
7. **Versioning and lifecycle management.** Versions, supersedes, deprecates and archives content and metadata with a complete auditable history. Content that changes without a version history cannot be trusted or cited; immutable versions with resolvable predecessors let a consuming system detect that what it cached is superseded, and an auditor reconstruct what was published when.
8. **Quality assurance and curation.** Supports review, approval and alignment confirmation with recorded outcomes, recorded roles and published criteria. Public content carries the authority of the body that publishes it, and an auditable gate applied against published criteria is what allows an authority to stand behind the collection and a teacher to rely on it. The workflow distinguishes metadata validation from pedagogical review because they are different judgements made by different people. The criteria themselves are set by the competent authority.
9. **Rights and licensing management.** Records and exposes licensing terms and usage rights in machine-readable form, including at component level within a package. A consuming system can only honour rights it can read; machine-readable licensing is a precondition for any open content strategy.
10. **Harvesting and federation.** Allows authorised external catalogues to harvest metadata in bulk and incrementally. Content described once can be discovered everywhere, without duplicating content and without creating competing copies whose divergence nobody can reconcile. Harvesting exposes metadata; access to content follows the same authorisation rules as for any consuming system.
11. **(Optional) AI-assisted services.** Provides bounded, human-in-the-loop semantic search, recommendation and lesson-plan assistance grounded exclusively in curated content, so that a teacher-facing tool can assemble a draft from assured national content with provenance preserved on every element. This functionality is optional in its entirety: a repository with every AI feature disabled remains fully conformant. AI processes never publish, alter or deprecate authoritative content, and never introduce generated substitute content into outputs presented as repository content.

{% hint style="info" %}
**Evidence.** Functionalities 6, 7 and 10 are exercised hardest under the conditions Kolibri is built for — versioned channels selectively retrieved and synchronised into offline environments. The GovStack architecture makes the same point as a principle, requiring Building Blocks to operate in low-resource environments with occasional power and limited bandwidth.
{% endhint %}


---

# 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/dpi-for-education/learning-content/specifications/key-digital-functionalities.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.