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

# Glossary

Definitions of the terms ReSouris uses. Cross-linked to the concept pages where each is developed in depth.

## Rostering

**Activity** — a specific unit of clinical work (e.g. `CT-ABDOMEN`, `MRI-BRAIN`). Activities are catalogue entries tied to competencies; the solver checks staff-competency-vs-activity-requirement before allocating.

**Assignment** — one row in `assignments` (pre-v1.6.2) or one row in `slot_assignment` (v1.6.2+) representing "this staff is doing this activity in this slot's sub-window". Carries a companion `assignment_score_breakdown` row explaining why.

**Cover** — a reassignment that fills a sub-window vacated by sickness, leave, or absence. Produced by the reschedule worker as a proposal; accepted by an admin.

**Handover** — the paid overlap period between two staff on either side of a split-shift sub-window. Range 0..60 minutes, per `service_lines.handover_minutes`. Clinical-safety-informed default of 15 min.

**Roster area** — a `departments` row; **"roster area" and "department" are the same thing**, and both are load-bearing (`roster_area_admin`, `roster_area_manager` in role names; `department_id` throughout the schema). The unit of RLS partitioning for BPP-EQUITY tables and the scope of the `roster_area_admin` role.

**Rostering tier** — a seniority band (`consultant`, `registrar`, `SHO`, `SpR`, etc.) that biases the solver toward tier-appropriate candidates for tier-tagged sub-slots.

**Service line (SL)** — a workstream (e.g. "CT scanning", "outpatient echocardiography"). Every rosterable slot belongs to a service line; slots inherit priority + target roster tier from their SL.

