> 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/the-worked-examples.md). # The worked examples These files show what each document of the specification-driven method looks like when it is filled in, using Progressa, the fictional country used across these knowledge products. They form one story: Progressa's quality authority for higher education, PHEQA, and its ministry of education, MoEYS, commission two applications so that a private institution gives its particulars to the state once. The first file fixes the facts every example uses. The others follow this course's subtopics in order: module 1 shows why services go wrong and the twelve documents that prevent it; module 2 shows the documents written before any design; module 3 shows one goal, *apply for a provisional licence*, designed in full and reviewed; module 4 shows the whole application settled once and described for the machine; module 5 shows the two applications as they will be generated, with the ministry reading the register across the data interface; module 6 shows a change of an institution's name, the trace report and the digital credential as the next service. The examples are written for the manager who commissions a service, judges the supplier and convenes the review. Each one ends with what to look for before accepting the document it shows. | File | Subtopic | What it shows | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | [E0\_progressa-fact-sheet.md](/experience-digital-transformation/building-block/the-worked-examples/e0-progressas-higher-education-services-the-fact-sheet-for-this-course.md) | All | The bodies, registers, lists, services, building blocks and the two applications that every example uses | | [E1-1\_where-an-agreed-service-gets-lost.md](/experience-digital-transformation/building-block/the-worked-examples/e1.1-one-institution-two-counters-where-progressas-service-was-lost.md) | 1.1 Where an agreed service gets lost | An institution that registered at PHEQA and filled in the same particulars again at MoEYS, each loss placed at one of the three places | | [E1-2\_three-rules-you-can-hold-a-supplier-to.md](/experience-digital-transformation/building-block/the-worked-examples/e1.2-a-suppliers-proposal-for-pheqa-read-against-the-three-rules.md) | 1.2 Three rules you can hold a supplier to | A supplier's proposal read against the three rules, each shortfall rewritten as a clause | | [E1-3\_a-question-with-a-name-on-it.md](/experience-digital-transformation/building-block/the-worked-examples/e1.3-the-appeal-period-a-guess-and-a-named-question.md) | 1.3 A question with a name on it is part of the specification | The appeal period written first as a guess, then as a named question with an owner and a date | | [E1-4\_twelve-documents-from-request-to-running-service.md](/experience-digital-transformation/building-block/the-worked-examples/e1.4-the-twelve-documents-filled-for-pheqas-registration-of-institutions.md) | 1.4 Twelve documents from the request to the running service | The twelve documents filled for PHEQA's registration of institutions, with the manager's points of decision marked | | [E1-5\_who-writes-who-checks-who-accepts.md](/experience-digital-transformation/building-block/the-worked-examples/e1.5-who-writes-checks-and-accepts-each-document-of-pheqas-registration-project.md) | 1.5 Who writes, who checks, who accepts | Who writes, checks and accepts each of the twelve documents, and who sits at each review | | [E2-1\_one-catalogue-of-the-sectors-services.md](/experience-digital-transformation/building-block/the-worked-examples/e2.1-progressas-catalogue-of-higher-education-services-and-the-blocks-they-rest-on.md) | 2.1 One catalogue of the sector's services, and the blocks they share | Progressa's catalogue of higher-education services, with six services resting on one register | | [E2-2\_write-down-what-was-asked.md](/experience-digital-transformation/building-block/the-worked-examples/e2.2-five-entries-of-pheqas-register-of-requirements.md) | 2.2 Write down what was asked before anyone designs | Five entries of PHEQA's register of requirements, in the regulation's words, and two open questions | | [E2-3\_the-records-and-whose-each-one-is.md](/experience-digital-transformation/building-block/the-worked-examples/e2.3-pheqas-records-and-the-three-answers-for-every-fact.md) | 2.3 The records the service keeps, and whose each one is | Four records in one sentence each, the three answers for every fact, and the read-back | | [E2-4\_every-goal-named-and-tied-to-what-was-asked.md](/experience-digital-transformation/building-block/the-worked-examples/e2.4-the-goals-of-pheqas-and-moeyss-applications-checked-in-both-directions.md) | 2.4 Every goal named, and each tied to what was asked | The goals of both applications checked against the register in both directions | | [E2-5\_what-every-goal-may-use.md](/experience-digital-transformation/building-block/the-worked-examples/e2.5-pheqas-shared-groundwork-a-setting-a-code-list-and-the-licences-states.md) | 2.5 What every goal may use, and may not invent | The application fee as a setting with an owner, the kinds of institution, the licence's states, and a goal that invented a fee | | [E2-6\_what-the-service-is-built-on.md](/experience-digital-transformation/building-block/the-worked-examples/e2.6-the-architecture-of-progressas-two-applications-on-one-page.md) | 2.6 What the service is built on, and what crosses its boundary | The two applications on one page, and the table of crossings | | [E3-1\_one-goal-written-as-a-story.md](/experience-digital-transformation/building-block/the-worked-examples/e3.1-apply-for-a-provisional-licence-the-main-story.md) | 3.1 One goal, written as a story a builder can follow | The main story of *apply for a provisional licence* | | [E3-2\_every-way-it-can-go-wrong.md](/experience-digital-transformation/building-block/the-worked-examples/e3.2-the-failures-of-apply-for-a-provisional-licence-each-with-its-own-ending.md) | 3.2 Every way it can go wrong, written down | Five failures of the story, each with its own ending | | [E3-3\_screens-every-value-with-its-source.md](/experience-digital-transformation/building-block/the-worked-examples/e3.3-the-screens-of-apply-for-a-provisional-licence-every-value-with-its-source.md) | 3.3 Screens worked out from the story, every value with its source | The five screens of the goal, with the source of every value | | [E3-4\_screens-officers-can-use.md](/experience-digital-transformation/building-block/the-worked-examples/e3.4-an-inspectors-screen-at-pheqa-before-and-after-five-rules.md) | 3.4 Screens officers can use (supplementary) | An inspector's screen before and after five rules | | [E3-5\_the-walk-through-your-officials-click.md](/experience-digital-transformation/building-block/the-worked-examples/e3.5-the-walk-through-of-apply-for-a-provisional-licence.md) | 3.5 The walk-through your officials click | The walk-through of the goal, each page with its version, clicked by the Registrar and the builder | | [E3-6\_the-review-three-people.md](/experience-digital-transformation/building-block/the-worked-examples/e3.6-the-review-of-the-provisional-licence-screens-at-pheqa.md) | 3.6 The review: three people, every open line given a name | The review of the goal's screens, and its record of open lines with owners and dates | | [E4-1\_four-questions-decided-once-for-every-screen.md](/experience-digital-transformation/building-block/the-worked-examples/e4.1-four-questions-decided-once-for-every-screen.md) | 4.1 Four questions decided once for every screen | MoEYS: pick and find; MoEYS: move and act; Who accepts it, and what she reads | | [E4-2\_no-list-longer-than-nine-choose-by-category.md](/experience-digital-transformation/building-block/the-worked-examples/e4.2-no-list-longer-than-nine-choose-by-category.md) | 4.2 No list longer than nine: choose by category | Progressa: the matters PHEQA advises on; Two steps on the screen | | [E4-3\_the-service-workflow-states-moves-and-who-may-make-each.md](/experience-digital-transformation/building-block/the-worked-examples/e4.3-the-service-workflow-states-moves-and-who-may-make-each.md) | 4.3 The service workflow: states, moves and who may make each | PHEQA: the states of a licence; The moves, and who may make each; The check: can every state be left? | | [E4-4\_one-file-a-program-reads-the-application-model.md](/experience-digital-transformation/building-block/the-worked-examples/e4.4-one-file-a-program-reads-the-application-model.md) | 4.4 One file a program reads: the application model | MoEYS: one section, in plain sentences; Ask for it in plain sentences | | [E4-5\_reviewing-the-model-what-it-assumed-and-what-it-could-not-express.md](/experience-digital-transformation/building-block/the-worked-examples/e4.5-reviewing-the-model-what-it-assumed-and-what-it-could-not-express.md) | 4.5 Reviewing the model: what it assumed, and what it could not express | MoEYS: two cards; When the answer is no | | [E4-6\_refused-not-worked-around.md](/experience-digital-transformation/building-block/the-worked-examples/e4.6-refused-not-worked-around.md) | 4.6 Refused, not worked around | MoEYS: one list of twenty, refused; Corrected, and admitted | | [E5-1\_from-one-file-to-a-running-application.md](/experience-digital-transformation/building-block/the-worked-examples/e5.1-from-one-file-to-a-running-application.md) | 5.1 From one file to a running application | Progressa: MoEYS's application; The questions you ask of the result; From the file to the menu | | [E5-2\_nothing-generated-is-edited-by-hand.md](/experience-digital-transformation/building-block/the-worked-examples/e5.2-nothing-generated-is-edited-by-hand.md) | 5.2 Nothing generated is edited by hand | Progressa: a label on MoEYS's form; A hand edit shown up; Write it into the contract | | [E5-3\_the-platforms-traps-caught-before-deployment.md](/experience-digital-transformation/building-block/the-worked-examples/e5.3-the-platforms-traps-caught-before-deployment.md) | 5.3 The platform's traps, caught before deployment | Progressa: a list with two filters; Caught by the check, not by an officer; What to ask a supplier | | [E5-4\_identity-and-registries-use-the-block-do-not-rebuild-it.md](/experience-digital-transformation/building-block/the-worked-examples/e5.4-identity-and-registries-use-the-block-do-not-rebuild-it.md) | 5.4 Identity and registries: use the block, do not rebuild it | What an institution is: the register; Progressa: one sign-in, one register, no copies; A block used, not a copy kept; Signed in, and read from the register | | [E5-5\_the-services-contract-with-the-registration-block-and-its-data-interface.md](/experience-digital-transformation/building-block/the-worked-examples/e5.5-the-services-contract-with-the-registration-block-and-its-data-interface.md) | 5.5 The service's contract with the registration block, and its data interface | Progressa: PHEQA's register, as MoEYS reads it; One institution, read across the exchange | | [E5-6\_payments-and-information-mediation-as-named-crossings.md](/experience-digital-transformation/building-block/the-worked-examples/e5.6-payments-and-information-mediation-as-named-crossings.md) | 5.6 Payments and information mediation as named crossings (supplementary) | Progressa: the crossings of PHEQA's registration service; Each row agreed by the other side | | [E5-7\_proof-on-the-running-system-a-task-a-person-finishes.md](/experience-digital-transformation/building-block/the-worked-examples/e5.7-proof-on-the-running-system-a-task-a-person-finishes.md) | 5.7 Proof on the running system: a task a person finishes | Progressa: approving a change of name; The record that it happened; The change of name, on the running application | | [E6-1\_what-to-require-from-a-supplier.md](/experience-digital-transformation/building-block/the-worked-examples/e6.1-the-deliverables-annex-of-moeyss-terms-of-reference-illustrative.md) | 6.1 What to require from a supplier | The deliverables annex of MoEYS's terms of reference (illustrative) | | [E6-2\_when-something-changes-correct-the-document-that-owns-the-fact.md](/experience-digital-transformation/building-block/the-worked-examples/e6.2-a-change-of-an-institutions-name-followed-through-both-bodies-illustrative.md) | 6.2 When something changes, correct the document that owns the fact | A change of an institution's name, followed through both bodies (illustrative) | | [E6-3\_read-where-the-work-stands-from-the-work.md](/experience-digital-transformation/building-block/the-worked-examples/e6.3-moeyss-trace-report-and-the-ministers-status-illustrative.md) | 6.3 Read where the work stands from the work | MoEYS's trace report and the minister's status (illustrative); and six of the method's rules, chosen for a manager | | [E6-4\_the-ai-assistant-at-every-step-and-the-person-who-rules.md](/experience-digital-transformation/building-block/the-worked-examples/e6.4-moeyss-rules-of-use-for-an-ai-assistant-on-one-page-illustrative.md) | 6.4 The AI assistant at every step, and the person who rules | MoEYS's rules of use for an AI assistant, on one page (illustrative) | | [E6-5\_the-next-service-on-the-same-foundation.md](/experience-digital-transformation/building-block/the-worked-examples/e6.5-pdcas-credential-as-a-catalogue-row-and-its-reuse-list-illustrative.md) | 6.5 The next service on the same foundation | PDCA's credential as a catalogue row, and its reuse list (illustrative) | | [E6-6\_carry-the-method-to-another-sector.md](/experience-digital-transformation/building-block/the-worked-examples/e6.6-what-another-sector-brings-and-what-stays-the-same-the-teams-blank-instrument.md) | 6.6 Carry the method to another sector | What another sector brings, and what stays the same (the team's blank instrument) | | [E6-7\_before-you-rely-on-it-what-the-method-does-not-claim.md](/experience-digital-transformation/building-block/the-worked-examples/e6.7-the-risk-paragraph-of-moeyss-briefing-note-illustrative.md) | 6.7 Before you rely on it: what the method does not claim (supplementary) | The risk paragraph of MoEYS's briefing note (illustrative) | **How the files link.** Register entries carry identifiers `R-…` (E2.2, E2.4, E3.1), goals `G-…` (E2.4), screens `S…` (E3.3, E3.5, E3.6) and crossings `X-…` (E2.6). The goal *apply for a provisional licence* is G-01 in E2.4 and is written out in full in E3.1 to E3.6. **Modules 4 to 6.** Their examples are carried by the scripts of their modules, and are taken from there as they stand, in the form of the examples of modules 1 to 3, by the program that renders the course guide. They are not edited in this folder: a correction is made in the module's script, and the file is written again. **The figures.** Every figure, date and article number about Progressa is invented. Figures from public sources are quoted with their source. --- # 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/the-worked-examples.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.