> 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/e6.6-what-another-sector-brings-and-what-stays-the-same-the-teams-blank-instrument.md). # E6.6 — What another sector brings, and what stays the same (the team's blank instrument) The team's blank instrument: it names no country, no institution and no person. No second sector is worked through, because the demonstration of this course is education. **Subtopic:** 6.6 — Carry the method to another sector **Public anchor:** None. The content is the SDD method's own: the contract of a sector's reference pack, checked so that the method's tools hold no sector's content; no public source is cited **Simulated case:** This is a simulated case for Progressa, a fictional country; every institution, name, date and figure in it is invented. **What it shows.** What another sector brings, and what stays the same (the team's blank instrument). **Form of this example.** Taken as it stands from the worked example that the script bundle of module 6 gives with the script of 6.6. The method's form names no country; the example is filled for Progressa. The team's blank instrument: it names no country, no institution and no person. No second sector is worked through, because the demonstration of this course is education; the education example of the other subtopics is the only worked one. The answer column is left blank for the new sector to fill. | What the sector brings | What it holds | The sector's answer | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | | Its catalogue of services | Every service the sector's bodies owe, each with the body that owes it, its state today and the blocks it rests on, written once for the whole sector | | | Its register of what was asked | One entry for each separate thing its own law, mandate and requests ask for, in their own words | | | Its records and their keepers | The records its services keep, and for every fact whether the sector keeps it, takes it from another body, or must not hold it | | | Its reference pack | Its usual procedures; reusable pieces of design; a checklist of what is realistic in the sector, which its officials review; reference points to compare a design against; and one finished example. A program checks that the pack is complete | | | The names before the first document | Who owns the service; who writes the catalogue; which officials correct the adapted examples | | | What stays the same | Why it does not depend on the sector | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | The twelve documents, and their order | Each document is defined by what it is for, not by what it is about | | The people who accept them, by role | The owner of the service, the head of the ICT unit and the official who will live with the result exist in every ministry | | The checks at each handover | They compare one document with another, whatever the documents describe | | The rules that always hold | No hand edits, a correction in the document that owns the fact, a question with an owner, progress read from the work | | The blank instruments | They carry the lines of each document, not the sector's content | What to look for before another sector starts. Every line of the first table is answered by that sector, from its own law and its own officials. A line answered from education is a guess about health or agriculture until the sector's officials confirm it. --- # 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/e6.6-what-another-sector-brings-and-what-stays-the-same-the-teams-blank-instrument.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.