# TSG Waterline: assumptions and their reasons

Cloud prices as of 2026-10-07; hardware as of 2026-10-10. All money is in US dollars. The tool can also show Australian dollars at the Reserve Bank of Australia's daily rate; that converts the display only and changes no comparison. Every figure below is a default that can be changed in the tool, and the organisations are illustrative, not empirical claims: every name is invented.

## Defaults and why they were chosen

### Working days per month

Days per month on which the organisation generates AI work. 22 is a normal working month; raise it for weekend or around-the-clock operations.

**Why this figure:** 22 for an organisation working a normal week. The organisations that run around the clock (the bank, insurer, hospital, university, online retailer, software company and energy retailer) use 30, because their customers and systems create work every day.

### Can wait hours for an answer (batch)

Whether this work can wait hours for an answer, like a back-office queue, rather than someone waiting on it. Work that can wait is charged the cloud’s batch price, and local hardware can run it at any available hour. Work that cannot wait pays the full cloud price, and local hardware serves it only in office hours. Set from the kind of work; change it to match yours.

**Why this figure:** Set from the kind of work: document intake, case assessment, long document review and compliance can wait; customer contact, drafting, knowledge search, code and custom work cannot.

### Cached share of input

The share of input tokens served from the provider’s cache, where the tier prices cached input separately. Repeated prompts and stable context raise it.

**Why this figure:** 30%: system prompts, shared documents and the earlier turns of a conversation are sent again with every call, and providers charge a fraction for the repeated part. An assumption, not a measured share: chat and code assistants often repeat more, one-off document work less.

### Batch discount

The discount a tier gives for work submitted as a batch instead of interactively, in exchange for a slower turnaround.

**Why this figure:** 50%: the discount major model providers publish for their batch services.

### Share of can-wait work sent via batch

Of the work marked as able to wait, the share sent through this tier’s batch service, which earns the batch discount. Work that cannot wait always pays the full price. 100% assumes all of it is batched, the same allowance local hardware gets for running it overnight.

**Why this figure:** 100% of the work marked as able to wait: the same allowance local hardware gets for running that work overnight, so neither side is favoured.

### Local can also take frontier work

The share of locally suitable frontier-routed work local may also take. Off by default: local is assumed to run commodity-class models. When the fleet is full, frontier work goes first, and it is credited at frontier prices. It is also assumed to succeed as often as it does on frontier cloud; models small enough to run locally often do worse on hard work, and the extra attempts are not counted.

**Why this figure:** 0 by default: hardware an organisation of this size can afford runs smaller open models than the frontier tier, and the tool has no measure of the quality lost. Raised, it credits that work at frontier prices with no allowance for weaker answers or extra attempts, so the result is a best case.

### Price per device, today

Street price per device in month 0, before any decline is applied. Devices bought later in the horizon are priced from this figure and the annual decline below.

**Why this figure:** Set by the hardware type. Desktop: the DGX Spark list price, US$4,699 since NVIDIA’s February 2026 rise. Two-GPU server: two RTX PRO 6000 Blackwell cards at about US$16,000 each in October 2026 listings, plus about US$18,000 for the server around them. Eight-GPU server: a typical integrated quote for an HGX H200 system, US$370,000, within a US$320,000 to US$420,000 range. Rented GPU: nothing to buy.

### Annual device price decline

What an equivalent device costs a year later. An assumption about future hardware, with the same standing as the cloud tiers’ own annual decline — not an observed rate.

**Why this figure:** An assumption, chosen so both sides of the comparison get cheaper over time, as the cloud tiers do through their own annual decline. For a rented GPU it is how fast the hourly rate falls.

### Annual throughput growth

How much faster a device bought a year later is, per device; devices already bought keep their speed. With the price decline it sets what the same money buys. An assumption about future hardware, not an observed rate. Held fixed, each refresh buys more capacity for the same money; buying to demand, it buys fewer devices.

