Designing for an Operation That Wouldn’t Stay Still
The software assumed stable relationships. The warehouse kept changing them.
A new distribution-center concept challenged assumptions that worked in more stable environments. Doors changed, trailers moved, conveyor paths merged, and equipment or maintenance could interrupt expected routes. The operating model also lacked a reliable formal signal for trailer completion.
I explored changing physical relationships, uncertainty, manual overrides, exceptions and fallback behavior rather than treating configuration as permanently true.
EXPLORATION / CONCEPT · NO IMPLEMENTED ROUTING OUTCOME CLAIMED
From configured path to active relationship.
Trailer / Door A → Conveyor B → Destination C
What should connect. Useful while those resources and relationships remain available.
Is the configured route still valid?
- Relationship
- Currently associated
- Availability
- Needs current resource evidence
- Override
- Explicit if manually changed
- Completion
- Unknown without an authoritative signal
Generalized comparison, not a live route, production screen or equipment-control instruction.
A valid configuration could become an invalid operating assumption.
The new facility changed the assumptions.
Limited trailer space, changing door assignments, merged conveyors, maintenance exceptions, manual overrides and unavailable equipment could invalidate an expected path.
Without a reliable “trailer complete” signal, inactivity could not establish that nothing else would arrive. That uncertainty belonged in the model.
How the problem changed
- Initial framing: where should this work route?
- Physical investigation: door, trailer, conveyor and capacity relationships could change.
- Exception discovery: maintenance, overrides and unavailable resources could invalidate paths.
- Signal gap: not every physical state had a reliable digital equivalent.
- Reframe: manage changing relationships under imperfect information.
Lifecycle reconstruction of the problem framing. Source artifacts can strengthen this model without implying a shipped routing system.
Route = relationship + current state + confidence.
- Relationship + availability
- What should connect, and can each resource participate now?
- State + confidence
- What is happening, and how well does the system know it?
- Permission + override
- Who can change the relationship, and has normal behavior been intentionally changed?
- Exception + fallback
- What blocks the expected path, and what alternatives require a decision?
- History
- Who changed what, when and why?
The route was not a line. It was a relationship with state.
Workflow: change a route without losing context
- Show the current source, door, conveyor, destination and status.
- Expose the change: moved trailer, new assignment, unavailable equipment or maintenance.
- Show the conflict instead of silently retaining the obsolete mapping.
- Evaluate alternatives against known availability and constraints.
- Have an authorized user choose or confirm the new relationship.
- Record a manual override’s owner, time and reason where appropriate.
- Make the active relationship visible to downstream users.
- Provide a deliberate return to normal behavior when the exception resolves.
CONCEPT · A decision workflow, not a claim that arbitrary rerouting was technically available or safe.
Design the rules for change, not just the happy path.
- Make the active relationship visible. Distinguish configured from current state.
- Represent uncertainty. Inactive does not mean confirmed complete. Unknown is a valid state.
- Make overrides first-class. Show what changed, who changed it, why and whether it remains active.
- Expose fallback before failure. Show alternatives, unavailable dependencies and required human decisions where feasible.
- Preserve downstream awareness. A route change may affect merges, capacity, labor, equipment use and maintenance windows.
Human override should be observable, not invisible.
Exceptions were part of normal operations.
- Confirmed
- A reliable event establishes the state.
- Inferred
- Available signals suggest the state.
- Manually set
- A user explicitly establishes it.
- Unknown
- Evidence is insufficient.
Illustrative evidence labels, not shipped UI states or calibrated probabilities.
Physical changes, unavailable or degraded equipment, redirected work, maintenance, intentional overrides and missing knowledge each need a clear representation.
In operational software, the exception path is often just another Tuesday.
Permissions, controls and safe feasibility
Who may alter a relationship? Which changes require confirmation or Engineering involvement? When must the system prevent a change?
Controls logic, equipment capability, safety procedures and engineering constraints determine what is possible. The interface cannot authorize a physical route simply by making an option selectable.
Dynamic systems need memory
Later investigation may need the route active at a particular time, the automatic or manual change, its owner, the exception present and when normal behavior resumed.
History helps explain why the operation behaved differently between two moments—not only whether someone followed a process.
Evidence → decision → tradeoff
Evidence
Physical assignments, conveyor dependencies, interruptions and overrides changed while completion signals remained incomplete.
Decision
Treat routing as a stateful relationship rather than a permanently valid configuration.
Tradeoff
A more truthful model introduces more states, permissions, exceptions and audit complexity.
What was real. What is reconstructed.
Operating constraints and exploration
New-site concept, limited space, changing door/trailer relationships, merged conveyors, maintenance, overrides, incomplete physical-state signaling and routing workflow exploration.
Explicit design logic
Normalized states, confidence representation, fallback model, richer audit behavior and connected prototype exploration.
Automation beyond the evidence
Predictive or automatically optimized routing behavior is not established by the original project.
The reconstruction makes the design logic testable. It does not rewrite the implementation history.
From original exploration to current prototype
Original: new-site model → physical/system constraints → workflow exploration → routing/state concepts → engineering discussion / feasibility.
Current: recovered operating assumptions → explicit state model → AI-assisted systems exploration → Codex Smart Warehouse prototype.
Current exploration may develop beyond the original concepts. It does not establish that the reconstructed interactions shipped at Target.
Reality check: UX cannot manufacture missing physical truth
Design can clarify current relationships, exceptions, overrides, fallback and history.
Safe paths, controls logic, machine compatibility, network feasibility, authoritative state signals and physical capacity require engineering and operational evidence.
From fixed configuration to change-aware systems.
- Identify the assumed stable relationship.
- Find what changes in reality.
- Separate configured from current state.
- Represent what is known, inferred or unknown.
- Design overrides explicitly.
- Provide fallback when the normal relationship is unavailable.
- Preserve history for later investigation.
Useful anywhere relationships change faster than software’s configuration model expects.