> 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/roadmap/module-2-the-registration-block/2.2-the-published-specification-and-how-to-judge-a-product-against-it.md). # 2.2 The published specification, and how to judge a product against it Ask every vendor to show the product against the published specification, requirement by requirement, and check whether GovStack lists it and at which compliance level. {% embed url="" %} The published specification, and how to judge a product against it (\~5 min) {% endembed %} **Watch first (\~5 min).** Then read on: the page carries what the video says, and the AI usage tip. > **Single message.** Ask every vendor to show the product against the published specification, requirement by requirement, and check whether GovStack lists it and at which compliance level. ## The concept A vendor tells you the product is GovStack compliant. That sentence alone tells you very little. What you need is the product shown against the published specification, one requirement at a time, with evidence your own team can check. Start by naming the edition. The GovStack site labels the default edition of the Registration specification 23Q4. Write that edition into your tender and your questionnaire, so every answer refers to the same text. The edition holds forty-two functional requirements in three groups: ten for the applicant, six for the operator who processes applications, and twenty-six for the analyst who builds services. It defines twelve data structures, such as the service, the registration and the role, and thirteen published operations. Each requirement is marked required or recommended. Turn that list into the vendor's homework. For every requirement, the vendor answers one of three things: met as delivered, met by configuration, or not met. Under every answer, ask for evidence you can check: a screen, a test record or a document. Do the same for the operations. Which of the thirteen does the product offer, and where are its test results? Ask also how the product exports and imports a service description, because the specification publishes no operation for creating or changing a service, and each product does it its own way. A product that answers in this form can be compared with the next one. A brochure cannot. Now what GovStack itself offers. Its testing application has a self-assessment form, where a software provider assesses the product against the functional requirements, and a set of automated tests of the interfaces. GovStack's website grades software at Level 1 or Level 2, depending on how many requirements are met. Its team checks a submission for completeness and plausibility, which is a review of what the provider sent, not a test of your installation. Accepted software is listed on the website with its level and a link to the full report. Be careful with thresholds, too: the website and the Architecture specification set different ones. When you quote a threshold, name its source. Here is such a sheet, built as an example for the product Progressa uses; it names no real product. Three rows show the pattern. The operator's decision is met by configuration, and the evidence is the registrar's screen with its three choices. Import and export of a service description is met, and the evidence is a file exported and imported into a second installation. The payment of fees is met but not used, because registering a learner carries no fee. ## Your turn โ€” Turn the specification's requirements into a vendor questionnaire {% hint style="success" %} **๐Ÿ’ก AI usage tip** ยท Turn the specification's requirements into a vendor questionnaire **Bring:** The functional requirements and operations of the edition you procure against, pasted with their numbers. **Get:** A questionnaire for vendors with one row for each requirement and the evidence to ask for under it, and a short set of questions on the operations. **Time:** \~10โ€“15 min ยท **Assistant:** any; the tips are tool-neutral. **Watch for:** Requirement headings and their levels must be quoted from the edition named, not paraphrased. {% endhint %} **The problem it solves.** An Architect who must compare registration products needs every vendor to answer the same questions in the same form. This prompt turns the published list of requirements into that questionnaire, with the evidence to ask for under each requirement. {% tabs %} {% tab title="Prompt" %} Copy the prompt, replace the bracketed parts with your own context, and run it in the AI assistant of your choice. Never paste personal data or unpublished documents โ€” see [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). ``` Below are the functional requirements of the GovStack Registration Building Block specification, in the edition [name the edition and its date as the site shows it], copied from sections 6.1, 6.2 and 6.3: [paste the requirements, each with its number, heading and level]. Build a questionnaire for vendors. For each requirement, keep its number, its heading and its level (REQUIRED or RECOMMENDED) exactly as pasted. Add three answer options: met as delivered, met by configuration, not met. Under each requirement, name the evidence a vendor should attach: a screen, a test record, a configuration file or a document, and say what that evidence must show. Then add one question for each of the published operations in sections 8.1 to 8.3: does the product offer it, and where are its test results? Output: a questionnaire for vendors with one row for each requirement and the evidence to ask for under it, followed by the questions on operations. ``` [Open in Claude](https://claude.ai/new?q=Below%20are%20the%20functional%20requirements%20of%20the%20GovStack%20Registration%20Building%20Block%20specification%2C%20in%20the%20edition%20%5Bname%20the%20edition%20and%20its%20date%20as%20the%20site%20shows%20it%5D%2C%20copied%20from%20sections%206.1%2C%206.2%20and%206.3%3A%20%5Bpaste%20the%20requirements%2C%20each%20with%20its%20number%2C%20heading%20and%20level%5D.%20Build%20a%20questionnaire%20for%20vendors.%20For%20each%20requirement%2C%20keep%20its%20number%2C%20its%20heading%20and%20its%20level%20%28REQUIRED%20or%20RECOMMENDED%29%20exactly%20as%20pasted.%20Add%20three%20answer%20options%3A%20met%20as%20delivered%2C%20met%20by%20configuration%2C%20not%20met.%20Under%20each%20requirement%2C%20name%20the%20evidence%20a%20vendor%20should%20attach%3A%20a%20screen%2C%20a%20test%20record%2C%20a%20configuration%20file%20or%20a%20document%2C%20and%20say%20what%20that%20evidence%20must%20show.%20Then%20add%20one%20question%20for%20each%20of%20the%20published%20operations%20in%20sections%208.1%20to%208.3%3A%20does%20the%20product%20offer%20it%2C%20and%20where%20are%20its%20test%20results%3F%20Output%3A%20a%20questionnaire%20for%20vendors%20with%20one%20row%20for%20each%20requirement%20and%20the%20evidence%20to%20ask%20for%20under%20it%2C%20followed%20by%20the%20questions%20on%20operations.) *(pre-fills the prompt in a new chat; check the bracketed parts before sending)* *What to bring and what you get are in the box above.* {% endtab %} {% tab title="Example input" %} {% hint style="warning" %} **Draft worked example, 2026-10-04.** Progressa is the fictional country used across these courses. The input below and the output in the next tab were made for this page by running the prompt once; they are shortened, and they have not been checked as the worked examples of the method have. {% endhint %} The bracketed parts of the prompt were replaced with the following: **\[the edition]:** GovStack Registration Building Block, default edition, site label 23Q4 (version history to 1.0). **\[the requirements]** (an excerpt; the full paste holds all 42 of sections 6.1 to 6.3): * 6.1.7 Pay fees for application โ€” REQUIRED * 6.2.3 Make decisions about an application โ€” REQUIRED * 6.3.2.10 Import/Export of service descriptions โ€” REQUIRED * 6.3.2.11 Text-to-speech feature โ€” RECOMMENDED * 6.3.3.2 Controlling the data capturing- Form field value validation from external API โ€” REQUIRED The operations of sections 8.1 to 8.3 were pasted as the site lists them: six for online registration (from `GET /services` to `POST /documents`), six for processing (from `GET /applications` to `POST /tasks/{taskId}/complete`) and one for the development platform (`GET /data/statistics`). {% endtab %} {% tab title="Example output" %} {% hint style="warning" %} **Draft: model output, shortened and unverified.** Read it with the notes in the next tab, not on its own. {% endhint %} **Answer for each requirement:** met as delivered / met by configuration / not met. | No. | Heading (as pasted) | Level | Evidence to attach | What it must show | | -------- | ----------------------------------------------------------------------------- | ----------- | ---------------------------------- | ----------------------------------------------------------------------------------- | | 6.1.7 | Pay fees for application | REQUIRED | Screen | The fee shown to the applicant before sending, and a paid test application | | 6.2.3 | Make decisions about an application | REQUIRED | Screen and test record | The operator's three choices; a file sent back with the wrong field marked | | 6.3.2.10 | Import/Export of service descriptions | REQUIRED | Configuration file and test record | An exported file in the product's named format, imported into a second installation | | 6.3.2.11 | Text-to-speech feature | RECOMMENDED | Screen | A screen read aloud | | 6.3.3.2 | Controlling the data capturing- Form field value validation from external API | REQUIRED | Test record | A field compared with an outside source, and a mismatch refused | **Questions on operations** (one for each of the 13): does the product offer it; where are its test results? For example: "`POST /tasks/{taskId}/complete` โ€” offered? Attach the test run, or your GovStack compliance report." {% endtab %} {% tab title="Reading the output" %} This is the teaching part of the tip. Work through the output the way a chief architect would: what is earned, what is invented, what is missing.
1. The headings and levels survive Every heading is quoted as pasted, including the specification's own odd punctuation in 6.3.3.2, and the one RECOMMENDED stays RECOMMENDED. That is the safeguard's point, and it holds in this run; the line-by-line check is still needed on the full 42.
2. A compliance report is not a test result The run offered the vendor "your GovStack compliance report" as evidence of an operation. That overreaches. GovStack's listing is a review of what the provider submitted, graded Level 1 or 2; it is not a run of the operation. Strike that option and ask for the test run itself.
3. What the questionnaire still lacks It asks nothing on how a service description is created or changed, which no published operation covers, and nothing on which edition the vendor's answers refer to. Add both, and check whether GovStack lists the product and at which level.
{% hint style="danger" %} **Safeguard.** Requirement headings and their levels must be quoted from the edition named, not paraphrased. Compare the questionnaire with the pasted text line by line before it is issued; a heading the model has reworded, or a RECOMMENDED turned into REQUIRED, changes what the vendor is bound to answer. {% endhint %} {% endtab %} {% tab title="What next" %} The answers let you choose the product, and the product's named format is what [2.3](/experience-digital-transformation/roadmap/module-2-the-registration-block/2.3-generating-the-registration-service.md) needs to draft the service description. The [build plan](/experience-digital-transformation/roadmap/the-build-plan.md) records the choice as one of its three settings. {% endtab %} {% endtabs %} ## Sources * GovStack Registration Building Block specification, default edition (), sections 6.1 to 6.3, 7.2, 8.1 to 8.3 * GovStack testing application (), with the GovStack website pages 'How is Compliance Measured?' and 'How to Submit Software?' * GovStack Architecture specification, edition 2.1.0, section 5.5.4 () --- # 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/roadmap/module-2-the-registration-block/2.2-the-published-specification-and-how-to-judge-a-product-against-it.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.