Wiki:Packs/Placement Decision Engine Build

A pack is a deployable set for a Claude project: one instruction block pasted into the project's custom instructions, and reference blocks saved as .md files and uploaded as project knowledge. Packs carry no installable skill.

This pack supports building a working placement decision engine — a constraint register, a test gate run against real placement proposals, supply cards, and a recompute log — by hand or in lightweight tooling first, ahead of any platform purchase. It is the implementation companion to CP-WFM-007, which carries the architecture the engine serves.

When to use it

Use this pack when an operation has accepted that placement should be a produced answer rather than a recurring argument, and wants a running mock: to test the logic on real decisions, to catch commitments that violate hard constraints before signature, and to generate the requirements document that disciplines any later purchase of a commercial scoring or orchestration platform. It assumes the sourcing architecture is broadly understood; it does not re-argue it.

How to deploy

1. Create a Claude project for the engine build.
2. Paste Block 1 into the project's custom instructions.
3. Save Blocks 2–5 each as a .md file with the stated filename and upload all four as project knowledge.
4. Start each working session by naming the artifact being built (register, a test, a card, the recompute log).

Block 1 — Project instructions

# Placement decision engine — build project

[CONTEXT]
This project builds a working mock of a placement decision engine for a
service operation: a constraint register, a six-test gate that scores
placement proposals, supply cards describing every pool work can go to,
and a recompute log that re-runs decisions when the world changes. The
mock is built independently of any vendor platform; one of its outputs
is the requirements document that disciplines a later platform purchase.

[ROUTING]
| Task | Open |
|---|---|
| Define or classify a constraint; build the register | constraint-register.md |
| Score a proposal; run or implement any of the six tests | gate-tests.md |
| Describe a supply pool; set up recompute triggers | supply-cards-recompute.md |
| Scope the build, its test cases, or platform requirements | build-spec.md |

[DISCIPLINES]
- The engine computes; leaders decide. Never emit a placement verdict —
  emit scored outcomes with reasons.
- Hard constraints are never encoded as scores. A legal or contractual
  bar excludes; it does not merely lower a ranking.
- CANNOT-RUN plus the named missing input is a real result. Never skip
  a test silently.
- Every outcome carries its explainability record: inputs, register
  entries cited by ID, and reasons in plain language.
- Pre-convergence, the mock restates freely when a definition changes.
  Immutability is a property to adopt after definitions settle.
- No figure transfers across domains without the transfer argument
  stated. Mark judgment figures [estimated].
- Experience/tenure is an always-on dimension of any comparison, never
  conditional on group size.

[OUTPUT]
One page per scored proposal: six test results in a row · every
non-pass explained in one plain sentence with its number · register
entries cited by ID · missing inputs named · the counterfactual (what
would have been decided without the gate). Requirements documents list
only demands proven by a build or test-case experience. Refuse to
produce unpriced "fail" verdicts where a price is computable.

Source: Wiki:Packs/Placement Decision Engine Build (CP-WFM-008) v1.0

Block 2 — constraint-register.md

# The constraint register

One row per constraint — never one per business unit or per legacy
organisation. Where views of the same constraint differ, the
disagreement is recorded inside the entry, not resolved by creating a
second entry. The register is the data model the gate runs against; the
schema is the asset and the container (spreadsheet, database) is
disposable.

## Schema — eleven fields

| # | Field | Content | Governing rule |
|---|---|---|---|
| 1 | ID | Permanent identifier | Never reused or renumbered |
| 2 | Statement | The constraint in one plain sentence | Plain version leads; term of art follows in brackets |
| 3 | Scope | The work it binds: routing group, channel, language, client, entity | Uses the operation's routing-group definition |
| 4 | Source instrument | Contract clause (cited) · regulation (cited) · platform limitation (named system) · operating preference (named holder) | The fourth category is legitimate and must be labelled — an unlabelled preference argues with the force of a law |
| 5 | Strictness | HARD · SOFT · PRICED | The field doing most of the work; see taxonomy below |
| 6 | Price to relax | For PRICED: number and method. For HARD-with-a-route: the instrument and its cost | "Unpriced" is a work item, not a resting state — an unpriced caution argues at full strength or not at all |
| 7 | Lead time to relax | How long relaxation takes once decided | Renegotiation cycles, statutory clocks, accreditation |
| 8 | Expiry / review date | When the constraint changes by itself: renewal, legal change in progress, dated window | Feeds the pass-with-a-dated-transition outcome; the contract renewal calendar populates this field wholesale |
| 9 | Disagreement record | Both readings, holders named, and what would settle it | A disagreement with a resolution test is an asset; one resolved by seniority is a liability that returns |
| 10 | Owner | Who can answer questions about it — not who adjudicates it | The register computes; owners inform; leaders decide |
| 11 | Last verified | Date and method | Entries older than two quarters flag stale at gate time |

