> For the complete documentation index, see [llms.txt](https://help.resouris.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.resouris.com/how-it-works/cost-model.md).

# Cost model

ReSouris expresses capacity in money as well as in sessions. This page explains what it configures, what it computes, and — most importantly — what it refuses to compute.

Read this before showing a cost figure to anyone who will ask where it came from.

***

## What a "cost" means here

Every money figure in ReSouris is the **employer cost of time**. Nothing else.

```
hourly cost  =  annual figure for the grade
                × (1 + on-cost percentage)
                ÷ productive hours per WTE year
```

It is deliberately **not**:

* what any individual is paid — the calculation uses the range for a grade, never a person's record;
* a price, a tariff, or a charge;
* an estimate of the value of the activity.

Configure it at **`/ui/admin/cost-model`**, gated on `admin.cost_model.write` (held by `tenant_admin`). ⓘ There is no separate *read* permission: that one permission gates the configuration screen itself, while the cost figures appear on other surfaces under their own gates. The separation is real but it is between **screens**, not between a read and a write permission — which is what you want, because changing the model changes the basis of every figure already on a page, and in a trust finance sets the model while operations reads the output.

***

## The three things you configure

### 1. Grade cost ranges, as periods

A grade's cost is a **spell**, not a fact. Pay scales change every April, so each range carries `effective_from` / `effective_to` and the system reads the one in force for the date being costed.

This is why last quarter's figures stay reproducible after an uplift. A model that overwrote the range in place would silently rewrite history, and the business case you presented in March would no longer reconstruct.

Each range carries a **source note**. Fill it in. A rate with no provenance is indistinguishable from a guess six months later, when the person who entered it has moved on.

### 2. The on-cost percentage, and its basis

On-cost covers employer National Insurance, pension contribution and any other employer-borne addition. The percentage is yours to set.

The **basis** matters as much as the number, and the two travel together:

* **`trust_cash`** — what the money actually leaves the organisation as. This is what a finance director means by cost.
* **`national_economic`** — the wider economic cost, used where an organisation accounts that way.

Those two are the whole set; the field refuses anything else.

Recording the basis alongside the percentage means a reader can tell whether your 27.5% is comparable with another department's 30%. Without it they cannot, and will assume it is.

### 3. Productive hours per WTE year

The denominator. Contracted hours minus leave, statutory days, mandatory training and expected absence — what a whole-time equivalent is actually available to deliver in a year.

This single number moves every hourly figure in the system proportionally. A department using 1,650 and one using 1,800 will report costs that differ by 9% for identical work. If you are comparing departments, compare this first.

***

## Unknown propagation — the rules that matter most

The system's behaviour when it *cannot* compute something is more important than its behaviour when it can. Three rules, applied without exception.

### An unpriced grade stays unpriced

Training grades and non-Agenda-for-Change roles frequently have no published range. ReSouris records that as **unknown** and never substitutes a plausible figure.

A fabricated number is worse than a gap in exactly the way that matters: the gap prompts a question, and the number does not. Somebody will build a case on it, and the first person to check will find it has no source.

### A partial total is never presented as a total

If any worker in a session is unpriced, the **session cost is unknown** — not the sum of the ones that happened to be priced.

This is the rule people find most surprising and it is not negotiable. A partial sum looks complete, is smaller than the truth, and carries no indication of what is missing. Where this bites, the surface names how many workers were unpriced so you can see the size of the hole rather than inferring it.

### Money is a band, and midpoints are not invented

A grade's cost is a range, so a figure derived from it is a range. Where a single number must be shown — a stored total, a comparison — the surface states which end of the band it used and why.

The convention is to use the **top** of the band for anything that reads as a business case, so that a proposal which still pays back does so on the pessimistic reading. Flattering the figure is the one direction a case must never lean.

***

## What reads the cost model

* **Throughput** — indicative cost per attendance against delivered activity.
* **The revision diary** — per-session cost, with the breakdown.
* **Training impact** — the price of a competency, derived from the cost of the supervised time it takes, and the comparator it is set against.

All three inherit the rules above. If the cost model is unconfigured or the master switch is off, those surfaces render "unknown" rather than a figure — which is correct, and is a poor demonstration. Configure it before you show the system to anybody.

***

## Vocabulary

Cost surfaces never use pay vocabulary — no *salary*, *pay*, *payroll*, *wages*, *remuneration*. Not squeamishness: a figure labelled with those words reads as a statement about an identifiable person's earnings, which is not what it is and not something a roster tool should appear to publish.

Every rendered figure is called **indicative**. This is enforced by a test rather than left to reviewers, because it is the kind of qualifier that quietly falls off a page during a redesign.


---

# 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://help.resouris.com/how-it-works/cost-model.md?ask=<question>&goal=<user_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.
