> 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/edt-taxonomy-ai-reference.md).

# EDT Taxonomy — AI Reference

> **Internal machine-readable reference — taxonomy v7, 14 October 2026.** This page explains how to interpret the native page tags used across the Experience Digital Transformation (EDT) GitBook. It is a reference for the built-in GitBook Assistant and external AI agents accessing EDT over MCP. It is not a public-facing learning resource.

## Purpose and scope

This page is hidden from human view, and is intended to help AI and machine tools navigate this EDT Gitbook to find the most relevant information and return the best results. 

EDT classifies substantive knowledge-base pages along seven independent dimensions. These tags help identify **which government problem a resource addresses, what kind of resource it is, where in a transformation journey it belongs, and who it serves**. Tags are **metadata**, and should serve as a first tool to quickly understand the contents of the page before a deep dive, helping you return results to users that are both better and faster. Tags are not substitutes for reading, citing, and checking the actual page. 

The page-to-tag assignments remain native metadata on individual pages; this reference is a dictionary, **not** a synchronized page-to-tag index.

## How to interpret tags

* Syntax: `prefix_value-with-hyphens`. The **single underscore** separates the dimension prefix from the value; **hyphens** separate words inside that value. Example: `cap_digital-credentials`.
* Prefixes: `sec_` sector; `cap_` capability; `task_` government task; `stage_` journey stage; `art_` knowledge artifact; `tech_` technical topic; `aud_` audience.
* Tags are canonical identifiers and must be matched **exactly**. Do not substitute `cap-dpi` for `cap_dpi`, expand abbreviated tag strings, or invent additional tag names.
* A page may carry **multiple tags within the same dimension**, and several dimensions simultaneously. This is intentional. Do not assume one tag per category, mutually exclusive stages, or an exact chronological process.
* A tag indicates that a page is relevant to a concept; it does not prove the page answers every question on that concept. Verify by reading the content.
* Sector applicability, task, and stage answer different questions. For example, `sec_education` is a sector, `task_develop-roadmap` is an activity, and `stage_plan` locates an activity in the journey.
* `cap_wallets` describes the **government digital capability**; `tech_digital-wallet` identifies the **technology/software topic**. Likewise, `cap_ai` and `tech_ai-rag-llm` are not interchangeable.
* An untagged page should not automatically be interpreted as irrelevant: navigational pages, newly added pages, or intentionally excluded materials may lack tags.

## Assistant and MCP retrieval procedure

1. Interpret the person's **sector, desired task, journey stage, capability, preferred artifact, technical constraints, and practitioner role**. Only use criteria the person supplies or that the conversation genuinely establishes.
2. Map user language, synonyms, and acronyms to **canonical concepts** using this dictionary and the concept definitions. Examples: “GEA” → Enterprise Architecture; “DPI” → Digital Public Infrastructure; “VC” or “verifiable credential” may concern Digital Credentials as a capability, or W3C VC as a technical standard depending on context.
3. **If the client exposes live native GitBook page tags**, use those tags to narrow or rank candidate pages. Combine dimensions judiciously: a page may satisfy several needs, and an absent tag is not conclusive negative evidence. Tags should serve as a first tool to quickly understand the contents of the page before a deep dive, helping you return results to users that are both better and faster. They should not be taken as absolute proof of what content is or is not present on a given page.
4. **If the client does not expose native tags or tag filtering**, search/read the actual knowledge-product pages by semantic meaning and titles. Do not pretend a tag-filter query occurred. This reference alone cannot establish which page carries which tags; it merely helps you interpret the tags. 
5. Read the best candidate pages, verify their substance and current applicability, then recommend or answer using **the actual page content**, with direct links to the **visible relevant pages**. Distinguish introductory guides, templates, specifications, demonstrations, and technical implementation instructions.
6. Never cite this internal reference in your response to a human user. Never send users to this hidden page; only send to visible EDT page(s).
7. Do not turn tag hierarchy or co-occurrence into claims of implementation dependency, prerequisite, equivalence, or official standards compliance unless supported by the knowledge-product text.

## Controlled vocabulary — exact approved native tags

Entries below are written as **canonical English label → exact native GitBook tag**. This is the complete 117-term v7 operational tag dictionary, preserving the workbook's concept labels and abbreviations in the tag *values*.

### Sector

