> 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/job-planning/job-plan-approval-workflow.md). # Job-plan approval workflow > **Reference**: NHS "Job Planning for Healthcare Science Staff" Guidelines §6.2 (triple-signoff cascade) + §5.1 Table 2 (per-band SPA minima). See also `hcs-job-planning-framework.md` for the framework overview. ## Triple-signoff cascade Guidelines §6.2 requires three signoffs before a Job Plan can be activated: 1. **Operational** — the line manager confirms the plan works for day-to-day service delivery. 2. **Budget** — finance / workforce confirms the plan is affordable. 3. **Professional** — the HCS Professional Lead confirms the plan meets professional standards (SPA sufficiency, safe scope, competency alignment). All three must be recorded (and un-revoked) before `transition_job_plan('active')` succeeds. The workflow refuses activation with a `MissingTripleSignoff` error listing which kinds are still outstanding. ## Signoff mechanics * **Record**: `POST /ui/admin/job-plans/{plan_id}/signoff` with `kind=operational|budget|professional`. Notes optional (≤500 chars). Requires the corresponding perm (professional requires `admin.job_plan.professional_signoff`). * **Revoke**: `POST /ui/admin/job-plans/signoffs/{signoff_id}/revoke`. Soft-delete via `revoked_utc + revoked_by_user_id`; the row stays in the audit trail. Another signoff of the same kind can then be recorded fresh. * **Audit trail**: every record + revoke fires the `job_plan.signoff_recorded` audit event with `{signoff_kind, signoff_id, revoked}` payload. ## Roles * **Line manager**: any user in the plan owner's reporting-line chain. * **Budget signer**: `tenant_admin` or a designated finance role. * **HCS Professional Lead**: new v2.0 role `hcs_professional_lead` (13th role, corpus-documented in `security-v1.1.md §3.1`). Tenant-seeded on demand via the Phase-6 RBAC UI. ## SPA-minimum check (Guidelines §5.1) On the transition to `active`, ReSouris also runs an SPA-minimum check per band grade (Guidelines Table 2 — see `hcs-job-planning-framework.md`). * **Compliant plans** transition normally with all three signoffs. * **Undershoot warns** (audit event `job_plan.spa_minimum_violated` fires with band + spa\_pct + min\_pct + magnitude). * **Undershoot blocks** unless the actor holds `admin.job_plan.override_spa_minimum` (delegated to tenant admins for Trust-level exceptions). The audit event always fires — override just unblocks the transition. Compliance trail remains complete. **v1.7.4 addition**: Trusts may raise the national minima *upward* via `/ui/admin/role-spa-minima` (per-band override table, MIG-207). Downward edits are refused by app-layer invariant. The per-band % is the same lookup key; the tenant override wins when present. **v1.7.4 addition**: WTE pro-rating. Absolute SPA hours scale by `staff.wte_fraction` — a 0.5 WTE band 8 worker's plan needs 4.6875 hours of SPA to meet the minimum, not 9.375. Previously the check refused most PT plans that were correctly shaped for the reduced week. See [WTE scaling + session-based rendering](/job-planning/wte-and-session-based.md). ## Nominating your Designated HCS Professional Lead (DLS) Guidelines §6.2 identifies a Trust-level DLS as the third-leg holder of the triple-signoff cascade. **v1.7.4 lands the nomination substrate** at `/ui/admin/job-plan-designated-lead` (gated on `admin.job_plan.professional_signoff`). The `job_plan_designated_lead` table (MIG-209) carries the current nominee plus a full history of past nominations; a partial UNIQUE `(tenant_id) WHERE active_to_date IS NULL` at the DB layer guarantees **at-most-one active DLS per tenant**. Trust patterns from operator conversations (all supported — pick one that suits your governance): * **Single lead per Trust**: the Head of Healthcare Science (or equivalent) holds the role platform-wide. Plans across all specialisms route to the same signer. Best for small-to-medium Trusts. * **Lead per specialism division**: separate leads for Lab Sciences / Physical Sciences / Physiological Sciences (or narrower — Radiotherapy Physics, Cardiac Physiology, etc.). Best for large Trusts with distinct professional communities. In this pattern the DLS row rotates by division; the `notes` field records the current scope. * **Lead per pay band**: 8c leads sign for Band 6-8b staff; a Band 9 lead signs for 8c and above. Least common but useful where the Lead's professional distance from the applicant matters. Ending a DLS nomination is a first-class action — `POST /ui/admin/job-plan-designated-lead/{id}/end` writes `active_to_date` and preserves the row for audit. A new nomination can be started immediately. ## Enhanced-scrutiny thresholds (Guidelines §6.7) Trusts may configure additional-signer requirements when a plan trips one of four canonical thresholds — `staff_band_at_or_above`, `total_pas_at_or_above`, `spa_pct_below`, `override_count_above`. Each rule pairs a threshold value with a named reviewer role who must sign the override. Rules are Trust-defined via `/ui/admin/enhanced-scrutiny-rules` (gated on `admin.job_plan.enhanced_scrutiny.override`). **v1.7.4 ships CRUD only**; the trigger evaluation + additional-signer enforcement at approval time lands in v1.8+ once Trusts have calibrated their thresholds. See [Consistency panels + enhanced scrutiny + appeal SLA](/job-planning/consistency-and-appeal-sla.md). ## Consistency panels (Guidelines §6.9) Trust-level review boards for cross-department distribution consistency. Trusts pick how many panels to run, which departments they cover, and who sits on them. Admin CRUD at `/ui/admin/consistency-panels` (gated on `admin.job_plan.consistency_panel.chair`). Members are named users; the panel record + membership history is preserved on closure. **Non-blocking advisory in v1.7.4** — the panel-review-required state transition lands in v1.8+. Convening a panel today produces an audit-visible record and a named-member roster; the actual review artefact is a v1.8+ concern. ## Appeal path (Guidelines §6.11) If the applicant disputes the outcome, they may open an appeal. * Cascade: Informal → mediation → formal\_appeal → executive\_review → resolved. * **New role `hcs_appeal_moderator`** (P42) chairs each stage. Corpus-documented + Phase-6 seeded. * **6-year retention** on appeal records per HR legal-record convention. **v1.7.4 addition**: daily SLA breach notifier. Open appeals past their per-kind deadline (informal 7d, mediation 14d, formal\_appeal 28d, executive\_review 42d — monotonically-non-decreasing per Guidelines §6.11) fire `job_plan.appeal_sla_breached` audit events. See [Scheduled jobs](/part-2-running-resouris/automations.md). **v1.7.4 addition**: `executive_review` state advance is gated on the current DLS (MIG-209 read via `application/job_plan/appeal_sla.py::can_advance_to_executive_review`). Fail-closed when no DLS is nominated. A future admin UI in v1.8+ calls this before allowing the transition; the gate helper is landed and unit-tested in v1.7.4. ## Review cadence Once approved, plans are subject to Guidelines §6.5 review cadence: * **6-month first review** after the plan becomes active. * **12-month annual review** thereafter. The **nightly review notifier** (v1.7.4, `application/job_plan/review_notifier.py::tick`, K8s CronJob at 02:00 UTC) flags plans crossing the 30-day pre-due threshold; overdue plans surface on the admin monitoring dashboard. The event payload includes the resolved line manager's `staff_id` so downstream email routing / dashboard cards can address the manager without re-querying. Idempotent per (plan, next\_review\_date) via 45-day audit-event dedupe. --- # 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/job-planning/job-plan-approval-workflow.md?ask=&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.