## Strictness taxonomy

- **HARD, no route** — law or regulation; "no" is the complete answer.
- **HARD, with a named route** — a contract bar whose relaxation
  instrument exists (renegotiation); it therefore has a price and a
  lead time.
- **PRICED** — tradeable at a computable cost (a dedication commitment,
  a concentration caution). Classification converts these rows from
  arguments into numbers.
- **SOFT** — a preference that yields to a stated argument (a
  minimum-team-size floor standing in for an unwritten concern).
- **Not a constraint** — an objective ordering ("protect premium
  service in-house") wearing a constraint's clothes. Record once, then
  move it to the objective register with a price.

## Six worked archetypes

1. Staff of one legal entity may not serve another entity's volume
   without renegotiation — HARD with a route; price and lead time from
   the commercial owner; expiry = renewal date.
2. Round-the-clock working is unlawful in a given jurisdiction — HARD,
   no route. The archetypal must-catch: commitments of this shape have
   been sold against known constraints in real estates because no step
   tested the proposal against the register.
3. A mobility restriction currently being relaxed with counsel engaged
   — HARD today, with an expiry date; a constraint with an expiry date
   is a planning input.
4. A dated exit or restructuring window — PRICED and dated; benefit
   arrives on a curve, not a switch.
5. An unpriced concentration caution — PRICED, currently unpriced;
   flagged as a work item.
6. A minimum-team-size floor — SOFT; an operating preference standing
   in for a concern nobody wrote down, visible only once classified.

## Population method — archaeology, not analysis

Three sources, three methods. Named positions: one structured
conversation per holder — what must be true · what makes it so · what
would change your mind — issued as a data request, never attached to a
proposal. Documents: contracts, offer terms, the renewal calendar;
every entry cites its clause; "we don't know why this group exists" 
creates an entry with an owner and a verification task, not a blank.
Configurations: what the routing platform actually enforces, pulled
from configuration, not memory; where configuration contradicts a
contract entry, record both in field 9 — the delivered state is a
finding.

## Hygiene

Nothing binds at gate time that is not in the register · asserted
entries marked as such · every PRICED entry states its method · what
could not be established is recorded, not dropped · any constraint
invoked at gate time without an entry becomes an entry before the run
completes — the gate is the register's collection mechanism.

Block 3 — gate-tests.md

# The gate — six tests, five outcomes, one record

Every placement proposal is scored before it becomes a decision. A
proposal states: what work, from where, to where, under what commercial
construct. The gate consumes the proposal and the constraint register
and returns one outcome per test.

## Outcomes

PASS · FAIL · FAIL-WITH-A-PRICE (the price computed, in heads and
money) · PASS-WITH-A-DATED-TRANSITION (eligible now; recompute at the
stated date from register field 8) · CANNOT-RUN + the named missing
input (a real result — it feeds the definitions queue and is never
silently skipped).

Fail-with-a-price is the outcome that makes the gate usable by a
commercial organisation: a proposal failing on cost grounds remains a
decision available to the business — it becomes a purchase rather than
an assumption. Pass-with-a-dated-transition 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).

## The six tests

1. **Continuity.** Does the placement concentrate work such that one
   failure takes it all? Compute the share of each routing group's
   volume at the largest single point of failure — site, supplier, and
   legal entity (entities fail as surely as buildings). Thresholds are
   policy; until set, report the concentration.
2. **Coverage floor.** Does the roster required to cover the promised
   hours exceed what volume justifies? Covering a clock takes ~5.6
   heads before absence, whatever the volume; apply shrinkage for the
   true floor. Read the commitment class (business-hours vs 24/7) from
   the agreement, not from practice — the class changes the viability
   threshold by roughly 3x. Produces fail-with-a-price naturally: floor
   minus justified staffing, priced at the receiving pool's cost.
3. **Pooling penalty.** What does a proposed split cost in additional
   staff for identical service? Erlang C, computed per pool vs pooled.
   Implementation note: compute Erlang C via the Erlang B recursion —
   the naive factorial form overflows above roughly 170 erlangs. Two
   standing sensitivities to report with every run: tighter targets
   raise the penalty, and lower handle time raises it — so every minute
   automation removes makes dedication more expensive, which couples
   this test to the recompute triggers.
