> 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/gea/module-4-progressa-end-to-end-the-method-on-one-sector/4.4-phase-3-adapt-fit-paera-and-decide-build-buy-or-share.md). # 4.4 Phase 3, Adapt — fit PAERA and decide build, buy or share Adapt fits PAERA to Progressa — localising principles, setting sector priorities, and deciding for each building block whether to build, buy, share or sandbox. {% embed url="" %} EA lifecycle Phase 3: localise the framework and decide build vs buy vs share (\~3 min) {% endembed %} **Watch first (\~3 min).** Then come back for the play. The video's recap slide carries an on-screen practice box — it is not narrated — and this page is where that box points. > **Single message.** Adapt fits PAERA to Progressa — localising principles, setting sector priorities, and deciding for each building block whether to build, buy, share or sandbox — signed off as the framework and sourcing approach. ## The concept Phase three is Adapt. PAERA is a starting point, not a constraint, so now the architects shape it to Progressa — its own principles, its sector priorities, and a sourcing decision for each building block. About four to six weeks. First, localise the principles. Progressa adopts PAERA's principles as its baseline and points each at its own laws — once-only against the data-protection act, reuse-before-build against the procurement rules. It adds one principle its context needs, about offline access for rural schools, and gives every principle a written implication so the Board can use it to settle an argument. Progressa does not draft principles from scratch. It inherits the thinking and localises the wording. Then the heart of Adapt: for each building block, a deliberate sourcing call. Progressa's Learner Registry — build it properly, because it is the authoritative core nobody else can own. Identity — do not build; share the national Identity Authority's platform. Exam management — buy a mature market product, it is a solved problem. Data exchange — share the Digital Government Authority's backbone. A new analytics capability nobody is sure about — sandbox it first, before committing. Four kinds of decision, made on purpose, written down with a reason each. Notice the pattern in those calls. The default is reuse and share; build is the exception that must justify itself. This is the phase where the whole-of-government saving is actually chosen — a procurement rule could not make these calls, only an architect looking across the whole sector. Adapt ends with the third sign-off: the localised framework and the sourcing approach are approved. On Progressa, the Board signs the principle set and the build-buy-share-sandbox matrix. This is a consequential gate — it commits the shape of everything that follows. Approve it, and the roadmap has a clear set of decisions to sequence. Skip the deliberation, and every project re-litigates build-versus-reuse on its own, which is exactly the fragmentation the EA exists to prevent. ## Do this on your own sector — Build your sourcing matrix {% hint style="success" %} **🔍 Diagnostic play · produces A24 Sourcing matrix** **Bring:** the building blocks needed and the shared platforms that exist. From **A14 rev.2, BB status register, A15** (see [Your country workbook](/experience-digital-transformation/gea/your-country-workbook.md)). **Get:** a build/buy/share/sandbox matrix with flags. As text in the chat, not a file or a chart. **Time:** \~20 min · **Assistant:** any; the plays are tool-neutral. **With the kit:** no skill in this release, so the prompt runs bare in any assistant. **Watch for:** A BUY or BUILD that looks cheapest for one project may be costliest for the country. {% endhint %} 🔍 **Diagnostic play.** You paste a description of your situation; the play assesses it. **What it does.** An architect in the Adapt phase needs a deliberate build/buy/share/sandbox call for each building block, defaulting to reuse, with any 'build' that duplicates an existing shared block flagged. {% 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](/experience-digital-transformation/gea/start-here/how-to-use-the-plays.md). ``` Below are the building blocks [country X]'s [sector] sector needs [list them — e.g. identity, payments, a sector registry, a case-management system, data exchange] and the shared platforms that already exist nationally [list: national identity, payments, data exchange, any shared registries — or note if unknown]. Produce a sourcing matrix. For each building block, give a deliberate call — BUILD, BUY, SHARE or SANDBOX — defaulting to reuse and share, with one line of reasoning each. Flag any BUILD that duplicates an existing shared block, and any BUY that risks vendor lock-in. End with the one or two blocks that are the authoritative core worth building well. Output: a sourcing matrix (block / call / reason) plus the flags. ``` [Open in Claude](https://claude.ai/new?q=Below%20are%20the%20building%20blocks%20%5Bcountry%20X%5D%27s%20%5Bsector%5D%20sector%20needs%20%5Blist%20them%20%E2%80%94%20e.g.%20identity%2C%20payments%2C%20a%20sector%20registry%2C%20a%20case-management%20system%2C%20data%20exchange%5D%20and%20the%20shared%20platforms%20that%20already%20exist%20nationally%20%5Blist%3A%20national%20identity%2C%20payments%2C%20data%20exchange%2C%20any%20shared%20registries%20%E2%80%94%20or%20note%20if%20unknown%5D.%20Produce%20a%20sourcing%20matrix.%20For%20each%20building%20block%2C%20give%20a%20deliberate%20call%20%E2%80%94%20BUILD%2C%20BUY%2C%20SHARE%20or%20SANDBOX%20%E2%80%94%20defaulting%20to%20reuse%20and%20share%2C%20with%20one%20line%20of%20reasoning%20each.%20Flag%20any%20BUILD%20that%20duplicates%20an%20existing%20shared%20block%2C%20and%20any%20BUY%20that%20risks%20vendor%20lock-in.%20End%20with%20the%20one%20or%20two%20blocks%20that%20are%20the%20authoritative%20core%20worth%20building%20well.%20Output%3A%20a%20sourcing%20matrix%20%28block%20%2F%20call%20%2F%20reason%29%20plus%20the%20flags.) *(experimental deep link: pre-fills the prompt in a new claude.ai chat; check the bracketed parts before sending)* *Input, output and the kit skill are in the box above.* {% endtab %} {% tab title="Example on Progressa — coming" %} {% hint style="warning" %} **Worked example pending.** The prompt above is final and runs today. The Progressa worked example, the annotated reading and the what-next notes are added when this module's examples are run (Module 1 shows the shape). {% endhint %} Run the play on [Progressa](/experience-digital-transformation/gea/start-here/progressa-the-demonstration-country.md) yourself in the meantime: paste the sections named in **Bring** above, and read the result against **Watch for**. {% endtab %} {% tab title="What next" %} File the output as **A24** in your country workbook once you have worked it the way **Watch for** asks. A fuller what-next is added with the worked example. **This artefact feeds:** [4.5 Design a first-cut target architecture from your gaps](/experience-digital-transformation/gea/module-4-progressa-end-to-end-the-method-on-one-sector/4.5-phase-4-plan-design-the-target-architecture.md) See the full chain in [Your country workbook](/experience-digital-transformation/gea/your-country-workbook.md). {% endtab %} {% endtabs %} ## Sources * PAERA v1.0 §5.6 (Sourcing Strategy) — * PAERA v1.0 §5.2 (Principles) — --- # 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/gea/module-4-progressa-end-to-end-the-method-on-one-sector/4.4-phase-3-adapt-fit-paera-and-decide-build-buy-or-share.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.