> 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/readme.md).

# Overview

**ReSouris** is a clinical **resource management** platform. It manages the resources a clinical department depends on — **people, spaces, equipment, competencies, and time** — and matches them against demand. The published roster is one output; the fuller value is a live, queryable, auditable model of your clinical workforce and estate.

It replaces spreadsheet rostering, ad-hoc email chains for sickness cover, and the four or five separate trackers most departments keep for training, CPD, accreditation renewal, room bookings, and equipment fitness. It runs as a shared cloud service, self-hosted on your infrastructure, or fully air-gapped. Every decision — allocation, absence, competency change, room reassignment, sickness re-plan — is logged into a tamper-evident audit chain.

## Three audiences, three entry points

This site serves three distinct audiences. Pick the guide that matches yours:

* **Clinical leadership** (Chief Medical Officer, Head of Department, Head of Nursing / Workforce, IT Director) — you want the mental model, the compliance posture, and evidence that fairness in allocation is defensible. Start with [What ReSouris manages](#what-resouris-manages) below → [Equity and fairness model](/how-it-works/equity-model.md) → [Audit and compliance](/part-2-running-resouris/audit-and-compliance.md).
* **Roster-area admins** — you author service lines, maintain the resource catalogues (staff, spaces, equipment, competencies), publish rosters, decide leave requests, and run the sickness-batch wizard. Start with [Getting started](/start-here/getting-started.md) → [Configuring a brand-new tenant](/start-here/getting-started.md#configuring-a-brand-new-tenant) if the tenant is new → [Quick start](/start-here/quick-start.md) → the [Guides](/set-up-what-you-schedule/create-a-service-line.md).
* **Clinical staff (workers)** — you view your roster, submit leave requests, keep your logbook, and see the team reporting structure through **My ReSouris**. Start with [Getting started](/start-here/getting-started.md#if-you-are-a-worker) → [Submit a leave request](/for-clinical-staff/submit-a-leave-request.md).

## What ReSouris manages

Resource management in a clinical department covers five interlocking asset classes. ReSouris holds a first-class model of each:

1. **People (workers).** Employment spells, effective-dated working patterns, competencies + skills + assessments, levels of attainment, training plans + job plans + CPD credits + accreditations, availability preferences + extended leave, line-management relationships including shared reporting, and worker self-service via the [My ReSouris portal](/start-here/getting-started.md#if-you-are-a-worker).
2. **Spaces and the estate.** A **Location → Space** hierarchy whose level names you choose — Areas, Buildings, Floors, ODS site codes — the Spaces catalogue, each space's weekly session pattern, space–service-line overrides, and fixed equipment held against a space. See [The estate](/how-it-works/the-estate.md) and [Spaces — the catalogue](/set-up-what-you-schedule/manage-spaces.md). ⓘ The screens say **Spaces**; older material and some table names say *rooms*.
3. **Equipment.** Equipment items, the skills needed to operate them, which service lines require them, and mandatory-equipment gating. See [Mandatory service lines and equipment](/set-up-what-you-schedule/equipment-mandatory-and-maintenance.md).
4. **Competencies and demand shape.** Service lines carrying per-competency splittability, on-call gates, Trust Admin scope, priority and a mandatory flag; the worker positions on each line with the competencies they require; and the competency demand each session has to satisfy. ⓘ A **clinic** used to be a second scheduling unit between the service line and the roster. It was retired in 2026-08 — say **service line** for the kind of work and **session** for one running of it.
5. **Time + audit trail.** Every state change on any of the above is logged into a tamper-evident audit chain (nightly seals, chained on export).

**Rostering is the output.** Given the resources on hand and the demand for a horizon, the constraint solver produces a defensible allocation — evidencing every decision against the tenant's allocation policy so a regulator can audit *why* worker X was assigned to slot Y over worker Z.

> ⓘ **Work first, fairness second — and it is enforced, not advisory.** The solver maximises four tiers in order and freezes each before moving on, so a fairness or preference weight cannot leave a session unstaffed at any magnitude. See [the decision order](/how-it-works/equity-model.md#the-decision-order).

Beyond the roster itself, the same model answers the questions a department is usually asked to evidence:

* **What is our capacity, and what is limiting it** — [What is stopping us](/understand-your-capacity/find-the-constraint.md), [Throughput and attendance](/understand-your-capacity/throughput-and-attendance.md), and the [cost model](/how-it-works/cost-model.md) with its [staffing rate card](/reference/rate-card.md).
* **What would training or recruitment buy us** — [Training impact and capacity economics](/understand-your-capacity/capacity-economics-and-attainment.md), measured as a counterfactual against the real estate rather than estimated.
* **Is the job-planning position defensible** — the [HCS framework](/job-planning/hcs-job-planning-framework.md), [approval workflow](/job-planning/job-plan-approval-workflow.md), [quarterly reconciliation](/job-planning/quarterly-reconciliation.md), and [consistency panels, enhanced scrutiny and appeals](/job-planning/consistency-and-appeal-sla.md).
* **Who can cover when a department cannot** — [lend staff between departments](/run-the-roster/cross-department-cover.md), under **Fairness & cover** in the sidebar.

## Why "resource management", not "rostering"

Three interlocking pains push most departments back to spreadsheets and email — and none of them are just about producing a schedule:

1. **The plan breaks mid-horizon.** Sickness, extended leave, unplanned reassignments, room outages — all invalidate an already-published roster. ReSouris's sickness-batch wizard triages multi-staff absence events together, extended-leave workflows integrate with maternity/paternity/long-sickness spells, and the reporting-structure tool (v1.7.2) handles the "manager promoted; move his 5 subordinates" pattern in one gesture. Leave requests flow through a proper submit → decide → withdraw state machine.
2. **The catalogue of resources drifts.** Competencies expire. Accreditations lapse. Rooms get repurposed. Equipment leaves the fleet. Line-management relationships change. Without a live model of the resource pool, rosters are built on stale assumptions. ReSouris's per-resource lifecycle surfaces (employment spells, competency assessments, working-pattern effective dates, room state, equipment catalogue) keep the model current — and the solver reads from that live state, not a snapshot.
3. **The evidence trail is scattered.** Regulators (GMC, CQC, NHS Improvement, equivalents overseas) increasingly expect allocation, competency, and workforce decisions to be evidenced. ReSouris's constraint solver produces defensible rosters and records the allocation policy behind every decision; the audit chain preserves every state change of every resource; the export/import pipeline (v1.6.3) round-trips users and their state with signed archives.

The published roster is a **view** onto this model. Change any resource — a competency lapses, a room goes offline, a manager retires — and the model updates immediately; the next re-solve reflects the new reality.

## Deployment modes

ReSouris installs in one of three modes, each with its own licence, delivery path, and renewal flow:

* **SaaS** — hosted at `*.rostaire.example`; licence auto-fetches on schedule.
* **Self-hosted** — customer installs on their own infrastructure; licence delivered as a signed file; revocation list pulled on schedule.
* **Air-gapped** — no internet reachability; licence delivered via signed offline transfer (MAK-style request/response); revocation list imported manually.

See [Deployment modes](/part-2-running-resouris/deployment-modes.md).

## Trust chain

ReSouris verifies signed artefacts against a pinned trust anchor that ships with every release. The chain is deliberately short:

```
R-ROOT-2026 (offline, HSM)
    ├── R-RELEASE-2026 — signs corpus + product releases
    ├── R-PLUGIN-2026 — signs plugin bundles
    ├── R-AUDIT-SEAL-2026 — signs nightly audit seals
    └── R-LICENCE-2026 — signs licence files (custodied by ReSouris Licence)
```

Licences are issued by the [ReSouris Licence](https://github.com/metkhoo/ReSouris-Licence-Generator) companion product. See [Install a licence](/part-2-running-resouris/install-a-licence.md).


---

# 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/readme.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.