POD acknowledgement lag

SCN-X11process lagStanding at Day-0

Logistics → ERP

A proof of delivery has been recorded in Logistics, but ERP has not yet confirmed the corresponding delivery.

Condition: physical POD before ERP delivery ack

Evidence anchors

Evidence

Logistics Shipment LSHP-2026-000003 · DELIVERED
POD-2026-000003 recorded; DLV-2026-000002 not confirmed
Open its cross-system journey

Comparison case

Logistics Shipment LSHP-2026-000009 · DELIVERED
POD-2026-000007 relayed; DLV-2026-000005 confirmed
Open its cross-system journey

An implemented mechanism can clear the Day-0 evidence records

runLogisticsToErpDeliveryRelay with only: [POD-2026-000003, POD-2026-000006] — two lag shipments, not one

Why this is here

Metrolane Day-0 deliberately includes realistic cross-system delays, duplicate source records and event-ordering conditions. They are verified parts of the frozen reference estate, not accidental data corruption.

Progression

Logistics → ERP delivery relay

A cross-system relay

Commands

ERP.confirm_delivery
LOGISTICS.acknowledge_erp_delivery

Prerequisites and refusals

NO_ACTIVE_POD
NOT_AN_ERP_DELIVERY
ALREADY_CONFIRMED

The Day-0 Explorer is read-only; this describes how the condition changes when the estate runs forward.

How Day-0 verifies this scenario

Definition: scenario-authority/specs/metrolane_cross_system_scenario_catalog_v1_6.csv
Standing verification: scenario-authority/packages/simulator/src/scenario-state.ts.txt
Verification result: PRESENT — the predicate holds in the frozen estate
Evidence anchors: scenario-authority/packages/simulator/src/scenario-anchors.ts.txt
Clearing relay: runLogisticsToErpDeliveryRelay
Activation time: D0-10d
Setup commands: LOGISTICS.record_proof_of_delivery, LOGISTICS.complete_delivery
Falsifies the predicate: YES