**Why this figure:** With the 15% price decline, the same money buys about 35% more a year, close to the long-run trend in computing power per dollar, which has doubled every two to two and a half years. Devices already bought keep their speed; software gains on them are not counted, which favours the cloud slightly.

### Useful life (months)

How long a device stays in service before it is retired and replaced. Amortisation is spread over this period, and the replacement is bought on that month’s terms.

**Why this figure:** Five years, the owner’s choice: inference hardware keeps serving after it is written down for tax, and large cloud providers now depreciate servers over five to six years. Many enterprises refresh accelerators every three to four years; 36 or 48 shows the difference. A shorter life raises the monthly cost and brings replacements forward. A rented GPU is re-rented every 12 months.

### Residual value

What a device is assumed to be worth at the end of its useful life, as a share of what it cost. Amortisation stops at it, and it returns as cash when the device is replaced.

**Why this figure:** 15% of the purchase price comes back when a device is retired: an assumption. Five-year-old accelerators can sell for less, so a lower figure is a fair test. Rented hardware has none.

### Effective tokens per second per device

Effective combined input and output tokens per second per device, for a device bought in month 0. Real throughput varies with the model, quantisation, input/output mix, context length, batching and concurrency, often by more than ten times: 250 tok/s is a deliberately conservative placeholder for a mixed business workload, not a universal figure.

**Why this figure:** Input and output tokens together. In published benchmarks an H100 serving a 70B model with batching generates about 2,400 output tokens a second at 100 requests at once, and reads input far faster: about 6,000 tokens a second in all at this tool’s mix. Every hardware type takes half of a comparable figure, on purpose, because real throughput varies more than ten times with the model and the work: desktop 250, two-GPU server 3,600, eight-GPU server 36,000, rented H100 3,000. A figure measured on your own work beats any of these.

### Hours a day people need answers

Hours a working day in which work that cannot wait arrives: someone is waiting on the answer. Local hardware can serve that work only in these hours, so it bounds how much of the fleet it can use. 8 is an office day; organisations whose staff and customers work around the clock use 24.

**Why this figure:** 8 for an office day. 24 for the organisations that run around the clock, whose staff and customers work at all hours.

### Available hours per month

Hours a month the fleet is available to serve work. 176 is a working month of 22 eight-hour days; 730 is around the clock. It sets raw capacity, so it moves cost per token directly. Hours outside office hours serve only work that can wait.

**Why this figure:** 176 for a fleet used in office hours (22 days of 8 hours), 730 for one left on around the clock, as the round-the-clock organisations’ fleets are.

### Headroom cap (max usable utilisation)

The largest share of raw capacity you are willing to schedule, leaving headroom for bursts. This is an input, and is not the utilisation the model reports achieving.

**Why this figure:** 70%: room left for bursts. Demand here is a monthly average, and work arrives unevenly through the day.

### Idle power (W)

Board power drawn when the device is on but not working. Energy cost interpolates between idle and peak by duty cycle, so an under-used fleet costs less to run than a saturated one.

**Why this figure:** Set by the hardware type: desktop 60 W, two-GPU server 300 W, eight-GPU server 2,000 W (measured HGX H200 systems idle above 2 kW). In the hourly rate for a rented GPU.

### Peak power (W)

Board power drawn under sustained load. With duty cycle, it sets the electricity bill.

**Why this figure:** Set by the hardware type: desktop 240 W, two-GPU server 1,800 W, eight-GPU server 10,000 W (measured HGX H200 systems peak above 10 kW). In the hourly rate for a rented GPU.

### Electricity price (per kWh)

Commercial electricity price. As region- and contract-dependent as the token prices, and just as much a placeholder — it is often the largest running cost after amortisation.

**Why this figure:** US$0.32 a kWh: an illustrative commercial tariff. Power prices vary widely by region and contract.

### Energy overhead multiplier (PUE)

Cooling and power-conversion overhead on top of board power. 1.0 assumes none, which suits desk-side devices more than a rack.

