> 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/e1.2-a-suppliers-proposal-for-pheqa-read-against-the-three-rules.md). # E1.2 — A supplier's proposal for PHEQA, read against the three rules 1\. Review a story, not a list. Officials agree to what a person does, step by step, and what they see at each step. They do not sign a list of fields. **Subtopic:** 1.2 — Three rules you can hold a supplier to **Public anchor:** PAERA version 1.0 (GovStack, 2024), section 2.3, on enterprise architecture as the description that lets the policy side and the technical side plan together; the three rules themselves are the SDD method's own **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.** A supplier's proposal for Progressa's registration of institutions read against the three rules, with each shortfall rewritten as a clause the manager can put to the supplier. **Form of this example.** The three rules are the method's and name no country. The proposal and the clauses are built for Progressa. ## The three rules 1. **Review a story, not a list.** Officials agree to what a person does, step by step, and what they see at each step. They do not sign a list of fields. 2. **Measure against a list the design did not write.** The design is checked against a list of what was asked, written before the design and from the customer's own words. A list the designers wrote from their own design proves nothing. 3. **End one check on the running system.** The last check is a real person finishing a real task on the system the service will run on. ## The proposal In October 2026 PHEQA received a proposal to build its registration service. Three passages matter here. > "Section 4. Design sign-off. The supplier will deliver a data dictionary of 140 fields covering the application, the institution and the licence. PHEQA's officials will sign each page of the dictionary to confirm the design." > "Section 5. Traceability. The supplier's analysts will prepare a requirements list from the approved design, and every requirement will be traced to a screen." > "Section 7. Testing. Testing is complete when all test scripts pass on the supplier's test server." ## Where it falls short, and the clause that fixes it | Rule | What the proposal says | Why it falls short | The clause PHEQA puts to the supplier | | ----------------------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Review a story, not a list | Officials sign 140 fields (section 4) | A registration officer cannot tell from a list of fields whether an applicant can finish an application, what happens when a document is missing, or who is told what. Signing it agrees to nothing an official can check | "For each goal of the service, the supplier delivers the story of what the person does, step by step, with every way it can fail, and the screens worked out from it, in a walk-through PHEQA's officials can click. PHEQA accepts the stories and the walk-through, not a list of fields." | | Measure against a list the design did not write | The requirements list is written from the approved design (section 5) | A list written from the design will always match the design. It cannot show that something PHEQA asked for was left out | "Before any design is written, the supplier delivers a register of what PHEQA asked for, one entry for each separate thing, in the words of PHEQA's regulations and requests, with where each was said. The Registrar of PHEQA accepts the register. The design is measured against it in both directions: every entry served by a goal, and every goal serving an entry." | | End one check on the running system | Testing ends on the supplier's test server (section 7) | Nobody from PHEQA uses that server. A test that passes there says nothing about the service PHEQA will run | "Acceptance ends when a registration officer of PHEQA, on PHEQA's own installation, finishes at least one real task of each goal, from signing in through PNIA to the recorded result, and the record of that journey is kept as the evidence of acceptance." | ## Why the first rule matters most for a manager PAERA treats enterprise architecture as the shared description that lets the policy side and the technical side plan together. A story with its screens is that shared description for one service: the registrar recognises her work in it, and the builder can build from it. A list of 140 fields is shared by nobody: the registrar cannot read it and the builder did not need her signature on it. **What to look for in your own procurement.** Before you sign a contract, find the three places in the proposal: what officials are asked to approve, what the design is measured against, and where testing ends. If any of the three is the supplier's own document or the supplier's own server, write the clause. --- # 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/e1.2-a-suppliers-proposal-for-pheqa-read-against-the-three-rules.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.