> 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/building-block/designing-digital-government-services-using-a-building-block-approach.md). # Designing Digital Government Services using a Building Block Approach This guide teaches a government team to design a digital public service on shared building blocks and have it built on a low-code platform. 37 videos in six modules · about 185 minutes of video · an AI usage tip on every page · 38 worked examples · ten blank instruments and a deliverables annex · self-paced · free and open This guide teaches a government team to design a digital public service on shared building blocks and have it built on a low-code platform. It uses specification-driven development, SDD for short: a method in which every document a person writes is accepted before the next is begun, and the last is turned into the running service by a program, never by hand. The shared building blocks are the digital systems that many services of a country stand on: digital identity, registries, payments and the exchange of data between public bodies. The guide has six modules and 37 subtopics. Each subtopic is one short video with a written page and an AI usage tip. Module 1 explains why digital services go wrong and what the method puts in the way. Modules 2 to 5 break a service down, design one goal of it, settle the whole application and generate it on the platform. Module 6 runs the method in an administration. Every example is set in Progressa, a fictional country: its quality authority for higher education and its ministry of education commission two applications so that a private institution gives its particulars to the state once. ![F1. The structure of this course: its modules and the two ways through them](https://3194217719-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FrVBocIKfigDPd5E7eF77%2Fuploads%2FMpBrL5IHxrF2JjssG4n9%2FF1_structure-b86e2ea0.png?alt=media) ## Outline | Module | Topic | Persona | Videos | AI tips | Status | | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ---------- | ------ | ------- | ------------ | | [1](/experience-digital-transformation/building-block/module-1-why-digital-services-go-wrong-and-the-method-that-prevents-it.md) | Why digital services go wrong, and the method that prevents it | Strategist | 5 | 5 tips | Prompts live | | [2](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it.md) | Break the service down before you design it | Strategist | 6 | 6 tips | Prompts live | | [3](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check.md) | Design one service as a story your officials can check | Architect | 6 | 6 tips | Prompts live | | [4](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine.md) | Settle the whole application once, then describe it for the machine | Architect | 6 | 6 tips | Prompts live | | [5](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks.md) | Generate the service on a low-code platform and connect the blocks | Architect | 7 | 7 tips | Prompts live | | [6](/experience-digital-transformation/building-block/module-6-run-the-method-in-your-administration.md) | Run the method in your administration | Strategist | 7 | 7 tips | Prompts live | *Prompts live — every page of the module is written, with its prompt. In production — the module's pages are added as its scripts are written.* {% hint style="success" %} **How the course works.** **Watch** the video → **Read** its page, the video written out in full → **Prompt** with its AI usage tip on your own service → **Compare** your draft with the worked example for Progressa. The [worked examples](/experience-digital-transformation/building-block/the-worked-examples.md) follow the [twelve documents](/experience-digital-transformation/building-block/the-twelve-documents.md) of the method in order and link to one another, from the catalogue of the sector's services to the running application, so that any screen can be followed back to the request behind it. Each document a person writes has a [blank instrument](/experience-digital-transformation/building-block/the-blank-instruments.md) to copy and fill in. {% endhint %} | Module | What you can do afterwards | What of the worked example it uses | | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | 1 | Explain to the minister why an agreed service gets lost on the way and what the twelve documents of the method put in its way | The story of an institution that registered at the quality authority and filled in the same particulars again at the ministry | | 2 | Commission the documents that are written before any design: the catalogue, the register, the records, the goals, the shared registers, the architecture | Filled extracts of the documents written before design, one for each subtopic | | 3 | Have one goal written as a story with its screens, and run the review at which officials agree it | One goal written in full, the application for a provisional licence, with its screens and walk-through | | 4 | Accept the interaction design, including the service workflow, and have the application model reviewed | The interaction design and the application model of the two applications | | 5 | Read what is generated, why nothing is edited by hand, and how the service uses identity, registries, payments and information mediation | The two applications as they will be generated on the low-code platform, with the ministry reading the register across the data interface | | 6 | Require the documents from a supplier, handle change, read progress from the work, use the AI assistant safely, and carry the method to the next service and another sector | A change of an institution's name, the trace report, and the digital credential as the next service | ## Audience — and the path for your role | Persona | Who that is in practice | Modules | What you leave with | | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Strategist** | The public-sector middle manager in education who commissions the service, judges the supplier's offer, convenes the review and answers to the minister and the donor | [1](/experience-digital-transformation/building-block/module-1-why-digital-services-go-wrong-and-the-method-that-prevents-it.md), [2](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it.md), [6](/experience-digital-transformation/building-block/module-6-run-the-method-in-your-administration.md) | The method and the documents to ask for: the three places a service gets lost and the three rules to hold a supplier to, the twelve documents and who accepts each, the documents written before any design, and the way to run the method as the administration's own way of commissioning services. | | **Architect** | The head of a sectoral ICT unit, or the project lead, who has a service specified and built by a supplier, convenes its reviews and accepts its documents | [3](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check.md), [4](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine.md), [5](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks.md) | The service specified and built: one goal written as a story with its screens and agreed at the review, the whole application settled and described for the machine, and the service generated on the low-code platform, connected to the shared blocks and proved on the running system. | Neither persona writes the documents of the method: staff, a supplier or an AI assistant does. The guide teaches what each document is for, what to see in it before accepting it, and where the manager's own decision lies. Modules 3, 4 and 5 go one level deeper than the others and still assume no knowledge of data models, version control, configuration files or the command line. ### Two ways through | Way | Modules | What it gives | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **The method alone** | [1](/experience-digital-transformation/building-block/module-1-why-digital-services-go-wrong-and-the-method-that-prevents-it.md), [2](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it.md), [6](/experience-digital-transformation/building-block/module-6-run-the-method-in-your-administration.md) | A team that wants the method alone follows modules 1, 2 and 6: why services go wrong, the documents that are written before any design, and how to run the method in an administration. | | **The service specified and built** | [3](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check.md), [4](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine.md), [5](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks.md) | A team that has a service specified and built follows modules 3, 4 and 5: one goal designed as a story, the whole application settled and described for the machine, and the service generated and connected to the shared blocks. | The order of the modules follows the order in which an administration meets the method. It first learns why services go wrong, then breaks a service down, designs one goal of it, settles the whole application, has it generated and connected, and finally runs the method as its own way of commissioning services. ## All videos Core marks the content without which the method cannot be followed from the request to the running service. Supplementary marks a video that deepens a core one and can be left out without losing the thread.
Module 1 — Why digital services go wrong, and the method that prevents it | # | Video | Class | Demonstration | Page | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------- | ----- | ------------- | --------- | | [1.1](/experience-digital-transformation/building-block/module-1-why-digital-services-go-wrong-and-the-method-that-prevents-it/1.1-where-an-agreed-service-gets-lost.md) | Where an agreed service gets lost | Core | — | Page live | | [1.2](/experience-digital-transformation/building-block/module-1-why-digital-services-go-wrong-and-the-method-that-prevents-it/1.2-three-rules-you-can-hold-a-supplier-to.md) | Three rules you can hold a supplier to | Core | — | Page live | | [1.3](/experience-digital-transformation/building-block/module-1-why-digital-services-go-wrong-and-the-method-that-prevents-it/1.3-a-question-with-a-name-on-it-is-part-of-the-specification.md) | A question with a name on it is part of the specification | Core | — | Page live | | [1.4](/experience-digital-transformation/building-block/module-1-why-digital-services-go-wrong-and-the-method-that-prevents-it/1.4-twelve-documents-from-the-request-to-the-running-service.md) | Twelve documents from the request to the running service | Core | — | Page live | | [1.5](/experience-digital-transformation/building-block/module-1-why-digital-services-go-wrong-and-the-method-that-prevents-it/1.5-who-writes-who-checks-who-accepts.md) | Who writes, who checks, who accepts | Core | — | Page live |
Module 2 — Break the service down before you design it | # | Video | Class | Demonstration | Page | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | ----- | ------------- | --------- | | [2.1](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.1-one-catalogue-of-the-sectors-services-and-the-blocks-they-share.md) | One catalogue of the sector's services, and the blocks they share | Core | — | Page live | | [2.2](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.2-write-down-what-was-asked-before-anyone-designs.md) | Write down what was asked before anyone designs | Core | — | Page live | | [2.3](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.3-the-records-the-service-keeps-and-whose-each-one-is.md) | The records the service keeps, and whose each one is | Core | — | Page live | | [2.4](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.4-every-goal-named-and-each-tied-to-what-was-asked.md) | Every goal named, and each tied to what was asked | Core | — | Page live | | [2.5](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.5-what-every-goal-may-use-and-may-not-invent.md) | What every goal may use, and may not invent | Core | — | Page live | | [2.6](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.6-what-the-service-is-built-on-and-what-crosses-its-boundary.md) | What the service is built on, and what crosses its boundary | Core | — | Page live |
Module 3 — Design one service as a story your officials can check | # | Video | Class | Demonstration | Page | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | ------------- | ------------- | --------- | | [3.1](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.1-one-goal-written-as-a-story-a-builder-can-follow.md) | One goal, written as a story a builder can follow | Core | — | Page live | | [3.2](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.2-every-way-it-can-go-wrong-written-down.md) | Every way it can go wrong, written down | Core | — | Page live | | [3.3](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.3-screens-worked-out-from-the-story-every-value-with-its-source.md) | Screens worked out from the story, every value with its source | Core | — | Page live | | [3.4](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.4-screens-officers-can-use.md) | Screens officers can use | Supplementary | — | Page live | | [3.5](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.5-the-walk-through-your-officials-click.md) | The walk-through your officials click | Core | Yes | Page live | | [3.6](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.6-the-review-three-people-every-open-line-given-a-name.md) | The review: three people, every open line given a name | Core | — | Page live |
Module 4 — Settle the whole application once, then describe it for the machine | # | Video | Class | Demonstration | Page | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ----- | ------------- | --------- | | [4.1](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.1-four-questions-decided-once-for-every-screen.md) | Four questions decided once for every screen | Core | — | Page live | | [4.2](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.2-no-list-longer-than-nine-choose-by-category.md) | No list longer than nine: choose by category | Core | — | Page live | | [4.3](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.3-the-service-workflow-states-moves-and-who-may-make-each.md) | The service workflow: states, moves and who may make each | Core | — | Page live | | [4.4](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.4-one-file-a-program-reads-the-application-model.md) | One file a program reads: the application model | Core | — | Page live | | [4.5](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.5-reviewing-the-model-what-it-assumed-and-what-it-could-not-express.md) | Reviewing the model: what it assumed, and what it could not express | Core | — | Page live | | [4.6](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.6-refused-not-worked-around.md) | Refused, not worked around | Core | Yes | Page live |
Module 5 — Generate the service on a low-code platform and connect the blocks | # | Video | Class | Demonstration | Page | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ------------- | ------------- | --------- | | [5.1](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.1-from-one-file-to-a-running-application.md) | From one file to a running application | Core | Yes | Page live | | [5.2](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.2-nothing-generated-is-edited-by-hand.md) | Nothing generated is edited by hand | Core | Yes | Page live | | [5.3](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.3-the-platforms-traps-caught-before-deployment.md) | The platform's traps, caught before deployment | Core | — | Page live | | [5.4](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.4-identity-and-registries-use-the-block-do-not-rebuild-it.md) | Identity and registries: use the block, do not rebuild it | Core | Yes | Page live | | [5.5](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.5-the-services-contract-with-the-registration-block-and-its-data-interface.md) | The service's contract with the registration block, and its data interface | Core | Yes | Page live | | [5.6](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.6-payments-and-information-mediation-as-named-crossings.md) | Payments and information mediation as named crossings | Supplementary | — | Page live | | [5.7](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.7-proof-on-the-running-system-a-task-a-person-finishes.md) | Proof on the running system: a task a person finishes | Core | Yes | Page live |
Module 6 — Run the method in your administration | # | Video | Class | Demonstration | Page | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | ------------- | ------------- | --------- | | [6.1](/experience-digital-transformation/building-block/module-6-run-the-method-in-your-administration/6.1-what-to-require-from-a-supplier.md) | What to require from a supplier | Core | — | Page live | | [6.2](/experience-digital-transformation/building-block/module-6-run-the-method-in-your-administration/6.2-when-something-changes-correct-the-document-that-owns-the-fact.md) | When something changes, correct the document that owns the fact | Core | Yes | Page live | | [6.3](/experience-digital-transformation/building-block/module-6-run-the-method-in-your-administration/6.3-read-where-the-work-stands-from-the-work.md) | Read where the work stands from the work | Core | — | Page live | | [6.4](/experience-digital-transformation/building-block/module-6-run-the-method-in-your-administration/6.4-the-ai-assistant-at-every-step-and-the-person-who-rules.md) | The AI assistant at every step, and the person who rules | Core | — | Page live | | [6.5](/experience-digital-transformation/building-block/module-6-run-the-method-in-your-administration/6.5-the-next-service-on-the-same-foundation.md) | The next service on the same foundation | Core | — | Page live | | [6.6](/experience-digital-transformation/building-block/module-6-run-the-method-in-your-administration/6.6-carry-the-method-to-another-sector.md) | Carry the method to another sector | Core | — | Page live | | [6.7](/experience-digital-transformation/building-block/module-6-run-the-method-in-your-administration/6.7-before-you-rely-on-it-what-the-method-does-not-claim.md) | Before you rely on it: what the method does not claim | Supplementary | — | Page live |
## How to use this guide Each subtopic page holds the content of its video written out in full, its worked example, its AI usage tip with the prompt ready to copy, and its sources with their links. A page can be read on its own, like the video it goes with. Every AI usage tip has four parts: the problem it solves, the prompt, what goes in and what comes out, and a safeguard. The safeguard says what a person must check before the output of the assistant is used. Every worked example is built for Progressa. Its names and values are invented for Progressa, and nothing in it is taken from the results of any country. Figures from public sources are given with their source, their year and their page. The twelve documents of the method are on one page, and each document a person writes has a blank instrument that a team can copy and fill in. Each module ends with a self-check: four questions on what a manager decides, each with the answer the module gives, to compare with after answering. The terms the guide uses are explained in its glossary. Before your first prompt, read [Working with AI](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) and [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): they hold the ground rules for using an assistant on government material, and they apply to every course in this knowledge base. ## 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), [**Building a Government Interoperability Framework (GIF)**](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-interoperability-framework-gif/building-a-government-interoperability-framework-gif) **and** [**Education Digital Public Infrastructure (DPI) Roadmap**](https://experience-digital-transform.gitbook.io/experience-digital-transformation/roadmap/education-digital-public-infrastructure-dpi-roadmap) **come before this course, but none is a prerequisite.** Modules 1, 2 and 6 stand on their own. Module 5 connects the service to identity, registries, payments and the data exchange as blocks already in place; on Progressa they are, so you can follow it without having taken those courses. **What you do need:** | | | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **A real service** | A public service, in education or another sector, that your administration is about to commission or has commissioned. The AI usage tips act on your service, not on a case study. No service to hand? Follow 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. | | **The customer's own documents** | The mandate, the forms, the decrees and the notes of the people who run the service today. The register of requirements is drawn from them ([2.2](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.2-write-down-what-was-asked-before-anyone-designs.md)). | | **An AI assistant** | Any general assistant — Claude, ChatGPT, Gemini. A free account is enough. Nothing to install. | | **Nothing to run** | No code is written. The demonstrations that need the generated application are shown as storyboards until it has been generated and checked. | | **About fifteen minutes, once** | The first 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 to work with the prompts and the ground rules for using an assistant on government material. Read them before your first prompt. | Time: each subtopic is a video of about five minutes, its page, and an AI usage tip of ten to fifteen minutes. A module is an afternoon. The whole course is roughly two 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 every course in this knowledge base.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 digital services go wrong, and the method that prevents it5 videos for the Strategist: the three places a service gets lost, the three rules, the twelve documents and who accepts each.Module 1 — Why digital services go wrong, and the method that prevents it