**Why this figure:** Set by the hardware type: 1 for a desktop in an office, 1.2 for a server room, 1.4 for a data centre (its power usage effectiveness). In the hourly rate for a rented GPU.

### Annual maintenance (share of hardware cost)

Annual maintenance and support allowance, as a share of what the hardware cost. Charged monthly against each cohort’s own purchase price.

**Why this figure:** Set by the hardware type: 5% for a desktop, 8% for the two-GPU server and 10% for the eight-GPU server, covering a support contract and, for the larger server, rack space. None for a rented GPU.

### People and operations (per month)

People and running overhead for the whole fleet, each month any device is in service: setting up and updating models, monitoring, patching, security and fixing what breaks. A flat amount, because the first device carries most of the work. Set by the hardware type; at 0, people costs are not counted at all and the answer says so.

**Why this figure:** Set by the hardware type, as a share of an engineer’s time at roughly US$15,000 a month: a desktop fleet US$300 (a few hours a month), a two-GPU server US$1,500 (a tenth), an eight-GPU server US$4,000 (a quarter, with on-call), a rented GPU US$500 (the provider looks after the hardware). It is the cost that moves the answer most, so your own figure matters more here than almost anywhere else.

### Hardware type

The kind of hardware: a desktop device, a two-GPU server or an eight-GPU data-centre server bought outright, or a data-centre GPU rented by the hour. Choosing one fills in its price, speed, power and running costs, all illustrative orders of magnitude to replace with your own. A rented GPU has nothing to buy or resell: it is paid for every available hour, and payback then compares rent with the cloud cost it saves.

**Why this figure:** Desktop is the default: the smallest purchase that runs a useful model, so the tool starts from the cheapest way in. The servers suit organisations whose work fills them. Each sample organisation starts on the type that pays back soonest for it, its fleet sized to its work, or on desktops when none pays back. With people costs counted that is desktops for all of them: a server needs more looking after, and their work fills only part of one. Each type’s figures, and where they come from, are under each input.

### Rent per device-hour

What one rented device costs an hour, charged for every available hour, falling each year by the device price decline. 0 for hardware you own. With a rented device, set the price per device to 0.

**Why this figure:** US$3.50 an hour for an H100: on-demand rates on specialist GPU clouds ran US$2.60 to US$3.99 in October 2026, and the median across all providers, large cloud platforms included, was US$5.00.

### Discount rate for discounted payback (annual)

The return a finance team expects from money spent now, used to shrink savings that arrive later. The discounted payback counts each month’s savings and costs at what they are worth today, so it comes later than the cash payback. It leaves out the cost of capital, which would count the same thing twice. 8% is an illustrative hurdle rate; it moves no cost, only the discounted payback.

**Why this figure:** 8%: a typical hurdle rate for a capital purchase. Your organisation’s own rate belongs here.

### Cost of capital (annual)

What the money tied up in hardware costs you: the interest if it is borrowed, or the return it could have earned elsewhere. Charged each month on the value not yet written off. The purchase price is already counted as cash when the device is bought, so this is the cost of having that money tied up, not a loan repayment. 0 ignores it.

**Why this figure:** 0: the hardware is paid for from cash, with no charge for the money tied up in it. The discounted payback already allows for the time value of money.

## Hardware types

- **Desktop device:** A DGX Spark-class desktop inference device, bought outright.
- **Two-GPU server:** A two-GPU server (RTX PRO 6000 Blackwell class, 96 GB each), bought outright: sized between a desktop and a data-centre server, for an organisation whose work outgrows a few desktops. It sits in a server room or a rack.
- **Eight-GPU server:** An eight-GPU H200-class data-centre server, bought outright and run in a rack: much faster per device, far dearer, with data-centre cooling and a support contract.
- **Rented GPU:** One H100-class data-centre GPU rented by the hour from a GPU cloud: nothing to buy, resell or power, paid for every available hour, and re-rented each year at that year’s speed and price.

