> 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/glossary.md). # Glossary Each term below is used in this guide, and each is explained in one plain sentence. Where the guide has a longer explanation, the subtopic that teaches it says more. | Term | What it means | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **AI assistant** | A program that drafts text from what it is given; in this method it proposes, and a named person decides what stands. | | **Application model** | The one file, written for a program to read, from which the application is generated. | | **Assumption** | A decision the writer of the application model had to make because the accepted documents were silent, named for a person to rule on. | | **Blank instrument** | An empty form for one document of the method, with the lines to fill in and the questions to ask before accepting it. | | **Building block** | A shared digital capability, such as identity, a register, payments or the exchange of data between bodies, that many services use instead of each building its own. | | **Catalogue of the sector's services** | One list of every service the bodies of a sector owe, with what each rests on, written once for the whole sector before any one service is specified. | | **Code list** | A fixed list of choices, such as the kinds of institution, written once and used by every goal that needs it. | | **Contract** | Here, the written promise one system makes to others: what they may ask of it, what they must send, and what comes back. | | **Crossing** | Any flow of data that leaves the service or enters it, named with the body on the other side and the block it goes through. | | **Data exchange** | The shared channel through which public bodies read each other's records, called Linkup in Progressa. | | **Data interface** | The agreed way one body's application reads another body's records across the data exchange, under a contract. | | **Digital credential** | A record issued by a body in a form that others can check, such as a learner's credential, which its holder keeps and shows when asked. | | **Digital public infrastructure (DPI)** | A set of shared digital systems, such as digital identity, digital payments and consent-based data sharing, on which many services are built. | | **Digital wallet** | An application in which a person keeps the credentials issued to them and shows them when asked. | | **Entity model** | The document that names the records the service keeps, says what each one means and whose each fact is, with its glossary and its business rules. | | **Generate** | To have a program make the working application from the accepted application model, so that nothing in it is built or changed by hand. | | **Goal** | Something one person wants to get done with the service, in one sitting, that leaves a result they can see. | | **Hand edit** | A change made directly on the platform to something a program generated, which the method forbids, because the correction belongs in the document that owns the fact. | | **Interaction design** | The document that settles once, for the whole application, how officers pick a value, find a record, move a case and act on a record. | | **Journey** | A real task written down before it is run, from a menu entry to what counts as finished, which a person then finishes on the running service as the final proof. | | **Loss** | Something an accepted document says that the application model cannot express, named with what was done instead. | | **Low-code platform** | A platform that builds an application from four kinds of part, forms, lists, menus and processes, put together largely without writing program code. | | **Open question** | A gap in a document written down with the person who owns it and the date by which it is to be answered, instead of being filled with a guess. | | **Progressa** | The fictional country in which every example of this guide is set, with every name and value invented. | | **Read-back** | The program that compares each generated file on the platform with what the accepted description would generate, and marks it in step, out of date or edited by hand. | | **Refusal** | The program's check before anything is generated, which stops a description that contradicts what the owner accepted or breaks a rule of the platform, and which nobody switches off. | | **Register of requirements** | One entry for each separate thing the customer asked for, in the customer's words, with where it was said, written before anyone designs. | | **Register of the platform's known differences** | The method's list of places where the platform's documentation promises one thing and a particular release does another. | | **Registry** | A record kept by one body as the single source of truth, such as PHEQA's register of institutions, which other services read and do not copy. | | **Review of three people** | The meeting at which the owner of the screens, the builder and the person who will live with the result agree a goal's screens, ending only when every open line has an owner and a date. | | **Screens of a use case** | What a person sees at each step of a goal's story, with the source of every value on every screen. | | **Service workflow** | Every state a case can be in, every move between states, and who may make each move, written once. | | **Setting** | A value the administration may change without changing the build, such as the application fee, written once with a named owner who confirms it. | | **Shared groundwork** | The states, settings, code lists and events that every goal shares, written once in one document. | | **Single message** | The one sentence each video, and its page, must leave with the learner. | | **Software architecture** | The document that says what the service is built on and names every flow that crosses its boundary to another body. | | **Specification-driven development (SDD)** | 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. | | **Stale list** | The list a program produces of the documents and generated files that a change makes out of date, so that each is produced again. | | **Standing** | How far a standard behind the method has come: a draft, in force, or in force but not yet tested by use. | | **State** | A stage a case can be in, such as granted, suspended or cancelled for a licence. | | **Storyboard** | The steps a demonstration recording will show, in order, with what the viewer sees at each step and what counts as a pass, written before the recording is made. | | **Trace report** | The report programs produce from the documents, showing each entry of the register of what was asked traced to a goal, a screen and a generated part, and what is not yet traced. | | **Twelve documents** | The documents of the method, from the customer's own documents to the working application, each accepted by a named person before the next is begun. | | **Use case** | One goal written out in full as a story a builder can follow, with every way it can go wrong and the ending of each. | | **Use case model** | The document that names every goal and ties each one to the entries of the register of what was asked that it serves. | | **Walk-through** | Linked web pages produced from the written screens, which officials click through at the review, each page carrying its version. | | **Worked example** | A filled example of a document of the method, built for Progressa, given with every subtopic. | --- # 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/glossary.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.