Industries / Logistics & supply chain
Logistics systems built around how field data actually arrives
We build the software layer over physical operations: transport management and dispatch, route planning heuristics, telematics ingestion, warehouse and yard management, carrier rate shopping, EDI over X12 and EDIFACT, shipment visibility and ETA prediction, cold chain monitoring and proof of delivery. Designed around imperfect field data, because that is the constraint that decides whether any of it works.
- Route optimisation described honestly as heuristics, never as optimality
- Dispatcher override treated as a signal, not as a failure
- EDI as a first-class integration surface, not a legacy footnote
- Field data quality named as the binding constraint up front
At a glance
- Systems
- TMS, WMS, YMS, visibility, proof of delivery
- EDI standards
- ANSI X12, UN/EDIFACT, plus flat-file and API partners
- Telematics
- Geotab, Samsara, Webfleet, CANbus and OEM APIs
- Routing approach
- Metaheuristics with dispatcher override and learning
- Realistic ETA accuracy
- Plus or minus 20 to 30 minutes on long-haul
- Availability target
- 99.95% on supported architectures
- Enquiries
- nitesh@redcubical.com
Routing
Route optimisation is heuristic, and saying otherwise is dishonest
What route optimisation can and cannot deliver
The vehicle routing problem is NP-hard. For any realistic instance — a hundred drops, time windows, capacities, driver hours — there is no algorithm that proves optimality in a usable planning window. Production routing uses construction heuristics plus metaheuristics such as guided local search or large neighbourhood search, returning a good solution inside a time budget. Expect 8 to 18 percent improvement against manual planning, not perfection.
How a working router is actually built
- Constraint model first. Vehicle capacity by weight, volume and pallet positions; time windows per stop; driver shift and break rules; site access restrictions such as vehicle length and tail-lift requirements; skill and licence matching; multi-compartment and temperature separation where relevant.
- A real distance and duration matrix from a road network with time-of-day traffic profiles. Straight-line distance produces plans that look excellent and cannot be driven.
- Construction heuristic to get a feasible solution quickly, typically savings-based or insertion-based.
- Metaheuristic improvement under a wall-clock budget: guided local search, tabu search or large neighbourhood search. Planners need an answer in minutes, so the budget is a hard design input.
- Objective weights owned by operations, because cost, service and driver fairness genuinely trade against each other and that trade is a business decision rather than a technical one.
- Explainability. When the plan does something surprising, the system says which constraint forced it. Unexplained plans get discarded wholesale by dispatchers.
Solver against dispatcher
A solver optimises the model it was given. A dispatcher carries knowledge that was never in the model:
- Site reality. A goods-in bay that closes at 14:00 on Fridays, a gate that a fifteen-metre trailer cannot turn into, a yard that floods.
- People. Which driver handles which customer well, who is new and needs a shorter round, who is on a return-to-work plan.
- Relationships. The customer who escalates if the delivery is early, the account under review where service outranks cost this month.
- Live disruption. A vehicle that failed its walk-around check, a driver calling in sick at 05:30, a road closed since last night.
So we build for collaboration rather than automation. The system proposes, the dispatcher adjusts, and every override is captured with a reason code. Reviewing override patterns monthly is the cheapest available source of missing constraints: a repeated override is almost always a rule the model does not yet hold. Systems that make overriding difficult get abandoned, and systems that never learn from overrides stay permanently mediocre.
Data in from the field
Telematics ingestion, shipment visibility and ETA prediction
How real-time visibility is built
Visibility is an ingestion and normalisation problem before it is a dashboard. Telematics arrives at varying frequency with gaps, buffered replays and clock skew; partner status updates arrive in batches with inconsistent event vocabularies. We normalise to one event model with provenance, then predict ETA from that. Honest accuracy is plus or minus 20 to 30 minutes on long-haul and a widening window across a multi-drop day.
| Source | Typical cadence and quality | How it misbehaves | Engineering response |
|---|---|---|---|
| Vehicle telematics unit | Position every 30 to 120 seconds, plus ignition, odometer and harsh-event data | Tunnel and rural gaps, buffered replay after reconnection out of order, device clock drift, position accuracy degrading in urban canyons | Idempotent ingestion keyed on device and event time, out-of-order tolerance, server-side receipt time stored alongside device time, and accuracy radius retained rather than discarded |
| Driver handheld application | Event-driven at arrival, delivery and exception | Scans at the depot instead of the door, offline for hours, battery death mid-round, duplicate submissions after a retry | Offline-first capture with a durable local queue, geofence validation on arrival events, deduplication keys, and a flag on events whose position does not match the stop |
| CANbus and OEM telematics API | Rich engine, fuel and temperature data at varying frequency | Vendor rate limits, inconsistent units across OEMs, undocumented field semantics | Per-vendor adapter with unit normalisation at the boundary, cached polling within rate limits, and units stored with every value |
| Carrier and partner status feeds | Batch or webhook, from near-real-time to once daily | Every partner has a different status vocabulary, statuses arrive out of sequence, and some partners only report at end of day | Status mapping tables per partner into one canonical event model, with sequence reconstruction by event time and a documented confidence level per partner |
| Cold chain sensors | Temperature and humidity every 5 to 15 minutes, sometimes only on download at the depot | Sensor drift, calibration expiry, gaps during the exact excursion you need evidence for | Calibration state stored with readings, gap detection raised as an explicit exception, and excursion evaluation on duration above threshold rather than on a single reading |
| Barcode and RFID scanning | High volume at receipt, pick, load and delivery | Damp or damaged labels, duplicate scans, scans at the wrong stage, RFID read-rate variation by load density | Deduplication within a time window, stage validation against expected sequence, and manual-entry fallback that is flagged rather than silently equal to a scan |
One rule governs all of it: never overwrite a field observation. Corrections are new events with a correction reference, so the history of what was believed at each point survives. Dispute resolution, carrier claims and customer credits all depend on the record of what was known when, not on the current best guess.
ETA prediction and its honest limits
ETA is a stack of estimates, each with its own error, and the errors compound across a route rather than cancel out.
- Travel time from a routing engine with historical and live traffic. Reliable within roughly 10 to 15 percent on motorway running, worse in dense urban networks.
- Service time per stop, which is usually the dominant error source. Unloading at a supermarket goods-in with a queue varies from eight minutes to fifty, and that variance propagates to every subsequent stop.
- Break and duty rules, which are predictable but interact with delay in ways that create step changes rather than smooth drift.
- Disruption, which is unpredictable by definition. The right response is to detect deviation quickly and re-predict, not to model it in advance.
So we publish a window rather than a time, widen it honestly for later stops, and re-predict on every position update. A model trained on your own historical service times per site and per time of day outperforms a generic estimate substantially, and that is the single highest-value modelling investment in visibility work. What we will not do is display a fifteen-minute promise for the eighteenth drop of the day, because the data does not support it and a missed narrow window damages trust more than an honest wide one.
Inside the four walls
Warehouse management, picking strategy and yard management
How we approach warehouse systems
Warehouse software is a throughput problem. Receipt, putaway, slotting, picking, packing, despatch and cycle counting each have measurable rates, and the binding constraint moves as volume changes. We instrument travel time, pick rate and dock utilisation first, because picking strategy chosen without measurement is a guess dressed as a design.
| Strategy | How it works | Best suited to | Cost and constraint |
|---|---|---|---|
| Discrete or single-order picking | One picker completes one order end to end | Low order volume, large orders, high-value or serialised goods needing traceability | Highest travel per line. Simple to run and simple to audit, which is why small operations keep it |
| Batch picking | One picker collects the same line across many orders, sorted afterwards | Many small orders sharing common lines, typical of e-commerce | Requires a sortation step and the space for it. Errors at sortation are expensive to trace back |
| Zone picking | Pickers stay in a zone; the order moves between zones | Large warehouses where travel dominates, and mixed storage types such as ambient and chilled | Zone imbalance stalls the line. Needs conveyor or handover discipline and active work balancing |
| Wave picking | Batches released as waves aligned to carrier collection times | Operations with hard carrier cut-offs and predictable order profiles | Rigid. A late order misses its wave, and wave sizing must be retuned as volume shifts |
| Cluster picking | One picker handles several orders simultaneously in a multi-tote cart | Small-item, multi-line e-commerce with good location density | Put-error risk into the wrong tote. Needs put-to-light or scan verification to hold accuracy |
| Goods-to-person | Automation brings stock to a fixed pick station | High volume, stable SKU profile, capital available | Large capital cost and a long commitment. Poorly suited to volatile assortments, and the software integration is a project in itself |
Slotting usually returns more than strategy change. Placing fast-moving lines in golden-zone locations near despatch commonly cuts travel by 15 to 30 percent for the cost of a reslotting exercise and a rule change, with no capital outlay. We look there before recommending anything that needs a purchase order.
What we build inside the WMS boundary
- Receipt and putaway with ASN matching, discrepancy capture at the dock, and putaway rules by velocity, size and temperature zone.
- Location and inventory model with licence-plate or handling-unit tracking, lot and batch, serial where required, and expiry-driven allocation using FEFO rather than FIFO for perishables.
- Task management assigning work by picker position, skill and equipment, with interleaving so a picker does not travel empty.
- Cycle counting weighted by velocity and value, with variance reporting per zone rather than one blended accuracy figure.
- Packing and despatch with cartonisation, weight verification against expected, label generation and manifest close per carrier.
- Handheld applications that work offline, because warehouse wireless coverage has dead spots in every building we have worked in.
Yard and dock management
- Dock appointment scheduling with slot capacity by dock type, so the yard stops being managed by whoever shouts loudest on the radio.
- Gate check-in and check-out with driver and vehicle identity, trailer number and seal number captured as structured data.
- Trailer location tracking in the yard, which sounds trivial and is the most common source of shunting waste we measure.
- Dwell time and turnaround metrics per carrier, which is also the evidence base for detention and demurrage discussions.
- Shunt task management so trailer moves are planned work rather than reactive requests.
- Loading verification tying the load to the manifest and the seal, because a seal mismatch discovered at destination is a claim.
A Gulf logistics operator we worked with cut average trailer turnaround materially without any physical change to the yard, simply by scheduling docks and making trailer position visible. The largest wins in yard work are usually informational rather than capital.
Partner integration
EDI, carrier integration and rate shopping
Why EDI is still a commercial precondition
EDI is unavoidable because your trading partners mandate it. ANSI X12 in North America and UN/EDIFACT internationally carry purchase orders, despatch advices, invoices and status messages for retailers, carriers and customs brokers. Being unable to exchange them means losing the account, so we treat EDI as a first-class surface with per-partner dialects, acknowledgement handling and a reprocessing path.
| Purpose | X12 | EDIFACT | What makes it awkward in practice |
|---|---|---|---|
| Purchase order | 850 | ORDERS | Partner-specific mandatory segments beyond the standard, and unit-of-measure conventions that differ from your catalogue |
| Order acknowledgement and change | 855 and 860 | ORDRSP and ORDCHG | Partial acceptance and substitution rules vary per partner, and change messages can arrive after despatch |
| Despatch advice | 856 | DESADV | Hierarchical pack structure down to carton and item. Getting the hierarchy wrong causes receipt failures and chargebacks |
| Invoice | 810 | INVOIC | Tolerance rules for price and quantity mismatch trigger deductions that are painful to dispute after the fact |
| Warehouse shipping order and advice | 940 and 945 | INSDES and RECADV | Third-party warehouse dialects differ per site even within the same provider |
| Transport instruction and status | 204 and 214 | IFTMIN and IFTSTA | Status code vocabularies map imperfectly to your internal event model, so canonical mapping tables are mandatory |
| Inventory advice | 846 | INVRPT | Snapshot against delta semantics differ per partner, and misreading which you received corrupts availability |
| Functional acknowledgement | 997 | CONTRL | Silence is not success. Unacknowledged messages must be chased automatically or they are simply lost |
Our EDI pattern: a translation layer with a per-partner profile, every inbound and outbound message archived exactly as transmitted, mapping into one canonical internal model, and a reprocessing path so a mapping fix can be replayed against stored originals. Errors go to a human queue with the raw message attached. EDI failures that silently disappear become chargebacks discovered a month later.
Carrier integration and rate shopping
- Rate shopping needs landed cost, not headline rate. Zone, weight break, dimensional weight, fuel surcharge, residential and remote-area surcharges, and any negotiated discount all apply before a comparison means anything.
- Service level is a constraint, not a tie-breaker. The cheapest carrier that misses the promise date is not eligible, so the promise is evaluated first and cost second.
- Carrier API quality varies enormously. Some offer clean REST with sandboxes; others offer SOAP with undocumented error codes and no test environment. We cache rate cards locally and rate offline where the API is unreliable, reconciling against invoices afterwards.
- Label generation must be resilient. A carrier label service outage stops despatch entirely, so we pre-generate where the carrier permits and hold a documented fallback per carrier.
- Invoice audit is where money is recovered. Comparing invoiced charges against expected landed cost per consignment routinely finds 2 to 5 percent in surcharge and weight-correction errors, and that reconciliation pays for itself faster than most optimisation work.
Customs and trade compliance documentation
- Commodity classification against HS codes held on the product master with country-specific extensions, validated at onboarding rather than at the border.
- Declaration data assembly for the relevant customs platform, with importer and exporter identifiers, incoterms, valuation basis and origin.
- Origin and preference documentation, including supplier declarations, since preferential duty claims need evidence retained for years.
- Restricted party and licence screening against sanctions and export control lists at order entry, not at despatch when the goods are already committed.
- Dangerous goods handling with correct classification, documentation and segregation rules reflected in both routing and loading constraints.
- Document archive with retention, because a customs audit years later asks for the declaration, the invoice and the origin evidence together.
We build the data assembly and validation. Classification decisions, duty positions and declarations remain your customs broker's and your compliance function's responsibility, and we design so their determinations are recorded as data rather than embedded in code.
Honesty
Field data quality is the binding constraint, not the algorithm
The constraint that decides whether logistics software works
Across every logistics engagement we have delivered, the limiting factor was the quality of data captured by drivers, scanners and partners — never the sophistication of the optimisation. A router fed arrival times recorded at the depot rather than at the door produces confident nonsense. Capture reliability is where the first budget should go, and we say so even when the optimisation work is the more attractive sale.
- Geofence validation on arrival and delivery events. An event recorded outside the stop geofence is flagged, not trusted, and the flag is visible in reporting
- Offline-first handheld and driver applications with a durable local queue, because coverage gaps are guaranteed and a failed submission must never lose the record
- Capture designed for one hand in the rain. Large targets, few taps, no free-text where a code will do, and no workflow that punishes the honest path
- Exception reasons as a short structured list rather than free text, so exceptions are analysable instead of merely readable
- Manual entry always distinguishable from a scan, since a typed barcode is a weaker observation and should not be treated as equal evidence
- Partner feed confidence scored and published, so a partner reporting once daily is not silently treated as real-time in an ETA model
- Data quality reported as an operational KPI per depot, per driver group and per partner, reviewed with operations rather than filed by engineering
- Device health monitored, covering battery, last sync and application version, because a handheld that stopped syncing three days ago is an invisible data hole
- Clock skew handled explicitly. Device time and server receipt time both stored, and never assume the device is right
- Corrections as new events with a reference to what they correct, never an overwrite, so the record of what was known when survives a dispute
Cold chain and proof of delivery
Two areas where evidence quality is the product rather than a supporting feature.
- Cold chain excursion logic on duration above threshold, not on a single reading, with calibration state and sensor identity stored alongside every measurement. A gap in the trace during a suspected excursion is itself an exception requiring disposition, and we surface it rather than interpolating over it.
- Proof of delivery captured completely at the point of delivery: trusted timestamp, GPS with accuracy radius, photograph, signature or one-time code, scanned identifiers, and device and user identity. Stored append-only and retrievable in seconds, because most disputes are decided on completeness of evidence rather than on argument.
- Chain of custody across handovers, including 3PL and final-mile partners, so responsibility at each leg is a matter of record. Claims against carriers succeed or fail on this.
Answers
Logistics and supply chain engineering questions
Can you build an optimal route optimisation engine?
No, and nobody can. The vehicle routing problem is NP-hard, so beyond trivial instances there is no algorithm that finds a proven optimum in usable time. What we build are heuristics and metaheuristics that produce good solutions inside a planning window, typically 8 to 18 percent better than manual planning on distance and drop count. Anybody selling optimality is selling a word, not a result.
What is the difference between a solver and a real-world dispatcher?
A solver minimises a cost function against the constraints you encoded. A dispatcher knows the loading bay at one site closes early on Fridays, that a particular driver will not take a certain vehicle, and that a customer complains if the delivery arrives before the manager does. We build systems that propose plans and let dispatchers override, then learn from the overrides, because most overrides are information rather than error.
Why is EDI still a requirement in 2026?
Because your trading partners mandate it. Large retailers, carriers, customs brokers and manufacturers run on X12 and EDIFACT with decades of embedded process, and being unable to trade an 850 purchase order or a DESADV despatch advice means losing the account. EDI is not legacy trivia, it is a commercial precondition, and we treat it as a first-class integration surface.
How accurate can ETA prediction be?
For long-haul with good telematics, plus or minus 20 to 30 minutes on a multi-hour journey is realistic. For final-mile with many stops, the arrival window widens through the day as service times vary, so a two-hour window mid-route is honest and a fifteen-minute promise for the last drop of the day is not. Accuracy is limited by service-time variance and traffic, not by the model.
What is the biggest constraint on a logistics project?
Field data quality, consistently. Drivers who scan at the depot rather than at the door, partners who send status updates in batches at midnight, handhelds with flat batteries, and barcodes that will not read in rain. No algorithm compensates for input that does not describe reality, so we invest in capture reliability and data validation before optimisation.
Do you integrate with telematics providers or build the hardware side?
We integrate. We ingest from Geotab, Samsara, Webfleet, CANbus gateways and OEM telematics APIs, normalise the feeds and handle gaps, buffering and clock skew. We do not manufacture devices, design vehicle harnesses or certify installations, and we would not pretend to.
Can you build a warehouse management system from scratch?
We can, and we usually advise against it for standard operations where a mature WMS will fit. Custom WMS work is justified when your operation is genuinely unusual, when you need a lightweight layer over a 3PL, or when an incumbent WMS needs picking and slotting logic it cannot express. We would rather integrate and extend than rebuild inventory and location management that already works.
How do you handle proof of delivery disputes?
By making the evidence complete and immutable at capture: timestamp from a trusted source, GPS position with accuracy radius, photograph, signature or one-time code, scanned identifiers and the device and user identity. Stored append-only and retrievable in seconds. Most disputes resolve on evidence completeness, so capture quality matters more than any workflow above it.
Start with a data capture and operations review
Three weeks, fixed fee. You get a field data quality assessment by depot and partner, an integration and EDI inventory, a routing feasibility test against your historical orders, and a costed plan sequenced capture-first.