| Type | Price | Rent | Tokens a second | Useful life | People and operations |
| --- | --- | --- | --- | --- | --- |
| Desktop device | US$4,699 | none | 250 | 60 months | US$300 a month |
| Two-GPU server | US$50,000 | none | 3,600 | 60 months | US$1,500 a month |
| Eight-GPU server | US$370,000 | none | 36,000 | 60 months | US$4,000 a month |
| Rented GPU | none (rented) | US$3.50 an hour | 3,000 | 12 months | US$500 a month |

## Cloud price tiers

Prices per million tokens, the median list price of a basket of current models as of 2026-10-07. The tiers stand for two price levels, not two products.

| Tier | Input | Output | Input from cache | Batch discount | Price fall a year | Basket |
| --- | --- | --- | --- | --- | --- | --- |
| Frontier | US$2.00 | US$10.00 | 30% | 50% | 25% | Anthropic Sonnet, OpenAI Sol, Google Gemini Pro, xAI Grok |
| Commodity | US$0.30 | US$1.20 | 30% | 50% | 20% | Anthropic Haiku, OpenAI Luna, Google Gemini Flash, Qwen Flash, DeepSeek Flash |

## Sample organisations

### Riverbend Community Care (Charity, 85 staff)

Every grant application runs to 40 pages, and each funder wants the same outcomes told their own way, so drafts go round and round. A shared inbox takes over a hundred donor and client emails a day. Caseworkers write up visit notes after hours. There is no capital budget; hardware waits for a grant that covers it.

Adoption profile: Funding-constrained. Hardware no local hardware by default.

### Parlour & Pine (Creative agency, 60 staff)

Every campaign needs dozens of headline and caption variants, and most are thrown away: "make another version" is the biggest line on the bill. The developers build client sites with an assistant open all day. The studio adopts every new tool early, because its pitch is being first.

Adoption profile: Progressive. Hardware no local hardware by default.

### Harbourline Bank (Retail bank, 6,000 staff)

The contact centre handles 20,000 chats a day and summarises every call. Developers lean on assistants across hundreds of systems. Fraud analysts ask the model to reason through each anti-money-laundering alert. New customers send passports and payslips as phone photos, and every page is read. Customer data cannot leave the bank's control without a fight with the regulator.

Adoption profile: Regulated / privacy-led. Hardware starts on: Desktop device.

### Southerly Mutual (Insurer, 3,000 staff)

A claim arrives as a form, eight photos and a medical report. Staff search policy wordings all day for what is covered. Underwriters read 30-page submissions, and the model reasons through each one. The few engineers who could tune these workflows are always needed somewhere else.

Adoption profile: Skills-constrained. Hardware starts on: Desktop device.

### Ashcombe Reid (Law firm, 300 staff)

A single dispute means tens of thousands of documents to sort for relevance. Contracts run to 60 pages, and each review reasons clause by clause. Lawyers turn every six minutes of work into a billing narrative. Client confidentiality means documents stay on the firm's own systems where they can.

Adoption profile: Regulated / privacy-led. Hardware starts on: Desktop device.

### Tally & Vane (Accounting firm, 400 staff)

Thousands of invoices and receipts arrive as scans each week. Audit teams test samples against controls, and tax research memos draw on long rulings. The partners fund change from cost savings, at the pace the savings arrive.

Adoption profile: Steady. Hardware starts on: Desktop device.

### Eastvale Health (Hospital network, 4,000 staff)

Every patient encounter becomes a clinical note and a discharge summary. Coders turn notes into billing codes. Patient data is sensitive, which makes where the work runs a question in itself. Patient records have to stay inside the network.

Adoption profile: Regulated / privacy-led. Hardware starts on: Desktop device.

### Northgate Shire (Local council, 900 staff)

One development application is 40 scanned pages of plans, reports and objections. Residents send hundreds of requests a day about potholes, bins and noise. A single freedom-of-information request can mean reading through years of email. Spending goes through annual budget rounds, and hardware is a capital bid.

