Placement Under Duress (generic process)

Placement Under Duress (generic process) is the generic process card, GP-502, for moving work between nodes when a severity 1 or 2 event has removed part of the supply or the demand picture. It is the second product of the continuity wire described on Integrated Global Resource Optimization Center, which states the principle this card implements: continuity is placement under duress, a sudden change in the constraint set answered by re-deriving placement rather than by executing a static binder. Business continuity is a partner function; it decides activation and holds the command structure, and this card does not. The card owns its method: the archive of configurations pre-computed per event class, the placement gate of The Placement Gate run in its emergency form, the rule that every emergency placement carries a dated expiry, and the unwind. It is called by step 8 of Crisis Trigger and Re-Plan (generic process) and is part of Process Standardization, under the continuity-interface section of the function catalog in Anatomy of a ROC Standard.

The archive is the card's distinctive object. The business-continuity standard requires continuity strategies and solutions to be determined and selected before a disruption, not during it, and the resilience literature's case studies attribute much of the difference between firms that recover from a supply disruption and those that do not to preparation made before the event; the archive is that preparation for placement, taken through the ordinary gate when there is time and re-run under the emergency rules when there is not.

Process profile

The profile extends the L0 identity fields of Process Decomposition (L0–L3). Local values are held by the deploying function and marked SET LOCALLY.

