allanninal.dev/build

Part 4 of 7 · Delivery route planner series ~7 min read

How a driver manifest gets built

An optimal route that lives only in a database helps no one. This post is about the handover to the person who actually does the work: how the ordered route becomes a driver manifest — stop by stop, with the address, the access note, and the window for each — rendered once to a PDF, dropped in S3, and sent as a link the driver opens on their phone. And why every line of it is a suggestion, not an order.

Key takeaways

  • The optimised route becomes a driver manifest: stops in order, each with address, window, access note, and a phone number.
  • It’s rendered once to a PDF, written to S3, and sent to the driver as a link — no app to install.
  • Each stop carries a check-off action, so tapping “done” is what later slides everyone else’s ETA.
  • The manifest is the suggested order, not a locked instruction — the driver can re-order, skip, or insert a stop.
  • One manifest per van per day; a fresh plan (a late order, a cancellation) reissues a new version, the old link expires.

From a route to a round sheet

The optimiser’s output is a list of stop references in an order — correct, but useless to a human as it stands. A driver doesn’t want an array; they want a round sheet they can glance at between stops. The manifest step turns one into the other. It reads the ordered route, joins each reference back to the clean stop record from Part 2 to pull in the human details, and lays them out in sequence: stop 1, stop 2, stop 3, each with the customer name, the full address and postcode, the time window if there is one, the access note, and a tap-to-call phone number. At the top sits the depot and the planned start time; at the bottom, the return.

It’s rendered once, in the morning, to a PDF — a format that opens on any phone, prints if the driver prefers paper, and looks the same offline in a dead-signal lane as it does on wifi. The PDF is written to S3 and the driver is sent a link to it, by SES email or an SMS through SNS, whichever the settings doc names. No app to install, no login to forget; a link, a list, and a phone.

Building the driver manifest: join the ordered route to stop details, render a PDF to S3, send the link Inside a dotted AWS account container, on the left, two stacked source boxes: the route table holding the ordered stop references from the optimiser, and the clean stop list holding each stop’s address, window, and access note. Arrows from both feed into a central box, drp-manifest, which joins them into an ordered round sheet. From drp-manifest one arrow goes right to an S3 box labelled manifest PDF, and a second arrow goes to a send box labelled SES or SNS, which sends a link out to the driver, shown as an external box on the far right. To the right of centre, a sample manifest panel lists stop 1, stop 2, and stop 3, each line showing an address, a time window, and an access note, illustrating what the driver sees. A note reads: the manifest is the suggested order, not a locked instruction — the driver can re-order, skip, or insert a stop. AWS account drp-routes ordered references Clean stop list address, window, note drp-manifest join into an ordered round sheet S3: manifest PDF rendered once Send link SES or SNS Driver opens the link Manifest — Van 1 1 · 14 Mill Lane, BS1 4QA · 09:15–10:15 · side gate 2 · Unit 7, Apex Pk, BS2 0RT · before noon · reception 3 · 3 Oak Rise, BS9 2LH · any time · leave w/ no. 5 each line taps to call, map, or mark done The manifest is the suggested order, not a locked instruction — the driver can re-order, skip, or insert a stop.
Fig 4. Building the manifest. The ordered route is joined to each stop’s human details, rendered once to a PDF in S3, and sent to the driver as a link. The driver sees a plain round sheet — address, window, access note — with each line tappable.

What goes on each line

A manifest line is built for someone glancing at it through a windscreen, so it carries only what the next stop needs and nothing else:

  • The position and address. “Stop 7 of 34” and the full address with postcode, so the driver knows where they are in the day and exactly where to point the van. The postcode doubles as a tap-to-navigate link into whatever map app the phone already has.
  • The window, if any. Shown plainly — “before noon,” “2–4pm” — so the driver can see at a glance which stops are flexible and which aren’t. The optimiser already guaranteed the order respects them; the line just reminds the human.
  • The access note. The single most undervalued field on the sheet. “Side gate, dog,” “ask for Priya at reception,” “leave with number 5 if out” — the local knowledge that turns a failed delivery into a successful one. It comes straight from the stop record and is shown verbatim.
  • A check-off action. Each line can be marked done. That tap is not cosmetic: it’s the event that tells the rest of the system the van has left a stop, which is what keeps the downstream ETAs honest in Part 5.

A proposal, not an instruction

This is the post where the series’ central guardrail becomes concrete. The manifest is the order the optimiser thinks is best — but the driver, not the planner, runs the round. A regular customer flags the van down for an unplanned collection; a road is shut; the driver simply knows the area better than the matrix does. In every case they re-order, skip, or insert a stop, and the system follows their actual progress rather than nagging them back onto the original sequence. Marking stop 9 done before stop 8 isn’t an error the system corrects; it’s information the system accepts. The plan exists to save the driver thinking on a normal day, not to override their judgement on an abnormal one.

There is exactly one manifest per van per day, versioned. If the day’s list genuinely changes before the vans leave — a late order lands, a customer cancels — the morning build can be re-run, the optimiser re-orders, and a fresh manifest version is issued; the old link stops working so no one drives yesterday’s plan by accident. Once the van is rolling, though, the manifest is fixed and changes are the driver’s, captured through their check-offs rather than through a reshuffled sheet.

Why this shape

  • Built for a glance. Each line shows position, address, window, and access note — nothing the driver doesn’t need mid-round.
  • A link, not an app. A PDF in S3 opens on any phone, prints, and works offline; nothing to install or log into.
  • The access note earns its place. Local knowledge, shown verbatim, is what turns a failed drop into a completed one.
  • Check-off is an event. Marking a stop done is what later moves everyone else’s ETA, not just a tick on a list.
  • One versioned manifest per van. A real change reissues it and expires the old link; en route, the driver is in charge.
All posts