Assignment and Release Workflow¶
Process protocol — instantiates Persistent Site Framing
Governs how occupants enter, hold, and leave sites through explicit turnover states and authority checks, so no placement or vacancy just happens.
An Assignment and Release Workflow is the archetype's process engine: it defines the states a site passes through as occupants come and go — reserved, assigned, occupied, cleaning, cool-down, on hold, released, vacant — and the authorized transitions between them. Its defining move is that turnover is a governed state machine, not an implicit side effect: an occupant does not simply "appear" in a site and a site does not silently go empty; each change is an explicit transition, permitted only to an actor with the authority to make it. The workflow is what turns "someone moved in" into "the reservation was confirmed by the desk, the site transitioned from reserved to occupied, and release will pass through cleaning before it can be reassigned."
Example¶
A hospital ward runs on bed turnover, and bad turnover means a patient waits on a gurney while a "free" bed is actually still dirty or still assigned to someone discharged an hour ago. The ward adopts an Assignment and Release Workflow. Each bed-site moves through defined states: on discharge it transitions occupied → awaiting-cleaning; housekeeping's sign-off transitions it to vacant-ready; the bed coordinator (and only the coordinator) can transition vacant-ready → reserved → occupied for an incoming admission. Every transition names who is allowed to make it, so a nurse cannot mark a bed clean and admissions cannot grab a bed that hasn't cleared cleaning.
The result is that the ward stops double-booking and stops losing beds to limbo. A bed is never "sort of free"; it is in exactly one state, and the only way it changes is a transition someone was authorized to perform.
How it works¶
The workflow is a state machine plus an authority layer. The state model enumerates every legitimate site state and the permitted transitions among them, so illegal jumps (occupied straight to occupied for a different occupant, skipping release) are simply not expressible. The authority layer attaches, to each transition, the permission required to perform it — who may reserve, who may confirm occupancy, who may release, who may place a maintenance hold. When two actors reach for the same transition on the same site, the workflow serializes them so only one wins. It leans on other mechanisms for the parts outside its remit: it asks a compatibility check whether a placement is allowed before it fires the transition, and it emits an event for the ledger to store — but the transition logic and the permission gate are its own.
Tuning parameters¶
- State granularity — a few coarse states versus many fine ones (separate cleaning, inspection, cool-down, reservation holds). Fine states model reality precisely but multiply transitions to manage; coarse states are simple but blur real intermediate conditions.
- Authority tightness — how narrowly each transition's permission is scoped. Tight scoping prevents unauthorized moves but bottlenecks on a few empowered roles; loose scoping is fast but invites mistakes.
- Reservation horizon — how far ahead and how long a site can be held before assignment. Long holds smooth planning but strand capacity in limbo; short holds keep sites live but raise contention.
- Concurrency policy — how simultaneous claims are serialized (first-come, priority, hold-and-confirm). This dial trades throughput against fairness under contention.
When it helps, and when it misleads¶
The workflow's strength is that it makes turnover legible and safe: every placement and vacancy is an authorized, ordered transition, which is what prevents the double-booking a naive system produces when two requests race for the same site — a classic race condition[n1]. It is also where vacancy becomes a real, actionable state rather than the absence of a record.
Its failure mode is rigidity under pressure: an over-strict state machine or an over-scoped authority layer makes people route around the workflow in a crunch — grabbing a bed off-book — and once off-book placements exist, the state model is quietly lying. The related misuse is enforcing states without honoring the compatibility gate, so an authorized-but-unsuitable placement sails through because "the transition was legal." The guarding discipline is to keep the state model faithful to real operations (add the states people actually use rather than forcing reality to fit), gate placement transitions on a fit check, and provide a fast, recorded override so pressure produces an audited exception rather than an invisible one.
How it implements the components¶
The workflow fills the archetype's turnover-governance components:
turnover_and_vacancy_rule— it defines the site states and the permitted transitions among them, making vacancy and every intermediate condition explicit.access_and_permission_policy— it attaches to each transition the authority required to perform it, so only permitted actors can place or release.
It governs the change but does not judge fitness or persist the record. Whether an occupant *may go in — capacity_and_affordance_profile and occupant_compatibility_criterion — is the Capacity-Fit Matrix's, its nearest twin (the matrix certifies eligibility; this workflow enacts the move). And storing what happened — occupancy_history_ledger — is the Occupancy Ledger's.*
Related¶
- Instantiates: Persistent Site Framing — the workflow is the archetype's turnover engine, where sites change state under authority.
- Consumes: Capacity-Fit Matrix — supplies the fit ruling the workflow checks before a placement transition.
- Sibling mechanisms: Site Registry · Physical or Virtual Labeling System · Site Map or Plan · Capacity-Fit Matrix · Occupancy Ledger · Site Lineage Tombstone · Vacancy Status Dashboard · Site Audit Walkthrough
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Governs how occupants enter, hold, and leave sites through explicit turnover states and authority checks, so no placement or vacancy just happens, making its operative form an enacted repeatable sequence of actions, handoffs, or states.
Independent corroboration: The frozen evidence defines Assignment and Release Workflow as 'Governs how occupants enter, hold, and leave sites through explicit turnover states and authority checks, so no placement or vacancy just happens', so its operative form is Protocol, Workflow & Routine.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Facility and service operations govern assignment, occupancy, cleaning, release, and vacancy through authorized turnover states.
Related originating lineages:
- Computer Science & Software Engineering — State machines and concurrency control formalize permitted transitions.
- Medicine & Healthcare — Hospital bed management provides a mature high-stakes application.
Review resolution: Both reviewers agree on organizational operations as primary. Computer science materially formalizes permitted transitions, authorization, and race handling, while hospital bed management supplies a mature high-stakes turnover practice. Logistics and public administration are additional uses, not separately formative here.
Attribution caveat: The workflow combines operational site assignment with an explicit state-machine and concurrency model, illustrated through mature hospital-bed turnover practice.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] A race condition is a defect where the outcome depends on the uncontrolled interleaving of concurrent operations — here, two requests claiming the same site at once. Serializing transitions per site is the standard corrective, which is why the workflow's concurrency policy is a first-class dial rather than an afterthought. ↩