Packing Queue و Fulfillment Priority

When “urgent” makes the queue unsafe

Three fulfillment items reach packing at the same time. One has only 35 minutes before the carrier cutoff. A second has waited four hours but inventory is incomplete. A third was dragged to “very urgent” in a UI without recorded override authority or reason. FIFO misses the cutoff; urgency-only scheduling sends blocked work to packing; drag-and-drop leaves no defensible explanation for why one item jumped ahead.

The lesson outcome is Packing Queue Priority and Fulfillment Evidence Board v1. Every queue position must trace to identity, location, readiness, deadline/cutoff, hold, age, override and starvation evidence. High priority is never permission to bypass a hard constraint.

COM-031 ownership boundary

COM-031 owns queue eligibility, priority class/reason, override audit and starvation protection for packing. COM-030 owns order-state transitions. COM-032 owns label printing and verification. This lesson does not invent order states and does not turn queue rank into authority to print, ship or complete an order.

Three red lines:

1. urgent != ready
2. vendor status != local priority authority
3. previous rank != valid rank after location/readiness change

Mental model: Work identity → Hard constraints → Time risk → Authorized override → Starvation guard → Queue

Auditable path:

fulfillment identity + assigned location → hold/readiness gates → promised ship-by + carrier cutoff → bounded priority class/reason → authorized override check → starvation guard → queue state → packing evidence

Hard constraints intentionally precede urgency. Missing inventory or packing readiness cannot be repaired by a larger score. A location move can stale location-bound readiness, so rank must be recomputed from the changed evidence.

Keep FACT, INFERENCE and DESIGN separate

FACT: Current Shopify documentation describes fulfillment orders as fulfillment work for order items expected to be fulfilled from assigned locations. After order routing, fulfillment orders are created and assigned to locations; status and request status expose lifecycle information.

FACT: assignedLocation is where fulfillment is expected to occur and can change before work starts. Shopify also restricts fulfillment-order moves based on lifecycle, destination inventory, permissions and some request-status conditions.

INFERENCE: Because work identity/location and lifecycle can change, a defensible packing queue should preserve readiness, deadline/cutoff, location, hold, age and override provenance as separate fields rather than collapsing them into one status or score.

DESIGN: In this lesson MAKNOW evaluates hard hold/readiness before priority, keeps priority class/reason deterministic, audits overrides, and applies starvation protection to old eligible work. Fixture thresholds are local teaching choices, not Shopify rules or universal warehouse policy.

The 24-dimension queue evidence contract

Gate 1 — Bind the queue item to fulfillment identity and location

Do not collapse queue_item_id, order_id and fulfillment_order_id. One order can contain multiple fulfillment work items. assigned_location must match the evidence snapshot used for readiness and priority.

Gate 2 — Hard holds precede urgency

If blocking_hold is active, the row is not executable queue work even with an imminent carrier cutoff. Priority only ranks eligible work.

Gate 3 — Inventory Ready and Packing Ready are distinct

Complete inventory does not prove a packing station/process is ready; packing readiness does not prove inventory is complete. Both are explicit. UNKNOWN or STALE is never silently coerced to true.

Gate 4 — Service level, promised ship-by and carrier cutoff are different

service_level expresses a service commitment. promised_ship_by is a shipment deadline. carrier_cutoff is the operational last opportunity on a pickup/dispatch path. Cutoff risk can justify priority, but cannot remove a hold.

Gate 5 — Prefer explainable class + reason over an opaque score

The fixture uses bounded tiers: P0_CUTOFF_RISK, P1_PROMISE_RISK, P2_STARVATION_GUARD, P3_STANDARD_READY. A reviewer must be able to reconstruct priority_reason. An unexplained 87/100 urgency score is weak evidence.

Gate 6 — Override only applies to eligible work

override_requested_by is not authority. A priority change needs valid override_authority and override_reason. Even a valid override cannot bypass inventory/packing readiness or an explicit hard hold.

Gate 7 — Starvation protection keeps low-urgency ready work visible

Old eligible work needs an aging/escalation policy so it cannot disappear forever behind newly urgent work. A starvation guard does not make blocked work ready; it only protects fairness among eligible rows.

Gate 8 — picked_at and packed_at are progress evidence, not priority causes

Execution timestamps help audit queue state and completion. A packed item must not reappear as fresh ready work because a priority function ignored completion evidence.

Gate 9 — Location transfer stales the prior rank

If fulfillment moves before work starts, inventory/packing readiness and cutoff context may change. The old rank is not an oracle. Rebuild location-bound evidence and recompute.

Gate 10 — Missing decisive evidence fails closed

Missing/unknown location, readiness, hold, cutoff or authority yields HOLD_UNKNOWN_EVIDENCE or another non-success state. The queue must not manufacture success to keep a UI tidy.

Worked examples

