> 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/resource-management-model.md).

# Resource management model

ReSouris is a **resource management** platform. This page names the resources it models, the lifecycle each one carries, and how they combine to produce a defensible published roster.

Read this before the other core-concepts pages — it's the mental scaffold everything else hangs on.

***

## The five asset classes

A clinical department depends on five interlocking resource classes. ReSouris holds a first-class model of each, with its own lifecycle events, its own audit trail, and its own read/write UI:

### 1. People (workers)

The workforce is the primary resource. Per worker, ReSouris holds:

* **Identity + employment**: user account (v1.0 baseline), linked staff record, `staff_employment_spell` history (v1.6.6 P31) — the temporal record of who was employed when. Archive / reactivate flow preserves accreditations + competencies + training across breaks.
* **Working patterns**: effective-dated `staff_working_pattern_assignment` (v1.6.6 P31) mapping worker to weekly cycles (1..4 weeks). Mid-cycle rotation changes get deterministic resolution.
* **Skills + competencies**: `skills` + `competencies` (v1.2), per-worker `staff_direct_skills` (v1.2 Path-B), competency assessments, supervision-posture closed set (t2\_indirect / t1\_direct / proficient).
* **Training + CPD + accreditation**: `training_plan` + `development_goal` + `goal_requirement` + `staff_clinical_activity` + `staff_cpd_credits` + `accreditations` (v1.2 P2 + P3). The [Worker Logbook](/for-clinical-staff/worker-logbook.md) is the worker-facing surface (v1.7.2 P37).
* **Availability + preferences**: `staff_availability_preference` (v1.6.7 P32) — worker-authored positive/negative preferences with per-slot masks + weekly patterns + date ranges.
* **Extended leave**: `staff_extended_leave` (v1.6.7 P32) — maternity / paternity / adoption / shared parental / sabbatical / long sickness / secondment / other-long-leave with returned-on + return-onboarding gate.
* **Line management**: `staff_line_management` spells (v1.6.8 P33) with N > 1 concurrent managers + `is_primary` flag (v1.7.3 P38). The [Reporting-structure tool](/manage-people/reporting-structure-tool.md) surfaces the org chart to admins; workers see it read-only via Team structure.

Lifecycle: **hired → active → (extended leave? → returned) → archived → reactivated (optional)**. Every transition is auditable.

### 2. Spaces and the estate

The physical estate, held as a **Location → Space** hierarchy whose level names each tenant chooses (Areas, Buildings, Floors, ODS site codes) — see [The estate](/how-it-works/the-estate.md). ⓘ The screens say **Spaces**; the tables still say `room`, and both mean the same thing. Per space, ReSouris holds:

* **Catalogue**: `rooms` — active/archived, physical/virtual, target roster tier, and the offsite flag a clinic used to carry.
* **Space–service-line scheduling**: `room_service_line_pattern` — subslot-keyed weekly pattern of which service line uses which room when; `room_service_line_override` for date-scoped one-offs. Solver enforces at HARD-constraint level.
* **Fixed equipment**: `room_equipment_fixed` — equipment permanently installed in a space, which travels with the space rather than being booked.

Lifecycle: **active → archived** (rare but supported; historical rosters preserve the reference).

### 3. Equipment

Portable and fixed items that gate specific procedures. Per item, ReSouris holds:

* **Catalogue**: `equipment_item`, with `equipment_type` — active/inactive.
* **Service-line eligibility**: `service_line_equipment` — which equipment is required by which service line.
* **Skills**: `equipment_skills` — which competencies are required to operate an equipment item.

Lifecycle: **active → inactive → retired**. The solver refuses to schedule a service line where required equipment is not available in the target space.

### 4. Competencies + demand shape (service lines + sessions)

The *demand* half of the model — what needs to happen and where.

