> 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/gif/building-a-government-interoperability-framework-gif.md). # Building a Government Interoperability Framework (GIF) Knowledge base for the \*Building a Government Interoperability Framework (GIF)\* video series — the concepts, the AI plays, the worked example and the runnable build pack, in one place. 38 videos in five modules · about 176 minutes of video · 38 AI plays · a runnable build pack · self-paced · free and open This is the companion to the video series on building a Government Interoperability Framework — the legal, organisational and technical configuration that lets public bodies exchange data so that a citizen is asked once. Where [Developing a Gov Enterprise Architecture (GEA)](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea) taught how to *plan* an Enterprise Architecture, this course teaches how to *build* the interoperability layer over that plan. The videos give you the concept in four to five minutes each. This knowledge base is where you do the work: every subtopic ends with a **play** (a structured prompt you run against your own country's context), a worked example on the fictional country Progressa, and an annotated reading of the result. This course ships two things. The videos and plays, which teach the build. And the [**build pack**](/experience-digital-transformation/gif/the-build-pack.md), which *is* the ready solution: a real once-only exchange running on an X-Road federation across Progressa's institutions — the decree, the Governance Pack, the semantic map and contracts, the member registrations, and the acceptance check that proves it. Run the plays and you leave with your own country's configuration; run the pack and you see the finished one. {% embed url="" %} Introduction to the course (\~9 min) {% endembed %} **Watch first (\~9 min).** Then come back for the play. ## Outline | Module | Topic | Persona | Videos | Plays | Status | | ------------------------------------------------------------------------------------------------ | ----------------------------------------- | ---------------------- | ------ | -------- | ----------- | | [1](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers.md) | Why interoperability and the four layers | Strategist | 7 | 7 plays | Videos live | | [2](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit.md) | Legal framework — the Decree Drafting Kit | Strategist | 6 | 6 plays | Videos live | | [3](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci.md) | Governance model — three tiers with RACI | Strategist | 6 | 6 plays | Videos live | | [4](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards.md) | Architecture and technical standards | Architect | 8 | 8 plays | Videos live | | [5](/experience-digital-transformation/gif/module-5-implementation-and-onboarding.md) | Implementation and onboarding | Architect / Strategist | 10 | 10 plays | Videos live | *Prompts live — concept and play on every page, worked example pending. Worked examples live — Progressa run and annotated. Videos live — embeds on every page.* {% hint style="success" %} **How the course works.** **Watch** the video → **Play** it on your own country → **Read** the output the way an architect would → **Carry** the artefact into the next play. Each play produces a numbered artefact (**B1–B38**), and the artefacts feed each other; run a module and the outputs assemble into [your framework workbook](/experience-digital-transformation/gif/your-framework-workbook.md) — the configuration of your own framework, layer by layer. {% endhint %} ## Audience — and the path for your role | Persona | Who that is in practice | Modules | What you leave with | | -------------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Strategist** | National interoperability authority, ministry CIO, Ministry of Justice sponsor, or development-partner lead | [1](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers.md), [2](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit.md), [3](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci.md), [5](/experience-digital-transformation/gif/module-5-implementation-and-onboarding.md) | The case and the foundation: why interoperability is built, the four layers, the once-only exchange to start with, the Strategic Foundation Document and the Use-Case Catalogue; the decree and the governance the framework needs; and, once it runs, the cross-check that keeps its documents honest and the portability map for the next sector. | | **Architect** | Chief or senior architect, integration lead, or agency technical lead building on the interoperability bus | [4](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards.md), [5](/experience-digital-transformation/gif/module-5-implementation-and-onboarding.md) | The build: the functional layers and trust zones, the standards portfolio, the semantic map and service contracts generated for a real exchange, the federation stood up and proven with a live once-only call, the production gap, and the bus watched from its logs. | This knowledge product covers the whole framework, but no single person does all of it. A governance lead does not draft articles; a technical architect does not write decrees. So the content is shaped into role-paths — curated routes through the videos, the plays and the build pack for each role that builds a framework — so a learner finds their lane instead of being asked to watch everything. | Role | Who | Follow these | Your path ends at | After it you can | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Strategist** | The national interoperability authority, a ministry CIO, a Ministry of Justice sponsor or a development-partner lead — who commissions and oversees the whole | [1.1](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.1-why-interoperability-cant-be-bought-only-built.md), [1.2](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.2-the-four-layers-of-interoperability.md), [1.3](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.3-the-once-only-promise.md), [1.4](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.4-the-strategic-foundation-document.md), [1.5](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.5-the-use-case-catalogue.md), [1.6](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.6-mapping-your-stakeholders.md), [1.7](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.7-what-the-world-already-proved.md), [5.1](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.1-plan-the-build-in-four-phases.md), [5.9](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.9-keep-the-documents-honest-the-consistency-cross-check.md), [5.10](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.10-carry-the-framework-to-the-next-sector.md) | the Strategic Foundation Document, the Use-Case Catalogue and the four-phase plan — and the sector-portability map for the next sector | Make the case, set the foundation, fund the build in phases, and take the framework to the next sector. | | **Governance lead** | The person who will run the Operating Authority or chair the Steering Committee | [1.1](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.1-why-interoperability-cant-be-bought-only-built.md), [1.2](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.2-the-four-layers-of-interoperability.md), [1.3](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.3-the-once-only-promise.md), [3.1](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.1-why-a-bus-needs-an-owner.md), [3.2](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.2-the-three-tiers-of-governance.md), [3.3](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.3-the-raci-matrix.md), [3.4](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.4-member-obligations.md), [3.5](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.5-the-four-technical-working-groups.md), [3.6](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.6-governance-as-living-configuration.md), [5.9](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.9-keep-the-documents-honest-the-consistency-cross-check.md) | the Governance Pack — the organisational configuration of the framework | Stand up the three tiers, the RACI and the Working Groups — with the regulator and the operator kept apart — and keep the framework current instead of frozen at launch. | | **Legal drafter** | The Ministry of Justice or ministry legal officer who drafts the decree | [1.4](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.4-the-strategic-foundation-document.md), [2.1](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.1-why-the-platform-needs-a-legal-mandate.md), [2.2](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.2-anatomy-of-an-interoperability-decree.md), [2.3](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.3-the-explanatory-memorandum-and-preamble.md), [2.4](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.4-the-draft-articles-package.md), [2.5](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.5-the-cover-note-and-two-track-regulatory-memo.md), [2.6](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.6-the-decree-as-configuration.md), [4.8](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.8-make-the-exchange-lawful-the-data-protection-envelope.md) | the decree — the legal configuration of the framework, and the data-protection envelope of each exchange | Draft, check and move an interoperability decree that authorises exactly the exchanges in the catalogue. | | **Technical architect** | The chief or senior architect, integration lead, or agency technical lead building on the bus | [1.2](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.2-the-four-layers-of-interoperability.md), [4.1](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.1-place-every-component-the-four-functional-layers.md), [4.2](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.2-secure-every-call-the-three-trust-zones.md), [4.3](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.3-adopt-the-standards-portfolio.md), [4.4](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.4-generate-the-semantic-map.md), [4.5](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.5-generate-a-service-contract.md), [4.6](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.6-put-a-real-data-source-on-the-bus-the-giga-case.md), [4.7](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.7-wire-a-service-onto-the-bus.md), [5.5](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.5-stand-up-the-federation.md), [5.6](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.6-run-the-once-only-exchange-live.md), [5.7](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.7-from-demonstration-to-production.md), [5.8](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.8-watch-the-bus-monitoring-and-anomaly-detection.md) | the semantic map, the service contracts and the X-Road service descriptions — the technical configuration — and the running federation | Design the layers, adopt the standards, generate the semantic map and contracts, stand the federation up, prove it and watch it. | | **Member-onboarding lead** | The Operating Authority's onboarding officer, or an agency's focal point for joining | [1.6](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.6-mapping-your-stakeholders.md), [3.4](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.4-member-obligations.md), [5.2](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.2-state-what-a-member-must-have-the-member-requirements.md), [5.3](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.3-make-connected-mean-dependable-the-sla.md), [5.4](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.4-admit-a-member-to-the-bus.md) | the member registrations — Member Requirements, the SLA, and the subsystem + access-control list that admits an agency to the bus | Take an agency from 'wants to join' to 'admitted, registered and dependable'. | The value is reach. A knowledge product that asks every viewer to watch everything reaches few; one that says 'if you are the legal drafter, watch these videos and use these plays' reaches each role where they are. The role-paths are how this course gets used rather than just published — and how a country trains the actual, distributed team that builds its framework, each member learning their part. The role-paths map cleanly onto the build pack. The legal drafter's path ends at the decree configuration; the technical architect's at the semantic map and the service contracts; the onboarding lead's at the member registrations. Each role learns its part and produces its part of the runnable build pack. So dissemination is not just teaching — it is how the framework actually gets built, by a distributed team each contributing the artefact their role owns. The knowledge product and the build pack are two halves of the same thing: what to do, and what to produce. {% hint style="warning" %} **Coordinate across lanes.** Role-paths curate, they do not silo. Each path notes the cross-dependencies the role must coordinate on — the architect needs the legal drafter's decree; the onboarding lead needs the architect's contracts — so a team that learns in lanes still builds one coherent framework. {% endhint %} Both tracks share the [Start here](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea/start-here) chapter and the same demonstration country. This is a course for the people who commission, draft, govern and build a framework; the build pack is where a developer starts. ## All videos
Module 1 — Why interoperability and the four layers · ~31 minutes across 7 videos | # | Video | Runtime | Status | | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | ------- | ------------------------------------- | | [1.1](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.1-why-interoperability-cant-be-bought-only-built.md) | Why interoperability can't be bought, only built | \~5 min | [watch](https://youtu.be/IRWI9kPg7P8) | | [1.2](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.2-the-four-layers-of-interoperability.md) | The four layers of interoperability | \~5 min | [watch](https://youtu.be/NMLSiWteIdQ) | | [1.3](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.3-the-once-only-promise.md) | The once-only promise | \~4 min | [watch](https://youtu.be/Ow_1eXwKvr0) | | [1.4](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.4-the-strategic-foundation-document.md) | The Strategic Foundation Document | \~4 min | [watch](https://youtu.be/XyRrSGZIu6c) | | [1.5](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.5-the-use-case-catalogue.md) | The Use-Case Catalogue | \~5 min | [watch](https://youtu.be/ZngzlZgK-IA) | | [1.6](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.6-mapping-your-stakeholders.md) | Mapping your stakeholders | \~4 min | [watch](https://youtu.be/78TLKd_YAqU) | | [1.7](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.7-what-the-world-already-proved.md) | What the world already proved | \~4 min | [watch](https://youtu.be/htVz40z5Lgs) |
Module 2 — Legal framework — the Decree Drafting Kit · ~29 minutes across 6 videos | # | Video | Runtime | Status | | -------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | ------- | ------------------------------------- | | [2.1](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.1-why-the-platform-needs-a-legal-mandate.md) | Why the platform needs a legal mandate | \~4 min | [watch](https://youtu.be/GH_3B0nkkRs) | | [2.2](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.2-anatomy-of-an-interoperability-decree.md) | Anatomy of an interoperability decree | \~5 min | [watch](https://youtu.be/dPC09rQ9PO8) | | [2.3](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.3-the-explanatory-memorandum-and-preamble.md) | The Explanatory Memorandum and Preamble | \~5 min | [watch](https://youtu.be/_BKpa-tjvqo) | | [2.4](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.4-the-draft-articles-package.md) | The Draft Articles Package | \~5 min | [watch](https://youtu.be/umVPqUvKEuQ) | | [2.5](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.5-the-cover-note-and-two-track-regulatory-memo.md) | The Cover Note and Two-Track Regulatory Memo | \~5 min | [watch](https://youtu.be/SCGu-whKdVg) | | [2.6](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.6-the-decree-as-configuration.md) | The decree as configuration | \~5 min | [watch](https://youtu.be/C5DeXidWSI8) |
Module 3 — Governance model — three tiers with RACI · ~28 minutes across 6 videos | # | Video | Runtime | Status | | --------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------- | ------- | ------------------------------------- | | [3.1](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.1-why-a-bus-needs-an-owner.md) | Why a bus needs an owner | \~5 min | [watch](https://youtu.be/eYtxj7uiCDE) | | [3.2](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.2-the-three-tiers-of-governance.md) | The three tiers of governance | \~5 min | [watch](https://youtu.be/GfH3xhTbv5k) | | [3.3](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.3-the-raci-matrix.md) | The RACI matrix | \~5 min | [watch](https://youtu.be/VAvK-lqodjE) | | [3.4](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.4-member-obligations.md) | Member obligations | \~4 min | [watch](https://youtu.be/MA3EguW6R-8) | | [3.5](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.5-the-four-technical-working-groups.md) | The four Technical Working Groups | \~4 min | [watch](https://youtu.be/udt4dpv_hDk) | | [3.6](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.6-governance-as-living-configuration.md) | Governance as living configuration | \~5 min | [watch](https://youtu.be/-RwVBNenaGs) |
Module 4 — Architecture and technical standards · ~40 minutes across 8 videos | # | Video | Runtime | Status | | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ------- | ------------------------------------- | | [4.1](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.1-place-every-component-the-four-functional-layers.md) | Place every component — the four functional layers | \~5 min | [watch](https://youtu.be/MBwLWDEYn4I) | | [4.2](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.2-secure-every-call-the-three-trust-zones.md) | Secure every call — the three trust zones | \~5 min | [watch](https://youtu.be/fJs6W9tB1ZY) | | [4.3](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.3-adopt-the-standards-portfolio.md) | Adopt the standards portfolio | \~5 min | [watch](https://youtu.be/XAJ2NiX9lKI) | | [4.4](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.4-generate-the-semantic-map.md) | Generate the semantic map | \~5 min | [watch](https://youtu.be/sTFEXDY45NQ) | | [4.5](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.5-generate-a-service-contract.md) | Generate a service contract | \~5 min | [watch](https://youtu.be/sB3dhN7FdP8) | | [4.6](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.6-put-a-real-data-source-on-the-bus-the-giga-case.md) | Put a real data source on the bus — the Giga case | \~5 min | [watch](https://youtu.be/Vj1ra1hPzC0) | | [4.7](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.7-wire-a-service-onto-the-bus.md) | Wire a service onto the bus | \~5 min | [watch](https://youtu.be/BIxUJd--lxM) | | [4.8](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.8-make-the-exchange-lawful-the-data-protection-envelope.md) | Make the exchange lawful — the data-protection envelope | \~5 min | [watch](https://youtu.be/9vBLQxBAykw) |
Module 5 — Implementation and onboarding · ~44 minutes across 10 videos | # | Video | Runtime | Status | | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ------- | ------------------------------------- | | [5.1](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.1-plan-the-build-in-four-phases.md) | Plan the build in four phases | \~5 min | [watch](https://youtu.be/1e0Q2k71goo) | | [5.2](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.2-state-what-a-member-must-have-the-member-requirements.md) | State what a member must have — the Member Requirements | \~4 min | [watch](https://youtu.be/bQqV6sEGIEU) | | [5.3](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.3-make-connected-mean-dependable-the-sla.md) | Make 'connected' mean 'dependable' — the SLA | \~4 min | [watch](https://youtu.be/Apqzgaj2-5o) | | [5.4](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.4-admit-a-member-to-the-bus.md) | Admit a member to the bus | \~5 min | [watch](https://youtu.be/FiWcZi8l0vc) | | [5.5](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.5-stand-up-the-federation.md) | Stand up the federation | \~5 min | [watch](https://youtu.be/VvemGlPBa6E) | | [5.6](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.6-run-the-once-only-exchange-live.md) | Run the once-only exchange, live | \~3 min | [watch](https://youtu.be/_6F_eXrJNSY) | | [5.7](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.7-from-demonstration-to-production.md) | From demonstration to production | \~5 min | [watch](https://youtu.be/EOfPIVAUYdU) | | [5.8](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.8-watch-the-bus-monitoring-and-anomaly-detection.md) | Watch the bus — monitoring and anomaly detection | \~4 min | [watch](https://youtu.be/DKQHuEa8cxs) | | [5.9](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.9-keep-the-documents-honest-the-consistency-cross-check.md) | Keep the documents honest — the consistency cross-check | \~5 min | [watch](https://youtu.be/rn6kfOj6rVo) | | [5.10](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.10-carry-the-framework-to-the-next-sector.md) | Carry the framework to the next sector | \~4 min | [watch](https://youtu.be/b2lSmCLgYHo) |
## The AI-play catalogue Across this course you meet thirty-seven AI plays — named tools, each turning a slow specialist task into a fast, reviewed draft. They are worth reading as one catalogue, because they are not one-off tricks. They are a reusable toolkit your framework keeps and applies to every decree, every exchange, every service it builds. Three of them stand out: the decree drafter turns your Strategic Foundation Document into the components of a decree (2.3, 2.4); the semantic mapper turns two agencies' field lists into a shared semantic map (4.4); and the service-contract generator turns a service brief and that semantic map into a callable contract (4.5). Three slow specialist tasks — legal drafting, semantic reconciliation, interface design — each compressed from weeks into a reviewed afternoon. Notice they share one pattern, and it is the pattern worth remembering. Each play generates from a published specification and a brief. Each output is confirmed against the source — the statute, the registry, the provider — before it is used. And a qualified human owns the result: the lawyer for the decree, the data owner for the semantic map, the architect for the contract. Generate fast, confirm carefully, a human always owns the result. That discipline is what makes AI a tool the framework can trust rather than a risk it runs. {% hint style="danger" %} **One pattern, every play.** Generate from a published spec and a brief · confirm every output against the source — the statute, the registry, the provider · a qualified human owns the result. The catalogue's value is in the confirm step — every entry below names what the output is checked against and who owns it, so no one treats a generated draft as final. A catalogue that lists the plays but drops the confirm-and-own discipline teaches the dangerous half of the lesson. {% endhint %} The value to you as the Strategist is leverage. A small team, with these plays, can draft a framework that would otherwise need scarce, expensive specialists for months. The plays do not replace the specialists — they let a few of them go much further. And because the plays are a catalogue, they are reused: the same decree drafter serves the next sector's decree, the same semantic mapper serves the next exchange. You build the toolkit once and apply it everywhere the framework grows.
The foundation (Module 1) · 7 plays | # | Play | Produces | Confirm against | | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [1.1](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.1-why-interoperability-cant-be-bought-only-built.md) | 🔍 Diagnose where your country procures interoperability instead of planning it | B1 Procured-vs-planned diagnostic | Treat the output as a hypothesis to test with the agencies named, not a finding. | | [1.2](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.2-the-four-layers-of-interoperability.md) | 🔍 Map a planned exchange across the four layers — and find the missing one | B2 Four-layer exchange map | The output reflects only what you described — a 'Ready' on the legal layer means you told it a mandate exists, not that counsel has confirmed it. | | [1.3](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.3-the-once-only-promise.md) | 🔍 Find your country's highest-value once-only exchange | B3 Highest-value once-only exchange | The interaction estimates are directional, for prioritisation only — confirm the authoritative source agency actually holds the fact reliably (a registry that is incomplete is not yet a trusted source) before committing it as the first build. | | [1.4](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.4-the-strategic-foundation-document.md) | ✍️ Draft your Strategic Foundation Document | B4 Strategic Foundation Document | This is a starting draft to negotiate, not a final charter — the scope and mandate sections in particular must be agreed with the named agencies and cleared by legal counsel before signature, because they create real obligations. | | [1.5](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.5-the-use-case-catalogue.md) | ✍️ Build your Use-Case Catalogue from your integration map | B5 Use-Case Catalogue | Readiness flags are first guesses from your description — the Legal and Semantic flags especially must be confirmed with the data owner and counsel. | | [1.6](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.6-mapping-your-stakeholders.md) | 🔍 Map your stakeholders into tiers and provider/consumer roles | B6 Stakeholder tier map | Attitudes change with leadership and incentives — treat the tiering as a snapshot to test through real conversations, not a fixed label. | | [1.7](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers/1.7-what-the-world-already-proved.md) | 🔍 Find the published standards your sector should reuse | B7 Standards-to-reuse shortlist | Standards adoption is also a political and licensing decision — confirm each candidate is genuinely open and acceptable to your data owners and regulators before committing, and check the version, since standards evolve and a superseded version can mislead. |
Legal configuration — the decree (Module 2) · 6 plays | # | Play | Produces | Confirm against | | -------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [2.1](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.1-why-the-platform-needs-a-legal-mandate.md) | 🔍 Assess your legal readiness for cross-agency exchange | B8 Legal-readiness assessment | This is a scoping aid for the legal drafting, not a legal opinion. | | [2.2](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.2-anatomy-of-an-interoperability-decree.md) | ✍️ Outline your decree's five components from your foundation | B9 Decree outline (five components) | The outline is a drafting plan, not legal content — every authority and article it names must be confirmed against the country's actual law by a qualified lawyer. | | [2.3](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.3-the-explanatory-memorandum-and-preamble.md) | ✍️ Generate the Explanatory Memorandum and Preamble | B10 Explanatory Memorandum and Preamble | Never let a \[confirm] placeholder reach the Ministry of Justice as if it were a real citation. | | [2.4](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.4-the-draft-articles-package.md) | ✍️ Draft one operative article against a published model | B11 Operative article draft | If you cannot supply a published model for an article, do not let the AI generate it from scratch — invented legal text reads convincingly and can be harmful. | | [2.5](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.5-the-cover-note-and-two-track-regulatory-memo.md) | ✍️ Draft the Cover Note and the Two-Track Regulatory Memo | B12 Cover Note and two-track memo | The memo's value depends on the actual text of the data-protection law — every point of intersection must be checked against the real articles by counsel and, ideally, walked through with the data-protection authority before filing; a memo that coordinates with a law as the model imagines it is worse than none. | | [2.6](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit/2.6-the-decree-as-configuration.md) | 🔍 Check your decree authorises exactly your catalogue (the legal acceptance check) | B13 Legal acceptance check | This check tests alignment between two of your own documents — it is not a ruling on whether an article is lawful or well-drafted. |
Organisational configuration — the Governance Pack (Module 3) · 6 plays | # | Play | Produces | Confirm against | | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [3.1](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.1-why-a-bus-needs-an-owner.md) | ✍️ Define the owner's mandate — and split the regulator from the operator | B14 Owner's mandate, regulator and operator split | Hosting the Operating Authority in an existing agency often requires a legal change to its mandate — treat every power the body does not already hold as a gap for legal counsel to close, not an assumption, and confirm the budget is a standing line, not a one-off project grant that disappears in year two. | | [3.2](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.2-the-three-tiers-of-governance.md) | ✍️ Draft the three-tier governance structure for your country | B15 Three-tier governance structure | Membership and decision scope must be agreed with the named bodies, not imposed on paper — a tier whose 'members' have not consented to the scope is a diagram, not governance. | | [3.3](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.3-the-raci-matrix.md) | ✍️ Draft the governance RACI for your framework's key decisions | B16 Governance RACI | A RACI only works if each Accountable body actually has the authority its row claims — verify that against the governance mandates and, where the decision compels an agency (suspension, mandatory connection), against the decree. | | [3.4](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.4-member-obligations.md) | ✍️ Draft the member obligations and membership agreement | B17 Member obligations and agreement | Enforcement powers — suspending or sanctioning a member — usually derive from the decree, not the agreement alone; mark any such power as \[confirm] against the legal layer. | | [3.5](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.5-the-four-technical-working-groups.md) | ✍️ Charter the four Technical Working Groups | B18 Four Working Group charters | A Working Group with no members who have the authority to commit their agencies produces recommendations no one implements — confirm that each group's membership includes people who can actually bind the data owners and systems they cover, especially for Semantics, where the meaning agreed must hold across agencies. | | [3.6](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci/3.6-governance-as-living-configuration.md) | ✍️ Set up your change-control process and standards-portfolio register | B19 Change control, standards register (with conformance fields) and semantic-registry charter | A change-control process only lives if it is light enough to use — resist adding approval steps that look rigorous but guarantee the process is bypassed. |
Technical configuration (Module 4) · 8 plays | # | Play | Produces | Confirm against | | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [4.1](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.1-place-every-component-the-four-functional-layers.md) | 🔍 Map your platform components to the four functional layers | B20 Component-to-layer map | The gap list is a prompt for discussion, not a procurement list — a 'missing' component may already be provided by the X-Road software you are adopting. | | [4.2](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.2-secure-every-call-the-three-trust-zones.md) | ✍️ Trace an exchange across the trust zones and name its security | B21 Trust-zone trace | This specifies the transport and identity security of the exchange; it does not cover whether the data should be shared at all — that is the legal and data-protection question (the decree and the data-protection envelope). | | [4.3](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.3-adopt-the-standards-portfolio.md) | 🔍 Assemble your standards portfolio from the published menu | B22 Standards portfolio | Confirm every version against the standard's own publication before locking the portfolio — an AI's recollection of a version number can be stale, and the portfolio is the one document every member must match exactly. | | [4.4](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.4-generate-the-semantic-map.md) | ✍️ Generate a semantic map for an exchange | B23 Semantic map | Identifier and code-list errors in a semantic map are the most dangerous defects in the whole framework — a wrong identifier silently merges two citizens' records. | | [4.5](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.5-generate-a-service-contract.md) | ✍️ Generate an OpenAPI service contract | B24 OpenAPI service contract | An OpenAPI contract that names fields the provider does not actually expose fails at the first real call — confirm every path and field against the provider system's real interface (not its documentation alone, which drifts) before publishing the contract or deriving the X-Road service description. | | [4.6](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.6-put-a-real-data-source-on-the-bus-the-giga-case.md) | ✍️ Map a real sector data source through bronze/silver/gold onto the bus | B25 Bronze/silver/gold source map | The de-duplication identifier in the silver stage is the highest-risk decision — a non-unique key merges records for different people. | | [4.7](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.7-wire-a-service-onto-the-bus.md) | ✍️ Generate the X-Road service description and wiring checklist | B26 X-Road service description and wiring checklist | Every member and subsystem identifier must be confirmed against the live X-Road registry before deployment — a wrong identifier does not error clearly, it silently routes nowhere or to the wrong place. | | [4.8](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards/4.8-make-the-exchange-lawful-the-data-protection-envelope.md) | ✍️ Draft the data-protection envelope for an exchange | B27 Data-protection envelope | If the lawful-basis check flags NOT AUTHORISED, the exchange must not go live regardless of how well it is built — route it back to the legal layer to amend the decree or the Use-Case Catalogue. |
The runnable slice, then operations (Module 5) · 10 plays | # | Play | Produces | Confirm against | | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [5.1](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.1-plan-the-build-in-four-phases.md) | ✍️ Draft your implementation plan — the phased schedule and the four plans beside it | B28 Implementation plan: phased schedule, investment, procurement, workforce, risk register and metrics | Cost and duration figures are the most scrutinised and the easiest to get wrong — treat every number as \[confirm] and benchmark it against documented comparable builds before putting it in front of a funder. | | [5.2](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.2-state-what-a-member-must-have-the-member-requirements.md) | ✍️ Draft the Member Requirements checklist | B29 Member Requirements checklist | A self-assessed 'met' is a claim, not proof — require the evidence column to be filled and spot-check the highest-risk items (clean data, lawful basis) before scheduling go-live. | | [5.3](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.3-make-connected-mean-dependable-the-sla.md) | ✍️ Draft the Service-Level Agreement template | B30 Service-Level Agreement template | An SLA target set without the provider's agreement will be ignored — every number must be confirmed as achievable with the provider agency before signing. | | [5.4](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.4-admit-a-member-to-the-bus.md) | ✍️ Generate the X-Road member registration (subsystem + ACL) | B31 X-Road member registration | Every X-Road identifier must be confirmed against the live registry before deployment — this is the single highest-stakes \[confirm] in the framework, because a wrong code can route one citizen's data to a service that asked about another. | | [5.5](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.5-stand-up-the-federation.md) | ✍️ Draft the federation stand-up run book | B32 Federation stand-up run book | A run book is only reproducible if it has been run — execute it end to end in the sandbox and confirm all four members register, before treating it as the build-pack run book. | | [5.6](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.6-run-the-once-only-exchange-live.md) | ✍️ Script and verify the once-only exchange (the acceptance check) | B33 Once-only acceptance script | An acceptance check that only proves the happy path is half a check — include the negative case (an unauthorised member is denied) and confirm the data returned is the right learner's, not merely that data returned. | | [5.7](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.7-from-demonstration-to-production.md) | 🔍 Build the demonstration-to-production gap checklist | B34 Demonstration-to-production gap checklist | The gap checklist is a planning aid, not a security sign-off — production hardening and audit must be done and independently reviewed, not merely listed. | | [5.8](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.8-watch-the-bus-monitoring-and-anomaly-detection.md) | 🔍 Summarise bus health and flag anomalies from the monitoring data | B35 Bus-health summary and anomaly list | Take the input from operational monitoring, never the message log, which stores the messages themselves; and check request paths, since a lookup by ID number can carry the number in the URL. | | [5.9](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.9-keep-the-documents-honest-the-consistency-cross-check.md) | 🔍 Cross-check the decree, Governance Pack and standards portfolio for drift | B36 Document-consistency report | The cross-check finds drift; it must not resolve it — deciding whether the decree or the catalogue is correct is a legal and governance judgement a human owns. | | [5.10](/experience-digital-transformation/gif/module-5-implementation-and-onboarding/5.10-carry-the-framework-to-the-next-sector.md) | ✍️ Map your framework's sector-portable vs sector-specific parts for a new sector | B37 Sector-portability map | The 'reused unchanged' list is only true if the platform was built sector-neutrally — confirm that none of your education-sector specifics leaked into the bus, governance or standards before promising they carry over. |
## From no framework to first service — the storyboard > **Single message.** The storyboard of a country going from nothing to its first live once-only exchange, mapped to the five modules — on an honest calendar, with a first visible service long before national coverage. End where a Strategist needs to end — with the whole journey in one picture. A country that starts with no interoperability framework, and the path it walks to its first live once-only service. This is the storyboard, and it is the through-line of everything this knowledge product teaches: the foundation, the decree, the governance, the architecture, the build, and a citizen finally asked once. | Where | What happens | The country, step by step | | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Module 1](/experience-digital-transformation/gif/module-1-why-interoperability-and-the-four-layers.md) | name the mandate, catalogue the exchanges, map the stakeholders | The country starts with fragmentation — the citizen at five counters. The Strategist writes the Strategic Foundation Document, ranks the exchanges in a Use-Case Catalogue, and maps the stakeholders. | | [Module 2](/experience-digital-transformation/gif/module-2-legal-framework-the-decree-drafting-kit.md) | draft and enact the decree | The decree is drafted and enacted — the legal on-switch. | | [Module 3](/experience-digital-transformation/gif/module-3-governance-model-three-tiers-with-raci.md) | stand up the three-tier governance and the Operating Authority | The three-tier governance and the Operating Authority are stood up. | | [Module 4](/experience-digital-transformation/gif/module-4-architecture-and-technical-standards.md) | design the layers, adopt the standards, generate the semantic map and contracts | The architects design the four layers, adopt the standards, and generate the semantic map and the service contracts. | | [Module 5](/experience-digital-transformation/gif/module-5-implementation-and-onboarding.md) | stand up the federation, onboard members, run the once-only call — then operate it | The federation is stood up, the first members are onboarded and conformance-tested, and the once-only exchange runs — a learner applies for a credential and is asked once. A first pilot service, live, with both go-live approvals recorded. Then the bus is watched from its logs, the framework's documents are kept honest, and the next sector is planned. | The time frame is the part that matters to a minister, so tell it honestly. The foundation — the decree, the governance, the architecture and the standards — is a year to eighteen months of work, longer in calendar time because legislative and budget cycles do not hurry. Then the four build phases: the platform and its first pilot members in the first six months, the first cross-ministry once-only exchanges in the second, the first-wave sectors by month eighteen. The first real milestone — a running platform with a handful of member services — lands two to three years from the day the programme starts; national coverage is a four-to-six-year programme. Not years of silent build and then a big-bang launch, but not six months either: a visible, gated win each phase, on a calendar the minister heard on day one. That is what makes the framework fundable and survivable — a plan that is still believable when the launch enthusiasm fades and the minister changes. Step back to see why it worked, because that is the deeper lesson. At every step, the framework gave the policy side and the technical side a shared language and a shared rhythm to decide together — the decree, where business and IT agreed the lawful exchanges; the semantic map, where they agreed what the data means; the governance table, where they sat together. A framework is, in the end, the shared language that lets business and IT build the new thing together. Without it, the conversation the build requires never happens, and the project stalls. That is why this storyboard ends in a working service rather than a stalled programme. {% hint style="success" %} **In one sentence.** From no framework to a first live once-only service, phase by gated phase on an honest calendar, by following the five modules — interoperability is built, not bought, and then enforced through every tender. {% endhint %} An interoperability framework is built, not bought — and once it exists, procurement is how it is enforced. It is built in deliberate, gated phases, on an honest calendar. And it ends in a real once-only exchange that a citizen actually feels — asked once, not five times. A country with no framework can walk this exact path: name the foundation, pass the decree, govern it, architect it, stand it up, and ask the citizen once. ### Your turn — Draft your country's no-framework-to-first-service storyboard {% hint style="info" %} **A play with no video.** This was the closing video of the v0.1 bundles (6.6); the storyboard above is what it said, and the prompt is the one thing from it a Strategist still needs — a storyboard of their own country for a minister or a funder. {% endhint %} {% hint style="success" %} **✍️ Drafting play · produces B38 Country storyboard** **Bring:** the first exchange, agencies and constraints. From **B5, B28** (see [Your framework workbook](/experience-digital-transformation/gif/your-framework-workbook.md)). **Get:** a one-page no-framework-to-first-service storyboard mapped to the modules and phases. As text in the chat, not a file or a chart. **Time:** \~15 min · **Assistant:** any; the plays are tool-neutral. **With the kit:** no skill in this release, so the prompt runs bare in any assistant. **Watch for:** A storyboard is a plan to inspire and align, not a guarantee — keep the timeline honest (the foundation before the build, the first cross-ministry exchange in the second build phase, national coverage over years) and avoid promising a big-bang. {% endhint %} ✍️ **Drafting play.** You give a few facts; the play produces a first draft of a document you will edit. **What it does.** A Strategist needs a one-page storyboard taking their country from no interoperability framework to its first live once-only service, mapped to the five modules and the phased plan — a narrative for a minister or a funder. This prompt drafts it. {% tabs %} {% tab title="Prompt" %} Copy the prompt, replace the bracketed parts with your own context, and run it in the AI assistant of your choice. Never paste personal data or unpublished documents — see [How to use the plays](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea/start-here/how-to-use-the-plays). ``` Draft a one-page storyboard for [country X] going from no Government Interoperability Framework to its first live once-only service. Use this context [paste: the first exchange you want to enable, the agencies involved, any constraints]. Structure it as the journey across the five modules: (1) the starting fragmentation (the citizen's repeated burden today); (2) foundation — mandate, use-case catalogue, stakeholders; (3) the decree; (4) governance; (5) architecture, standards, semantic map, contracts; (6) stand-up, onboarding, the live once-only exchange — ending with the citizen asked once. Map it to the phased plan on an honest calendar: the foundation first (a year to eighteen months), then the first pilot members in the build's first six months, the first cross-ministry once-only exchange in the second, first-wave coverage by month eighteen, national coverage over four to six years. Close with one line on why it works: the framework gives business and IT a shared language to build together. Tone: for a minister or funder. Output: the one-page storyboard. ``` [Open in Claude](https://claude.ai/new?q=Draft%20a%20one-page%20storyboard%20for%20%5Bcountry%20X%5D%20going%20from%20no%20Government%20Interoperability%20Framework%20to%20its%20first%20live%20once-only%20service.%20Use%20this%20context%20%5Bpaste%3A%20the%20first%20exchange%20you%20want%20to%20enable%2C%20the%20agencies%20involved%2C%20any%20constraints%5D.%20Structure%20it%20as%20the%20journey%20across%20the%20five%20modules%3A%20%281%29%20the%20starting%20fragmentation%20%28the%20citizen%27s%20repeated%20burden%20today%29%3B%20%282%29%20foundation%20%E2%80%94%20mandate%2C%20use-case%20catalogue%2C%20stakeholders%3B%20%283%29%20the%20decree%3B%20%284%29%20governance%3B%20%285%29%20architecture%2C%20standards%2C%20semantic%20map%2C%20contracts%3B%20%286%29%20stand-up%2C%20onboarding%2C%20the%20live%20once-only%20exchange%20%E2%80%94%20ending%20with%20the%20citizen%20asked%20once.%20Map%20it%20to%20the%20phased%20plan%20on%20an%20honest%20calendar%3A%20the%20foundation%20first%20%28a%20year%20to%20eighteen%20months%29%2C%20then%20the%20first%20pilot%20members%20in%20the%20build%27s%20first%20six%20months%2C%20the%20first%20cross-ministry%20once-only%20exchange%20in%20the%20second%2C%20first-wave%20coverage%20by%20month%20eighteen%2C%20national%20coverage%20over%20four%20to%20six%20years.%20Close%20with%20one%20line%20on%20why%20it%20works%3A%20the%20framework%20gives%20business%20and%20IT%20a%20shared%20language%20to%20build%20together.%20Tone%3A%20for%20a%20minister%20or%20funder.%20Output%3A%20the%20one-page%20storyboard.) *(experimental deep link: pre-fills the prompt in a new claude.ai chat; check the bracketed parts before sending)* {% endtab %} {% tab title="What next" %} File the output as **B38** in [your framework workbook](/experience-digital-transformation/gif/your-framework-workbook.md). It is the narrative that wraps the Use-Case Catalogue (B5) and the four-phase plan (B28) for the people who fund them; it feeds nothing further — it is where the chain ends, in a minister's hands. {% hint style="danger" %} **Safeguard for this play.** A storyboard is a plan to inspire and align, not a guarantee — keep the timeline honest (the foundation before the build, the first cross-ministry exchange in the second build phase, national coverage over years) and avoid promising a big-bang. The credibility of the whole narrative rests on the first once-only service being genuinely achievable on the calendar stated; do not let the storyboard over-promise what the first phase delivers. {% endhint %} {% endtab %} {% endtabs %} ## Prerequisites [**Developing a Gov Enterprise Architecture (GEA)**](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea) **is the natural starting point but not a prerequisite.** Three of its artefacts hand off into this course — the Governance Board terms of reference (A7) into the Operating Authority (3.1), the sourcing matrix (A24) into the standards portfolio (4.3), and the country context pack (A0) into Module 1. If you have none of them, Module 1 and the [Play 0 supplement](/experience-digital-transformation/gif/play-0-supplement.md) build what this course needs on their own. **What you do need:** | | | | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **A real subject** | A sector, an exchange, or a pair of agencies you can describe in a few paragraphs. The plays act on your context, not on a case study. No subject to hand? Run everything on [Progressa](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea/start-here/progressa-the-demonstration-country) instead. | | **Enough access to describe it** | You should be able to name your country's main registers, the bodies that hold them, the exchanges that exist today and the law they sit under — or spend an afternoon on [Play 0](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea/start-here/play-0-build-your-country-context) and its [supplement](/experience-digital-transformation/gif/play-0-supplement.md) building that picture from public sources. | | **An AI assistant** | Any general assistant — Claude, ChatGPT, Gemini. A free account is enough. Nothing to install; the [ea-plays kit](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea/start-here/the-ea-plays-kit) is optional and only sharpens some of the plays for Claude users. One of its skills, `gif-decree-draft`, is this course's own; the **With the kit** line of each play names the skill that helps, if one does; source at [github.com/alaponin/ea-plays-kit](https://github.com/alaponin/ea-plays-kit). | | **A machine, for the build pack only** | Modules 1–3 write no code. The build pack needs Docker and about 11 GiB of RAM; the [Run it](/experience-digital-transformation/gif/the-build-pack/run-it-the-run-book.md) page says exactly what. You can complete every play without running it. | | **About fifteen minutes, once** | The first three pages of [Start here](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea/start-here) cover how the plays work and the ground rules for using an assistant on government material. Read them before your first play. | Time: each subtopic is a four-to-five-minute video plus a ten-to-twenty-five-minute play. A module is an afternoon; Modules 4 and 5 are two. The whole Knowledge Product is roughly three working days spread over as long as you like.

