> 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.1-what-the-registration-block-does.md). # 2.1 What the Registration block does A registration block takes an application, lets an officer decide and, on approval, writes to a register and gives the applicant proof. {% embed url="" %} What the Registration block does (\~5 min) {% endembed %} **Watch first (\~5 min).** Then read on: the page carries what the video says, and the AI usage tip. > **Single message.** A registration block takes an application, lets an officer decide and, on approval, writes to a register and gives the applicant proof, and built once it serves every ministry that registers people or things. ## The concept Every ministry registers something. Schools register learners. A business registry registers companies. A population registry records births. Each office asks for information, checks it, decides, records it and gives back proof. The Registration block is shared software that does exactly that. The GovStack Registration specification defines registration in one sentence. It is the process through which an applicant gets information recorded in a registry and receives a credential as proof of registration. At least two parties are involved: the applicant, and the authorised representative of the registry, whom the specification calls the registrar. Others may join. A witness, another public body or a database may confirm what the applicant says. A bank may receive a fee. Notice the two outcomes. A record is written, and proof goes back to the applicant. A service that stops at capturing a form has done neither. The block has three capabilities. The first is online registration. The applicant fills in a form, uploads documents, pays a fee where there is one, sends the file and follows its status until a decision arrives. The second is processing. In the back office an operator, who may be a person or an automated role, approves the file, rejects it or sends it back for correction. On approval the system sends the information to a registry and issues the credential. The third is the development platform. There an analyst sets up the rules, the screens and the checks of each service, without writing code. Here is Progressa's learner registration seen through those three parts. A parent, or a learner old enough, applies online. The registrar of PLR, the Progressa Learner Registry, decides in the back office. An analyst in the ministry configures the service. In the service, the parent meets the guide, the form, the documents and the send button, and later the decision and the confirmation. One thing the block does not do is keep the record for the long term. The specification leaves storage to the Digital Registries block. The registration block's job is to connect to it and write there. Now the reason this is a shared block and not a school system. PAERA, the GovStack reference architecture, says that digitising a state registry needs two building blocks: Registration and a Digital Registry. That holds for a business registry, a population registry and a learner register alike. So the ministry that builds the block first pays for it, and each ministry after it sets up a new service on the same block. That re-use is only visible to someone planning for the whole government, which is why the decision belongs above any single project. ## Your turn โ€” Map your paper registration onto the block's three capabilities {% hint style="success" %} **๐Ÿ’ก AI usage tip** ยท Map your paper registration onto the block's three capabilities **Bring:** The description of one registration procedure as it works today. **Get:** A table that sorts each step of your procedure into the three capabilities, with the decisions an officer takes, and a list of the steps that could not be placed. **Time:** \~10โ€“15 min ยท **Assistant:** any; the tips are tool-neutral. **Watch for:** Who may decide is set by the law and the regulations that create the registration, not by the prompt. {% endhint %} **The problem it solves.** Before anyone configures a service, the Architect needs to see an existing paper procedure in the block's terms: what the applicant does, what the officer decides, and what the analyst must set up. This prompt sorts the procedure into the three capabilities and lists every decision an officer takes in it. {% 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 is the description of a registration procedure as it works today in [country X], run by [the registering body]: [paste the procedure โ€” the form, the steps at the counter, who signs what, what the applicant receives at the end]. Using the three capabilities of the GovStack Registration Building Block โ€” (1) online registration by the applicant, (2) processing of registrations by operators, (3) the development platform used by an analyst โ€” sort every step of the procedure into one capability. Then list every decision an officer takes in the procedure (approve, reject, send back for correction, or another), and for each decision say which office takes it today. Mark any step you cannot place. Output: a table that sorts each step of your procedure into the three capabilities, with the decisions an officer takes, plus a short list of the steps you could not place. ``` [Open in Claude](https://claude.ai/new?q=Below%20is%20the%20description%20of%20a%20registration%20procedure%20as%20it%20works%20today%20in%20%5Bcountry%20X%5D%2C%20run%20by%20%5Bthe%20registering%20body%5D%3A%20%5Bpaste%20the%20procedure%20%E2%80%94%20the%20form%2C%20the%20steps%20at%20the%20counter%2C%20who%20signs%20what%2C%20what%20the%20applicant%20receives%20at%20the%20end%5D.%20Using%20the%20three%20capabilities%20of%20the%20GovStack%20Registration%20Building%20Block%20%E2%80%94%20%281%29%20online%20registration%20by%20the%20applicant%2C%20%282%29%20processing%20of%20registrations%20by%20operators%2C%20%283%29%20the%20development%20platform%20used%20by%20an%20analyst%20%E2%80%94%20sort%20every%20step%20of%20the%20procedure%20into%20one%20capability.%20Then%20list%20every%20decision%20an%20officer%20takes%20in%20the%20procedure%20%28approve%2C%20reject%2C%20send%20back%20for%20correction%2C%20or%20another%29%2C%20and%20for%20each%20decision%20say%20which%20office%20takes%20it%20today.%20Mark%20any%20step%20you%20cannot%20place.%20Output%3A%20a%20table%20that%20sorts%20each%20step%20of%20your%20procedure%20into%20the%20three%20capabilities%2C%20with%20the%20decisions%20an%20officer%20takes%2C%20plus%20a%20short%20list%20of%20the%20steps%20you%20could%20not%20place.) *(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: **\[country X]:** Progressa. **\[the registering body]:** the primary school, under the Ministry of Education, Youth and Skills (MoEYS). **\[the procedure]:** A parent collects a paper enrolment form at the school office in the term before the school year starts. The parent fills it in and brings it back with the child's birth certificate; a learner who transfers also brings a letter from the previous school. The school clerk checks that every box is filled and returns incomplete forms to the parent. The head teacher reads each form, admits the child or refuses (no place, or the child is under three) and signs the form. The parent receives a stamped admission slip. Each term the head teacher keys the admitted learners into the district EMIS, with its own learner number. The form itself is a template the district education office printed in 2019. {% 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 %} | Step today | Capability | Decision an officer takes | Office that takes it today | | ------------------------------------------------------------------- | ----------------------------------- | ------------------------- | -------------------------- | | Parent collects and fills in the form | (1) online registration | โ€” | โ€” | | Parent brings the birth certificate and, for a transfer, the letter | (1) online registration (documents) | โ€” | โ€” | | Clerk checks every box is filled | (2) processing | Send back for correction | School clerk | | Head teacher reads, admits or refuses, signs | (2) processing | Approve; reject | Head teacher | | Parent receives the stamped admission slip | (2) processing (result issued) | โ€” | โ€” | | District office designs and prints the form | (3) development platform | โ€” | District education office | **Steps I could not place:** * Keying admitted learners into district EMIS each term: it is the write to a register, but the register is a district list, not an authoritative one. * The birth certificate shown at the counter: checked by eye, with nothing recorded; no capability holds a check that leaves no trace. {% 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 decisions are found where they hide The clerk's return of an incomplete form is a decision, send back for correction, and the table names it. That is supported by the input, and it matters: in the block, completeness on sending removes most of that work before anyone sees the file.
2. "Office that takes it today" is not "office that should take it" The table rightly records the head teacher as deciding today. Read too fast, it suggests the head teacher is the registrar of the new service. Progressa has no legal basis yet for a learner register (G-01), so no text names the registrar; until it does, the deciding office is an open question, not a row to copy into the configuration.
3. The two unplaced steps are the design questions The EMIS keying is where the record is written after approval, and the birth certificate is where identity is checked. Both are answered later in this module: the write to the learner register, and the comparison with PNIA's record. Check the termly census return too; the description did not mention it, and it may be a second register.
{% hint style="danger" %} **Safeguard.** Who may decide is set by the law and the regulations that create the registration, not by the prompt. Take the deciding office for each decision from the legal text and correct the table where the model has guessed; a decision placed with the wrong office is the error that surfaces only after the service is live. {% endhint %} {% endtab %} {% tab title="What next" %} The sorted steps become the registration brief in the specification's terms, from which [2.3](/experience-digital-transformation/roadmap/module-2-the-registration-block/2.3-generating-the-registration-service.md) drafts the service description. The open question of who decides goes to the legal basis, gap G-01 of the [gap register](/experience-digital-transformation/roadmap/the-worked-examples/e6-the-gap-register-and-its-priorities-for-progressa.md). {% endtab %} {% endtabs %} ## Sources * GovStack Registration Building Block specification, default edition (), sections 2 and 4.1 to 4.4 * PAERA v1.0, Annex 1, A1.2.5 () --- # 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.1-what-the-registration-block-does.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.