> 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/actors-and-roles.md).

# Actors and Roles

This specification distinguishes data roles, which attach to the repository and to the items held in it, from system actors, which describe the parties that interact with the Building Block.

## Data roles

Every repository, and every item within it, carries the following roles. A conformant implementation MUST be able to record them, because they are what allows an implementer to configure role-based access and permission controls.

| Role       | Definition                                                                                   |
| ---------- | -------------------------------------------------------------------------------------------- |
| Owner      | The single authority entitled to grant access to the item. May be an individual or an entity |
| Custodian  | The party accountable for holding the item and for its integrity while held                  |
| Maintainer | The party operating the infrastructure on which the item is held                             |
| User       | Any party that consumes the item. Plural by nature                                           |
| Issuer     | The party that issued the item, where issuance is distinct from ownership                    |

Ownership of a repository is distinct from ownership of an item within it. An education authority may own a repository while an individual owns a certificate held in it, or a contributing institution owns a resource it submitted. A conformant implementation MUST represent both levels.

Under the GovStack Single Source of Truth principle there are no duplicate copies, so an item has one owner, one issuer and one custodian; users and maintainers may be plural. Federation across institutions therefore means distributed custody of non-duplicated items, not replication.

Access enforcement is not a function of this Building Block. The owner is the single authority to grant access. Where an item is not classified public, that authority is expressed through a consent agreement signed by an individual owner, or a data-sharing agreement signed by the sharing entities, and enforced by the Consent Building Block and the Information Mediator. This specification states which roles are authorised for which purposes; it does not implement the enforcement.

## System actors

| Actor                                     | Role relative to the Building Block                                                                                                                                                        |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Curriculum / education authority          | Owns the curriculum framework; sets quality and alignment policy; accountable for the repository as a public asset                                                                         |
| Metadata curators                         | Validate metadata against the schema and the controlled vocabularies; confirm completeness                                                                                                 |
| Subject experts and pedagogical reviewers | Assess educational quality and assert curriculum alignment — a disciplinary judgement, distinct from metadata validation and in practice performed by different people                     |
| Accredited content providers              | Submit content and metadata under authorisation. Providers may be institutional publishers, or individual educators contributing under an authorisation granted by the competent authority |
| Consuming systems                         | Learning management systems, EdTech applications, teacher tools, national portals and AI services that discover and retrieve content via the APIs                                          |
| External catalogues                       | Authorised aggregators and federated repositories that harvest metadata                                                                                                                    |
| Teachers and learners                     | Beneficiaries, whether through a consuming system or, where a jurisdiction chooses, through a learner-facing application                                                                   |
| Repository operator                       | The organisation running a conformant implementation on the authority's behalf                                                                                                             |

The operating arrangement varies legitimately: the education ministry in-house; an arm's-length public body or national agency; a supplier contracted under public governance; or a regional body acting for several states. What holds constant is the separation of accountability — the curriculum authority owns the curriculum and sets alignment policy, the operator runs the infrastructure. They may be the same legal entity, but the accountabilities remain distinct, and that separation is what allows the content asset to survive a change of operator.


---

# 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/actors-and-roles.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.
