Placement Engine Build Path

From WFM Labs

Part of the Planning Week chain · previous: Migrating a Book of Business · next: Launching an Analytics Notebook Platform Placement engine build path is the sequence by which a workforce planning function builds a placement engine, the machinery in which constraints define the feasible set, scores rank inside it and the owner decides, by running every part of it by hand before any of it is encoded. It matters because an engine fails in two opposite ways: logic never tested on real decisions gets encoded and produces confident wrong answers at scale, or the logic waits for a perfect platform while the estate keeps deciding by meeting. The page produces the engine's sub-plan shell (SP-001) and is worked in a session with Wiki:Packs/Placement Decision Engine Build (CP-WFM-008), the existing pack that carries the register schema, the gate tests, the supply cards and the build specification; the shell itself is opened with Wiki:Packs/Technology Plan (CP-WFM-016).

The page is walked on Day 3 afternoon as the third chapter of Technology Migration Plan for a Workforce Function, ten minutes, and it is a path rather than an architecture. Placement Engine Architecture specifies the two layers, a decision layer the operation owns and never delegates and a measurement layer it may build or buy, and the four decision-layer objects: the constraint register, the gate, the supply cards and the recompute log. That page names the machinery a placement engine too, and reserves constraint solver for the component inside the measurement layer that states each goal's likelihood and names the binding constraint; these pages use engine for the machinery as a whole. Nothing from it is restated here. The Placement Gate carries the gate itself, its six tests and five outcomes, and how a question reaches it from the intake door.

Why hand-run first

The placement function is the concept: work sits where objectives and constraints say, at every horizon. The placement engine is the machinery. A function that has the concept and not the machinery decides placement in meetings, and the constraints that should have bound the decision exist in contracts, regulation and platform configuration but never meet it. A function that buys the machinery before it has run the concept by hand encodes whatever the room believed on the day of configuration, and the engine defends it.

The path therefore runs the decision layer on paper first, measures what each step produces, and encodes only what the hand-run has proven. The rule that keeps the build small is the one the architecture page gives for definitions: no test, no definition. The same rule applies to every component here: no hand-run, no code. The ordinary principle for placing automation authority applies to the whole path: the machinery may go as far as the stage before the one whose error is costliest, and no further, until its reliability is measured.[1] The decision, which pool, which supplier, which construct, is never delegated at any step; what the path automates is the computation that informs it.

The eight steps

Step Build What is measured Depends on
1 The gate on paper, run first retrospectively on a decision already made and going well, then on two or three live placement questions from the intake door The counterfactual on each output page: what the owner would have decided without the gate; the count of cannot-run results and the missing inputs they name The intake door; the interim protocol (one intake, 48-hour readout, acceptance gate)
2 Constraint register v1 and the recompute trigger list, the register seeded from the hand-runs and from archaeology (contracts, the renewal calendar, platform configuration, named positions) and the trigger log kept by hand for a quarter Entries by strictness class; the number of entries whose price to relax is unpriced; the list of fired triggers and the decisions that went stale unnoticed Step 1
3 Supply cards, one per pool, with one measured attribute per objective family and tenure depth from the ramp entry of The Definitions Register Pools with a card; attributes with an evidence source; the flexibility numbers that were never measured before The register's ramp entry (RMP-01); the capability ontology on paper
4 The six tests computed where queueing arithmetic allows: four of the six, with the coverage-floor and pooling-cost tests as Erlang-family calculations through the recursion that does not overflow at high offered load[2] Tests computed rather than judged; the priced outcome in use on a live proposal Steps 2 and 3; the register's occupancy and handle-time entries
5 Simulation and notebooks together: the pooling-cost and coverage-floor tests priced in the Python analytics platform, and the simulation engine for the cases queueing arithmetic cannot price (a network redesign, an outage effect)[3] Placement cases priced with their method attached; the difference between the arithmetic and the simulation on the same case Launching an Analytics Notebook Platform; the plan of record on one core
6 The engine at the capacity horizon: the solver over the register and the cards inside the clearing stage of the monthly Capacity Planning Cycle, stating for each goal the likelihood of meeting it and naming the binding constraint Moves proposed and accepted or declined with price; the binding constraint named per goal; the decision layer's objects unchanged by the encoding Steps 4 and 5; the acceptance cases in the build specification, one designed to fail
7 Recompute on triggers: the trigger classes automated (a contract renews, automation absorbs a task type, a regulatory relaxation lands, a language crosses its coverage threshold, a card changes) and a standing feasible-set report each quarter Recomputes fired against triggers logged; decisions re-run before they went stale Step 6; the register's expiry field populated from the renewal calendar
8 Real time last: the capability layer as a platform inside intraday automation, placing supply on attributes when a trigger fires, with the intraday action delegated to the automation component Placements executed by the automation against placements recomputed by the engine; the catch rate for the class of action Expanding Intraday Automation; the ontology exercised by hand for two quarters

