Placement Engine Architecture
A placement engine is the machinery that turns the placement of service work — which pool, which supplier, which construct — from a recurring argument into a produced answer: constraints in, placement out, re-run when conditions change. This page specifies a universal architecture for such an engine in two layers: a decision layer the operation must own, and a measurement layer that can be built in-house or procured from a commercial platform — with a hard boundary between them. It is the implementation companion to Placement Rules and the Tenure Contract, which supplies the decision instrument the engine automates, and it is deployable as a working build via Wiki:Packs/Placement Decision Engine Build.
The problem the engine solves
In most service estates the constraints on placement exist — in contract clauses, in regulation, in platform configuration, and in the considered positions of the people who own each part of the operation — but they never meet the decision. Two failure shapes recur, and they fail in opposite directions: a documented hard constraint fails to stop a commitment, because no step tests proposals against the constraint set before signature; and an undocumented objection stops a proposal only because a particular executive happened to attend. In neither case did a process do the work.
The deeper cause is that constraint knowledge is held at the same organisational grain that adjudicates it: the unit holding a constraint is also the unit deciding whether it binds, so the constraint becomes negotiable at the point of decision, and the estate accumulates several incompatible constraint views rather than one testable list. A test cannot run against four registers. It needs one rule.
Two layers, one boundary
The decision layer holds the constraint register, the gate, the supply cards, and the recompute log. It is owned by the operation and never delegated — because it encodes what the operation may and may not do, and because whoever owns the constraint list effectively owns the feasible set.
The measurement layer holds governed metric records and comparative scoring — the evidence the decision layer's cards and tests consume. It is legitimate to procure this layer commercially; several platforms offer credible versions of it.
The boundary rule: a hard constraint is never encoded as a score. A legal bar, a contract term, or a clearance requirement excludes; it does not merely lower a ranking. A constraint encoded as a score is a preference wearing a rule's clothes — it can be outvoted by enough good numbers, which is precisely what a hard constraint must never permit. The corollary sets the commercial boundary: the constraint list and the gate belong to the operation; what a platform bids for is measurement and scoring inside the feasible set the constraints define.
The decision layer
The constraint register
One row per constraint — never one per business unit or legacy organisation. Each entry carries a plain-language statement, the work it binds, a named source instrument (contract clause, regulation, platform limitation, or operating preference — the last is legitimate and must be labelled, because an unlabelled preference argues with the force of a law), a strictness class, a price and lead time to relax where tradeable, an expiry or review date where one exists, a disagreement record naming both readings and what would settle them, and an owner who informs rather than adjudicates.
The strictness taxonomy does most of the register's work:
| Class | Meaning |
|---|---|
| Hard, no route | Law or regulation; "no" is the complete answer |
| Hard, with a route | A contract bar whose relaxation instrument exists — so it has a price and a lead time |
| Priced | Tradeable at a computable cost someone can choose to pay |
| Soft | A preference that yields to a stated argument |
| Dated | True today, changing by itself on a known date |
What this means in practice. Classification alone converts much of what an estate carries as immovable into trades nobody has priced — and moves objectives masquerading as constraints ("protect the premium book in-house") out of the constraint set and into the objective function, where they belong with a price attached.
The gate
Every placement proposal is scored before it becomes a decision, against six tests: continuity (does one failure take all of this work down) · coverage floor (do the promised hours cost more crew than the volume justifies) · pooling cost (what does the proposed split cost in additional staff, priced) · contractual eligibility (what does the agreement actually permit) · language viability (does each affected language pool remain workable) · construct fit (does what was sold pool with the destination). Four of the six are computable with standard queueing arithmetic; the coverage and pooling tests are Erlang-family calculations, best implemented through the Erlang B recursion, since the naive factorial form overflows at high offered load.
Five outcomes: pass · fail · fail-unless-a-stated-price-is-paid · pass-until-a-stated-date · cannot-run, with the missing input named. The priced outcome is what makes the gate usable by a commercial organisation — a proposal failing on cost grounds remains available as a decision; it becomes a purchase rather than an assumption. The dated outcome is the recompute property demonstrated by hand: without it, every dated constraint is forced into a false pass (the date is forgotten) or a false fail (today is treated as permanent). Cannot-run is a real result, never silently skipped — it names the definitional or data gap that must close.
The gate's output is one page per proposal: the answers, every non-pass explained in one plain sentence with its number, register entries cited by identifier, and the counterfactual — what the proposal's owner would have decided without the gate, recorded honestly. The counterfactual field is how the gate proves its value or its redundancy, and either is worth knowing.
Supply cards
Each pool work can be routed to — owned centres, supplier engagements, in-market teams, and automated capacity — carries one card with at least one measured attribute per objective family: cost per productive hour on a single stated hour base · quality at equal experience, with the measuring instrument's resolution stated · speed, as two numbers that must never be blurred — time to fill a seat and time to proficiency · flexibility, as two auditable numbers — the genuinely variable share of the pool's cost at 30, 60 and 90 days, and its realised routing connections to the rest of the estate, taken from routing data rather than the skills matrix. Flexibility is typically unmeasured anywhere in an estate; the card is what first makes it a number. An automated pool's card adds drift terms: per-task quality measured on the operation's own work, evaluation stability across model updates, and regression results.
The recompute
The engine's single advantage over a well-run spreadsheet is that it re-runs when the world moves. Trigger classes are all observable in any estate today: a contract renews or expires (the register's date field, populated wholesale from the renewal calendar) · automation absorbs a task type — which both drains the affected human pools and raises the cost of every dedication, since shorter handle times raise pooling penalties · a legal or regulatory relaxation lands · a language crosses its coverage-viability threshold · a pool's card materially changes.
Build the trigger log first, by hand, for a quarter — a list of fired triggers and what should have been re-checked. It costs nothing, sizes any real build honestly, and produces the most persuasive artifact available: the list of decisions that went stale with nobody noticing. The automation case writes itself from that list, or it does not; either is the right answer.
The measurement layer
The decision layer's tests and cards consume evidence, and the evidence layer has a canonical shape — whether built in-house or procured:
- Governed metric records. Every metric stamped with a settled definition, carrying full source lineage, computed through versioned formulas whose corrections apply forward only. The sequencing consequence is absolute: point an immutable store at unsettled definitions and every early record is permanently wrong — defensible nonsense, forever. Definitions converge first; the store ingests second. (During the hand-built phase, the mock takes the opposite position and restates freely — immutability is a virtue to adopt after convergence.)
- Comparative scores. Three families — a percentile against a fresh peer group built each evaluation cycle, a benchmark-anchored classification with operation-set thresholds, and composite scores authored against named formulas — each carrying volatility, and every trend carrying direction, velocity and volatility, converting point-in-time readings into trajectories.
- Two non-negotiable dimensions, where commercial offerings most often fall short by default: peer groups must be able to span the firm boundary — owned centres, each supplier, in-market and automated capacity in one comparison, since that is the comparison every sourcing decision needs — and experience must be an always-on adjustment, never a refinement dropped silently when a peer group is small. A comparison that drops the experience adjustment at small sizes produces exactly the invalid comparison the layer exists to prevent, now carrying a governance stamp.
- Explainability records. Every published figure carries its inputs and method, so a challenge is settled by the record rather than by whoever produced it.
- Goal confidence and the binding constraint. The layer's most valuable advanced product: given a goal and the scored supply assigned to it, a constraint solver states the likelihood of meeting the goal — and reads its own solution's by-products to name the most-constraining constraint, the one whose relaxation most improves the odds. Naming the binding constraint is a stronger product than issuing a recommendation, because it hands the decision-maker a purchasable lever rather than an opinion.
Building it: two prongs
A placement engine fails two ways: logic never tested on real decisions gets encoded into a platform and produces confident wrong answers at scale, or the logic waits for a perfect platform while the estate keeps deciding by meeting. The build therefore runs two prongs in parallel. Prong one proves the logic by hand — the register seeded from archaeology, the gate run first retrospectively on a decision already made and going well (zero risk; it seeds the register), then on one live decision, with a running mock built against acceptance cases one of which is designed to fail: a proposal violating a hard legal constraint must be caught, and if the mock passes it, the mock is wrong. Prong two builds the data foundation — the shared definitions the tests consume, derived mechanically by working backwards from the six tests (the rule that keeps the list short: no test, no definition), then the measurement layer, bought or built. The join: nothing is encoded that the hand-run has not proven. The mock's by-product is the requirements document any platform must meet — which converts the eventual platform conversation from a sales meeting into a specification.
Failure modes
Hard constraints encoded as scores · cannot-run results silently skipped · the platform bought before the definitions settle · peer comparisons that stop at the firm boundary · the experience adjustment dropped at small group sizes · the gate operated as a veto rather than as information (the gate computes; leaders decide) · the register duplicated per business unit, recreating the incompatible views it exists to replace · the trigger log skipped, so the engine is justified by argument rather than by the list of stale decisions.
Maturity Model considerations
Levels 1–2: placement decided by meeting, on rate and precedent; constraint knowledge fragmented. Level 3: a register exists; checks run ad hoc on contested proposals; outcomes are binary. Level 4: the gate runs routinely with all five outcomes; supply cards current; the trigger log kept by hand; the priced outcome in regular commercial use. Level 5: recompute automated on the trigger classes; the measurement layer feeds the cards on one instrument spanning the firm boundary; a standing feasible-set report reaches leadership each quarter; placement questions arriving anywhere in the estate get the same machinery with a price attached.
See also
- Sourcing Strategy Under Imperfect Data — the two-track strategy this engine serves
- Placement Rules and the Tenure Contract — the decision instrument the engine automates
- Sourcing Design Axes: Node and Client Ownership — the design surface placements are chosen from
- Vendor Governance Placement — where measurement must sit for the comparison to survive
- Service Chain Decomposition and Node Sourcing — the work model that generates placement units
- Chaining and Flexibility Design — the connectivity the cards' flexibility numbers measure
- Wiki:Packs/Placement Decision Engine Build — the deployable build pack (
CP-WFM-008)
Use this with Claude
A ready-to-deploy instruction set and reference files for building the engine are at Wiki:Packs/Placement Decision Engine Build (CP-WFM-008).