Field	Generic value
Card	GP-502 · local card id assigned by the standards committee at deployment
Class	both: the placement runs on the real-time clock; the archive refresh on the strategic clock
Trigger	a crisis re-plan (GP-501) that calls the placement lever; the archive refresh on its cadence
Cadence	event-driven; the archive is refreshed quarterly against the current constraint register (SET LOCALLY; quarterly is typical [A]) and after every post-event review
Scope in	the archive; the emergency gate; the placement order; the expiry register; the unwind; the archive refresh
Scope out	activation and command (the continuity owner's); the routine gate (Placement Decision Through the Gate (generic process)); the routing change's mechanics (Vendor Change Control for Routing); contract negotiation
Inputs	the re-plan; the archive entry for the event class; the constraint register and supply cards of Placement Engine Architecture; the capability record (skills, languages, permissions); the expiry register
Outputs	the gate output page in emergency form; the placement order (what moves where, from when, until when); the expiry register entry; the unwind order; the archive revision and the recompute-log entry
Upstream	GP-501; the placement function's register and cards; the capability record
Downstream	the node owners who receive the work; routing change control; the real-time desk; the continuity command (informed); GP-501 step 13 (the unwind)
Resources	the archive; the constraint register; the capability record; the routing change path; the expiry register. Platforms are named at L3, never here
Decision points	is there an archive entry; are its pre-run tests still current; does a never-suspended test fail; does the move exceed the tier; extend or unwind at expiry
Authority tier	moves inside the archive at tier 3, the ROC duty lead; moves outside the archive or across a contractual boundary at tier 4, the function head; a move that changes a client promise to the executive sponsor by exception; all of this where leadership has given the wire authority to move work; otherwise the order goes as a proposal to operations and the continuity command
Risk and compliance flags	contractual eligibility (consent, data residency, service credits); language viability; data-access permissions at the receiving node; cross-border employment rules; an emergency placement that outlives its event
Variant-prone steps	the gate where a jurisdiction requires works-council notice before work moves; the order where a client requires consent; the routing step where a partner platform is not integrated
Automation candidates	eight L2 sub-steps (listed below)

L1 flow

1. Receive the placement call from the re-plan, with the scope and the gap by node. Owner: the placement lead.
2. Does the archive hold a configuration for this event class? If not, run the emergency gate from the register and log the archive gap. Owner: the placement lead.
3. Load the entry: bodies of work, destination nodes, routing changes, and the tests pre-run with their dates. Owner: the placement analyst.
4. Are the pre-run tests still current against the register's dates? Re-run any stale row. Owner: the placement analyst.
5. Run the emergency gate: contractual eligibility and language viability always; continuity in its reversed form (does the move concentrate the surviving work on one node); pooling cost, coverage floor and construct fit suspended and recorded as suspended-by-policy, never silently skipped; the mark is distinct from the gate's cannot-run, which names a missing input. Owner: the placement analyst.
6. Does a never-suspended test fail? If yes, the move is unavailable; return to the re-plan for another lever. Owner: the placement lead.
7. Set the expiry: a date and time on every emergency placement, with a review before it. Owner: the placement lead.
8. Does the move exceed tier 3? If yes, to the function head; if a client promise changes, to the executive sponsor. Owner: the ROC duty lead.
9. Issue the order: where leadership has given the wire authority to move work, to the node owners, and raise the routing change; otherwise as a proposal to operations and the continuity command, and raise the change on their acceptance. Owner: the placement lead.
10. Confirm the move landed: routing, capability record, the receiving node's acknowledgement. Owner: the real-time analyst.
11. At the review before expiry: is the re-plan still active? If yes, extend with a stated reason and a new date; if no, unwind. Owner: the placement lead.
12. Unwind: reverse the routing change, return the work, confirm, close the order. Owner: the placement lead.
13. Record the outcome in the recompute log and revise the archive entry. Owner: the placement analyst.
14. Refresh the archive on cadence: re-run every entry's tests against the current register and cards. Owner: the placement analyst.

L2 step table

Step	Sub-step	Owner (seat)	Inputs	Outputs	Duration	Automation candidate	Documentation join key
1	1.1 Log the call with the re-plan version	placement lead	re-plan	placement call entry	minutes	N	order template
2	2.1 Look up the event class in the archive index	placement lead	event class	entry, or gap logged	minutes	N	archive index
3	3.1 Load bodies of work, destinations, routing changes, pre-run tests	placement analyst	archive entry	loaded configuration	minutes	N	archive entry template
4	4.1 Compare each pre-run test's date to its register rows	placement analyst	entry, register	current or stale per test	minutes	Y	currency check
4	4.2 Re-run stale tests	placement analyst	register, cards	refreshed results	SET LOCALLY	Y (compute)	gate checklist
5	5.1 Read contractual eligibility from the register for each body of work and destination	placement analyst	register	pass or fail, clause cited	minutes	Y (lookup)	gate checklist
5	5.2 Test language viability at each destination	placement analyst	capability record	pass or fail per language	minutes	Y (compute)	gate checklist
5	5.3 Record suspended tests as suspended-by-policy	placement analyst	—	output page rows	minutes	N	gate checklist
6	6.1 Decide availability of the move	placement lead	output page	available, or returned to GP-501	minutes	N	gate checklist
7	7.1 Set expiry and review date; enter in the register	placement lead	order	expiry entry	minutes	N	expiry register
8	8.1 Sign at tier 3, or obtain tier 4 sign-off where required	ROC duty lead, function head	order, output page	signed order	SET LOCALLY	N	order template
9	9.1 Issue the order, or the proposal where the wire carries no authority; raise the routing change	placement lead	signed order	order issued, change raised	SET LOCALLY	Y (draft)	order template
10	10.1 Verify routing, capability record and acknowledgement	real-time analyst	routing state, record	landed, or exception	SET LOCALLY	Y (verify)	landing checklist
11	11.1 Review before expiry; extend with reason or unwind	placement lead	re-plan status	extension entry or unwind order	minutes	N	expiry register
12	12.1 Reverse the routing change; return work; confirm; close	placement lead	order	closed order	SET LOCALLY	N	unwind checklist
13	13.1 Write the recompute-log entry; revise the archive	placement analyst	outcome	log entry, revision	SET LOCALLY	Y (draft)	recompute log
14	14.1 Re-run every entry's tests; retire entries that fail	placement analyst	register, cards	refreshed archive, gap list	per cadence	Y (compute)	archive refresh procedure

Variants

Recorded per Standard and Variant in Process Documentation:

• Statutory. Data-residency and cross-border employment limits are register entries that the eligibility test reads; SET LOCALLY, no row. A jurisdiction whose works council must be informed before work moves inserts a notification step between steps 8 and 9, owned by the works-council liaison, approved by the function head.
• Contractual. A client that forbids overflow is a register entry, no row. A client that requires consent before relocation inserts a consent step before step 9 under a variant row, reviewed at contract renewal.
• Structural. A destination whose partner platform takes no routing change from the function varies step 9 to a manual hand-off through the partner's oversight owner, with a review date.
• Transitional. A unit from a predecessor organization whose archive is still in its old form keeps it under a variant row with an expiry at the first archive refresh on the shared register.

L3 register

Job aid	Anchored to	Form
The archive index and the entry template	steps 2 to 3	work instruction
The currency check against register dates	step 4	work instruction
The emergency gate checklist: suspended-by-policy, never suspended, reversed	step 5	runbook
The expiry register and its review alarms	steps 7 and 11	work instruction
The placement order template and tier table	steps 8 to 9	work instruction
The landing checklist	step 10	runbook
The unwind checklist	step 12	runbook
The archive refresh procedure and gap log	steps 13 to 14	playbook

Automation candidates

Flagged at L2 per Process Decomposition (L0–L3); released per class of action on a published catch rate per Human Gates and Number Grades. The eight rows marked Y are ranked by how easy a catch rate is to publish for each.

1. The currency check (4.1): a date comparison, and a stale pre-run test is the commonest way an archive entry fails [A].
2. The eligibility lookup (5.1): a clause read from the register; after #1 because it depends on the register row being current.
3. The language-viability computation (5.2): coverage against the capability record; after #2 because the record drifts between refreshes.
4. The stale-test re-run (4.2): after #3 because it re-runs whichever test went stale, because it can re-run any of the six tests, so no single catch rate covers it.
5. The archive refresh (14.1): the same re-run on a calendar across every entry; after #4 because errors accumulate before anyone reads the result.
6. The landing verification (10.1): routing and record state compared to the order; after #5 because routing state is read from platforms that differ per node.
7. The order draft (9.1): assembled, then signed; after #6 because its output is a document whose errors are found by the signer, not by rule.
8. The recompute-log entry (13.1): written after the event; last because a miss there is cheap and slow to detect.

The extension decision (11.1) is never a candidate. It is the point at which an emergency placement becomes a permanent one; the expiry rule generalizes the convention on Standard and Variant in Process Documentation that an accommodated variation without a date is never retired, and the staffing penalty of a split pool that was acceptable for a week is paid every week it outlives its event. The availability decision (6.1) also stays human, because a hard constraint excludes and never lowers a score, principle 2 of Operating Principles for Work Placement, and the person signing must see the clause.

Maturity Model Position

Four scales on this wiki use the word level; the launch page states which is which. On the WFM Labs Maturity Model™ a function that moves work in a crisis through a written order with an expiry is at Level 2; one with an archive refreshed on cadence and an emergency gate that records suspended-by-policy is at Level 3; one whose emergency gate runs with all five outcomes, whose archive is current and whose trigger log is kept by hand is at Level 4; one whose archive is re-run by the placement engine's automated recompute on the trigger classes is at Level 5, where Placement Engine Architecture places that recompute.

See Also

• Process Standardization — the hub and the inventory this card belongs to
• Integrated Global Resource Optimization Center — continuity as placement under duress
• The Placement Gate — the six tests and five outcomes this card runs in emergency form
• Placement Engine Architecture — the register, the cards and the recompute
• Crisis Trigger and Re-Plan (generic process) — the re-plan that calls this card
• Vendor Change Control for Routing — the routing change the order raises
• Operating Principles for Work Placement — a hard constraint excludes, it never lowers a score
• Standard and Variant in Process Documentation — how the variants above are recorded