Adoption profile: Funding-constrained. Hardware no local hardware by default.

### Kestrel University (University, 5,000 staff)

Tutors give feedback on thousands of assignments a week. Students ask the same enrolment questions in a hundred ways. Researchers draft long grant applications. Central IT moves at the pace of the committee cycle.

Adoption profile: Steady. Hardware starts on: Desktop device.

### Brightcart (Online retailer, 1,500 staff)

Customer chat runs around the clock. Every new product needs a description written from a photo and a spec sheet. Reviews and returns notes are read for patterns. Margins are thin, so each change has to pay for itself.

Adoption profile: Steady. Hardware starts on: Desktop device.

### Loopwright (Software company, 400 staff)

Coding agents loop: read the codebase, change it, run the tests, read the failure, try again. Each task sends tens of thousands of tokens of context, many times over. This is the heaviest use per person of any organisation here. The engineers optimise their own tools as a matter of pride.

Adoption profile: Progressive. Hardware starts on: Desktop device.

### Coastline Energy (Energy retailer, 4,000 staff)

Every customer call is summarised for the next agent. Billing disputes need the account history read in full. Field crews send photos and short notes from every job. IT skills are scarce, and the outage crews come first.

Adoption profile: Skills-constrained. Hardware starts on: Desktop device.

## How the model works: What this is

### What this tool is not

It is not advice, and it produces no recommendation: it states what follows arithmetically from the assumptions on screen. It is not a vendor comparison: products are named only to give a default its scale, such as a DGX Spark-class device or the leading Claude, GPT or Gemini tier, never to rank them. It is not a full costing of running hardware in production: rack space, networking, spare devices and procurement time are left out. It is not a costing in Australian prices: A$ converts US-dollar figures at the published rate. It is not a forecast, because every price, growth rate and decline rate in it is an editable assumption rather than an observation. Its usefulness depends entirely on replacing the shipped placeholders with figures from your own quotes and measurements.

### Local inference is not repatriation

Running inference on your own hardware does not mean moving enterprise systems or authoritative data out of the cloud. A single request can travel through a local model and still read cloud-hosted data, call cloud APIs and write back to cloud systems of record. This model only ever moves the inference step, and only for work marked suitable for it. Identity, storage, databases and applications can all stay exactly where they are.

### Strategic value, and why it is kept outside the financial comparison

Data residency, latency, independence from a vendor and control over model versions can all matter, and none of them has a defensible market price. The tool lets you attach a monthly figure to them, keeps it visually separate from the financial case, and never folds it silently into the headline comparison. Any figure entered there is your estimate rather than a derived result.

## How the model works: Tokens and prices

### Tokens, and why input and output are priced differently

A token is roughly three quarters of a word. Every request has an input side — the prompt, the context, the retrieved documents — and an output side, the generated answer. Providers charge more for output than input, typically three to five times more, because generating is more expensive than reading. A workload that reads a lot and writes a little therefore costs far less per token than its total volume suggests, and the preset mixes here are input-heavy.

### $/MTok — the unit both sides finally report in

Cloud providers quote dollars per million tokens. Hardware quotes tokens per second and a purchase price. Those cannot be compared until both are expressed the same way, so the model converts the fleet into dollars per million tokens actually served: everything the hardware costs in a month, divided by the tokens it processed that month. That is why an under-used fleet has a high figure — the cost is spread over fewer tokens — and why utilisation matters more than the sticker price.

### Frontier and commodity tiers are illustrative, not vendors

The two cloud tiers stand for two price levels, not two named products. Frontier is the most capable and most expensive class of model; commodity is the cheaper, widely available class that most routine work can use. No vendor is named anywhere in this tool, and the prices shipped are placeholders you are expected to replace with the ones you are actually quoted.

### Routing: which work can run locally at all