📒

The worked examplesOne for each subtopic, built for Progressa and linked to one another: the shape of the documents you will commission.The worked examples

🧰

The blank instrumentsA blank to copy and fill in for each document a person writes, with the questions to ask before accepting it.The blank instruments
## Reference pages
The twelve documentsEach document of the method with who writes it, what goes in, what comes out, its blank instrument, where a person decides and how it is checked.The twelve documents
The blank instrumentsA blank to copy and fill in for each document a person writes, with the questions to ask before accepting it.The blank instruments
The worked examplesOne worked example for each subtopic, built for Progressa.The worked examples
Frameworks and standardsThe public frameworks and standards this guide cites, in five kinds, each with its address.Frameworks and standards
The public sourcesEvery public source this guide cites, with its edition or date and its address.The public sources
The standings of the method's standardsHow far each standard behind the twelve documents has come, stated once for the whole guide.The standings of the method's standards
GlossaryEvery term this guide uses, each in one plain sentence.Glossary
FiguresThe figures of the guide, with the subtopics that use them.Figures
## Where this sits | Part | What it takes | What it gives | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [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), [Building a Government Interoperability Framework (GIF)](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-interoperability-framework-gif/building-a-government-interoperability-framework-gif) and [Education Digital Public Infrastructure (DPI) Roadmap](https://experience-digital-transform.gitbook.io/experience-digital-transformation/roadmap/education-digital-public-infrastructure-dpi-roadmap), before this course | — | The enterprise architecture; the data exchange layer and the rules of interoperability; the proven foundational blocks and the roadmap | | Module 1 | A service that went wrong, and the people who commission the next one | The three places a service gets lost, the three rules, the twelve documents and who accepts each | | Module 2 | The sector's mandate and the customer's own documents | The catalogue, the register, the records, the goals, the shared registers and the architecture | | Modules 3 and 4 | The documents of module 2 | One goal as a story with its screens and walk-through, agreed at the review; the interaction design and the service workflow; the application model, reviewed and admitted | | Module 5 | The admitted model and the shared blocks | The generated service on the low-code platform, connected to identity, registries, payments and the data exchange, proved on the running system | | Module 6 | The proved service | The supplier's deliverables, the handling of change, progress read from the work, the rules for the AI assistant, the next service and another sector | All the courses in this knowledge base 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 one 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). {% 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 the AI usage tip of 2.2 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/building-block/designing-digital-government-services-using-a-building-block-approach.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.