**Slot** — an addressable **half-day time bucket**, and nothing else. Shape: `{id, date, day_of_week, half, week_index}` — e.g. `2026-08-11-am`. Halves are `am` and `pm`; weekdays only. A slot carries **no activity, no room, no service line and no department**, and is shared across every service line in the tenant. Slots **contain** sub-slots. Computed at solve time — there is no slots table. *(Corrected 2026-08-08: this entry previously described a slot as `(activity × room × time window)` grouped by service line and sitting inside sub-slots. Every one of those clauses was wrong. See* [*Session*](#session) *for the unit that does carry a service line and a room.)*

**Slot assignment** — v1.6.2+ join between a slot and a staff for a sub-window. Prior to v1.6.2, `assignments` did this at slot granularity; from v1.6.2 the finer granularity is required for split shifts.

**Split shift** — one slot filled by more than one staff, each for a non-overlapping sub-window, with a handover between them. Opt-in per service line + activity (v1.6.2 P27).

**Sub-slot** — a fixed-width block **inside** a slot (e.g. 30-minute increments, per the tenant's `deployment_settings.subslot_minutes`). A slot contains sub-slots, not the other way round.

**Sub-window** — a time window within a slot in which one staff assignment is valid. Introduced in P27 to support split shifts. For non-split slots, the sub-window equals the slot's full window.

**Working pattern** — a staff's day-of-week × session pattern (e.g. "Mon AM + PM, Wed AM only, Thu PM"). Enforces contracted hours and days-off.

## Fairness + equity

**Allocation policy** — the weight + window + exclusion configuration the solver uses to score candidates. See [Equity model](/how-it-works/equity-model.md).

**Assignment score breakdown** — the per-assignment record of the five score components (priority, mandatory-bonus, competency-value, equity-deficit, entitlement-debt) that led the solver to this choice. Row per assignment.

**Carry-over policy** — how job-plan credited-count "rolls" between periods. Closed set: `rolling | none | half_life | accumulate`.

**Competency value** — the score component reflecting how well a staff's competencies match a slot's requirements. Higher for proficient over supervised.

**Development goal** — a per-(training-plan, competency) row that tracks progress toward a target level. Contains typed `goal_requirement` entries.

**Entitlement** — a `job_plan_entitlement` row: per-(plan, activity, period) target count. E.g. "12 CT-Abdomen sessions per 13-week period."

**Entitlement debt** — `job_plan_debt` view output; the difference between expected (target × periods\_elapsed) and credited counts, after carry-over decay.

**Equity adjustment** — a standing-policy override on a staff's inclusion in an equity dimension. Discrimination-risk mitigation with mandatory sign-off. Closed-set kind: `exclude_from_dimension | weight_denominator | weight_numerator | paused`.

**Equity counter** — materialised view rolling per-staff totals per (equity dimension × period). Solver reads at score time.

**Equity deficit** — the score component reflecting how far below fair share a staff is on a specific dimension.

**Equity dimension** — a way of measuring fair share (e.g. `weekend_shifts_per_staff`). Seven come with the platform; tenants can extend.

**Feedback thread** — a discussion attached to any BPP-EQUITY artefact. State machine: `open → resolved → reopened`.

**Workload Plan** *(renamed from "Job plan" at v1.7.3.7; the old name collided with **HCS Job Plan** below, which is what that rename existed to end)* — a per-staff contract for activity-level entitlements. See [Equity model](/how-it-works/equity-model.md#job-plans). Distinct from **HCS Job Plan** (below), which is the Guidelines-shaped v2.0 framework built on top.

**HCS Job Plan** — the NHS "Job Planning for Healthcare Science Staff" Guidelines governance framework implemented in v2.0 (P42) + rounded out to operational completeness in v1.7.4 (P43). Category-based (DCC/SPA/ANR/ED) with per-band SPA minima, triple-signoff, cycles, quarterly reconciliation, review cadence, team plans, consistency panels, enhanced-scrutiny thresholds, and appeal SLA. See [HCS Job Planning framework overview](/job-planning/hcs-job-planning-framework.md).

**Workload Plan ledger** *(table remains `job_plan_ledger` — see* [*Canonical vocabulary register*](https://github.com/metkhoo/rostaireone/tree/main/docs/vocabulary-register.md) *§4 on why schema identifiers are not renamed)* — append-only credit log for entitlement fulfilment. Closed-set source kind: `slot_assignment | manual_credit | manual_debit | carry_over | correction`.

**Mandatory bonus** — the score component for hard-required assignments (e.g. supervised training with a named supervisor). Effectively locks the assignment.

**Priority** (service line) — the per-SL lex-priority weight fed to the solver.

**Training plan** — per-staff development plan. Workflow-driven approval; dual-pathway signoff.

## HCS Job Planning (v2.0 P42 + v1.7.4 P43)

**Activity domain** — the Guidelines Appendix A specialism taxonomy. Stored in `activity_domain_catalog` (MIG-208, global reference table, no tenant\_id). Five-value `domain_group` closed set: `clinical_science | medical_physics | clinical_engineering | clinical_bioinformatics | other`. v1.7.4 ships a \~33-row starter seed; full \~200-row expansion tracked as v1.8+ follow-up.

**Appeal SLA** — Guidelines §6.11 per-kind deadline on open appeals. Defaults (calendar days, monotonically non-decreasing): informal 7, mediation 14, formal\_appeal 28, executive\_review 42. Daily cron fires `job_plan.appeal_sla_breached` audit events for over-SLA rows with 1-day dedupe.

**Consistency panel** — Trust-level review board for cross-department distribution consistency per Guidelines §6.9. Stored in `consistency_panel` + `consistency_panel_member` (MIG-212). Chair-level admin CRUD gated on `admin.job_plan.consistency_panel.chair`. Non-blocking advisory in v1.7.4.

**Cycle** — annual planning cadence per Guidelines §6.7 in `job_plan_cycle` (MIG-203). Five-value state closed set: `planning | open | negotiating | mediation_window | closed`. Partial UNIQUE `(tenant, department) WHERE state <> 'closed'` guarantees at-most-one non-closed cycle per department at the DB layer.

**DCC / SPA / ANR / ED** — Guidelines §3-§4.2 activity categories. Direct Clinical Care / Supporting Professional Activities / Additional NHS Responsibilities / External Duties. Seeded as a tenant-independent closed-set table `job_plan_activity_category` (MIG-187) so cross-tenant reporting means the same thing everywhere.

**DLS** — **D**esignated HCS Professional **L**ead. Guidelines §6.2 third-leg signer on Job Plan approval. Nominated per tenant via `job_plan_designated_lead` (MIG-209); partial UNIQUE ensures at-most-one active DLS per tenant. Nomination admin surface at `/ui/admin/job-plan-designated-lead`.

**Enhanced scrutiny** — Guidelines §6.7 Trust-configurable thresholds that trip an additional signer. Four canonical trigger kinds in `enhanced_scrutiny_rule` (MIG-210): `staff_band_at_or_above`, `total_pas_at_or_above`, `spa_pct_below`, `override_count_above`. v1.7.4 ships CRUD only; trigger evaluation lands in v1.8+.

**PA** — Programmed Activity. Guidelines §3 unit of contracted time. Default 3.75h; 5-value closed set on `deployment_settings.programmed_activity_hours` (3.25 / 3.50 / 3.75 / 4.00 / 4.25). Installation-wide so cross-tenant KPI reporting is comparable.

**Quarterly reconciliation** — Guidelines §5.1.5 per-quarter planned-vs-delivered snapshot in `job_plan_quarterly_reconciliation` (MIG-204). Immutable-once-signed at the DB layer via `WHERE signed_utc IS NULL` guard on the reconciler's `DO UPDATE`. Distinct from the fine-grained `entitlement_bank` (MIG-193) — MIG-204 aggregates for signable reporting.

**Clinic** *(retired 2026-08-17)* — **no longer part of ReSouris.** A clinic used to sit between the service line and the roster as a second scheduling unit. Say **service line** for the kind of work and **session** for one running of it at a time and place. Everything a clinic carried moved: its code and name to the service line, its required skills to the line's worker positions, its priority and mandatory flag to the line, its Trust Admin toggle to the line, and its offsite flag to the **room** — where the work actually happens. Removing it changed no rosters. ⚠️ Three names still read "clinic" on purpose: the `/ui/trust-admin/…-clinics` URLs (a URL is an operational interface — bookmarks and links would break), the `admin.clinic.read` / `admin.clinic.update` permissions (they gate ten live endpoints across departments, service lines, rooms and clinical governance), and the `clinics_configured` readiness identifier (a fixed value in a closed set — the label you see reads "Competency demand configured").

**Session** *(canonical, ratified 2026-08-07)* — **one service line, performed in one room, between a start time and an end time.** The schedulable clinical unit, matching NHS usage ("theatre session", "clinic session"). **Real, and authored per department** since v1.9.5: `session_definitions` holds the pattern a space runs (`start_local_time`, `duration_seconds`, `next_day`) and `roster_sessions` holds the expanded instances. ⚠️ *This entry previously said sessions were synthetic and hard-coded to 09:00–13:00 and 13:00–17:00 UTC. That stopped being true when session definitions shipped, and a department reading it would have concluded ReSouris could not represent its actual timetable.* A department authors its own: 08:50–13:00 mornings, 13:30–18:00 afternoons, and a consultant clinic at 13:00–17:30 are all expressible, and all are in the reference estate. Distinct from: **auth session** (the `sessions` table, MIG-001), **connection** (the Postgres session that RLS scopes via `SET LOCAL`), **service-line day** (`service_line_admin_status`, per `(service_line, date)` — a whole day, not a half), **governance meeting** (`clinical_governance_sessions`), and the half-day unit of a session-based contract below. See [Canonical vocabulary register](https://github.com/metkhoo/rostaireone/tree/main/docs/vocabulary-register.md).

**Session-based contract** — worker whose contract is expressed as N sessions per week rather than N hours. `staff.contract_kind='session_based'` + `staff.sessions_per_week` (MIG-192). Rollup UIs render as "N sessions" (with optional weekly cadence) instead of "N.NN PA".

**Triple-signoff cascade** — Guidelines §6.2 three signoffs required before Job Plan activation: operational (line manager), budget (finance), professional (DLS). All three rows must exist (unrevoked) in `job_plan_signoff` (MIG-194) before `transition_job_plan('active')` succeeds.

**WTE fraction** — per-worker whole-time-equivalent scaling factor in `staff.wte_fraction` (MIG-211). `numeric(3,2)`, CHECK `0 < wte_fraction <= 1.00`, DEFAULT 1.00. Powers SPA-minimum pro-rating + KPI headline denominator scaling. Pre-P43 rows land as full-time (matches historical implicit assumption).

## Sickness + leave

**Batch** (sickness) — grouping of overlapping-date sickness reports so the reschedule worker triages them together. Admin-authored via the wizard, or auto-formed by worker self-reports joining an open matching batch.

**K=3 stub** — the default new-batch size when a worker self-reports and no matching open batch exists. Placeholder pending the admin filling in additional detail.

**Leave request** — a `leave_requests` row with kind + date range + notes. State machine: `pending → approved | denied | withdrawn`. Withdraw preserves the row for audit.

**Reschedule proposal** — a candidate reassignment for a sub-window affected by sickness or approved leave. Multiple sibling proposals may cover the same sub-window; accepting one supersedes the siblings.

**Sibling proposal** — reschedule proposal sharing the same target sub-window as another. Superseded on accept-one via MIG-140.

**Skip pending** — admin-on-behalf shortcut to move a leave request straight to `approved`. Leaves `submitted_by_user_id` NULL.

**Withdraw** — worker's action on their own pending leave request. Transitions to `withdrawn` — a first-class state, not a soft-delete.

## Licences + trust

**Air-gapped** — deployment with no internet reachability. Uses signed offline file transfer for licences + manual revocation import.

**Corpus** — the versioned wire contract (`v1.1/`). Signed with `R-RELEASE-2026`.

**Deployment mode** — closed set: `saas | self_hosted | air_gapped`. Baked into every licence; enforced at install.

**Grant** — a key in the licence body's `grants` object. Booleans for features, integers for quotas.

**Installation ID** — optional UUID binding a licence to a single install. Refuses install on any other host.

**JWKS** — JSON Web Key Set. Public-key document at `/api/tenants/{slug}/keys/public.jwks` (future) used to verify tenant-signed artefacts. See the FOUNDATIONAL: Per-Tenant Signing Key Infrastructure enhancement.

**Licence body** — the JSON document inside the signed licence file. See `v1.1/docs/commercial/licensing-v1.1.md` §6.

**MAK** — Multiple Activation Key. NHS-familiar term reused for the offline-signed licence-request/response flow used by air-gapped deployments.

**R-ROOT-2026** — the offline HSM-custodied root key. Signs subkey introductions in the trust anchor.

**R-RELEASE-2026** — subkey signing corpus + product releases.

**R-PLUGIN-2026** — subkey signing plugin bundles.

**R-AUDIT-SEAL-2026** — subkey signing nightly audit seals.

**R-LICENCE-2026** — subkey signing licence files. Custodied by the ReSouris Licence companion product.

**R-LICENCE-AUDIT-2026** — fifth subkey introduced in v1.7 D5 for the ReSouris Licence side's audit-seal signing.

**Revocation list** — signed JSON published at the URL in every licence's `revocation_check_url`. Contains revoked licence IDs + effective dates. Pulled daily in online modes; manually imported in air-gapped mode.

**Trust anchor** — the pinned public-key material at `dist/trust-anchor-v1.1.json`. Root + subkey introductions. Ships with every release.

## Audit + compliance

**Audit chain** — the per-tenant hash-linked sequence of audit events.

**Audit event kind** — the `action` string on an audit event row. Payload shapes for the enhancement-chain event kinds are documented in `v1.1/docs/security/security-v1.1.md §3.4`. Recent additions include `job_plan.review_due` (P43.A3), `job_plan.spa_drift_detected` (P43.E2), and `job_plan.appeal_sla_breached` (P43.H2).

**Audit seal** — nightly signature over a canonical summary of the previous day's chain: the chain head hash, the event count, and the first and last event ids. Not a Merkle root — there is no inclusion proof for a single event. Written to `audit_seals` (append-only via MIG-014). Signed with `R-AUDIT-SEAL-2026`.

**Chain hashes** — the two per-event fields that form the link: `prev_hash`, which is the preceding row's `row_hash` for the same tenant, and `row_hash = sha256(prev_hash || canonical_bytes(this_event))`, where the canonical bytes are RFC 8785 over the whole event rather than the payload alone. Retroactive edit detection.

**Redaction** — PII-stripping at audit-write time per the tenant's redaction rules. Failure emits an alerted event with stub payload rather than silently leaking.

**Support bundle** — encrypted `.tar.gz` of audit + config snapshot + logs, produced by admin for support tickets. Signed + encrypted; ReSouris decrypts.

**Witness** — third-party durability backend for audit seals. `LocalFs` in v1; S3 Object Lock as a graduated stub in v1.5+.

## User export + import (v1.6.3)

**Canonical dict** — the walker's output for a per-user export: a JSON dict with `shape_version`, `issuer_tenant_id`, `subject_user_id`, `export_mode`, `issued_utc`, and a `sheets` map keyed by the F6 22-sheet allowlist. Signature is over the JCS canonical bytes of this dict; writers project from it into XLSX or JSON archives.

**DSAR archive** — a signed export in `mode=dsar`. Redacted per the F3 redaction table (12 `(sheet, column, kind)` triples; deterministic `placeholder_uuid` within one archive). Export-only — the reader refuses to import DSAR archives.

**Transfer archive** — a signed export in `mode=transfer`. Unredacted; eligible for same-tenant import via the wizard. Cross-tenant transfer refused in v1.6.3 (F5); waits for per-tenant signing infrastructure.

**Import batch** — a row in `import_batch` (MIG-159) tracking one in-flight import through its state machine: `uploaded → previewed → committed | aborted`. Every audit event emitted by the wizard carries the batch id.

**F6 allowlist** — the closed set of 22 exportable sheets. Walker refuses to include tables not on the list.

**FK mapping declaration** — the operator-supplied dict `{column_name: {src_value: tgt_value}}` resolving tenant-scoped foreign keys at import time. Silent match-by-name refused per F8.

**Deferred sheets** — sheets in the archive that the v1.6.3 committer does not yet write. Reported honestly in the wizard's commit summary. the committer writes `user`, `user_roles` and `staff_direct_skills`; other 19 sheets are v1.7+ scope.

## Room service-line scheduling (v1.6.4)

**Room-SL pattern** — recurring weekly rule keyed on `(tenant, room, day_of_week 0..6, subslot_index 0..47) → service_line_id`. Stored in `room_service_line_pattern` (MIG-142). Solver reads it as a HARD constraint; v1.6.4 exposes admin authoring at AM/PM granularity (F3).

**Room-SL override** — one-off exception keyed on `(tenant, room, date, subslot_index) → service_line_id`. Stored in `room_service_line_override` (MIG-143). Supersedes the pattern for that date (F4 override wins). Bounded to today .. today + 365 days (F8).

**Effective grid** — the union of pattern rows + override rows the solver reads for a room. UI renders it with override cells visually flagged (F4).

**Satisfiability check** — pre-save advisory that catches `PRE_FILL_CONFLICT` at author time. Warns when a proposed pattern cell references a service line the room cannot host. Doesn't block per F6 — legitimate to author ahead of the room mapping.

## Roster grid actions (v1.6.8.2 – v1.6.8.4)

**⋯ menu** — the per-cell actions button in the top-right of every roster-grid cell. Opens a flat menu whose contents depend on cell state (empty / filled / cancelled) and, for filled cells, enumerates every person on the slot so multi-staff cells get one Replace / one Change-SL entry per person. Introduced v1.6.8.2 to replace the older `+` add-only button; right-click on the cell opens the same menu.

**Assignment origin** — `assignments.origin` closed set (MIG-172): `solver` (default; produced by the CP-SAT solver) or `manual` (added by an operator via the ⋯ menu → Add manually OR Replace flow). Manual rows render with a 2px dashed indigo left border + tiny "M" corner badge on `/ui/rosters/{id}/spaces` so admins can scan solver-vs-hand-authored at a glance.

**Session cancellation** — mark a specific `(revision, room, iso_date, half)` slot as not-running. Stored in `roster_slot_cancellation` (MIG-173) with a 6-value reason closed set + reason-driven default staff-handling. Cancellations are per-revision by design; CASCADE on `revision_id` + re-solve discards them. Reversible via `un_cancelled_utc`. See [Cancel a session](/run-the-roster/cancel-a-session.md).

**Release staff (cancellation)** — one of two staff-handling modes on cancellation. When ticked, the assignment rows for the slot are DELETED and the originally-scheduled `staff_ids` are snapshotted in the cancellation's `released_staff_ids_jsonb`. When unticked (preserve semantics), assignment rows stay in place and the UI renders them crossed-out under the CANCELLED banner. Default is reason-driven: equipment\_broken + venue\_unavailable pre-tick release; everything else preserves for SUS/PBR audit.

**OOH column** — the third sub-column per day on the Primary roster tab (added v1.6.8.4, enhancement #57). Time band: 18:00 UTC of the day → 09:00 UTC of the next day. OOH assignments render in the START day's OOH column (no next-day cell stretch). MIG-174 admits `half='ooh'` on `roster_slot_cancellation`.

**Working from home tab** — third tab on `/ui/rosters/{id}/spaces` filtered to `rooms.target_roster_tier='tertiary'`. Renamed from "Tertiary roster" in v1.6.8.4. Currently uses the same Rooms × Days grid shape as Primary; enhancement #58 (planned) reworks it to a Staff × Days grid driven by a new `assignments.work_location` column.

## Architecture

**Adapter** — module under `adapters/`. Implements a `contracts/` protocol. ARC-001: adapters MUST NOT import `host/`.

**ARC-001** — architectural rule: adapters isolated from host layer. Enforced by `tests/arc/`.

**Closed set** — cardinality-pinned enumeration (roles, permissions, migrations, error codes, etc.). See [Architecture](/reference/architecture.md#closed-sets).

**Contract** — module under `contracts/`. Type protocols + closed-set catalogues.

**Corpus manifest** — `v1.1/package-manifest-v1.1.json`. Pins cardinalities + per-file hashes.

**Deployment settings** — per-tenant configuration. `subslot_minutes`, notification settings, calendar horizon, licence-store, etc.

**FORCE ROW LEVEL SECURITY** — Postgres RLS mode preventing table-owner bypass. Applied to every tenanted table.

**MIG** — migration. Sequential integer ID. Every MIG is reviewed for reversibility; reversibility exceptions are user-authorised (see MIG-146, P24.A3).

**RLS** — row-level security. Postgres primitive scoping row visibility. See `tenant_isolation` + `department_isolation` policies.

**Widget** — a UI dashboard component from the v1.6 P25 framework. Delivered as signed plugin bundles reusing the enhancement #19 install lifecycle. Nine subsystem plugin kinds; `widget` was added as the ninth.

**Workflow definition** — per-tenant per-artefact-kind approval workflow override. Applies to allocation policies, training plans, job plans, equity flags. States + transitions + signers all tenant-configurable.


---

# 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/reference/glossary.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.