Use reason-specific evidence requirements
Synthetic carrier task A reaches the confirmed address but recipient is absent; task B cannot identify the address; task C has no reliable attempt evidence. The local rule asks A for a new receiving arrangement, B for an address correction and C for investigation. None is delivered. The reason labels are invented local codes, not a provider status dictionary.
| Constraint | Required record | Example decision rule |
|---|---|---|
| Attempt evidence | Task + observed event + location reference | No evidence means unknown, not absent recipient |
| Reason | Recipient absent / address unresolved / unknown | Each maps to a different action |
| Delivered state | Separate proof reference | Attempt reason does not set delivered |
Test three unsuccessful outcomes
| Case | Input | Expected decision |
|---|---|---|
| A | Confirmed address; absent recipient | Arrange another receiving plan |
| B | Address not identified | Correct address before rescheduling |
| C | No reliable event evidence | Investigate; do not infer reason |
- Read attempt evidence
- Classify supported reason
- Assign reason-specific follow-up
- Keep delivered state separate
A vague “failed” code cannot supply the missing reason; keep next-action selection pending.
How many of A, B and C have evidenced delivery completion?
Show the worked answer
Zero. Their recorded outcomes are an unsuccessful attempt, an address gap and an unknown event respectively.
Require unknown reasons to remain visible so automatic scheduling does not repeatedly send a driver to an unresolved address.