> 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/consistency-and-appeal-sla.md).

# Consistency panels, enhanced scrutiny and appeals

ReSouris's v1.7.4 release rounds out the Guidelines §6.7-§6.11 governance surface. Three related surfaces:

* **Consistency panels** — Trust-level review boards that spot cross-department distribution outliers before signoff.
* **Enhanced-scrutiny thresholds** — Trust-configurable rules that trip an additional signer when a plan exceeds Trust-defined thresholds.
* **Appeal SLA notifications** — daily audit-event stream flagging appeal-cascade stages that have missed their deadline.

None of these gate plan approval in v1.7.4. They are *advisory* surfaces that surface intent to operators; the next release lands the real gate behaviour once Trusts have opted in.

## Consistency panels

**Where.** Trust Admin → **Consistency panels** (`/ui/admin/consistency-panels`). Requires `admin.job_plan.consistency_panel.chair`.

Guidelines §6.9 describes a Trust-level board that reviews a subset of proposed Job Plans for cross-department distribution consistency. Panels are Trust-defined: each Trust picks how many panels to run, which departments they cover, and who sits on them.

### Creating a panel

* **Name** (1-120 characters). Unique among *active* panels for the tenant — closing an old "SPA distribution" panel and starting a fresh one with the same name is supported.
* **Active from** — the panel's start date. Membership adds are gated on the panel being active.
* **Chair** (optional) — a named user who leads the panel. Displayed on the panel row; not otherwise privileged.
* **Notes** (optional, 500 chars) — free-text scope description.

### Managing membership

Once a panel is active, add or remove members via the inline forms. Each user appears at most once as an *active* member — remove-then-re-add creates a new membership row so the audit history is preserved. Closed panels do not accept membership changes.

### Closing a panel

Set an end date on the panel form. Closed panels stay visible for audit reference; the row shows the close date and its members are frozen at the close point.

## Enhanced-scrutiny thresholds

**Where.** Trust Admin → **Enhanced-scrutiny thresholds** (`/ui/admin/enhanced-scrutiny-rules`). Requires `admin.job_plan.enhanced_scrutiny.override`.

Guidelines §6.7 identifies four canonical triggers that Trusts may configure to require an additional named-reviewer sign-off on a Job Plan:

| Trigger                  | What it catches                                                        |
| ------------------------ | ---------------------------------------------------------------------- |
| `staff_band_at_or_above` | Senior staff (e.g. band 9+) whose plans warrant additional visibility. |
| `total_pas_at_or_above`  | High-PA plans (e.g. ≥ 12 PA) that carry outsized workload.             |
| `spa_pct_below`          | Plans allocating less than the Trust-set SPA floor.                    |
| `override_count_above`   | Plans that have already used multiple SPA-minimum overrides.           |

Each rule combines a **threshold value** (numeric) with the **required reviewer role** whose holder must sign the override at approval time. At most one rule per trigger kind per tenant — replace an old rule by deleting it and adding a new one.

The v1.7.4 surface is CRUD only. The trigger evaluation + additional-signer requirement will land as an approval-time gate in the next release, once Trusts have had a chance to calibrate their thresholds.

## Appeal SLA notifications

**Where.** Audit trail (search for `job_plan.appeal_sla_breached`). No UI surface in v1.7.4 — the audit stream is the interface.

Guidelines §6.11 defines a four-stage appeal cascade. Each stage carries a review deadline. ReSouris runs a daily cron that walks every open appeal and fires a `job_plan.appeal_sla_breached` audit event when an appeal exceeds its stage deadline.

### Default deadlines

| Stage            | Deadline (calendar days) |
| ---------------- | -----------------------: |
| Informal         |                        7 |
| Mediation        |                       14 |
| Formal appeal    |                       28 |
| Executive review |                       42 |

Values are monotonically non-decreasing by cascade severity — later stages carry more deliberation time. The daily cron runs at 03:00 UTC.

### Dedupe behaviour

The cron uses a **1-day dedupe window** so a re-run within the same day does not spam the audit trail. A still-open breach re-fires the next day (and every day thereafter) as a live nag signal until the appeal is resolved. Resolved appeals (with `closed_utc` set) stop firing immediately.

### Payload shape

Each breach event carries:

* `appeal_id`, `plan_id`, `staff_id` — the appeal and its subject.
* `kind` — one of `informal`, `mediation`, `formal_appeal`, `executive_review`.
* `opened_utc` — when the appeal stage opened.
* `breached_utc` — the deadline (opened + SLA days).
* `sla_days` — the deadline threshold in days.

Trusts that need to route breach notifications elsewhere (email, dashboard, ticket) can subscribe to the audit stream and filter on `action = 'job_plan.appeal_sla_breached'`.

## Where this fits in the wider Guidelines coverage

| Guidelines section                | Surface                  | ReSouris location                          |
| --------------------------------- | ------------------------ | ------------------------------------------ |
| §5.1.5 quarterly reconciliation   | Sign-off snapshot        | `/ui/admin/job-plan-reconciliation/latest` |
| §6.2 triple-signoff cascade       | Third-leg DLS nomination | `/ui/admin/job-plan-designated-lead`       |
| §6.7 enhanced-scrutiny thresholds | Trust CRUD               | `/ui/admin/enhanced-scrutiny-rules`        |
| §6.9 consistency panels           | Trust panel machinery    | `/ui/admin/consistency-panels`             |
| §6.11 appeal cascade              | Appeal SLA cron          | audit event stream                         |
| §6.12 KPI headline metrics        | Preset dashboard bundle  | `/ui/admin/job-plan-monitoring`            |


---

# 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/consistency-and-appeal-sla.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.