> 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/describe-the-workload-before-comparing-models.md). # Describe the workload before comparing models The unit of decision is a workload. In this article, a workload means the actual public service or technical component, together with the data, people, interfaces, operating constraints, and public obligations that make its hosting decision specific. A permit portal, a registry, an identity component, or a shared notification service is more than software. Each has users and staff, data and records, links to other systems, demand patterns, accessibility needs, service objectives, and rules and policies about what it may do. This definition gives a team something concrete to examine. A public information site with a predictable audience has a different operating profile from a case-management service that holds sensitive records and must remain usable around a statutory deadline. A shared identity component has a different failure consequence from a single departmental reporting tool. The institution should describe the impact of failure, acceptable interruption, recovery time and recovery point objectives, required alternative routes, data and records obligations, interfaces, operating roles, and demand pattern before deciding where the workload might run. ![Three-stage public-service workload inquiry. Service facts include public purpose, criticality, data and records, integration, demand and change, and continuity. These lead to institutional tests of jurisdiction, accountability, capability, contracts, cost, connectivity, and exit, ending with questions to assess.](https://1406653965-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkZFMZ3jCMUwHtTN0sL4J%2Fuploads%2Fgit-blob-5a49e56c1a7a8b5334c3bf693421a5a6146dc01b%2Ffinal.png?alt=media) That description also exposes uncertainty early. A team may know that support is ending but not know every integration, who owns a key interface, or whether a backup can be restored. It can record those gaps and decide whether discovery, redesign, a limited pilot, or retention is appropriate. Treating unknown dependencies as a reason for more evidence is more useful than treating them as an argument for or against cloud. Once there is enough evidence to compare arrangements, the team needs to keep three decisions separate. Otherwise, a label such as “private cloud” or “SaaS” can be made to carry claims about control, responsibility, or operating capability that it cannot establish. --- # 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/describe-the-workload-before-comparing-models.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.