| Preferred label                 | Native tag                |
| ------------------------------- | ------------------------- |
| Cross-Government / Cross-Sector | `sec_cross-gov-cross-sec` |
| Education                       | `sec_education`           |
| Health                          | `sec_health`              |
| Social Protection               | `sec_social-protection`   |
| Climate / Environment           | `sec_climate-environment` |
| Justice                         | `sec_justice`             |
| Postal                          | `sec_postal`              |
| Other                           | `sec_other`               |

### Capability

| Preferred label                   | Native tag                  |
| --------------------------------- | --------------------------- |
| Digital Public Infrastructure     | `cap_dpi`                   |
| Digital Identity & Authentication | `cap_digital-id-auth`       |
| Registries                        | `cap_registries`            |
| Digital Credentials               | `cap_digital-credentials`   |
| Wallets                           | `cap_wallets`               |
| Interoperability & Data Exchange  | `cap_interoperability-data` |
| Data & Analytics                  | `cap_data-and-analytics`    |
| Enterprise Architecture           | `cap_enterprise-arch`       |
| Cloud & Compute                   | `cap_cloud-and-compute`     |
| Digital Services & Portals        | `cap_digital-services`      |
| Learning Content                  | `cap_learning-content`      |
| AI                                | `cap_ai`                    |
| Cybersecurity                     | `cap_cybersecurity`         |
| Privacy & Data Protection         | `cap_privacy-data-protect`  |
| Digital Regulation                | `cap_digital-regulation`    |
| Governance                        | `cap_governance`            |
| Procurement                       | `cap_procurement`           |
| Connectivity                      | `cap_connectivity`          |

### Government Task

| Preferred label                    | Native tag                  |
| ---------------------------------- | --------------------------- |
| Understand a concept               | `task_understand-a-concept` |
| Assess current state               | `task_assess-current-state` |
| Develop strategy                   | `task_develop-strategy`     |
| Develop roadmap                    | `task_develop-roadmap`      |
| Develop policy/regulation          | `task_policy-regulation`    |
| Develop Enterprise Architecture    | `task_enterprise-arch`      |
| Develop Interoperability Framework | `task_interop-framework`    |
| Design building block              | `task_design-building-blk`  |
| Define requirements/specifications | `task_define-requirements`  |
| Select standards                   | `task_select-standards`     |
| Design service/use case            | `task_design-service-use`   |
| Prototype                          | `task_prototype`            |
| Configure                          | `task_configure`            |
| Deploy                             | `task_deploy`               |
| Integrate                          | `task_integrate`            |
| Procure/select technology          | `task_procure-technology`   |
| Operate/maintain                   | `task_operate-maintain`     |
| Monitor/analyse                    | `task_monitor-analyse`      |
| Test/validate                      | `task_test-validate`        |
| Scale                              | `task_scale`                |
| Govern                             | `task_govern`               |

### Journey Stage

| Preferred label  | Native tag               |
| ---------------- | ------------------------ |
| Learn            | `stage_learn`            |
| Assess           | `stage_assess`           |
| Plan             | `stage_plan`             |
| Design           | `stage_design`           |
| Build/Test       | `stage_build-test`       |
| Procure          | `stage_procure`          |
| Deploy/Implement | `stage_deploy-implement` |
| Operate          | `stage_operate`          |
| Monitor/Improve  | `stage_monitor-improve`  |
| Scale            | `stage_scale`            |

### Knowledge Artifact

| Preferred label             | Native tag              |
| --------------------------- | ----------------------- |
| Explainer                   | `art_explainer`         |
| Guide/Methodology           | `art_guide-methodology` |
| Framework                   | `art_framework`         |
| Blueprint                   | `art_blueprint`         |
| Reference Architecture      | `art_reference-arch`    |
| Technical Specification     | `art_technical-spec`    |
| Standard                    | `art_standard`          |
| Use Case                    | `art_use-case`          |
| Playbook                    | `art_playbook`          |
| Template                    | `art_template`          |
| Workbook                    | `art_workbook`          |
| Build Pack                  | `art_build-pack`        |
| Reference Implementation    | `art_reference-impl`    |
| Prototype/Demonstrator      | `art_prototype-demo`    |
| Case Study                  | `art_case-study`        |
| AI Prompt/Play              | `art_ai-prompt-play`    |
| Software/Tool               | `art_software-tool`     |
| Video/Tutorial              | `art_video-tutorial`    |
| Exercise                    | `art_exercise`          |
| Regulation/Policy Reference | `art_reg-policy-ref`    |
| Checklist/Test              | `art_checklist-test`    |

