> 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/wte-and-session-based.md).

# WTE scaling and session-based rendering

ReSouris's v1.7.4 release adds a single source of truth for per-worker whole-time-equivalent (WTE) scaling: `staff.wte_fraction`. Two Guidelines-mandated behaviours read it:

* **Guidelines §5.1 SPA-minimum pro-rating** — a band 8 worker on 0.5 WTE has a pro-rata SPA minimum equal to half the full-time figure.
* **Guidelines §6.12 KPI headline denominators** — the "team SPA compliance" widget renders against per-worker WTE-scaled expected hours, not against the assumed-full-time raw number.

The v1.7.4 release lands the substrate. Where existing surfaces already assume full-time, they continue to work correctly for full-time workers and improve for part-timers as data-plane callers pick up the pro-rated helper.

## Setting a worker's WTE

WTE is stored on the `staff` row alongside band grade, contract kind, and other core attributes. Values must be strictly between 0 and 1.00 (inclusive of 1.00), with two decimal places of precision — so 0.60, 0.75, 0.80 are typical values.

* **Default is 1.00.** Pre-P43 rows are all backfilled as full-time, matching the prior implicit assumption. No manual backfill needed.
* **Edit gate** stays on the surrounding admin staff-edit flow. There is no separate WTE permission — anyone who could edit the staff row can also edit WTE.

## SPA-minimum pro-rating

The Guidelines Table 2 minimum SPA percentage is defined for a full-time worker. ReSouris's approval-time check reads the target percentage and the worker's WTE, then pro-rates the absolute hours accordingly. The percentage minimum is unchanged (still 25% for band 8, say), but the *absolute* SPA hours required scale with WTE.

The upshot: 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.

## KPI denominators

Widgets in the `/ui/admin/job-plan-monitoring` preset dashboard now compute per-worker expected hours using WTE-scaled contracted hours. The visible effect: PT-heavy teams no longer show a systemic under-compliance signal on the SPA-compliance widget, because the denominator matches the actual contract.

## Session-based rendering

MIG-192 (v2.0 P42) introduced a `staff.contract_kind` closed set with two values:

* `time_based` (default) — worker's PA counts render as `"N.NN PA"`.
* `session_based` — worker's PA counts render as `"N sessions"`, with an optional `(M/week)` cadence appended when `staff.sessions_per_week` is set.

Rollup UIs (team plan aggregates, KPI labels) switch based on the worker's contract kind. Forward-compatible: an unknown `contract_kind` (from a future release) falls back to the `PA` rendering rather than emitting a raw literal to the operator.

## What deliberately did not change

* **The `role_spa_minimum` seed** (per-band %s from Guidelines Table 2) is unchanged. Only the interpretation for PT workers is affected.
* **Existing admin surfaces** continue to render as before for full-time workers; PT workers benefit as data-plane callers pick up the new helper (surface-by-surface migration; no big-bang change).
* **No new permission** was added. Editing WTE stays under the existing staff-edit gate.


---

# 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/wte-and-session-based.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.