> 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/cloud-for-dpi/chapter-1/use-a-route-not-a-label.md). # Use a route, not a label The decision matrix below turns common service conditions into starting routes. It does not select an arrangement automatically. A route only remains credible after the authority tests its obligations, digital sovereignty, continuity, cost, dependencies, and exit position. ![Decision matrix that routes public-service conditions to a starting arrangement. A stable specialised service with sustained operational capability routes to owned, colocated, or managed hosting, with a self-operated, managed, or mixed model. Variable demand or a custom service with a clear benefit from managed components routes to public cloud, then IaaS or PaaS, with mixed or managed operation. A standard function that meets requirements routes to SaaS, with authority governance of configuration, identity, records, support, export, and continuity. A transition or necessary specialized dependency routes to hybrid operation and a phased mixed model. A need for more than one provider routes to multi-cloud only where there is a defined capability or diversification need and tested recovery. Every route passes through a control gate: public accountability and digital sovereignty, lawful control, real choice, technology visibility, retained competence, recovery, evidence, data export, supplier dependency, and exit.](https://1406653965-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkZFMZ3jCMUwHtTN0sL4J%2Fuploads%2Fgit-blob-64e55db121c41f9d5ffa6804baf1505abb7c8f6d%2Ffinal.png?alt=media) ## Make the choices in order Start with placement: where will the workload and its data-processing components run? The question is not whether public cloud is modern or private cloud is safer. It is whether the selected environment can meet location, connectivity, integration, performance, recovery, maintenance, and lifecycle requirements, and whether the authority can govern the supplier, cost, and exit dependencies it creates. Hybrid and multi-cloud are combination patterns, not peer locations. They need a stated purpose and tested arrangements for identity, data flows, monitoring, backup, incident response, records, and recovery across the resulting boundaries. Then choose the service layer: which parts of the stack will the provider manage? IaaS, PaaS, and SaaS move technical work and evidence requirements between the authority, its partner, and the provider. They do not move public accountability. The test is whether the required controls, configuration authority, evidence, data export, recovery, and migration remain practical at the chosen layer. Then define the operating model: who performs the work, and who retains the capability to direct it? The authority may operate the service, use a managed partner, outsource defined work, or combine these models. The arrangement needs named owners for service decisions, controls, incidents, recovery, supplier oversight, and cost, together with enough retained competence to interpret evidence, direct recovery, and improve the service. A mixed model should identify the boundary of delegated work rather than imply diluted accountability. Digital sovereignty tests all three choices. It is not a deployment model and it is not established by private cloud, local hosting, data residency, or a national provider alone. It asks whether the authority can meet applicable legal and jurisdictional requirements, exercise real choice, see and influence critical technology, and retain the competence to operate, recover, change, or leave the arrangement. Recovery, evidence, data export, supplier dependency, and exit should be tested across the complete arrangement. The permit service could run in a public cloud, use PaaS for its database and integration, and be operated by a mixed internal and managed team. It could instead be SaaS, while its immediate decision is about configuration, identity, records, support, and export rather than virtual machines. Keeping placement, service model, sourcing, and practical control separate prevents a label from carrying claims it cannot support. --- # 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/cloud-for-dpi/chapter-1/use-a-route-not-a-label.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.