1. Ready + cutoff in 35 minutes → QUEUE_P0_CUTOFF_RISK

Inventory and packing are ready, no hold exists, location is stable and cutoff is near. priority_reason=CARRIER_CUTOFF_WITHIN_WINDOW is reconstructible.

2. Four hours old but inventory incomplete → HOLD_NOT_READY

Age, service level and even override requests cannot manufacture readiness.

3. “Urgent” without override authority → REJECTED_UNAUTHORIZED_OVERRIDE

The request is preserved, but official rank does not change without authority and a reason.

4. Ready and old, no near deadline → QUEUE_P2_STARVATION_GUARD

Aged eligible work is promoted by the starvation guard so it cannot wait indefinitely.

5. Hard quality/risk hold + imminent cutoff → HOLD_BLOCKING_CONSTRAINT

The time risk is real, but the hard hold is more decisive. Urgency is not a bypass token.

6. Transfer to a new location → RECOMPUTE_LOCATION_CHANGE until evidence is rebuilt

If readiness_location still points to the old location, prior inventory_ready=true is stale. Revalidate readiness/cutoff at the destination, then compute a new class.

Common failure modes

• FIFO as the only rule;
• UI drag-and-drop with no audit trail;
• one opaque urgency score mixing holds and deadlines;
• promoting blocked work because cutoff is near;
• merging inventory readiness with packing readiness;
• treating service level as deadline/cutoff evidence;
• override without actor/authority/reason;
• aging without starvation policy;
• reusing old rank after a location move;
• coercing UNKNOWN/STALE evidence into success.

Alternatives and trade-offs

FIFO: simple and predictable, but ignores deadline risk and can promote blocked old work.

Earliest-deadline-first: useful for time commitments, but unsafe without readiness and hold gates.

Weighted score: flexible, but explainability suffers when weights/vetoes are unclear. Bounded tiers plus reason are easier to audit here.

Manual dispatcher: valuable for exceptions, but requires explicit override authority and reason or the queue becomes oral policy.

Strict location queues: simple and locality-friendly, but any reroute must rebuild readiness and cutoff context.

For this scope the defensible pattern is: hard gates → bounded class/reason → controlled override → aging/starvation guard.

Experienced bridge: thirteen review questions

1. Are queue item and fulfillment-order identities distinct and stable?
2. Does assigned location match this evidence snapshot?
3. What do fulfillment/request status prove—and not prove?
4. Are inventory and packing readiness separate?
5. Is blocking hold evaluated before priority?
6. Is service level separate from promised ship-by?
7. Is carrier cutoff valid for this path/location?
8. Can priority class be reconstructed from priority reason?
9. Are override actor, authority and reason all present?
10. Can override bypass any hard hold? It must not.
11. Does old eligible work have starvation protection?
12. Are picked/packed evidence consistent with queue state?
13. After a location move, was the result recomputed or copied?

Guided and independent practice

The offline lab provides eight fixtures. Run the cutoff-risk baseline, then compare inventory-blocked, unauthorized override, location-change-with-stale-readiness, aged-without-starvation-guard, explicit hold and missing-evidence cases.

Independent exercise: move a standard row from LOC-A to LOC-B. At LOC-B the carrier cutoff is 90 minutes later, but packing readiness has not been confirmed. You may not copy the old rank or only change the location string. Rebuild readiness/cutoff evidence, then compute a fresh class/reason.

Verification evidence

A passing artifact populates all 24 dimensions or preserves an explicit non-success state. Hard hold and readiness are evaluated before urgency; class/reason are deterministic; override provenance is complete; starvation protection only applies to eligible work; and location transfer invalidates/recomputes location-bound evidence.

The lab is synthetic and offline: no Shopify shop, WMS, real inventory, API key or customer data is required.

Assessment and transfer

To finish the lesson you must be able to:

1. separate COM-031 from COM-030 and COM-032;
2. build Packing Queue Priority and Fulfillment Evidence Board v1 from a fixture;
3. keep inventory-blocked and hard-held work fail-closed despite urgency;
4. reject unauthorized override and detect starvation-policy failure;
5. recompute a fulfillment moved to another location from fresh evidence;
6. explain why vendor status, FIFO or a single score is not sufficient priority proof.

References and freshness

• Shopify GraphQL Admin API — FulfillmentOrder lifecycle and order routing; rechecked 2026-09-15; review due 2026-10-18.
• Shopify FulfillmentOrderAssignedLocation — assigned-location semantics and pre-work changes; rechecked 2026-09-15; review due 2026-10-18.
• Shopify fulfillmentOrderMove — move restrictions involving lifecycle, inventory, permissions and request status; rechecked 2026-09-15; review due 2026-10-18.
• Tier, override and starvation rules in this lesson are local MAKNOW DESIGN and are not attributed to Shopify.