Steps 1 to 4 are the first prong the architecture page describes, proving the logic by hand; steps 5 and 6 are where the second prong, the data foundation and the measurement layer, joins it. The join rule is the architecture's: nothing is encoded that the hand-run has not proven, and the mock's by-product is the requirements document any platform must meet. The solver at step 6 is a constraint-satisfaction problem in the ordinary sense, hard constraints as exclusions and preferences as an objective inside the feasible set, and the technology for it is mature;[4] Constraint Programming for WFM describes it. What is not mature in most functions is the register the solver reads, which is why the path spends four steps on it.

What the path never delegates

The four decision-layer objects stay with the operation at every step. A hard constraint is never encoded as a score; a legal bar, a contract term or a clearance excludes and does not lower a ranking. Cannot-run is a real result, never silently skipped, and the missing input it names is a definitions or data work item. The gate computes and leaders decide: an engine operated as a veto is the failure mode, and the counterfactual field on every output page is how the gate proves its value or its redundancy. And the register is one, never one per business unit, because a test cannot run against four registers.

The path also fixes what a platform is bought for. The measurement layer, governed metric records with lineage and comparative scoring at matched tenure across the firm boundary, is what a platform bids for, and the build specification in CP-WFM-008 states the two demands most commercial offerings fail by default. The decision layer is what the function builds, on paper first, and keeps.

Worked example

The series example's function runs step 1 on Day 3 afternoon, Wednesday 22 April 2026, on a decision already made: the email-to-voice transfer of 22 FTE [M] that the planning lead declined on Friday 27 March 2026 with the recorded price "training lead time exceeds phase 2 date; requisition instead." Run retrospectively through the six tests, the proposal returns fail-unless-a-stated-price-is-paid on the pooling-cost test, with the price the lead had already recorded, and the counterfactual field reads "declined on the same ground without the gate." The register gains its first entries from the run: the training lead time as a dated constraint, the partner cohort's contract terms as hard with a route. Sub-plan shell SP-001 is opened with the engine's owner as a seat, the placement function, and its first three deliverables: the register v1 with the trigger log kept by hand through Tuesday 30 June 2026; supply cards for the migrating book's pools by Q4 2026; the six tests computed on one live question by Q1 2027. Step 6 is placed in the worked example's Q2 2027, after the plan of record is on one core; step 8 is placed in 2028, after the ontology has run by hand in the gate for two quarters. On Day 4 morning D-14 confirms the seat.

The artifact this page produces

The sub-plan shell (SP), one row for the engine. One filled example row:

ID Sub-plan Owner (seat) First three deliverables Depends on (build-order step) Measure Quarter
SP-001 Engine The placement function's lead seat Register v1 with the hand-kept trigger log (by Tue 30 Jun 2026); supply cards for the migrating book's pools (Q4 2026); the six tests computed on one live question (Q1 2027) Step 1 (the register and the ontology on paper); step 3 for the engine itself Counterfactuals recorded per gate run; cannot-run results with a named input; decisions that went stale, from the trigger log Q2 2026 to Q2 2027 for steps 1 to 6 (the example's quarters)

Produced in a working session with Wiki:Packs/Placement Decision Engine Build (CP-WFM-008) for the engine and Wiki:Packs/Technology Plan (CP-WFM-016) for the shell; the filled set is part of blueprint v0.1.

What would change this

The page claims that an engine encoded before its logic has run by hand on real decisions will produce confident wrong answers, and that the hand-kept trigger log is the most persuasive artifact for the build. The observation that would overturn it is a function that procured a placement or scoring platform first, configured it on its vendor's definitions, and produced placement recommendations that node owners accepted and that a later hand audit of the constraint set found correct. If that function exists, the first four steps are a slower route to the same engine and the path should begin at step 5.

How this connects

Maturity Model Position

Four scales on this wiki use the word level; the launch page states which is which. This page uses the WFM Labs Maturity Model™'s Levels 1–5. Steps 1 to 4 are Level 3 work done by hand: a register exists and checks run on contested proposals. Steps 5 and 6 are Level 4: the gate runs routinely with all five outcomes, cards are current and the trigger log is kept. Steps 7 and 8 are the Level 5 components, and the path places them last on purpose.

Use this with Claude

A ready-to-deploy instruction set and reference files are at Wiki:Packs/Placement Decision Engine Build (CP-WFM-008).

See Also

References

  1. ↑ Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). "A model for types and levels of human interaction with automation". IEEE Transactions on Systems, Man, and Cybernetics — Part A 30(3), 286–297. doi:10.1109/3468.844354.
  2. ↑ Cooper, R. B. (1981). Introduction to Queueing Theory (2nd ed.). North-Holland. ISBN 0-444-00379-7.
  3. ↑ Law, A. M. (2015). Simulation Modeling and Analysis (5th ed.). McGraw-Hill Education. ISBN 978-0-07-340132-4.
  4. ↑ Rossi, F., van Beek, P., & Walsh, T. (eds.) (2006). Handbook of Constraint Programming. Elsevier. ISBN 978-0-444-52726-4.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Placement_Engine_Build_Path&oldid=4732"