> 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/cross-functional-requirements.md). # Cross-Functional Requirements A conformant implementation MUST satisfy the GovStack cross-functional requirements baseline (govstack-cfr) and the GovStack Security Requirements in full. The requirements below extend that baseline for the education domain. | ID | Requirement | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | LCR-CC-002 | The repository MUST ensure the integrity of content and metadata, including tamper-evidence for published items — for example checksums or signatures on manifests — so that a consuming system can establish that what it retrieved is what was published | | LCR-CC-003 | Beyond the logging carried by the baseline, the repository MUST record the domain events of the content lifecycle — submission, metadata validation, quality review, alignment assertion, publication, version supersession, deprecation and recall — each with actor, role, timestamp and recorded outcome, and MUST expose them for audit | | LCR-CC-004 | The repository MUST minimise personal data. Content and metadata records MUST NOT embed personal data of learners. Where usage logs or optional AI features process personal data, processing MUST comply with applicable data-protection law and MUST consume the Consent Building Block. Provenance identifying an individual contributor is required by LCR-ING-004 and is not learner data | | LCR-CC-006 | Metadata, vocabularies and curriculum representations MUST conform to the models in Data Structures, with published crosswalks to the standards listed in Other Resources | | LCR-CC-007 | Every metadata record MUST carry accessibility metadata sufficient for a consuming system to filter by accessibility features and by known limitations. Accessibility description SHOULD align to recognised standards, for example schema.org accessibility properties informed by WCAG | | LCR-CC-008 | The repository MUST permit content in any language to exist within it and MUST NOT privilege any language in its data model. Language and script MUST be tagged using IETF BCP 47 on every content item and metadata record. Language editions of the same underlying resource MUST be linked as such. The repository MUST provide an indexing scheme allowing a consuming system to discover content across languages and retrieve the edition it requires. This specification does not define the content of any language edition | | LCR-CC-009 | The repository MUST remain operable and consistent at the scale of the system it serves. Implementations MUST document their availability, performance and capacity characteristics, and MUST provide for long-term preservation and archival of published content, including content deprecated or withdrawn from active discovery | | LCR-CC-011 | The specification and conformant repositories SHOULD align with the Digital Public Goods Standard. Publicly funded content SHOULD carry open licences consistent with the UNESCO OER Recommendation where national policy permits | | LCR-CC-013 | Consuming-system interfaces MUST function under constrained connectivity. Bulk retrieval, caching signals and offline-friendly packaging are REQUIRED capabilities of the API surface, not implementation courtesies | | LCR-CC-014 | Every content item MUST carry a classification determining its visibility: public, private or confidential. Classification MUST be recorded at registration and MUST be exposed to authorised consuming systems | | LCR-CC-015 | The owner of an item is the single authority entitled to grant access to it. Where an item is not classified public, access MUST be authorised through a consent agreement signed by an individual owner, or a data-sharing agreement signed by the sharing entities. The repository MUST record which roles are authorised for which purposes; it MUST NOT implement its own enforcement of those agreements, which is performed by the Consent Building Block and the Information Mediator | | LCR-CC-016 | The repository MUST hold a single authoritative instance of each content item, consistent with the GovStack Single Source of Truth principle. Where several institutions participate in a shared repository, participation MUST be by distributed custody of non-duplicated items, not by replication. Cached copies held by consuming systems for offline use under LCR-CC-013 are not duplicates for the purposes of this requirement, provided they resolve to the authoritative instance and can detect supersession | {% hint style="info" %} **Evidence.** The accessibility and multilingual requirements are not aspirational. Norway's NDLA maintains publicly owned resources across two written language standards with open APIs, and Finland's aoe.fi records metadata in Finnish, Swedish and English — evidence that BCP 47-tagged multilingual records and accessibility description are operationally routine when specified from the start, and painful to retrofit when not. {% 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/cross-functional-requirements.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.