An event-driven design connecting shipment identity, operational constraints and an AI reasoning layer. Every proposed action passes through validation and operator approval.
Barcode scans first. RFID readers and vehicle telemetry follow after field validation. ERP or order-management adapters normalize order updates into the same shipment model.
An edge gateway would queue scans offline, deduplicate retries and preserve both device and server timestamps. Late or conflicting reads become reviewable exceptions.
A proposed PostgreSQL event ledger maintains orders, shipment units, manifests, vehicles, driver availability, delivery evidence and reconciliation state. A worker queue handles retries and state transitions.
Every write must enforce tenant boundaries, state-transition rules and idempotency. Files and delivery photos need retention controls and scoped access.
A rules service checks weight, volume, cargo compatibility, time windows, vehicle capability and driver availability. A routing solver such as OR-Tools proposes feasible assignments using a licensed traffic and travel-time provider.
A solver may return a feasible candidate rather than a globally optimal route. Stale traffic or infeasible jobs must produce a clear fallback for the dispatcher.
Claude would extract structured delivery requirements from documents, summarize exceptions and draft recommended actions. Controlled tools would retrieve shipment evidence and request validated route candidates.
API calls belong on a server. Untrusted documents cannot authorize actions. Recommendations must reference available evidence; missing facts prompt review. No Claude API is connected today.
Before dispatch, the backend would re-check current shipment state, enforce permissions and validate the proposed manifest. An operator approves the change. An idempotent command is then sent to the relevant system and acknowledged. Approval, rejection, execution and failure are recorded separately. Settlement review does not trigger payment.
Keeping the status explicit makes the product easier to evaluate and the pilot easier to scope.
| Capability | Current prototype | Planned validation |
|---|---|---|
| Order + scan workflow | Synthetic orders and barcode events | CSV import, scanner adapter, duplicate and missing reads |
| Load consolidation | Zone grouping and weight checks | Volume, time windows and cargo compatibility |
| Loading verification | Wrong-vehicle scan blocked in demo | Physical scans, offline events and departure policy |
| Traffic + dispatch | Predefined clear/congested scenarios | Licensed traffic data, solver, operator approval and command acknowledgement |
| AI reasoning | Not connected | Claude API, extraction evaluation and evidence-linked suggestions |
| Delivery + settlement | Synthetic signed records and charge matching | Driver workflow, real delivery evidence and billing integration |
| Security + reliability | No accounts, customer data or external calls | Tenant isolation, access controls, audit logs, recovery and retention |
Baseline and pilot measurements should use the same shipment cohorts, operating conditions and definitions.
Count re-entry, dispatcher edits and review minutes per shipment. Compare the pilot with the current workflow.
Measure scan coverage, duplicate reads, false alerts and loading mismatches. Inspect failures by device and location.
Track on-time delivery, vehicle utilization, ETA error and reconciliation time. No performance result is claimed yet.