> 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/internal-workflows.md).

# Internal Workflows

Each workflow is specified with a normative text description. Sequence diagrams are published as a supporting artefact; the textual state definitions are the source of truth, so the specification remains fully accessible without them.

## Content lifecycle

* **Submitted** — registered at ingestion with provenance, data roles and classification recorded. Schema-valid, or quarantined with machine-readable error detail.
* **In metadata review** — metadata validated against the schema and the controlled vocabularies; completeness confirmed. May return to the provider with recorded reasons.
* **In educational review** — quality assessed against the published criteria by a subject or pedagogical reviewer, and curriculum alignment asserted or confirmed. Recorded as a separate outcome with a separate accountable role. May return to the provider or to metadata review with recorded reasons.
* **Approved** — all gates passed; awaiting a publication decision.
* **Published** — discoverable and retrievable by authorised consumers. Immutable: any change creates a new version that re-enters review.
* **Deprecated** — superseded or withdrawn from recommendation. Still resolvable, with deprecation signalled programmatically.
* **Archived** — preserved for the record; excluded from default discovery.

Recall is an authority-initiated transition from Published directly to Deprecated or Archived, effective immediately across the API surface.

```mermaid
stateDiagram-v2
    [*] --> Submitted
    Submitted --> MetadataReview: schema valid
    Submitted --> Submitted: returned to provider
    MetadataReview --> EducationalReview: metadata confirmed
    MetadataReview --> Submitted: changes requested
    EducationalReview --> Approved: quality and alignment confirmed
    EducationalReview --> MetadataReview: metadata issue found
    Approved --> Published: publication decision
    Published --> MetadataReview: new version submitted
    Published --> Deprecated: superseded or recalled
    Deprecated --> Archived: retention decision
    Archived --> [*]
```

Diagram description: seven lifecycle states in order — Submitted, In metadata review, In educational review, Approved, Published, Deprecated, Archived — with return loops from either review stage to the provider, a loop from educational review back to metadata review, a path from Published back into review when a new version is submitted, and a recall path from Published directly to Deprecated.

## Curriculum-change propagation

When a framework version changes, the repository computes the set of alignment records referencing changed or removed nodes; affected content is flagged for review without being unpublished; curators re-map, confirm or deprecate each flagged alignment; and consuming systems can query flag status throughout, so nothing silently rots.

This is the operational payoff of first-class alignment records. Because each record carries its framework version and assertor, the affected set is computable rather than requiring manual audit.

## Harvesting

Authorised catalogues register, receive harvesting scopes, and pull incremental metadata through the harvesting API. Deletions and deprecations are expressed in the feed, so downstream catalogues converge on the repository's state. Content is never pushed; harvesters resolve references under normal authorisation, and harvested records resolve back to the authoritative instance.

## Access authorisation

For any request against a non-public item, the repository establishes the requesting party's identity through the Identity Building Block, determines the item's classification and recorded owner, and confirms that an applicable consent or data-sharing agreement authorises the requested operation for that party and purpose.

The repository does not evaluate or store those agreements. It records which roles are authorised for which purposes and defers to the Consent Building Block and the Information Mediator for verification and enforcement. Where no applicable authorisation exists, the request is refused and the refusal logged.

## Optional AI lesson-plan assistance

**Input:** a curriculum node and teacher constraints — time, level, language, accessibility needs. **Process:** retrieval of curated candidate resources for that node, then assembly of a draft plan citing each resource with its provenance and alignment. **Output:** a draft explicitly marked as AI-assisted, delivered to the requesting teacher-facing system for human review.

Guardrails are normative per LCR-AI-001 to LCR-AI-005: curated content only; provenance preserved on every element; the teacher decides; no autonomous publication or alteration of authoritative content; consent and transparency obligations honoured. A conformant repository MAY omit this workflow entirely.


---

# 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/internal-workflows.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.