4. **Contractual eligibility.** What does the client agreement actually
   permit? Archaeology, not computation: read clauses against the
   proposal; any invoked constraint without an entry becomes an entry.
   The dated outcome originates here — eligibility that changes at
   renewal returns pass-with-a-dated-transition.
5. **Language viability.** Is each affected language pool viable
   against its occupancy floor — not its volume? Same arithmetic family
   as the coverage floor, applied per language with a stated
   attribution rule (contact language vs client language vs market).
6. **Construct compatibility.** Which service construct is this work
   sold under, and does it pool with the destination? Record the sold
   label and the delivered configuration separately — they are known to
   diverge in real estates — and price any gap rather than assuming
   either.

## Why the gate exists — two failure shapes it replaces

Real estates demonstrate both: a documented hard constraint that did
not stop a commitment (sold anyway, because no step tested the proposal
against the constraint set before signature), and an undocumented
objection that stopped a proposal only because a specific executive
happened to be in the room. The two fail in opposite directions and
prove the same thing: in neither case did a process do the work.

## The scoring record

One page per proposal: the proposal in two sentences · six results in
a row · every non-pass explained in one plain sentence with its number
· register entries cited by ID · missing inputs named · 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 — either is worth knowing.

## First runs

Run a retrospective pass on a decision already made and going well —
zero risk, debugs the tests, populates the register with real entries.
Then one live decision, with the result delivered to the proposal's
owner as theirs. Expect two or three CANNOT-RUNs on the first live run;
those are findings that scope the definitions work, not failures.

Block 4 — supply-cards-recompute.md

# Supply cards and the recompute log

## One card per pool

Every pool work can be routed to — each owned centre, each supplier
engagement, each in-market team, each automated capacity — gets one
card, refreshed on a stated cadence. Four objective families, at least
one measured attribute each:

| Objective | Attributes | Source |
|---|---|---|
| Cost | Cost per productive hour on a stated hour base · cost per resolved case where measurable | Contracts and finance, base stated |
| Quality | Performance at equal tenure, with the instrument's resolution stated · error rates where instrumented | The comparison layer |
| Speed | Time to seat AND time to proficiency — two goods, two numbers, never one | Ramp records |
| Flexibility | Genuinely variable cost share at 30/60/90 days (contract-term audit) · realised routing edges to the rest of the estate (from routing data, not the skills matrix) · notice and minimums | Contracts + routing systems |

Flexibility typically has no measured attribute anywhere in an estate;
the two auditable numbers above make it measurable. The variable-share
audit is the test separating bought elasticity from a hiring
arrangement wearing an elasticity costume.

An automated pool's card carries the same four families plus its drift
terms: per-intent quality on the operation's own work (never
transferred from another domain without the transfer argument), 
evaluation stability across model updates, regression results, and the
recompute triggers it has fired.

## The recompute log — the property that justifies an engine

The engine's single advantage over a spreadsheet is that it re-runs
when the world moves. Trigger classes, each observable today:

| Trigger | Source | What recomputes |
|---|---|---|
| Contract renewal / expiry | Register field 8 | Every placement citing the entry |
| Legal or regulatory change | Entries with relaxation in progress | The affected feasible set |
| Language crosses its viability threshold | Volume vs the coverage floors | Language placements, both directions |
| Automation milestone | The automation programme's own reporting | Every human pool the automated node drains — automation takes the most routine work first, so each step re-poses the sizing question for the rest. Also every dedication price, since lower handle time raises the pooling penalty |
| Tooling maturity change | Assist deployments per book of work | Eligibility for the affected work |
| Card material change | Attrition breach, cost restatement, edge break | Placements on that pool |

Build sequence: the trigger log first, by hand, for a quarter — a list
of fired triggers and what should have recomputed. It costs nothing,
sizes the real build honestly, and produces the most persuasive
artifact available: the list of decisions that went stale with nobody
noticing.

## Definitions: derived, not decreed

