> 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/description.md). # Description ## Overview The Learning Content Repository (LCR) Building Block is a reusable, interoperable component that stores, organises, assures and serves curated, machine-readable learning content as shared digital public infrastructure, with explicit and queryable curriculum alignment where that alignment has been asserted, and decoupled from any delivery channel, presentation layer or application. The paradigm it encodes is content as infrastructure. Most education systems treat learning content as an attribute of a platform: each learning management system, portal or application holds its own copy, in its own format, with its own — often absent — curriculum mapping. The LCR inverts this. Content becomes a managed public asset: curated by or on behalf of the competent education authority, described with standardised metadata, alignable to one or more curriculum frameworks, and exposed through open Application Programming Interfaces (APIs) to any authorised consuming system. Platforms come and go; the asset endures. The repository is the grid, not the appliance. It does not teach, sequence, assess or convene. It guarantees that trusted, well-described content exists, is findable, and is programmatically available, and leaves delivery to the systems best placed to do it. Content and curriculum are distinct layers. A curriculum framework links to a collection of content, and the same content may be reused across several curricula and courses. Alignment between the two is an asserted relationship, modelled as a first-class record, not a property of the content. A content item may carry no alignment, one, or many. A jurisdiction may require alignment before publication as a matter of national policy, and a conformant repository is configurable to enforce such a policy; this specification does not impose one. ## Distinguishing the LCR from adjacent systems A Content Management System (CMS) creates, edits, manages and publishes content, which may or may not be curriculum-aligned. The LCR provides a shared place to register, organise, quality-assure and align learning content with curriculum elements, and makes that content discoverable and reusable across systems. A learning management system (LMS) then consumes that content to deliver learning, manage the learning experience, and track learner progress. The boundary rule used throughout: if a capability concerns the existence, description, quality, curriculum alignment or programmatic availability of content, it is LCR; if it concerns how content is delivered to, sequenced for, produced by, discussed among or assessed against learners and teachers, it is not. These are functional boundaries, not product boundaries. Real products combine several of these functions, and that is expected. Conformance is assessed against the repository functions defined here, not against whether an implementing product also performs others — so an authority evaluating a learning management system that includes a content store can assess the repository part of it on its own terms. ## Problem statement The Building Block responds to six recurring failures observed across education systems. * **Fragmentation and duplication.** Publicly funded content is scattered across disconnected systems and re-procured repeatedly, with no common point of curation or reuse. * **Weak interoperability.** Content and metadata are held in proprietary or inconsistent formats, preventing exchange and limiting machine processing. * **Weak or absent curriculum alignment.** Content is not, or only loosely, associated with the official curriculum, making it hard to find the right resource for a given competency or grade. * **Limited machine-readability.** Without standardised, semantically coded metadata, content cannot be reliably discovered, filtered, recommended or assembled by software, including by responsible artificial intelligence services. * **Inconsistent quality and provenance.** There is often no shared, auditable process for assuring the quality, accuracy, accessibility and licensing status of public learning content. * **Repeated and avoidable cost.** Every education system that builds its own repository pays separately for capability others have already funded. The effect is sharpest in smaller systems: the cost of building and sustaining a repository is largely independent of the number of learners it serves, so the smallest systems face the highest cost per learner, and many cannot justify building one at all. A standardised LCR addresses all six by providing a single authoritative, interoperable source of curated content that any compliant application can build upon. {% hint style="info" %} **Evidence.** England's Oak National Academy maintains a curriculum-sequenced body of lessons independently of any delivery platform, published largely under open licences and exposed through an open API alongside machine-readable curriculum data. India's DIKSHA, built on the open-source Sunbird stack, shows the same separation at very large scale: one national content layer powers many state portals, applications and QR-coded textbooks. {% endhint %} ## Explore this section {% columns %} {% column %} [**Actors and Roles**](/experience-digital-transformation/dpi-for-education/learning-content/specifications/description/actors-and-roles.md) {% endcolumn %} {% column %} [**Anchor Use Cases**](/experience-digital-transformation/dpi-for-education/learning-content/specifications/description/anchor-use-cases.md) {% endcolumn %} {% endcolumns %} {% columns %} {% column %} [**Scope**](/experience-digital-transformation/dpi-for-education/learning-content/specifications/description/scope.md) {% endcolumn %} {% column %} [**Relationship to Other Building Blocks**](/experience-digital-transformation/dpi-for-education/learning-content/specifications/description/relationship-to-other-building-blocks.md) {% endcolumn %} {% endcolumns %} --- # 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/description.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.