Wiki:Packs/Work Placement Processes

A deployable Claude project setup for localizing the four generic process cards of the work-placement pillar into one workforce function's standard: the placement decision through the gate, the vendor performance review cycle, the sourcing decision under imperfect data, and the loan and trade between internal pools. Each card is carried as a reference file condensed from its wiki page, with its profile, L1 flow, L2 rows, variant classes, L3 register and ranked automation candidates; a shared rules file holds the SET LOCALLY mark, the variant test, the tier vocabulary, the number grades and the catch-rate release rule. The pack produces, per card, the function's own L0 cover with its profile settled, its L1 flow with owning seats, its L2 step table, its L3 register and its variant rows. Copy Block 1 into a project's custom instructions; save Blocks 2–6 as Markdown files and upload them as project knowledge. See Wiki:Packs for how packs work.

When to use it

Use this pack when a function has a catalog row for a work-placement process and must turn the generic card into its own documented, certifiable process: on the day the placement section of its standard is due, when a certifier asks for the L2 of the gate flow or the scorecard cycle, or when a predecessor organization's sourcing committee, scorecard format or loan practice has to be reconciled with the standard as variants rather than as a second copy. It is not for running the gate's six tests, building the constraint register or the supply cards (Wiki:Packs/Placement Decision Engine Build, CP-WFM-008), building the comparability map (Wiki:Packs/Service Quality Comparability, CP-WFM-003), or deciding what the function's processes are (Wiki:Packs/Process Inventory and Shell Catalog, CP-OPS-008). Wiki:Packs/Process Decomposition (CP-OPS-001) is the engine: its fifteen-column L2 table, its L0 form and its shell marks are what this pack's output is written into. This pack carries the cards. Sibling packs carry the other pillars: CP-OPS-009 forecasting, CP-OPS-010 scheduling, CP-OPS-011 real-time, CP-OPS-013 the continuity interface, CP-OPS-014 cross-cutting governance.

How to deploy

1. Create a project in Claude named for the function's work, not the method: "Placement section localization", not "Process cards".
2. Paste Block 1 into the project's custom instructions.
3. Save each remaining block as the filename in its heading and upload it as project knowledge.
4. Start a conversation naming the card (GP-401 to GP-404), with the function's catalog row for it, its list of supply nodes (sites, service centers, partners, automated capacity) and, where one exists, its constraint register's strictness classes.

Block 1 — Project instructions

You are localizing generic process cards for the work-placement pillar of a
workforce function's standard. The pillar's four cards are in the reference
files; `localization-rules.md` holds the conventions. The cards are generic:
every threshold, band, cap, readout target and system name is marked SET
LOCALLY, and the deploying function supplies those values on its own L0 and
L3.

Vendor management is not a function: a partner is a supply node like a hub
or a service center; placing work with it is a decision of the placement
function, and reviewing the placed work is a process of that same function,
on the same instrument and definitions as any internal supply node; no
separate vendor-management function, no second scorecard. The supply-node
owner, who owns the body of work and never operates the supply node, decides
outside the function's tier ladder: the function owns the method and signs
the advice (tier 3 or 4 per card); the supply-node owner accepts, pays the
stated price or declines, and a decline is recorded with its price.

Routing: open the file for the task.

| Task | File |
|---|---|
| Any card: profile rows, the variant test, tiers, grades, releases | `localization-rules.md` |
| The gate flow: door, proposal, counterfactual, sitting, output page, recompute | `gp-401-placement-decision-through-the-gate.md` |
| The scorecard cycle: comparability, method signature, review, fee at risk, allocation | `gp-402-vendor-performance-review-cycle.md` |
| The near-term sourcing decision: evidence tiers, assumptions grid, sensitivity table | `gp-403-sourcing-decision-under-imperfect-data.md` |
| A loan or trade between internal pools: eligibility, tier, execution, settlement | `gp-404-loan-and-trade-between-internal-pools.md` |

For the card the user names, in this order:

1. Read its profile with the user and settle each row as `true as written`,
   `SET LOCALLY: <value>` or `variant: <class>`.
2. Walk the L1 one step at a time, confirming the owning seat per step.
3. Expand the L2 rows into the function's own fifteen-column table
   (CP-OPS-001 `framework.md`), filling owner, ticketing code, notification,
   approver and duration.
4. Run the variant test on every local difference and write the variant rows.
5. Carry the automation candidates over unchanged, in the card's rank order,
   and ask for the function's catch-rate evidence per class before marking
   any as released.
6. Emit `L0-cover.md` (identity + profile), `L1-flow.md`,
   `L2-step-decomposition.md`, `L3-register.md` and `variants.md`.

Disciplines:
- Never fill a local value the user has not given; leave the mark and seat.
- Never name a product or platform in any file marked for publication.
- Two owners on one step, a decision with no decider, a job aid that does not
  exist: a finding, in its own section, never a footnote.
- Seats, never names. Tier vocabulary only: tiers 1 to 4, executive sponsor
  by exception; boards and committees are forums, never tiers.
- Every number keeps its grade; every number the user adds gets one.
- A signature, a sealed counterfactual, a bilateral agreement and the
  supply-node owner's decision are never candidates; a step the card marks
  "never a candidate" stays human.
- A contract term is a constraint-register entry, SET LOCALLY, not a variant.
- One card per conversation.

Output: the five Markdown files, each headed with the card id, the local card
id, version and date; a findings section listing every unresolved SET
LOCALLY, every variant row awaiting approval and every ownership conflict;
every automation candidate marked `flagged` or `released on evidence:
<reference>`. Refuse to localize a process the function has not described,
to set a local value by inference, or to publish a file that names a
platform.

Source: Wiki:Packs/Work Placement Processes (CP-OPS-012) v1.0

Block 2 — localization-rules.md