The engine's inputs need shared definitions, and the honest scope is
derived mechanically: work backwards from what the six tests consume.
Typical result: roughly a dozen definitions (what counts as a contact
per channel · handle time including asynchronous work · occupancy vs
utilisation · shrinkage · the productive-hour base · service-level
measurement grain · the exclusivity constructs' delivered meaning · the
routing-group unit · the constraint-entry schema itself · coverage
commitment class · language attribution · headcount system of record ·
tenure and attrition at named-team grain). The rule that keeps the list
short: no test, no row. Notably, quality-rubric harmonisation is
usually NOT on the list — no gate test consumes a quality score — so
the hardest, most political definitional item is formally deferrable.

Definitions apply prospectively; history is never restated on the
operation's books. The mock itself, however, restates freely while
definitions converge — immutability is a virtue to adopt at the
platform stage, after convergence, not before.

Block 5 — build-spec.md

# The mock — build specification

## Why a mock before a platform

Framework before platform: prove the logic on the operation's own
decisions first, then buy machinery that runs it at scale. A mock that
runs is worth more than a requirements workshop — what it cannot
express is discovered by building. The mock also keeps the walk-away
from any platform purchase priced at zero: the manual gate, the
register, and the cards proceed identically whether or not a platform
is ever bought.

## v0 — the gate, running

- Data model: constraint entries (the eleven-field schema) · proposals
  · supply cards. Spreadsheet, notebook, or lightweight database —
  whatever runs fastest.
- The six tests as functions; Erlang-based tests via the Erlang B
  recursion (the naive form overflows above ~170 erlangs).
- The five outcomes, including CANNOT-RUN with the named missing input.
- Output: the one-page scoring record with the counterfactual field.
- Every outcome carries its explainability record — inputs, entries
  cited, reasons in plain language — so challenges are answered by the
  record, not by whoever ran it.

## v1 — the recompute

The trigger log; on a fired trigger, re-run every proposal citing the
affected entries and diff the outcomes. Stretch goal: for any failed or
expensive proposal, name the binding constraint — which register entry,
relaxed, flips the outcome, and at what price. Naming the binding
constraint is a better product than issuing a recommendation.

## Acceptance test cases — four shapes, one designed to fail

1. Retrospective: a move already in motion and going well — should
   PASS; populates the register with real entries as a by-product.
2. Live: a quantified, endorsed proposal — expected PASS with a priced
   caveat (typically the surge-backup question).
3. The unlawful-commitment counterexample — a proposal violating a
   HARD legal constraint MUST FAIL. If the mock lets it through, the
   mock is wrong.
4. A dated case — a placement touching an expiring constraint must
   return PASS-WITH-A-DATED-TRANSITION with the date attached.

## What the mock produces for any platform conversation

A requirements document generated from building rather than imagined:

- The definition IDs every consumed metric is stamped with — and the
  demand that an immutable metric store ingest nothing whose
  definition is not settled, because forward-only correction applied
  to unsettled definitions produces permanently wrong records.
- The score inputs the gate actually wants from a scoring layer.
- Two hard demands most commercial scoring platforms fail by default:
  peer groups that span firm boundaries (owned centres, each supplier,
  in-market, automated capacity — the comparison every sourcing
  decision needs), and tenure/experience as an always-on dimension,
  never conditional on group size.
- The trigger feed the recompute needs — including what a
  constraint-solver's exhaust would have to emit for the engine to
  consume "most-constraining constraint" signals.
- The integration boundary, stated plainly: constraints and the gate
  belong to the operation; scoring within the feasible set is what a
  platform bids for. A hard constraint encoded as a score is a
  preference wearing a rule's clothes.

## Working discipline

First cut in about a week; rough is fine, running matters. Checkpoints
at (a) data model plus one test end-to-end, (b) all four acceptance
cases behaving. Gaps hit along the way — missing definitions, missing
data, ambiguous constraints — are half the deliverable: record them,
never work around them silently.

Usage notes

The instruction block loads with every message in the project — keep it under 500 words if edited. Reference blocks are derived from the source articles listed in the infobox and will drift as those articles evolve; a material change to any of them is the trigger to regenerate and increment the version. The pack deliberately contains no organisation-specific data: registers, cards, and test cases are populated inside the consuming project, which is where confidential material belongs.

Change history

Version	Date	Change
1.0	2026-08-27	Initial release: instruction block + four reference blocks

See also

• Sourcing Strategy Under Imperfect Data — the strategy frame the build serves

• Placement Engine Architecture — the full architecture this pack builds, with figures

• Wiki:Packs/Sourcing Architecture for an Agentic Service Chain — the architecture this engine serves
• Placement Rules and the Tenure Contract
• Sourcing Design Axes: Node and Client Ownership
• Vendor Governance Placement