A logistics system's software is correct and operations still fail. What class of failure is this, and how should the architecture accommodate it?

The class of failure

The physical world diverges from the system's model of it. A package is damaged, mis-scanned, loaded onto the wrong vehicle, delivered to a neighbour, or lost. A vehicle breaks down. An address does not exist. A recipient is absent.

None of these is a software defect and all of them must be represented, because a system that models only the successful path cannot express what actually happened.

How the architecture accommodates it

• Every state machine has an exception path with a defined terminal state. Not an error — a business outcome: damaged, lost, refused, returned, undeliverable.
• The physical action is the authority, and the system is a record of it. Where they disagree, the system is wrong — which means the interface must allow an operator to correct it, with an audit trail rather than a silent overwrite.
• Reconciliation against physical counts, since recorded stock and physical stock diverge for reasons unrelated to concurrency and no consistency model addresses a mis-pick.
• Compensation that is honest about being physical. A wrong delivery's compensation is a return journey with real cost, not a database operation — and a design that writes a compensating action pretending otherwise gives downstream systems false confidence.
• Safety stock and buffers, which convert an unpredictable physical failure into a predictable cost.

The design rule that follows

Order the irreversible steps last. Every step moved later is a compensation you may never need to run — and when a compensation genuinely cannot exist, such as a package already collected, move the step later or gate it rather than writing an action that lies about being able to undo.

The operational half

An exception queue with an owner and a resolution clock. Physical exceptions are continuous and normal, not incidents — and treating them as incidents means they are handled by whoever is available rather than by a process, which is where the cost accumulates.

The frequency of the exception path is a metric the business manages, not a bug engineers eliminate.