> 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/ai-wallet-use-case/chapter-06-replication-and-sustainability.md). # Chapter 06: Replication and Sustainability This closing chapter addresses the question the Knowledge Product exists to answer: how another country, ministry, or implementer takes what has been demonstrated and makes it their own. It sets out what standardises across deployments and what must be localised, provides a country-tailoring checklist and a replication sequence, describes the capacity building a local team needs, and records the licensing and stewardship arrangements that keep every artefact reusable after the contract ends. {% embed url="" %} ## 6.1 How to Replicate This Approach #### 6.1.1 What standardises and what must be localised The architecture was designed so that the expensive parts travel and the sovereign parts stay local. The dividing line follows the artefact separation established in Chapter 2 (Section 2.5.2): skill files carry provider knowledge, schemas carry data shapes, and rulebooks carry national policy. | Standardises across countries | Must be localised per country | | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | The open standards stack: W3C VC 2.0, SD-JWT VC, OpenID4VCI, OpenID4VP with DCQL, GovStack Wallet BB, ISO/IEC 27560, OpenAPI 3.1. | The national digital identity system: the live IdP replaces the sandbox mock, following the documented integration pattern. | | Provider-published skill files, unchanged: they target the provider's API, not any country's policy. | Rulebooks: the national qualification framework, issuer authorisation, guardian consent, payment, retention, and trust rules. | | The marketplace platform, its vetting pipeline, and its governance model. | Schemas: learner profile attributes, credential fields, and national identifiers within the vc-ed and Open Badges 3.0 alignment. | | The integration patterns of Chapter 4: backend proxy, HMAC-verified webhooks, SSE, and the UI-flow-first sequence. | The legal framework: data protection supervision, electronic signature law, and the mandate of each registry. | | The deployment machinery of Chapter 5: container images, the Helm chart, and the CI/CD workflow. | The hosting environment: sovereign, local, or hybrid cloud, plus the managed database and domain, certificates, and DNS. | | The learning pathway of this Knowledge Product, written for adaptation into video modules. | Language and branding: the strings-driven internationalisation and theme tokens of Chapter 4 (Section 4.5.3). | #### 6.1.2 Country-tailoring checklist A country adaptation works through the following checklist, in order: * Confirm the legal basis: Identify the authority for the learner registry, the recognised electronic signature regime, and the data protection obligations that will govern consent records. * Localise the rulebooks: Encode the national qualification framework, issuer authorisation rules, guardian and minor handling, fees, and retention into the rulebook artefacts, keeping them versioned and separate from code. * Localise the schemas: Adapt the learner profile and credential schemas to national attributes and identifiers while retaining the vc-ed and Open Badges 3.0 alignment so credentials stay portable. * Select wallet providers through the marketplace: Compare providers on a like-for-like basis against the same boundary conditions; any conformant provider's skills can replace another's, as Chapter 2 (Section 2.7) defines. * Wire the national building blocks: Replace the sandbox mocks one at a time: identity provider first, then trust services, payments, and the information mediator, each behind its documented contract. * Choose the hosting model: Sovereign, local, or hybrid cloud; the Helm chart and managed-database switch of Chapter 5 apply unchanged. * Run the AI integration assisted build: Install the chosen skills into the agents the local team already uses and rebuild the journeys against national systems, with every artefact reviewed as in Chapter 3 (Section 3.3.4). * Verify before launch: Run the end-to-end journeys against a real wallet, the capacity gate against the deployed stack, and an accessibility review of the portals. #### 6.1.3 The replication sequence In practice, the eight items above collapse into a short sequence for a competent team: stand up the marketplace (or point at a shared regional instance), install the provider skills, hand the agent the localised schemas and rulebooks together with the use-case prompts, and let the AI integration-assisted build of Chapter 3 produce the national application, which deploys with the Chapter 5 machinery. The demonstration website for Chapter 5 (Section 5.2.2) is the reference to measure against: a replication is complete when the four journeys of Chapter 1 run end-to-end against national systems. #### 6.1.4 Capacity building for local teams The approach changes the skills profile a country needs. Because the provider's knowledge arrives as skill files and the agent absorbs the routine integration work, the local team is small and senior rather than large and junior: | Role | Responsibility | Indicative profile | | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | System integrator with domain skills | Drives the AI integration-assisted build: installs skills, frames prompts, owns the use-case UI flow and the journey logic. | One or two engineers familiar with web development and the education domain. | | Reviewing engineer | Reviews every AI-generated artefact, owns security and privacy decisions, and signs off deliverables. | A senior engineer; may be the same person as the integrator in small teams, but review must be a distinct act. | | Platform operator | Operates the Kubernetes deployment, secrets, backups, and monitoring of Chapter 5. | A DevOps engineer with Helm experience. | | Ministry roles | Registrar, validation unit, and registration officers exercising the workflows of Chapter 4. | Existing administrative staff, trained on the portals. | \ The Knowledge Product doubles as the training curriculum: its chapters map directly onto the learning objectives, from usecase scope and registry specification through low-code configuration, DPI integration, and cloud deployment. It is written so that a separate production team can adapt each section into the corresponding video module without further input from the original authors or any single service provider. ## 6.2 Open Source and Licensing Licensing is arranged so that nothing in the Knowledge Product locks an adopter to any party, that proprietary components be identifiable and carry exit options: | Artefact | Licence | Notes | | ------------------------------------------------------------------------------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Knowledge Product content (all chapters and annexes) | CC BY 4.0 | Free to translate, adapt, and republish with attribution, including adaptation into video learning modules. | | Marketplace platform and prototype source code | Apache 2.0 | The repository including the Helm chart, test suites, and CI/CD workflow. | | Provider skill bundles (the prototype provider's included) | Apache 2.0 | Each provider maintains its own in a public repository and publishes to the marketplace. | | Schemas and rulebooks | Apache 2.0 (with CC BY 4.0 documentation) | Designed to be forked and localised per country. | | GovStack Wallet BB OpenAPI contracts | Open specification | Reusable directly from the GovStack specs-as-code pipeline. | | Wallet products used in the prototype (iGrant.io Organisation Wallet Suite and Data Wallet) | Commercial products, used during the project term | Replaceable by any provider meeting the boundary conditions of Chapter 2 (Section 2.7); self-hosting is documented by the provider (docs.igrant.io). | \ The wallet products are the only components that are not open source, and they sit behind the vendor-neutral boundary the whole architecture enforces: the GovStack Wallet BB roles, the OpenID protocol surfaces, and the OpenAPI contracts. The exit option is structural rather than contractual, since another provider's skills can be installed against the same boundaries. ## 6.3 Post-Contract Sustainability #### 6.3.1 Repository stewardship At handover, the repositories (platform, prototype, schemas, rulebooks, and the published skill bundles) transfer to stewardship under a Giga or ITU GitHub organisation, with the sandbox deployment reproducible by any operator from the Helm chart and CI/CD workflow of Chapter 5. A documented contributor guide accompanies the transfer so that vendors and governments can extend the prototype through the ordinary open-source route of issues and pull requests. #### 6.3.2 The marketplace as the sustainability mechanism Sustainability is designed into the marketplace model itself rather than depending on any single maintainer. Each wallet provider maintains its own skills against its own API, so the catalogue stays current without central effort; the two-gate vetting pipeline of Chapter 3 keeps quality independent of who submits; and the Official and Community endorsement split lets the steward signal maturity without blocking contribution. A provider leaving the ecosystem strands nothing: its published bundles remain forkable under their open licences, and competing providers meet the same boundaries. #### 6.3.3 Roadmap beyond education The education usecase is the first demonstration, not the limit. The same pattern - a sector usecase expressed as journeys, provider skills from the marketplace, localised schemas and rulebooks, and an ai assisted build validated at open-standard boundaries - extends directly to health credentials (vaccination and professional registration), social protection entitlements, and professional licensing. Each new sector reuses the marketplace, the governance pipeline, the deployment machinery, and the replication method of this chapter; what changes is the domain model and the rulebooks. That is the intended trajectory for the Knowledge Product after handover: a growing catalogue of sector usecases on a shared, open, vendor-neutral foundation. --- # 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/ai-wallet-use-case/chapter-06-replication-and-sustainability.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.