Each workload carries a complexity, which decides whether it routes to the frontier tier or the commodity tier, and a separate flag for whether it is suitable for local inference. By default local hardware draws only on commodity-routed, locally suitable work, and the frontier price appears as a benchmark in comparisons rather than as a substitution the model makes. Raise “Local can also take frontier work” and local may also take a share of locally suitable frontier-routed work: it is served first when the fleet is full, and credited at frontier prices.

### Why cloud prices decline, and why hardware does too

Each cloud tier carries an annual price decline, so a token bought in month 48 costs less than the same token in month 0. Hardware gets the same treatment: an annual device price decline and an annual throughput growth rate, so a device purchased three years into the horizon is priced and specified as the device available then, not the one on sale today. Without both sides moving, the comparison would quietly favour whichever side was allowed to improve.

The annual decline applies to each tier’s list price, and list prices fall slowly: a new top model tends to launch at much the same price as the one it replaces. The price of a fixed level of capability falls far faster, by tens of times a year in published analyses, because work that once needed the top tier can later run on a cheaper one. In this model that faster effect appears as routing, as work moves from the frontier tier to the commodity tier, rather than as a steeper price decline.

### Australian dollars are a display, not Australian costs

The model runs in US dollars: the cloud prices it compares against are billed in US dollars, and the hardware defaults are US list prices. Choosing A$ converts every figure on screen, and every money input, at the Reserve Bank of Australia's published rate, which is shown with its date beside the switch. Both sides of every comparison are converted by the same rate, so the rate changes no answer: payback, break-even, the cost ratio and every flip point are the same in either currency. A shared link keeps the rate it was made with, and can be switched to today's.

What A$ does not do is price things the Australian way. Hardware bought in Australia usually costs more than its converted US list price, and Australian tariffs and wages differ again. Those are inputs like any other: an Australian quote entered with A$ selected is stored and shown as entered.

## How the model works: Hardware

### Capacity, duty cycle, the headroom cap and utilisation are four different things

Raw capacity is every token the fleet could process in a month if it ran flat out during its available hours. The headroom cap is an input: the largest share of raw capacity you are willing to schedule, leaving room for bursts. Duty cycle is what actually ran, as a share of raw capacity, and it is what drives the electricity bill. Utilisation, reported separately, measures served work against usable capacity rather than raw. Four similar-sounding quantities, none interchangeable.

Not every hour of capacity serves every kind of work. Work someone is waiting on (a customer reply, a search, help with code) arrives in the hours people work, so local hardware can serve it only then: an office day, or around the clock for an organisation that runs that way. Work that can wait hours for an answer (a document queue, a compliance check) can run at any available hour, overnight included. The same split applies in the cloud: work that can wait is sent through the batch service at its discount, and work that cannot pays the full price. A fleet left on around the clock is only fully used if enough of its work can wait.

### Achieved utilisation is an output, not an input

The headroom cap you set is a ceiling on what the model will schedule. The utilisation reported beside the figures is what the workload actually demanded of the fleet that month. They share a word and are not the same quantity: one is an assumption you choose, the other is a result you read. A fleet sized for a later year spends its early months at low achieved utilisation, which is visible rather than hidden.

### Spillover, when the fleet cannot serve demand

If locally suitable demand in a month exceeds what the fleet can schedule within its headroom cap, the excess does not vanish and does not queue. It is bought from the cloud tier it was routed to instead, and reported as spill. A month with spill means the local price you are reading covers only the share the fleet served; the rest was bought at cloud prices.

### Amortisation, residual value, and what "cost per month" includes

A device is paid for once and used for years, so the monthly local cost spreads the purchase across the useful life rather than charging it all in the month of purchase. Amortisation stops at an assumed resale value, which comes back as cash when the device is retired and replaced. The monthly figure also carries electricity, a maintenance allowance as a share of hardware cost, a flat monthly amount for the people who run the fleet, and a cost of capital if a rate is set: what the money tied up in hardware could have earned, or costs to borrow, charged on the value not yet written off. The people cost is set by the hardware type, from a few hours a month for a desktop fleet to a quarter of an engineer for a data-centre server; at 0, the time spent updating models, monitoring, patching and fixing things is not counted, and owning looks cheaper than it is. Not modelled at all: rack or data-centre space, networking, spare devices for failover, and the time it takes to buy hardware. A rented GPU has nothing to amortise or resell: its rent is paid for every available hour instead, and counted the same way in cash and accruals. Payback, by contrast, is measured on cash rather than accruals.