🛡️

Working with AIWhat an assistant is good for, the four ways it misleads you, and the safeguards. Read once; applies to all four Knowledge Products.https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea/start-here/working-with-ai-the-ground-rules

🏁

Module 1 — Why, the four layers, the foundationSeven videos and seven plays for the Strategist making the case and laying the foundation.Module 1 — Why interoperability and the four layers

🧰

The build packThe ready solution: the Linkup federation, the member registrations and the once-only exchange, run from a run book and proven by an acceptance check.The build pack

📒

Your framework workbookThe artefacts the plays produce, grouped by configuration layer — the retention mechanism of the course.Your framework workbook
## Where this sits This course is the second of four Knowledge Products. The first is [Developing a Gov Enterprise Architecture (GEA)](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea), and the third is [Education Digital Public Infrastructure (DPI) Roadmap](https://experience-digital-transform.gitbook.io/experience-digital-transformation/roadmap/education-digital-public-infrastructure-dpi-roadmap); a fourth, on building-block services, is planned. All four use [**Progressa**](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea/start-here/progressa-the-demonstration-country) as the single worked example and share one set of [ground rules](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea/start-here/working-with-ai-the-ground-rules). **What this course is the companion to.** Behind the videos sits a five-piece interoperability toolkit, each piece at a different altitude: a **Reference Model** (what a framework is — the four interoperability layers and the four functional layers), an eight-step **Method** (how to develop one; Modules 1–5 follow its steps), a **Toolkit** of fourteen templates (the artefacts the plays draft — the Strategic Foundation Document, the Use-Case Catalogue, the Decree Drafting Kit, the Governance Model, the standards catalogue, Member Requirements, the SLA, the onboarding workflow, the conformance test plan, the risk register, the success metrics), a **Reference Architecture** (the enforceable target design and its rules, on five layers — the four plus infrastructure — with governance and legal cross-cutting), and an **RA-to-RFP path** that turns the reference architecture plus a country's own enterprise architecture into an issuable tender. The videos teach the first three and point at the last two: a framework is planned first, and then procurement is how it is enforced. The four-layer interoperability model — Technical, Semantic, Organisational, Legal — is the EU European Interoperability Framework's and the NIIS X-Road documentation's; PAERA v1.0 ([paera.govstack.global](https://paera.govstack.global)) anchors the interoperability framing (§3.4.3), the Once-Only principle (§5.2), the legal layer (§3.2) and the governance setup (§3.1.3). {% hint style="info" %} **Use this knowledge base from your AI assistant.** Every page is also published as plain Markdown, and the knowledge base exposes an `llms.txt` and an MCP endpoint at `/~gitbook/mcp`. Point Claude, ChatGPT or another assistant at the knowledge base and ask it to *run play 2.3 with the following context* — the knowledge base becomes the tool's reference, not just yours. {% 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/gif/building-a-government-interoperability-framework-gif.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.