The Placement Gate
Part of the Planning Week chain · previous: Decision Rights by Planning Horizon · next: Work Placement Landscape
The placement gate is the six-test, five-outcome check a placement question runs through before it becomes a decision, and this page is about running it as a standing practice: how a question reaches the gate, what the one page it produces must record, what triggers a rerun, and why the gate is run by hand for a year before any engine runs it. It matters because a workforce function that places work needs one door and one check, or placements are decided in the meeting that happened to be scheduled. The gate's tests and outcomes are specified on Placement Engine Architecture and its decision instrument on Placement Rules and the Tenure Contract; this page extends both with the operating route and does not restate them. The page produces the gate output page (GO) and is worked in a session with Wiki:Packs/Placement Decision Engine Build (CP-WFM-008); it is walked on Day 3 morning of a planning week, as the placement route from the intake door.
From the intake door to the gate
The intake door is the single entry for any ask a workforce function receives, and its six fields are on The Question Register and Knowledge Base, which routes what arrives into five classes: planning request, performance question, data pull, event and definitions question. Executive Issue Register carries the extract-not-summarize discipline that keeps what arrives gradeable, and the claim grades it enters under. This chain's door adds a route those five do not carry, the placement question, and Enterprise Interconnection Plan carries it among the function's interfaces, where the chain's routing is reconciled against the live five; this page picks the question up at that point. An ask is a placement question when it proposes, or would result in, a body of work sitting somewhere other than where it sits now, at any horizon, whether it arrives as "can the partner take the overflow," "the new book needs a team," "we should move the language pool," or as a renewal notice. Most placement questions do not arrive labeled as such; the door's placement route exists so that the person at the door asks the labeling question rather than the requester.
Once routed, the question is written as a proposal in the gate's terms before anything is computed: the body of work, the node it sits at and the node proposed (a node being a hub, a service center, a partner, or automated), the horizon, the owner of the work, and who is asking. Intent Normalization Before Work Placement is the demand-side prerequisite: a proposal about a body of work that is labeled differently in two channels cannot be gated until the label is one. A proposal that cannot be written in these terms is returned to the door with what is missing named, which is the gate's fifth outcome applied before the tests.
The six tests and the five outcomes, reconciled
The six tests are the engine page's: continuity, coverage floor, pooling cost, contractual eligibility, language viability and construct fit; four are computable with queueing arithmetic; on this chain the remaining two are read from the constraint register, which is this page's operating choice rather than the engine page's specification. The five outcomes are pass, fail, fail-unless-a-stated-price-is-paid, pass-until-a-stated-date, and cannot-run. The count needs one sentence of reconciliation, because Placement Rules and the Tenure Contract lists four outcomes and Placement Engine Architecture five. The four are the decisions the gate can return; the fifth, cannot-run with the missing input named, is not a decision but a real result, and it is counted because a gate that skips a test it cannot run silently returns a false pass. On this chain the count is five, and a hand-run gate records cannot-run as often as it records anything else in its first quarter, which is the point: the list of missing inputs is the definitions register's queue (The Definitions Register).
Principle 2 of Operating Principles for Work Placement is what makes the fail outcome a fail: a hard constraint excludes, it never lowers a score. Where a room has struck that principle, the gate has four outcomes and no exclusions, and it is an advisory scoring, not a gate.
The output page
The gate's product is one page per proposal, and the page is the artifact this chain adds. It records:
| Field | What it holds | Why it is recorded |
|---|---|---|
| Proposal | The body of work, from-node, to-node, horizon, owner, requester | So the answer can be read without the meeting that produced it |
| Six results | One row per test: outcome, the number where there is one, its grade | Every non-pass is explained in one plain sentence with its number |
| Register citations | Constraint and definition entries cited by identifier | So a changed entry can find every page that relied on it |
| The price or the date | For a priced fail, the cost of overriding the soft constraint; for a dated pass, the date and the condition | The priced outcome is what makes the gate usable by a commercial organization; the dated one is what makes it recomputable |
| Missing inputs | For cannot-run, what is missing and who obtains it | The definitions queue |
| The counterfactual | What the proposal's owner would have decided without the gate, written before the result is read | How the gate proves its value or its redundancy; either is worth knowing |
| The decision | What the node owner decided, and if a decline, its price | Principle 5: the function owns the method, the node owner owns the decision, every decline is recorded with its price |
The counterfactual field is filled first, by the proposal's owner, and sealed before the tests run. A gate whose counterfactuals always match its results is redundant and can be retired; a gate whose counterfactuals diverge on the priced outcome has found the delta that, on Placement Rules and the Tenure Contract's account, is what an on-request sizing does not return. The recorded counterfactual is also the only honest way to estimate what the gate is worth, because a before-and-after on placement outcomes has no control group; the pairing of a stated expectation with an observed result is the form of calibration a forecaster uses when no experiment is available.[1]
Every number on the page carries its grade as Human Gates and Number Grades defines them: [M] measured, [C] computed (inheriting its weakest input), [E] estimated with a range, [A] asserted. A pooling-cost figure computed from a measured volume and an estimated shrinkage is [E], and the page says so. The coverage and pooling tests rest on queueing arithmetic whose behavior with pooled and split arrival streams is well characterized,[2] and the staffing penalty a skill-based split carries is real but collapses quickly with limited cross-training, which is what the pooling test prices rather than argues.[3]
The recompute trigger list
A gate run once is a decision; a gate rerun when the world moves is a placement function. The engine page names the trigger classes; the operating practice is to keep them as a list with an owner and a source for each, and to keep it before any engine exists.
| Trigger | Source | What is rerun |
|---|---|---|
| A contract renews, expires or is amended | The renewal calendar, read as a constraint-relaxation schedule | Every dated pass whose date is the contract's; every eligibility test citing it |
| Automation absorbs a task type | The catch-rate report of the overseen process (The Agent Overseer) | Pooling cost for every pool that held the task; the affected supply cards |
| A regulatory or legal condition changes | The constraint register's owner | Every proposal that cited the entry |
| A language pool crosses its viability threshold | The supply card's tenure and volume fields | Language viability for that pool |
| A supply card materially changes | The card's owner, monthly | Every open proposal reading that card |
| A forecast revision moves a body of work across a coverage floor | The forecast version record | Coverage floor for the affected node |
| An incident or continuity event | The incident record, via the continuity wire | Continuity for the affected work |
The list is built by hand for a quarter before anything is automated: a log of fired triggers and what should have been rechecked. It costs nothing and produces the most persuasive artifact a placement function has, the list of decisions that went stale with no one noticing.
Hand-run before any engine
The gate runs by hand for the whole of Arc 1, the consolidate-and-standardize arc, on two or three live questions a quarter. Placement Engine Architecture gives the reason the hand-run precedes any platform, the shape of its two prongs and the acceptance case that must fail; that argument is not repeated here. What the operating route adds is a cadence and a quota: two or three live questions a quarter is enough to seed the constraint register and to find the definitions the tests consume, and few enough that each one gets a written output page rather than a verbal answer. Placement Engine Build Path is the dated path from the hand-run to the engine, and Wiki:Packs/Placement Decision Engine Build the working session in which the register, the tests, the supply cards and the recompute log are built; this page is the practice they build from.
The interim protocol — one intake, a 48-hour readout, an acceptance gate — is what the hand-run looks like from the requester's side until the engine runs: a question in at the door, a one-page answer inside two business days, and the node owner's signature or decline with its price on the page. It is this chain's protocol; the forty-eight hours is the target The Question Register and Knowledge Base sets for a first readout on a performance question, carried across to a placement question here. Vendor Governance Placement carries the principle beneath it, that standard-setting, measurement and enforcement are separable and need not sit together, which is what lets the function run the readout while the node owner keeps the acceptance; Enterprise Interconnection Plan carries the protocol's place among the interfaces.
Worked example
The chain's worked example function ran its first three gate questions by hand between the planning week (Mon 20 Apr – Thu 23 Apr 2026) and the end of the first-quarter front-load, Tue 30 Jun 2026. The first was retrospective: the migrating book's phase 2 plan, signed Fri 27 Mar 2026, was rerun through the six tests on Mon 11 May 2026 as if it were a proposal, with the counterfactual sealed as "hire to about 310 FTE [E]" (the signed plan). It returned pass-until-a-stated-date on contractual eligibility (the partner's minimum-engagement term); a priced fail on pooling cost for the email-to-voice move of 22 FTE that the plan signature had already declined with the price "training lead time exceeds phase 2 date," the gate adding what the decline did not carry, a pooling cost for the split of about 6 FTE [E] over phase 2 (range 4–9) against the pooled alternative; and cannot-run on language viability, with the missing input named as the partner pool's tenure depth per language, which opened a row in the definitions register. The counterfactual matched the result on five tests and diverged on none the gate could run, which the room read correctly: a retrospective run proves the register, not the gate. The second and third questions were live: a proposal to move a language pool, raised at the door in May, and a renewal notice. Their pages are the first two entries in the recompute log. (The series' Q-011, the training-pull card of Wed 8 Apr, is not among them; it was returned in one line on 10 Apr and is not reopened here.) All numbers carry the series' grades: voice handled 4,210 [M], handle time 452 s [M] against 412 s [A] carried, shrinkage 30 % [E] (28–32), occupancy 85 % [A].
The artifact this page produces
The gate output page (GO), one page per proposal, one row per test. It is filed with the counterfactual record, which the registers' steward keeps. One filled example row from the six:
| Test | Outcome | Number and grade | Register entry cited | Plain sentence |
|---|---|---|---|---|
| Pooling cost | Fail unless a stated price is paid | the declined move is 22 FTE; the split costs about 6 FTE [E] more than the pooled alternative over phase 2 (range 4–9) | the decline record for the 22 FTE email-to-voice move; the shrinkage definition SHR-01 | Splitting the work as proposed costs about six further posts for the phase; the price is recorded and the owner may pay it |
Produced in a working session with Wiki:Packs/Placement Decision Engine Build (CP-WFM-008); the first quarter's output pages are the recompute log's seed and part of blueprint v0.1.
What would change this
The page's claim is that a gate hand-run for a year, with its counterfactual sealed first, is worth more than an engine built in the same year. The observation that would overturn it is a year of output pages whose counterfactuals match the results on every test that could run, with no cannot-run outcomes after the first quarter. That would mean the estate's placement questions already get asked and answered well without the gate, and the right move would be to skip the hand-run, encode the register directly, and spend the year on the definitions the cannot-runs would have found.
How this connects
- Previous in the chain: Decision Rights by Planning Horizon — the RACI that names who signs the output page
- Next in the chain: Work Placement Landscape — where the gated moves show as transitions between bands
- Defers to: Placement Engine Architecture (the six tests, the five outcomes, supply cards and the recompute: extended here, never restated) · Placement Rules and the Tenure Contract (the discriminating question and the four decision outcomes) · Intent Normalization Before Work Placement (the demand-side prerequisite) · The Question Register and Knowledge Base (the intake door's six fields, its five routing classes and the 48-hour readout target) · Executive Issue Register (the extract discipline and the claim grades)
- Feeds: Placement Engine Build Path (the dated path from hand-run to engine) · Enterprise Interconnection Plan (the placement route among the six)
Maturity Model Position
A gate run routinely by hand, with all five outcomes, a sealed counterfactual and a trigger log kept by hand, is Level 4 Advanced practice on the WFM Labs Maturity Model™ and needs no engine (Level 4: Planning in Distributions); Placement Engine Architecture and Placement Rules and the Tenure Contract agree on this and both place automated recompute on the trigger classes at Level 5. What Arc 1 therefore carries is the climb from Level 3 (Level 3: The Automation Layer) to Level 4 for placement specifically, ahead of the function's overall position, which is the normal shape of a climb: one practice reaches the next level before the function does. Arc 2 is where the engine does it. Four scales on this wiki use the word "level"; Planning Week for a Workforce Function states which is which. This page uses the maturity Levels 1–5.
Use this with Claude
A ready-to-deploy instruction set and reference files for building the constraint register, the gate tests, the supply cards and the recompute log are at Wiki:Packs/Placement Decision Engine Build (CP-WFM-008).
See Also
- Planning Week for a Workforce Function
- Operating Principles for Work Placement — principle 2 (hard constraints exclude) and principle 5 (the node owner decides)
- The Workforce Broker — the clearing cycle the gate's monthly questions arrive from
- Constraint Programming for WFM — the same solver family, applied to rostering rather than to placement
- Human Gates and Number Grades — the grades every number on the output page carries
References
- ↑ Tetlock, P. E., & Gardner, D. (2015). Superforecasting: The Art and Science of Prediction. New York: Crown. Chapters 3 and 7. ISBN 978-0-8041-3669-3.
- ↑ Gans, N., Koole, G., & Mandelbaum, A. (2003). "Telephone Call Centers: Tutorial, Review, and Research Prospects". Manufacturing & Service Operations Management 5(2), 79–141. doi:10.1287/msom.5.2.79.16071.
- ↑ Wallace, R. B., & Whitt, W. (2005). "A Staffing Algorithm for Call Centers with Skill-Based Routing". Manufacturing & Service Operations Management 7(4), 276–294. doi:10.1287/msom.1050.0086. Agents carrying only two skills each, in appropriate combinations, perform almost as well as agents carrying all skills.