* **Service lines**: named clinical services (`service_lines`) with:
  * `priority` (lex-priority for the solver's fairness objective)
  * `allow_split_shifts` + `handover_minutes` (v1.6.2 P27)
  * `has_on_call` (v1.6.5 P30 enhancement #40)
  * `supports_admin_status` — whether the Trust plans this line's patient numbers ahead (v1.6.5 P30 enhancement #41)
  * `is_mandatory` — the solver treats every session on the line as high-priority
  * The competencies its **worker positions** require: this, and nothing else, is what the engine reads as the line's skill demand
* **Sessions**: one running of a service line at a time and place (`roster_sessions`), carrying the room, the time and the staff.

> **Changed in v1.8.3.** A third entity, the **clinic**, used to sit between the service line and the roster, owning `no_skills`, `seat_requirements_jsonb`, a priority and the Trust Admin scope. It has been removed. Measured before removal, the roster engine read exactly **two** facts from a clinic — a priority and a mandatory flag — and both already had homes on the service line; its `required_skills_jsonb` was never read at all. Removing it moved no rosters.

Lifecycle: service lines evolve at admin discretion; sessions roll on the horizon.

### 5. Time + the audit trail

The transverse resource — every state change on every resource is logged.

* **Audit chain**: `audit_events` (v1.0 baseline) — append-only, hash-chained, sealed nightly by a dedicated signing key. See [Audit and compliance](/part-2-running-resouris/audit-and-compliance.md).
* **Change log**: every corpus document has a change-log table at its foot; every MIG carries a `Checksum:` line; every plugin bundle carries a signed manifest.

***

## The rostering read: demand meets resources

The published roster is a materialised view onto the resource model at a point in time. The [constraint solver](/part-2-running-resouris/solver-scaling.md) takes as input:

* **Demand**: the horizon's sessions (from #4) with their service line's competency requirements + priority.
* **Resources**: currently-employed workers with their working patterns + availability + preferences + line-management context (from #1), and the rooms + equipment eligible for each service line (from #2, #3).
* **Policy**: the tenant's active `allocation_policy` (v1.2 BPP-EQUITY) — the weights + windows + exclusions the solver optimises against.

It produces `assignments` rows (worker → slot → room). Each assignment carries a `slot_assignment` sub-record (v1.6.2 P27) so split shifts + handovers are first-class.

**Re-solve is idempotent + declarative.** Change the resource pool (add a worker, retire a room, promote a competency) and the next re-solve reflects the new reality — no manual patchwork on the last-published roster.

***

## Change-of-plan flows

Real clinical work invalidates the plan mid-horizon. ReSouris models each disruption class as a first-class flow:

* **Sickness** → the [Sickness batch wizard](/run-the-roster/report-a-sickness-batch.md) triages multi-staff absence together, proposing cover options that respect competencies + workload balance.
* **Extended leave** → the [Extended leave workflow](/run-the-roster/availability-and-extended-leave.md) captures started-on + expected-return + return-onboarding indicators.
* **Leave requests** → worker self-service submit → admin decide → withdraw state machine (v1.5 P24 [Submit a leave request](/for-clinical-staff/submit-a-leave-request.md)).
* **Session cancellation** → per-slot cancellation with reason-driven staff handling (v1.6.8.3 enhancement #55).
* **Reporting reshuffles** → the [Reporting-structure tool](/manage-people/reporting-structure-tool.md) handles bulk manager reassignment (v1.7.2 P37) + shared reporting (v1.7.3 P38).
* **Manual overrides** → the [Roster grid ⋯ menu](/run-the-roster/roster-grid-actions.md) supports hand-authored assignments with a `manual` origin marker for audit.

Each flow closes with a re-solve, an audit event, and a fresh published roster.

***

## Why this framing matters

If you think of ReSouris as *just* a roster producer, you'll build workflows around the roster PDF: emailing it, printing it, marking it up by hand. That reintroduces the drift the tool exists to eliminate.

If you think of it as a **resource management platform**, the roster is a read on the model — always available, always current, never edited outside the system. Every change flows through a lifecycle event on the underlying resource, and the audit trail follows for free.

Read [Roster lifecycle](/how-it-works/roster-lifecycle.md) next for the operator-level flow of producing + publishing a roster on top of this model.


---

# 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/resource-management-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.