## How the model works: Payback

### Payback, and why "never" is a legitimate answer

Payback is the time from the first hardware purchase to the month when the cash spent on hardware is first exceeded by the cloud spend it avoided, so it is stated as months after purchase. If the cloud price it displaces is low enough, that crossing never happens inside the horizon, and the tool reports exactly that rather than extrapolating past the period you asked about. A blank or "not within four years" is a real finding, not a missing number. When payback comes later than the hardware’s useful life, the answer says so: by then the first devices have been replaced, and the cash spent on their replacements counts too.

### Break-even utilisation, and when it is out of reach

Break-even utilisation is the share of usable capacity the fleet would have to serve for its cost per token to match a cloud tier. Read it beside the utilisation actually achieved: if break-even needs more than 100%, no amount of demand closes the gap within the headroom cap, and the tool says so. Against a cheap commodity price the required figure is often far above what any workload could deliver.

### What moves the answer, and where it flips

"What moves the answer" re-runs the whole scenario with one input at a time halved and doubled, everything else held as set, and draws how far local cost moves against cloud. The longest bar is the input the answer is most sensitive to. Half to double is a range for seeing sensitivity, not a claim about how far any input will actually move.

Where a bar crosses "same cost", the tool searches for the value at which local and cloud cost the same, to within 1%, and labels it: local stays cheaper until electricity rises to a stated price, for example. That is a threshold, not a forecast. It says how far an assumption would have to be wrong for the answer to change. A probability would need a likelihood for every input, and those likelihoods would be invented, so the tool shows thresholds instead.

## How the model works: Time and adoption

### Horizon and ramp — why month 48 is not a forecast

The horizon is how far the scenario runs. The stage ramps describe how the optimisation levers come in, and AI activity grows at its own annual rate. All of these are assumptions you set. The figures at the horizon are therefore the arithmetic consequence of the inputs you chose, not a prediction about that month. Stage months are calendar months: a longer horizon shows more of the same months rather than stretching them, and a stage that starts after the horizon is not shown. Changing the ramp shape or the annual activity growth changes the answer, which is the point: the tool is for testing what follows from a set of beliefs.

### How the five adoption profiles differ

A profile sets how fast and how far an organisation optimises. The organisation sets what the work is; the profile sets how it goes about improving it. "Stages end" gives the calendar months the first three stages end on, which stay put whatever the horizon, then how fast routing keeps improving afterwards. "How far" is how far workflow optimisation, routing to cheaper models and moving work onto local hardware each go. Every value is an illustrative assumption and can be changed after a profile is picked.

| Profile | Why | Stages end | How far: workflow · routing · local | Default for |
| --- | --- | --- | --- | --- |
| Progressive | Competitive edge; has the people and the budget. | 3 · 9 · 18, then fast | high · high · medium | Parlour & Pine, Loopwright |
| Steady | Cost discipline at a normal pace. | 6 · 18 · 30, then steady | medium · medium · medium | Tally & Vane, Kestrel University, Brightcart, generic and custom |
| Funding-constrained | Lives on grants; capital spending waits for a funding round. | 6 · 24 · 40, then slow | medium · high · low | Riverbend Community Care, Northgate Shire |
| Skills-constrained | Can't hire or keep the engineers optimisation needs. | 9 · 30 · 42, then slow | low · medium · low | Southerly Mutual, Coastline Energy |
| Regulated / privacy-led | Data has to stay in-house wherever possible. | 6 · 18 · 30, then slow | medium · medium · high | Harbourline Bank, Ashcombe Reid, Eastvale Health |