<!-- Derived from [[Standard and Variant in Process Documentation]], [[Decision Authority Tiers in Workforce Operations]], [[Human Gates and Number Grades]] and [[Process Shells for a Workforce Standard]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# Localization Rules

The conventions every card file in this pack follows and every localized
artifact must keep. Read before the first card.

## 1. SET LOCALLY

A generic step never carries a threshold, a calendar, a system name, a
notification value or a named approver. Where the step needs one, the row
reads `SET LOCALLY — <seat>`: a value exists, it is local, and the seat named
holds it. The deploying function fills it on its own L0 and L3, never on the
generic card.

- A profile row settled with the user reads exactly one of `true as written`,
  `SET LOCALLY: <value>` or `variant: <class>`.
- Never fill a SET LOCALLY value the user has not given; leave the mark and
  its seat.
- A local value changes nothing above it. Trigger, scope, class and authority
  tier are the card's; changing any of those reopens L0 approval. A local
  value does not.
- Platforms are named at L3 and in the user's own artifacts only, never in a
  file marked for publication.

## 2. The variant test (ask in order, for every local difference)

1. Does the generic step fail here, or does the site prefer another way?
   Preference is not admitted.
2. Can the difference be expressed as a parameter of the generic step (a
   threshold, a calendar, an approver tier)? Then it is SET LOCALLY and takes
   no variant row.
3. If a different step is needed, does it change the step's owner, its inputs
   or outputs, or its position in the flow? Only then is it a variant.
   Otherwise it is an L3 work-instruction difference, held in the local job
   aid.
4. What would retire it? Every row names its retirement condition, even "the
   statute changes".

The test is asymmetric by design: a parameter is cheap; a variant is a branch
that every automation rule must carry and the overseer must verify separately.

## 3. The four variant classes

| Class | What it is | Approver | Expiry or review |
|---|---|---|---|
| statutory | law or regulation in a jurisdiction | function head (tier 4), on legal advice | review date |
| contractual | a client contract or a collective agreement | placement and vendor lead (a tier 3 seat of the placement pillar) | reviewed at renewal |
| structural | a site, platform or channel that cannot run the generic step | the process owner, at that seat's tier | review date |
| transitional | a predecessor organization's way, kept until a dated cut-over | the standards committee | expires; the date is mandatory |

A variant row carries: `V-nnn` · process and steps modified · scope (as
classes where published outside the function) · class · the difference, in
the same active voice and ownership form as the generic step · owner seat ·
approved by and date · expiry or review · automation effect (`blocks` ·
`parameterizes` · `none`).

## 4. Authority tiers (write only these)

| Tier | Seat | Signs |
|---|---|---|
| 1 | the pillar's analyst seat inside guardrails (scheduler, forecaster, real-time analyst, placement analyst) | actions inside published guardrails; no approval sought |
| 2 | supervisor or team lead | actions the guardrails exclude, on the analyst's recommendation; minor L2 and L3 changes |
| 3 | operations manager or ROC duty lead | actions that cross a queue, skill, site or supply node; incident ownership at the top severity rows |
| 4 | function head | the lock, the plan of record, build parameters, a statutory variant, a version of the standard |
| exception | executive sponsor | a gap outside the band the plan can absorb; one client's service traded against another's; a change to the standard's scope |

A seat may take a lower tier's decision, never a higher tier's. Never write
"planner tier"; never make a board or a committee a tier. Where the decision
belongs to a supply-node owner under the decision-rights table, write
"advice at tier n; decision per the decision-rights table".

## 5. Number grades

Every number carries a bracket: `[M]` measured · `[C]` computed · `[E]`
estimated · `[A]` asserted. A computed figure is never better than its weakest
input. Nothing carried across a platform, channel or cohort change is [M] in
the new state; it is [A] until measured there. An [A] figure may inform a
proposal but may not by itself carry a plan. Prefer "typically" + [A] over
invented precision. Keep every grade the card carries; give every number the
user supplies a grade.

## 6. One owner per step

Each L1 step and each L2 row has exactly one owning seat; seats, never names.
Where a card writes two seats ("scheduler; capacity planner"), the first owns
and the second contributes; confirm this with the user. Two seats claiming one
step, a decision with no decider, or a named job aid that does not exist is a
finding, reported in its own section. Decision steps are questions.

## 7. The catch-rate release rule

An automation candidate is flagged at L2 (at L1 on a deferring card). It is
released per class of action on a published catch rate: the proportion of
the rule's known errors that the verification step detects, published per
class and per variant, never per process and never on a maturity label. A
rule is released into the tier of the seat whose decision it replaces, never
above it. Release order: the generic step first; then each variant whose
automation effect reads `parameterizes`; never a variant whose effect reads
`blocks` until it is retired or the rule rewritten. Carry the card's ranked
list over unchanged; ask for the function's catch-rate evidence per class
before marking any candidate released; a candidate without evidence stays
`flagged`. A step the card names as never a candidate stays human in every
localization.

## 8. Vocabulary

Class: strategic · real-time · both · supporting. L3 forms: work instruction ·
playbook · runbook. Lifecycle status: `Shell` · `1.1 approved` · `1.2
authoring` · `1.3 in peer review` · `2.1 submitted` · `2.1 approved` · `2.1
conditionally approved` · `2.1 not approved` · `2.2 deploying` · `Live` ·
`3.1 under review` · `Certified L<n>` · `Expired`. Dates as "Thu 16 Oct 2026".
Write "client portfolio" for a set of client contracts, "supply node" for a
site, partner or platform that supplies capacity, and "predecessor
organization" for an organization absorbed by merger or acquisition.

Block 3 — gp-401-placement-decision-through-the-gate.md

<!-- Derived from [[Placement Decision Through the Gate (generic process)]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# GP-401 Placement Decision Through the Gate

The flow that turns a placement question, any ask that would put a body of
work somewhere other than where it sits now, at any horizon, into a
recorded decision: intake door, proposal in the gate's terms, constraint
check, the sitting, the one-page output with its counterfactual sealed
first, the function head's signature as the function's advice, the supply node
owner's decision, the ramp commitment, a monitoring owner and mitigation
trigger, and the filing that makes the decision recomputable. The gate is a
check, not a process; the flow gives it one door, one form, one output, one
signature, one filing. Not restated: the six tests and five outcomes on
Placement Engine Architecture; the instrument on Placement Rules and the
Tenure Contract; the practice on The Placement Gate.

## Profile
| Field | Generic value |
|---|---|
| Card | GP-401 · local id by the standards committee |
| Class | both: the same flow serves a renewal eighteen months out and an overflow proposal for next week; only the readout target differs |
| Trigger | a placement question reaches the intake door, or a recompute trigger fires against a recorded decision |
| Cadence | on demand; typically two or three live questions a quarter in a function that has just adopted the gate [A]; a recompute pass monthly (SET LOCALLY) |
| Scope in | every proposal moving a body of work between supply nodes (hub, service center, partner, automated capacity) at any horizon: renewals, overflow, new client portfolios, pool moves, automation absorbing a task type |
| Scope out | the tests' arithmetic; the constraint register's upkeep; the routing change that executes a decision; the vendor scorecard (GP-402); shaping a sourcing proposal before the door (GP-403) |
| Inputs | the ask as it arrived; constraint register; supply cards of the sending supply node and the receiving supply node; the forecast and its lock; definitions register; contract renewal calendar |
| Outputs | the gate output page (six results, price or date, citations, counterfactual, signed advice, decision); ramp commitment; monitoring assignment and mitigation trigger; recompute-log entry; a definitions-register row per cannot-run |
| Upstream | the intake door; the monthly clearing; the capacity plan (GP-102); the incident record via the continuity wire |
| Downstream | routing and change control; the vendor review cycle (ramp milestones become scorecard rows); scheduling; finance; the recompute log |
| Resources | constraint register; supply cards; queueing arithmetic for the coverage and pooling tests; output page template; recompute log; platforms at L3 only |
| Decision points | is this a placement question; can it be written in the gate's terms; did every test run; accept, pay or decline; has a recompute trigger fired |
| Authority tier | tier 3 (placement lead) sits the gate; tier 4 (function head) signs the outcome as the function's advice; the supply-node owner, who owns the body of work and never operates the supply node, decides outside the function's ladder and records a decline with its price; a change to the network's design goes to the executive sponsor |
| Risk and compliance flags | a move changing the work's jurisdiction engages consultation obligations; a move across a contract boundary is a commercial change; a decision filed without its counterfactual can never prove the gate's value or redundancy |
| Variant-prone steps | consultation where required; the signature where a predecessor organization's sourcing committee still signs; the card read where a supply node has no supply card |
| Automation candidates | eight L2 sub-steps (eight ranks) |

## L1 flow (fifteen steps, five decisions; owner seat per step)
1. Receive the ask. Decision: a placement question? Yes → 2; no → the door's other routes — intake owner
2. Write the proposal in the gate's terms: body of work, sending supply node, receiving supply node, horizon, owner of the work, requester — placement analyst
3. Decision: body of work labeled once across channels, every field filled? Yes → 4; no → return to the door with the gap named — placement analyst
4. Seal the counterfactual: what the proposal's owner would decide without the gate, before any test runs — supply-node owner
5. Pull the binding constraint-register entries, cited by identifier with strictness class and date — placement analyst
6. Read the supply cards of the sending supply node and the receiving supply node — placement analyst
7. Sit the gate: six tests, one row each with outcome, number and grade — placement lead
8. Decision: every test run? Yes → 9; no → cannot-run; name the missing input and its obtainer; open a register row; partial readout inside the readout target (SET LOCALLY) — placement lead
9. Assemble the one-page output: six results, every non-pass in one sentence with its number, price or date, citations, counterfactual, decision field open — placement analyst
10. Sign the outcome as the function's advice; refer a network-design change to the executive sponsor — function head
11. Decision: accept, pay the stated price, or decline? A decline carries its price; a priced acceptance is a purchase — supply-node owner, outside the ladder
12. Record the ramp commitment: time to fill, time to proficiency, milestones, steady-state target, each tracked separately — placement lead
13. Name the monitoring owner; write the mitigation trigger as an observable condition — placement lead
14. File the page, counterfactual and ramp sheet; cross-reference every cited entry — registers' steward
15. Decision, monthly: a recompute trigger fired? Yes → rerun from 5 with the sealed counterfactual carried; no → stands — placement lead

## L2 step table (readout targets, thresholds, platforms SET LOCALLY)
| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | 1.1 Apply the labeling question; log the ask | intake owner | the ask | class; log entry | minutes | Y (logging) | L3-401-01 |
| 2 | 2.1 Fill the six proposal fields | placement analyst | ask; body-of-work dictionary | proposal | one sitting | N | L3-401-02 |
| 3 | 3.1 Check the label is one across channels; return if a field is empty | placement analyst | definitions register | pass, or return note | same day | Y (lookup) | L3-401-02 |
| 4 | 4.1 Write and seal the counterfactual | supply-node owner | proposal | sealed record | before 5 | N — never | L3-401-03 |
| 5 | 5.1 Query binding entries; flag lapsed dates and open disagreements | placement analyst | constraint register | cited entries with class and date | minutes | Y (query) | L3-401-04 |
| 6 | 6.1 Read both supply cards; carry each attribute's grade | placement analyst | supply cards | card extract | minutes | Y (lookup) | L3-401-05 |
| 7 | 7.1 Run continuity and construct fit from the register | placement lead | cited entries; proposal | two test rows | one sitting | N | L3-401-06 |
| 7 | 7.2 Compute coverage floor and pooling cost | placement lead | volume, handle time, shrinkage, service target, graded | two rows with numbers and grades | one sitting | Y (arithmetic) | L3-401-06 |
| 7 | 7.3 Read contractual eligibility and language viability | placement lead | cited entries; card tenure and volume fields | two test rows | one sitting | N | L3-401-06 |
| 8 | 8.1 Per test not run: name input and obtainer; open a register row | placement lead | test rows | cannot-run rows; register rows | same day | N | L3-401-09 |
| 9 | 9.1 Assemble the output page | placement analyst | rows, citations, counterfactual | output page, decision open | one sitting | Y (assembly) | L3-401-07 |
| 10 | 10.1 Sign as the function's advice; refer a network-design change | function head | output page | signed advice, or referral | inside readout target (SET LOCALLY) | N — never | L3-401-07 |
| 11 | 11.1 Record the decision; a decline carries its price | supply-node owner | signed page | recorded decision | inside readout target (SET LOCALLY) | N — never | L3-401-07 |
| 12 | 12.1 Write the ramp commitment | placement lead (receiving supply-node lead consulted) | card's speed fields | ramp sheet | one sitting | N | L3-401-08 |
| 13 | 13.1 Name the monitoring owner; write the trigger | placement lead | ramp sheet; trigger list | monitoring assignment | minutes | N | L3-401-08 |
| 14 | 14.1 File and cross-reference | registers' steward | completed page | recompute-log entry | same day | Y (filing) | L3-401-10 |
| 15 | 15.1 Walk the trigger list against open decisions | placement lead | trigger list; renewal calendar; card change log | decisions to rerun | monthly | Y (detection) | L3-401-10 |

Row 12.1 names two seats on the live card; settle one owner, record the
other as consulted, or report a finding.

## Variants
- Statutory: a works council's consultation right over moving work into or out of a site → consultation step between 11 and 12, owner works-council liaison, approver function head; the obligation is a hard register entry, the inserted step is the variant.
- Contractual: a contract forbidding overflow, fixing a construct or dedicating a pool is a register entry read at step 5 → SET LOCALLY, no row; a fail or priced fail is the generic step working.
- Structural: a supply node with no supply card returns cannot-run on two tests; step 6 varied to read a declared interim sheet, reviewed monthly until a card exists.
- Transitional: a predecessor organization's sourcing committee still signing → second signature at step 10 under a row with an expiry the standards committee dates.

## L3 register (readout target and recompute bounds SET LOCALLY)
| Job aid | Anchored to | Form |
|---|---|---|
| L3-401-01 Labeling question at the door; question log | 1 | work instruction |
| L3-401-02 Proposal form; body-of-work dictionary; return note | 2–3 | work instruction |
| L3-401-03 Counterfactual seal: who writes, where held, who may open | 4 | work instruction |
| L3-401-04 Constraint-register pull: query, citation format, date and disagreement checks | 5 | work instruction |
| L3-401-05 Supply-card read sheet | 6 | work instruction |
| L3-401-06 Six-test workbook: arithmetic rows, register reads, row format | 7 | work instruction; Erlang C; Pooling Architecture in Service Workforces |
| L3-401-07 Output page template, signature block, decision record | 9–11 | work instruction |
| L3-401-08 Ramp commitment sheet; mitigation trigger form | 12–13 | playbook |
| L3-401-09 Cannot-run readout | 8 | runbook |
| L3-401-10 Recompute log; trigger list with owners and sources | 14–15 | playbook |

## Automation candidates (ranked by ease of publishing a catch rate)
1. Constraint-register pull (5.1): a deterministic query with a date check; every error is a countable mismatch.
2. Supply-card read (6.1): after 1 because a card attribute carries a grade the lookup must copy, one more failure class.
3. Coverage-floor and pooling-cost arithmetic (7.2): after 2 because its catch rate depends on the inputs' grades as well as the formula.
4. Label check (3.1): after 3 because "one across channels" is a register judgment the lookup only approximates until the register is complete.
5. Output-page assembly (9.1): after 4 because it composes four earlier candidates and inherits their error classes.
6. Filing and cross-reference (14.1): after 5 because a filing error is silent until a recompute needs the citation.
7. Question log (1.1): after 6 because it is only as good as the labeling question answered by hand before it.
8. Recompute-trigger detection (15.1): last because its catch rate is published against a hand-kept trigger log built for a quarter first.

Never: the counterfactual seal (4.1), the one record by which the gate
proves its value or redundancy; the function head's signature (10.1); the
decision (11.1), the supply-node owner's. A hard constraint excludes and never
lowers a score, so a fail is computable; paying a price is a purchase and
is not.

Block 4 — gp-402-vendor-performance-review-cycle.md

<!-- Derived from [[Vendor Performance Review Cycle (generic process)]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# GP-402 Vendor Performance Review Cycle

The monthly cycle that scores every external supply node, reviews the score
with the partner, agrees corrective action, settles the fee at risk and
decides whether the score moves any allocation. Vendor management is not a
function: the partner is a supply node like a hub or a service center, placing
work with it is a placement decision, and reviewing the placed work is a
process of the same function on the same instrument and definitions as any
internal supply node. A second scorecard lets a partner optimise the cheaper one.
A supplier ranked on outcomes dominated by the system it operates within
has been ranked on the system, so the cycle has a comparability check
before a scorecard, a method owner who signs the method and a function head
who signs the findings; neither approves the consequence. Not restated:
Performance-Based Vendor Allocation Design (comparability, the three
components, fee at risk, allocation); BPO and Vendor Workforce Management;
Vendor Change Control for Routing.

## Profile
Local values are marked SET LOCALLY.

| Field | Generic value |
|---|---|
| Card | GP-402 · local id by the standards committee |
| Class | supporting; its allocation consequence feeds the strategic placement decision, its ramp rows read the real-time record |
| Trigger | first business day after the month's actuals close (SET LOCALLY) |
| Cadence | monthly per partner supply seat (one supplier, one body of work, one commercial form); cross-partner calibration quarterly; weights reviewed only at an announced date |
| Scope in | every external supply node; every body of work placed there; the three components per channel; corrective-action register; fee-at-risk settlement; allocation consequence |
| Scope out | the placement decision (GP-401); contract negotiation and renewal; invoice validation and rate-card true-ups; the routing change itself; the daily performance conversation at the partner's site |
| Inputs | the month's interaction-level data from the buyer's systems; the partner's own figures (reconciliation inputs only); contract bands, fee mechanism, renewal date; the ramp commitment from the gate; the comparability map; last month's actions |
| Outputs | signed scorecard per partner and channel, every number graded; review record; corrective-action register; fee-at-risk settlement; allocation decision (moved, held, deferred to renewal) with reason; updated supply card |
| Upstream | the gate output and ramp commitment; definitions register; the forecast delivered under contract; the capacity state from intraday automation |
| Downstream | change control (a move); the capacity plan; the sourcing decision (the card's quality and reliability fields); finance; the recompute log (a materially changed card is a trigger) |
| Resources | one measurement instrument across supply nodes; scorecard template; comparability map; action register; fee calculation; guardrail check; platforms at L3 only |
| Decision points | every delta path at comparability grade A or B; any component outside its band; does the index move the allocation inside the guardrails and the capacity gate |
| Authority tier | the method owner (tier 3) signs the method; the function head (tier 4) signs the findings as the function's advice; corrective action is agreed with the partner by the partner's oversight owner; an allocation move is approved by the change-control board, a forum not a tier; a change to the partner network's design goes to the executive sponsor |
| Risk and compliance flags | a scorecard on the partner's own figures is unaudited; a consequence on an unvalidated adjustment loses credibility with every partner; interaction data crossing a jurisdiction engages data-protection law; the commercial pen and the daily performance conversation are different seats |
| Variant-prone steps | the data pull where law restricts export; the fee step where no fee-at-risk clause exists; the format where a predecessor organization's scorecard is contracted |
| Automation candidates | ten L2 sub-steps (ten ranks) |

## L1 flow (fifteen steps, three decisions; owner seat per step)
The oversight owner is the buyer-side seat holding the commercial pen.
1. Open the cycle; confirm the partner list and each seat's bands — placement analyst
2. Pull the month's data on one instrument per body of work from the buyer's systems — reporting analyst
3. Reconcile the partner's figures; log each discrepancy with its cause; open a definitions-register row where definitions differ — reporting analyst
4. Decision: every delta path at comparability grade A or B? Yes → 5; no → C reported as direction only, D separately, no stated delta — method owner
5. Assemble the scorecard per channel on the three components and the single index, ramp read against the gate's milestones, every number graded — placement analyst
6. Validate and sign the method: case-mix adjustment refitted on the cadence the work changes; adjusted ranking agrees with the ranking on a randomly assigned slice — method owner, separate from the findings signatory
7. Issue the pre-read; open the dispute path with its closing date — oversight owner
8. Hold the bilateral review: findings by component, root causes, disputes, last month's actions; partner present — placement lead
9. Decision: any component outside its contracted band? Yes → 10; no → 11 — placement lead
10. Agree corrective action with the partner: one owner, one date, the closing measure; close or carry prior actions — oversight owner
11. Sign the findings as the function's advice — function head
12. Compute the fee at risk on the index and the contract's mechanism; pass to the oversight owner, who alone transacts it — placement analyst
13. Decision: does the index move the allocation inside the guardrails and the capacity gate? Yes → change request to the board; no → "held" with reason; an expensive move queued to renewal — placement lead
14. Publish the cycle record; update the partner's supply card — registers' steward
15. Quarterly: calibrate across partners on aggregate distributions, never a leaderboard; weights only at the announced date — method owner

## L2 step table (bands, weights, dates, platforms SET LOCALLY)
| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | 1.1 Confirm partner list, bands, renewal dates | placement analyst | contract register | cycle sheet | minutes | Y (lookup) | L3-402-01 |
| 2 | 2.1 Run the pull per body of work on the one instrument | reporting analyst | buyer's systems | data set with grades | same day | Y (extraction) | L3-402-02 |
| 2 | 2.2 Receive the partner's figures | reporting analyst | partner report | reconciliation input | same day | N | L3-402-02 |
| 3 | 3.1 Reconcile; classify each discrepancy (definition, coverage, timing, error) | reporting analyst | pull; partner figures | discrepancy log | one sitting | Y (matching) | L3-402-03 |
| 3 | 3.2 Open a register row per definitional difference | reporting analyst | discrepancy log | register rows | minutes | N | L3-402-03 |
| 4 | 4.1 Read each path's comparability grade; mark C and D | method owner | comparability map | reporting rule per row | minutes | Y (lookup) | L3-402-04 |
| 5 | 5.1 Compute components per channel and the index | placement analyst | data set; published weights | scores; index | one sitting | Y (arithmetic) | L3-402-05 |
| 5 | 5.2 Read ramp attainment; attrition at account level with tenure distribution | placement analyst | ramp sheet; staffing extract | reliability rows | one sitting | N | L3-402-05 |
| 6 | 6.1 Check refit and random-slice agreement; sign the method | method owner | model record; slice ranking | signed method | one sitting | N — never | L3-402-06 |
| 7 | 7.1 Issue the pre-read; log the dispute window | oversight owner | signed scorecard | pre-read record | same day | Y (issue) | L3-402-07 |
| 8 | 8.1 Run the review to the agenda; minute findings and disputes | placement lead (oversight owner co-chairs) | scorecard; prior actions | minutes | one meeting | N | L3-402-08 |
| 9 | 9.1 Compare each component to its band; list breaches | placement lead | scorecard; bands | breach list | minutes | Y (comparison) | L3-402-08 |
| 10 | 10.1 Agree owner, date, closing measure per breach | oversight owner | breach list; register | updated register | inside the review | N — never | L3-402-09 |
| 11 | 11.1 Sign the findings | function head | scorecard; minutes; actions | signed findings | same day | N — never | L3-402-09 |
| 12 | 12.1 Compute the fee at risk; pass to the oversight owner | placement analyst (oversight owner approving) | index; mechanism | settlement instruction | same day | Y (arithmetic) | L3-402-10 |
| 13 | 13.1 Run the guardrail check (floors, ceilings, deadband, capacity gate, sample threshold) | placement lead | index; guardrails; capacity state | move, hold, or defer | minutes | Y (check) | L3-402-11 |
| 13 | 13.2 Raise the change request where the check passes | placement lead | guardrail result | change request | same day | N | L3-402-11 |
| 14 | 14.1 Publish the record; update the card; flag a material change as a recompute trigger | registers' steward | all outputs | cycle record; card update | same day | Y (filing) | L3-402-12 |
| 15 | 15.1 Quarterly calibration; weight review at the announced date | method owner | four cycles' records | calibration note | one sitting a quarter | N | L3-402-13 |

Rows 8.1 and 12.1 name two seats on the live card; one owner each here,
the other recorded as consulted or informed, or reported as a finding.

## Variants
- Statutory: data-protection law forbidding interaction-level export → 2.1 varied to in-jurisdiction sampling on the same instrument, at the grade sampling earns; owner method owner, approver function head on legal advice.
- Contractual: bands, weights and fee mechanism are contract parameters, SET LOCALLY, no row; no fee-at-risk clause → step 12 removed for that seat under a row dated to renewal.
- Structural: a partner with no data feed is scored from its own reports at [A], every path at comparability grade C at best; pull step varied, reviewed quarterly; no allocation consequence on a grade C path.
- Transitional: a predecessor organization's scorecard format written into the contract → both formats under a row until the renewal date, the expiry.

## L3 register
Bands, weights and dates are SET LOCALLY in the L2 rows; each decision
branch is an L2 row of its own.

| Job aid | Anchored to | Form |
|---|---|---|
| L3-402-01 Cycle calendar; partner-seat sheet with bands and renewal dates | 1 | work instruction |
| L3-402-02 Data-pull specification per body of work | 2 | work instruction |
| L3-402-03 Reconciliation sheet; discrepancy classification | 3 | work instruction |
| L3-402-04 Comparability map; reporting rule per grade | 4 | work instruction; Sourcing Strategy Under Imperfect Data |
| L3-402-05 Scorecard template: components, channels, index, grades | 5 | work instruction; Performance-Based Vendor Allocation Design |
| L3-402-06 Method-validation checklist: refit record, slice agreement, weight record | 6 | work instruction |
| L3-402-07 Pre-read and dispute path | 7 | work instruction |
| L3-402-08 Review agenda and minutes form | 8–9 | playbook |
| L3-402-09 Corrective-action register; findings signature block | 10–11 | playbook |
| L3-402-10 Fee-at-risk calculation sheet per mechanism | 12 | work instruction |
| L3-402-11 Guardrail check; renewal-deferral note | 13 | work instruction |
| L3-402-12 Cycle record layout; supply-card update | 14 | work instruction |
| L3-402-13 Quarterly calibration pack | 15 | playbook |
| L3-402-14 A partner's staffing collapses mid-month | 5–10 | runbook |

## Automation candidates (ranked by ease of publishing a catch rate)
1. Data pull (2.1): deterministic extraction from the buyer's own systems; every error is a row the reconciliation can count.
2. Partner-seat lookup (1.1): after 1 only because a lapsed band or date is caught later, at the review.
3. Reconciliation match (3.1): after 2 because matching two sources adds the false-match class; definitional causes stay human.
4. Comparability-map lookup (4.1): after 3 because the map is hand-maintained and a stale grade is invisible to the lookup.
5. Component and index arithmetic (5.1): after 4 because its catch rate depends on the inputs' grades as well as the formula.
6. Fee computation (12.1): after 5 because it inherits the index's errors and adds the mechanism's.
7. Band comparison (9.1): after 6 because a breach list is only as good as the bands on the seat sheet.
8. Guardrail check (13.1): after 7 because it reads the capacity state too; run live-but-inert, publishing the move it would have made, it earns its catch rate before any volume moves.
9. Pre-read issue (7.1): after 8 because an issuing error is caught by the partner, outside the function's verification.
10. Record filing (14.1): last because a filing error is silent until a recompute or audit needs it.

Never: the method owner's signature (6.1), the separation that keeps the
method from being tuned to a preferred outcome; the corrective-action
agreement (10.1), a bilateral commitment; the function head's signature
(11.1). The allocation move is the change-control board's, because
measurement produces signal continuously while a partner's capacity
responds over months.

Block 5 — gp-403-sourcing-decision-under-imperfect-data.md

<!-- Derived from [[Sourcing Decision Under Imperfect Data (generic process)]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# GP-403 Sourcing Decision Under Imperfect Data

The decision taken when a near-term placement must be made now, for a
financial target, a renewal or a migration, while the measurement estate
cannot yet support a fair comparison between the pools it chooses among.
Disciplines, on Sourcing Strategy Under Imperfect Data: decide now on what
is solid; choose on structure rather than scores that cannot discriminate;
state every assumption with its evidence tier; instrument every move so
the data foundation is built from the decisions themselves. That page gives
disciplines; this card owns the step sequence. Its product is a shaped
proposal handed to GP-401 with its assumptions grid, sensitivity table and
evidence-tier statement: the gate is the check, this is the shaping and
the record of what was assumed.

## Profile
| Field | Generic value |
|---|---|
| Card | GP-403 · local id by the standards committee |
| Class | strategic; horizon the near term, a quarter to a year [A] |
| Trigger | a dated commercial or operational event forcing a placement choice before the comparison estate is ready: a financial target, a client renewal, a migration, a contract expiry, a site decision |
| Cadence | on demand, by event; every open decision's assumptions grid re-read at each monthly recompute pass (SET LOCALLY) |
| Scope in | the shaping: frame and horizon, constraints by relax cost and lead time, the two evidence tiers, the comparability map, structural criteria, assumptions grid, sensitivity table, instrumentation sheet, the recommendation signed as advice, review dates |
| Scope out | the six-test check (GP-401); the long-horizon sourcing programme; the comparability study's method; the vendor scorecard that later reads the move (GP-402) |
| Inputs | counts, contracts, costs on a stated base, tenure records (hard tier); calibrated estimates with ranges (estimate tier); constraint register; supply cards; comparability map; the variable-cost-share audit at 30, 60 and 90 days |
| Outputs | the shaped proposal in the gate's six fields; assumptions grid, every input graded; sensitivity table; instrumentation sheet; evidence-tier statement; the signed recommendation; a review date per assumption |
| Upstream | the capacity plan and its clearing (GP-102); definitions register; renewal calendar; the comparability study |
| Downstream | the gate; the vendor review cycle and the capacity plan (the instrumented move's rows); the data foundation (definitions found missing); the recompute log |
| Resources | assumptions grid; input grade sheet; sensitivity table; comparability map; supply cards; platforms at L3 only |
| Decision points | a required hard-tier input missing; any path below comparability grade B; the answer reversing inside an estimated range; a review date or change condition fired |
| Authority tier | the placement lead (tier 3) signs the recommendation as advice; the function head (tier 4) signs the gate outcome in GP-401; the supply-node owner decides outside the function's ladder; a change to the network's design goes to the executive sponsor |
| Risk and compliance flags | an estimate printed as history; a move justified on an instrument that cannot discriminate; a tenure comparison dropped for a small group; a move that banks its benefit and leaves the data broken |
| Variant-prone steps | the hard-tier pull where a jurisdiction limits what may be recorded; the cost base where a contract prices a different unit; the map where a predecessor organization's instrument is still in use |
| Automation candidates | two L2 sub-steps (two ranks); few by design |

## L1 flow (thirteen steps, four decisions; owner seat per step)
Each step applies one discipline of the strategy page.
1. Frame the question and horizon: event date, body of work, candidate pools, what must be delivered and when — placement lead
2. Classify the binding constraints by relax cost and lead time from the register's strictness classes — placement analyst
3. Pull the hard tier: counts, contract terms as written, costs normalised to the stated base, tenure records — reporting analyst
4. Decision: a required hard-tier input missing? Yes → obtain before the event date, or carry as a named gap; no → 5 — placement lead
5. Build the estimate tier: every unmeasured input as a range with its grade, prioritised by value of information; never blended with the hard tier — placement analyst
6. Grade every comparison path on the comparability map — method owner
7. Decision: any path below comparability grade B? Yes → C as direction only, D separately; the decision rests on structure at 8; no → 8 — method owner
8. Run the structural criteria: concentration, integration, chainability, coverage floor, pooling penalty, contract terms — placement analyst
9. Build the assumptions grid: statement, grade, source, owner, what would change it, review date — placement analyst
10. Compute the sensitivity table: the answer at each end of every range, reversing inputs named. Decision: reversal inside any range? Yes → narrow, obtain, or carry it on the page; no → 11 — placement analyst
11. Write the instrumentation sheet: one scorecard at origin and destination, receiving-team tenure recorded, ramp tracked apart from steady state, definitions retired — placement analyst
12. Write the recommendation with its grid and evidence-tier statement; sign as advice; hand the shaped proposal in the gate's six fields to GP-401, whose step 4 seals the counterfactual — placement lead
13. Set a review date per assumption; log to the recompute pass. Decision, monthly: a date or change condition fired? Yes → rerun from 9; no → stands — placement lead

## L2 step table (lead time, cut-off, ranges, platforms SET LOCALLY)
| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | 1.1 Write the frame | placement lead | event; capacity plan | frame sheet | one sitting | N | L3-403-01 |
| 2 | 2.1 List constraints with class, relax cost, lead time | placement analyst | constraint register | constraint list | one sitting | N | L3-403-02 |
| 3 | 3.1 Pull counts, contract terms, costs, tenure records | reporting analyst | systems of record; contract register | hard-tier data with grades | same day | Y (extraction) | L3-403-03 |
| 3 | 3.2 Normalise every cost to the stated base | reporting analyst | rate cards; loaded-cost extracts | normalised cost rows | one sitting | N | L3-403-03 |
| 4 | 4.1 Mark each missing input: obtain by date, or named gap | placement lead | data set; event date | gap list | minutes | N | L3-403-03 |
| 5 | 5.1 Elicit each estimate as a range from its owner; grade it | placement analyst (estimate owners supply) | gap list; unmeasured inputs | estimate rows | one sitting per owner | N — never | L3-403-04 |
| 5 | 5.2 Order estimates by value of information; stop below the cut-off (SET LOCALLY) | placement analyst | estimate rows | prioritised tier | minutes | N | L3-403-04 |
| 6 | 6.1 Grade each path on the map | method owner | comparability map | path grades | minutes | N | L3-403-05 |
| 7 | 7.1 Apply the reporting rule per grade | method owner | path grades | rule per path | minutes | N | L3-403-05 |
| 8 | 8.1 Score each pool on the structural criteria | placement analyst | hard tier; constraint list | structural check sheet | one sitting | N | L3-403-06 |
| 9 | 9.1 Write the grid row per assumption | placement analyst | all above | assumptions grid | one sitting | N | L3-403-07 |
| 10 | 10.1 Recompute the answer at each end of every range | placement analyst | grid; structural check | sensitivity table | minutes | Y (arithmetic) | L3-403-08 |
| 10 | 10.2 Name reversing inputs; narrow, obtain, or carry | placement analyst | sensitivity table | reversal note | same day | N | L3-403-08 |
| 11 | 11.1 Write the instrumentation sheet and retired definitions | placement analyst | the move; definitions register | instrumentation sheet | one sitting | N | L3-403-09 |
| 12 | 12.1 Write the recommendation; sign as advice | placement lead | grid; table; sheet | signed recommendation | one sitting | N — never | L3-403-10 |
| 12 | 12.2 Fill the gate's six fields; hand off | placement lead | recommendation | shaped proposal | minutes | N | L3-403-10 |
| 13 | 13.1 Log a review date per assumption; walk monthly | placement lead (registers' steward logs) | grid | recompute entries | monthly | N | L3-403-11 |

Rows 5.1 and 13.1 name two seats on the live card; one owner each here,
the other recorded as consulted, or reported as a finding.

## Variants
- Statutory: a jurisdiction restricting what may be recorded about individuals limits tenure and attrition inputs to aggregates; 3.1 varied to carry the aggregate with its grade; owner works-council liaison, approver function head on legal advice.
- Contractual: a contract pricing a different unit (per contact, per resolved case, per productive hour) is a cost-base parameter of 3.2, SET LOCALLY, normalised before comparison; no row.
- Structural: a telemetry-dark pool with no readable instrument sits at comparability grade D; step 8 varied to exclude it from scored comparison and place it on structure alone, reviewed quarterly until an instrument exists.
- Transitional: a predecessor organization's quality instrument still in use keeps that body of work's paths at grade C under a row expiring at the instrument's retirement date.

## L3 register
| Job aid | Anchored to | Form |
|---|---|---|
| L3-403-01 Frame sheet | 1 | work instruction |
| L3-403-02 Constraint list by relax cost and lead time | 2 | work instruction; Placement Engine Architecture |
| L3-403-03 Hard-tier pull specification; cost-base sheet | 3–4 | work instruction |
| L3-403-04 Input grade sheet; calibrated-estimate elicitation | 5 | work instruction; Human Gates and Number Grades |
| L3-403-05 Comparability map; reporting rule per grade | 6–7 | work instruction; Sourcing Strategy Under Imperfect Data |
| L3-403-06 Structural-criteria check sheet | 8 | work instruction; Pooling Architecture in Service Workforces |
| L3-403-07 Assumptions grid layout | 9 | work instruction |
| L3-403-08 Sensitivity table; reversal note | 10 | work instruction |
| L3-403-09 Instrumentation sheet; retired-definitions list | 11 | playbook |
| L3-403-10 Recommendation form; evidence-tier statement | 12 | work instruction |
| L3-403-11 Review-date log; monthly walk | 13 | playbook |
| L3-403-12 A required hard-tier input cannot be obtained by the event date | 4 | runbook |

Two conventions: an estimate carries its range on every page, never a
point; a tenure comparison is never dropped for a small group, because a
higher score from a long-tenured team against a lower one from a new team
may describe the same capability at two costs. The sensitivity table is
the tornado diagram in tabular form.

## Automation candidates (ranked by ease of publishing a catch rate)
1. Hard-tier data pull (3.1): deterministic; every error is a row the sheet can count.
2. Sensitivity table (10.1): after 1 because it is arithmetic only once the grid exists, and its catch rate depends on the ranges being those the owners gave; the overseer checks that correspondence.

Nothing else. The structural criterion is a judgment about which risk the
estate can bear. Assumption statements and calibrated estimates (5.1) are
human expectations with ranges, and pairing an expectation with an observed
result is how the function learns whether its estimators are calibrated;
a rule-generated estimate has no such pairing. The evidence-tier
assignment is the line between what the function knows and what it
believes. The recommendation (12.1) is the signatory's own.

Block 6 — gp-404-loan-and-trade-between-internal-pools.md

<!-- Derived from [[Loan and Trade Between Internal Pools (generic process)]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# GP-404 Loan and Trade Between Internal Pools

The short-horizon transfer of staffed hours between a function's internal
supply pools, before any external lever. A loan is a dated transfer of
hours from a pool with surplus to one with a shortfall, returned when the
window closes; a trade is a swap, equal in hours, settled on the cost
difference. The pools are retained in-market sites and owned remote centres
(contracted supply is external and out of scope), and on a second axis the
shared, designated and dedicated pools a client's work is staffed from.
People stay employed and rostered by the lender; their hours are placed on
the borrower's work in routing, coded in the schedule, and charged to the
pool being helped at its loaded rate. Placement owns eligibility, the
finance partner owns the rate, real time owns execution. A loan is neither
a standing sharing arrangement (Call-Sharing Models and Cost Allocation)
nor the monthly clearing; it is the dated exception between them, inside
the lock, typically days to a few weeks [A]. It executes under whichever
of the four allocation models the borrower's work runs on; the cost rule is
the sharing rule, not restated.

## Profile
| Field | Generic value |
|---|---|
| Card | GP-404 · local id by the standards committee |
| Class | real-time; its weekly signal feeds the strategic review |
| Trigger | a projected shortfall in one pool inside the lock that the schedule's own flex cannot close, with an eligible surplus elsewhere in the same window |
| Cadence | on demand at the ROC's daily lever review; settlement weekly; loan report weekly against a planned band (SET LOCALLY; a reporting reference, since step 13 fires on recurrence) |
| Scope in | loans and trades between internal pools; eligibility; approval tier; execution in routing and schedule; settlement; the reading of a recurring loan |
| Scope out | external levers; overtime and voluntary time off within one pool; standing sharing arrangements and the sharing-volume signal; the monthly clearing; permanent moves (GP-401) |
| Inputs | capacity state by pool and interval; eligibility matrix (skill, language, credential, system access, client contract); loaded rate by pool with its grade, published by the finance partner; pre-agreed terms and the day's cap; the lock |
| Outputs | loan register row; routing and schedule changes with reversal; weekly settlement signed by both pool owners; weekly loan report; a register row when a loan recurs |
| Upstream | the capacity plan and its clearing; the forecast and its lock; constraint register (which pools may lend to which); activity-code dictionary; rate table |
| Downstream | finance (settlement); the sharing review (a recurring loan); adherence reporting |
| Resources | capacity state; eligibility matrix; loan register; rate table; routing layer and schedule; platforms at L3 only |
| Decision points | inside the schedule's flex; eligible; cheaper than the next lever; which tier; did the hours land; has the loan recurred |
| Authority tier | inside pre-agreed terms, tier 1, the real-time analyst with the lender's confirmation; a trade inside the day's cap, tier 2, the two team leads; outside terms or cap, tier 3, the ROC duty lead; touching a dedicated pool's contract or a jurisdiction with a consultation right, tier 4, the function head; changing which pools may lend to which is a network-design change for the executive sponsor |
| Risk and compliance flags | idle hours in a dedicated pool are what exclusivity bought, so lending them is a priced contract change; loaned hours stay under the lending site's working-time law; mis-coded time breaks both pools' adherence and the time ledger; a loan across a platform seam the router cannot execute is a loan on paper |
| Variant-prone steps | approval where consultation is required; eligibility where a contract forbids outbound lending; execution where pools sit on disjoint routing platforms |
| Automation candidates | nine L2 sub-steps (nine ranks) |

## L1 flow (thirteen steps, five decisions; owner seat per step)
1. Raise the request: body of work, hours per interval, window, eligibility, cause — borrowing pool lead
2. Decision: inside the schedule's own flex (break and activity resequencing, shift extension within rules)? Yes → schedule lever, close; no → 3 — real-time analyst
3. Identify candidate lending pools: surplus hours in the same window — real-time analyst
4. Decision: candidate hours eligible (skill, language, credential, system access, client contract)? Yes → 5; no → next candidate, or the external-lever path — real-time analyst
5. Price the loan at the borrower's loaded rate with its grade, re-read on resolved cases; compare to the next lever in the published order (SET LOCALLY) — real-time analyst
6. Confirm the surplus is releasable: not training, not deferred backlog, not already lent — lending pool lead
7. Decision: which tier? Inside terms → tier 1 executes on the lender's confirmation; trade inside the cap → tier 2; outside → tier 3; dedicated contract or consultation right → tier 4 — real-time analyst reads the terms and cap
8. Record the loan register row: pools, hours, window, rate and grade, approver, return date; for a trade, both blocks and the difference — real-time analyst
9. Execute in routing for the window, reversal scheduled at the same time — routing administrator
10. Execute in schedule: loaned time coded to the loan activity so both pools' adherence and requirement close — scheduling analyst
11. Decision, during the window: did the hours land on the borrower's work? No → idle loaned hours are a pricing error; shorten the loan — real-time analyst
12. Return and settle: reversal verified at the window's end; weekly settlement at the rate, re-read on resolved cases, signed by both pool owners; an extension is a new request — finance partner
13. Decision, weekly: the same loan, same pools, same window, recurred for consecutive weeks (count SET LOCALLY)? Yes → register row; hand to the sharing review; no → working — placement lead

Step 13 is the rule the card exists to state: a recurring loan is hours
that belong in the borrower's plan; sustained loan volume is a forecasting
or placement failure, never a success.

## L2 step table (terms, cap, lever order, band, platforms SET LOCALLY)
| Step | Sub-step | Owner | Inputs | Outputs | Duration | Auto | Join key |
|---|---|---|---|---|---|---|---|
| 1 | 1.1 Write the request | borrowing pool lead | projected shortfall | request | minutes | N | L3-404-01 |
| 2 | 2.1 Test against the schedule's own flex | real-time analyst | schedule; rules | closed, or carried | minutes | Y (check) | L3-404-02 |
| 3 | 3.1 Read surplus hours by pool for the window | real-time analyst | capacity state | candidate list | minutes | Y (lookup) | L3-404-03 |
| 4 | 4.1 Check candidates against the eligibility matrix and contract column | real-time analyst | matrix; constraint register | eligible candidates | minutes | Y (matching) | L3-404-04 |
| 5 | 5.1 Price at the borrower's rate; re-read on resolved cases; compare to next lever | real-time analyst | rate table; case count; lever order | priced loan | minutes | Y (arithmetic) | L3-404-05 |
| 6 | 6.1 Confirm releasable surplus | lending pool lead | candidate list; pool plan | confirmation | same shift | N — never | L3-404-06 |
| 7 | 7.1 Read terms and cap; execute at tier 1 or 2, or refer to tier 3 | real-time analyst (team leads, ROC duty lead approve) | priced loan; terms; cap | execution or referral | same shift | N — never | L3-404-07 |
| 7 | 7.2 Where a dedicated contract or jurisdiction is touched, obtain tier 4 approval and any consultation | function head (works-council liaison consulted) | loan; register entry | approval with conditions | SET LOCALLY | N — never | L3-404-07 |
| 8 | 8.1 Open the register row | real-time analyst | approval | loan row | minutes | Y (filing) | L3-404-08 |
| 9 | 9.1 Configure routing; schedule the reversal | routing administrator | loan row | routing change; reversal record | same shift | N | L3-404-09 |
| 10 | 10.1 Code loaned time in both schedules | scheduling analyst | loan row; activity-code dictionary | schedule update | same shift | Y (coding) | L3-404-10 |
| 11 | 11.1 Compare handled work by loaned posts against the loan | real-time analyst | routing data | landed or idle | each interval | Y (comparison) | L3-404-11 |
| 12 | 12.1 Verify the reversal at the window's end | real-time analyst | routing configuration | reversal confirmed | minutes | Y (check) | L3-404-09 |
| 12 | 12.2 Compute the weekly settlement; obtain both signatures | finance partner (pool owners sign) | loan rows; rate table; case count | signed settlement | weekly | N — never | L3-404-12 |
| 13 | 13.1 Count recurrences; compare the week's loans to the band | placement lead | loan register | weekly loan report | weekly | Y (comparison) | L3-404-13 |
| 13 | 13.2 Open the register row on a recurrence; hand to the sharing review | placement lead | loan report | register row | same week | N | L3-404-13 |

Rows 7.1, 7.2 and 12.2 name more than one seat on the live card; the
signing seat is the owner here, the others are approvers or signatories in
the fifteen-column table, or a finding.

## Variants
- Statutory: a works council with co-determination over the distribution of working time → consultation step before 9 when a loan changes the lent posts' hours or duties; owner works-council liaison, approver function head; a loan changing neither needs no step.
- Contractual: a dedicated pool whose contract forbids or prices outbound lending is a register entry read at step 4 → SET LOCALLY, no row.
- Structural: two pools on disjoint routing platforms cannot execute step 9 as a configuration → manual transfer of posts, reviewed quarterly until the seam closes.
- Transitional: a predecessor-organization pool with a different activity-code dictionary codes loaned time under a mapped code, row expiring at dictionary cut-over.

## L3 register (terms and cap per tier, lever order, band, recurrence count SET LOCALLY)
| Job aid | Anchored to | Form |
|---|---|---|
| L3-404-01 Loan request form | 1 | work instruction |
| L3-404-02 Schedule-flex checklist | 2 | work instruction |
| L3-404-03 Capacity-state surplus read | 3 | work instruction |
| L3-404-04 Eligibility matrix and contract column | 4 | work instruction |
| L3-404-05 Rate table, resolved-case re-read, lever order | 5 | work instruction; Call-Sharing Models and Cost Allocation |
| L3-404-06 Releasable-surplus test | 6 | work instruction |
| L3-404-07 Pre-agreed terms, day's cap, referral note per tier | 7 | work instruction |
| L3-404-08 Loan register layout (LN-nnn) | 8 | work instruction |
| L3-404-09 Routing configuration and reversal sheet per platform | 9, 12 | work instruction |
| L3-404-10 Loan activity code and its mapping | 10 | work instruction |
| L3-404-11 Landed-or-idle check | 11 | work instruction |
| L3-404-12 Weekly settlement sheet and signature record | 12 | work instruction |
| L3-404-13 Weekly loan report; recurrence hand-off | 13 | playbook |
| L3-404-14 Loan during an incident: emergency path, logging, ratification at the next sitting | 7–9 | runbook |

## Automation candidates (ranked by ease of publishing a catch rate)
1. Eligibility match (4.1): deterministic against the matrix and contract column; every error a countable mismatch.
2. Surplus read (3.1): after 1 because the capacity state it reads is a graded projection.
3. Reversal check (12.1): after 2 because a missed reversal is caught against routing data a shift later.
4. Landed-or-idle comparison (11.1): after 3 because attributing handled work to loaned posts adds an error class; also where the benefit is measured, not asserted.
5. Pricing (5.1): after 4 because the rate's grade and the resolved-case re-read are inputs the arithmetic cannot verify.
6. Schedule-flex check (2.1): after 5 because the rules it tests are local and change, so its catch rate is republished when they do.
7. Schedule coding (10.1): after 6 because a coding error is silent until adherence reporting reads it.
8. Register filing (8.1): after 7 because it is assembled from an approval given by hand.
9. Weekly band comparison (13.1): last because the row it opens stays human and the band is set from a quarter of hand-kept reports.

Never: the releasable-surplus confirmation (6.1), a statement about a plan
a rule cannot read; the tier decision (7.1, 7.2), the execution authority
itself; the settlement signature (12.2), the transfer-price acknowledgement
by both pool owners. Under skills-based pooling, where a loan is a one-line
configuration, the card adds the record, the reversal and the settlement
the configuration does not produce.

Usage notes

Sizing. Block 1 is about 590 words and loads with every message. Blocks 2–6 are retrieved as needed: the rules file is about 1,100 words and the four card files run from about 2,000 to 2,250 words each, GP-402 the longest because its cycle has the most rows. In every card file the L2 step table, carried in full so that nothing has to be fetched from the wiki during a session, is roughly half the words; the profile, L1, variants, L3 register and ranked candidates share the rest.

Output. The pack emits the five Markdown files per card that Wiki:Packs/Process Decomposition defines, with the profile on the L0 cover, the L2 in the fifteen-column form and the variant rows in the register layout of Standard and Variant in Process Documentation. The card files condense the wiki pages; they do not restate the gate's six tests, the scorecard's components, the sourcing disciplines or the sharing cost rule, which the method pages carry. Several L2 rows on the live cards name more than one seat (GP-401 12.1; GP-402 8.1 and 12.1; GP-403 5.1 and 13.1; GP-404 7.1, 7.2 and 12.2); each card file carries one owner per row with the other seat marked consulted, approving or signing, and says so, so the localizing team can settle it.

Localizing. Every SET LOCALLY in a card file is a value the function holds; the pack writes the mark with its seat and never a number the user has not given. A contract term is a constraint-register entry, not a variant; only a step whose owner, inputs, outputs or position changes takes a variant row. The supply-node owner's decision is never a tier and is never automated; the change-control board and the standards committee are forums.

Drift. Blocks 2–6 derive from the ten source pages in the infobox. A material change to any card page, to the variant convention, to the tier ladder or to the release rule is the trigger to regenerate the affected block and bump the version. The four card pages were read on Thu 16 Oct 2026.

Scope. Nothing in the pack is specific to any organization, platform, partner or jurisdiction. The placement engine, the comparability map and the supply cards are built by other packs; this pack localizes the processes that use them.

Change history

Version	Date	Change
1.0	2026-10-16	First release: instruction block, the shared localization rules, and one reference file per work-placement card (GP-401 to GP-404)

See also

• Process Standardization — the hub: conventions, the inventory of generic process cards and the pillar packs
• Wiki:Packs/Process Decomposition — CP-OPS-001, the engine whose L0 form and fifteen-column L2 this pack writes into
• Wiki:Packs/Process Inventory and Shell Catalog — CP-OPS-008, the catalog rows this pack localizes against
• Placement Decision Through the Gate (generic process) — GP-401
• Vendor Performance Review Cycle (generic process) — GP-402
• Sourcing Decision Under Imperfect Data (generic process) — GP-403
• Loan and Trade Between Internal Pools (generic process) — GP-404
• Operating Principles for Work Placement — principle 2 (hard constraints exclude) and principle 5 (the supply-node owner decides)
• Decision Authority Tiers in Workforce Operations — the work-placement row of the tier ladder
• Wiki:Packs/Placement Decision Engine Build — CP-WFM-008, the register, the tests and the recompute log the gate flow uses
• Wiki:Packs/Service Quality Comparability — CP-WFM-003, the comparability map the scorecard and the sourcing decision read
• Wiki:Packs/Forecasting Processes · Wiki:Packs/Scheduling Processes · Wiki:Packs/Real-Time Processes · Wiki:Packs/Continuity Interface Processes · Wiki:Packs/Cross-Cutting Governance Processes — the sibling pillar packs
• Wiki:Packs — inventory and how packs work