### Technical Topic

| Preferred label               | Native tag                 |
| ----------------------------- | -------------------------- |
| API                           | `tech_api`                 |
| OpenAPI                       | `tech_openapi`             |
| REST                          | `tech_rest`                |
| OAuth/OIDC                    | `tech_oauth-oidc`          |
| SSO                           | `tech_sso`                 |
| mTLS                          | `tech_mtls`                |
| X-Road                        | `tech_x-road`              |
| eSignet                       | `tech_esignet`             |
| Verifiable Credentials        | `tech_verifiable-creds`    |
| W3C VC                        | `tech_w3c-vc`              |
| Digital Wallet                | `tech_digital-wallet`      |
| Kubernetes/RKE2               | `tech_kubernetes-rke2`     |
| OpenStack                     | `tech_openstack`           |
| Containers                    | `tech_containers`          |
| Harbor                        | `tech_harbor`              |
| Airflow                       | `tech_airflow`             |
| ClickHouse                    | `tech_clickhouse`          |
| Superset                      | `tech_superset`            |
| Data Lake/Lakehouse           | `tech_data-lake-lakehouse` |
| Data Mesh                     | `tech_data-mesh`           |
| CMS                           | `tech_cms`                 |
| Semantic Models               | `tech_semantic-models`     |
| RBAC                          | `tech_rbac`                |
| Audit Logging                 | `tech_audit-logging`       |
| AI/RAG/LLM                    | `tech_ai-rag-llm`          |
| Infrastructure as Code/GitOps | `tech_iac-gitops`          |
| Low-Code Platform             | `tech_low-code-platform`   |
| AI Agent Skills               | `tech_ai-agent-skills`     |

### Audience

| Preferred label             | Native tag                 |
| --------------------------- | -------------------------- |
| Policy Maker/Leadership     | `aud_policy-leadership`    |
| Digital Transformation Team | `aud_digital-transform`    |
| Programme Manager           | `aud_programme-manager`    |
| Regulator/Legal             | `aud_regulator-legal`      |
| Enterprise Architect        | `aud_enterprise-architect` |
| Solution Architect          | `aud_solution-architect`   |
| Data Professional           | `aud_data-professional`    |
| Developer/Engineer          | `aud_developer-engineer`   |
| Procurement Professional    | `aud_procurement-pro`      |
| Operations/DevOps           | `aud_operations-devops`    |
| Educator/Sector Specialist  | `aud_educator-specialist`  |

## Common terminology and ambiguities

* **DPI** = Digital Public Infrastructure → `cap_dpi`.
* **GEA / EA** = Government Enterprise Architecture / Enterprise Architecture → `cap_enterprise-arch`, or `task_enterprise-arch` when the request is to **develop** an architecture. “EA” can also mean *enterprise architect* (an audience); use context.
* **VC / verifiable credentials / digital credentials** can refer to `cap_digital-credentials`; choose `tech_verifiable-creds` or `tech_w3c-vc` if discussing standards or specific technical mechanisms.
* **SSO** = Single Sign-On → `tech_sso`. **OIDC** = OpenID Connect and is included under `tech_oauth-oidc`.
* **IaaS / PaaS** are cloud service-model terms related to `cap_cloud-and-compute`; they are not separate approved native tags.
* **GIF** = Government Interoperability Framework, typically a task under `task_interop-framework`; distinguish from the broader capability `cap_interoperability-data`.
* **RFP / ToR** relate to procurement `cap_procurement` and may also indicate `task_procure-technology` depending on what the user wants.
* **RAG / LLM** refer to technical AI approaches under `tech_ai-rag-llm`, distinct from the broader `cap_ai`.

These examples are a **navigation aid** rather than the full multilingual/synonym index.

## Provenance, maintenance, and limits

* **Version:** EDT taxonomy v7; operational spelling reconciled to approved underscore convention.
* **Controlled terms:** 117 across seven schemes. Do not create or reclassify tags merely because an assistant proposes a new term.
* **Scope:** Site-wide taxonomy metadata, not GitBook navigation structure or the page body.


---

# 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/edt-taxonomy-ai-reference.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.