Doormile Platform Dossier

Seven stages, two route branches, one convergence. Every arrow below is a real state transition in the Go backend — the labels are the endpoints that cause them and the statuses they write.

1. 01Acquisition. A rep registers a business on site; the survey coordinates are the proof they stood there. The lead converts to a Tenant with its own rate card and depot sites.
2. 02Origination. Three doors, one object. Bookingsource is the only thing that distinguishes them.
3. 03Dispatch. Nearby available riders from Redis, scored by Claude with reasoning logged, degrading to greedy-nearest after five seconds.
4. 04First mile. Accept, reach, collect — each an idempotent state transition, because riders work on flaky mobile networks.
5. 05Custody handoff. Booking becomes Consignment. A six-digit code goes to the receiver and to nobody else.
6. 06Route fork. Matching 3-digit pincode prefixes skip the hub entirely. Everything else rides a tripsheet.
7. 07Close. The consignee reads six digits aloud. Nothing else marks a parcel delivered.

A milk round has five properties, and all five are anti-on-demand: a fixed beat, a rider who owns it, standing orders that recur by default, a promised slot, and density economics. Stage 03 above is built on the opposite premise.

Morning / Afternoon / Evening look like rounds. They aren't. They bucket on orderdate — when the order was placed — so a wave describes arrival, not departure. The dispatch folder's own CLAUDE.md records that the promised-delivery field was tried here and deliberately rejected.

There is a second constraint recorded in that file worth carrying forward: the filter field and the bucket field must be the same field. An earlier attempt to admit rows on updatedat while bucketing on createdat put six orders in the Evening batch at 10:41 in the morning on a day with no orders at all.

Four additions, roughly in dependency order. None of them fight the existing pipeline — the consignment, OTP and proof-of-delivery machinery downstream of stage 05 stays exactly as it is.

1. 01A Beat entity — an ordered stop sequence owned by a tenant and a hub, with a slot window. This is the object the whole model is missing.
2. 02Rider-to-beat assignment that persists — across days, not per parcel. rider_substitutions in jupiter is already the covering mechanism; it just needs a beat to point at.
3. 03A standing-order generator — materialises tomorrow's bookings from a recurrence rule against a TenantLocation, so the day's round exists before anyone books it.
4. 04Bucketing moved to the slot field — at which point the original clustered windows become correct again, and a wave finally means a departure.

Everything from a booking existing to a parcel being in a rider's hands. The happy path runs down the centre; every exception branch on the right is one the backend actually implements.

Two details worth holding onto. ALREADY_PICKED_UP and INVALID_STATE are stable machine-readable codes the rider app branches on, so the state machine is enforced server-side rather than trusted from the client. And commitAssignment writes booking, assignment and miler availability in a single transaction — there is no window where a rider is holding a job the booking does not know about.

The line-haul leg. This is the only one with no automation at all — every decision below is made by a person at a screen.

The only leg with real road-network routing — and the only one with a retry loop, because a delivery can fail in a way a pickup cannot.

Every status a parcel can hold, in the order it holds them, colour-coded by leg. Read it as a snake: left to right, drop, right to left, drop, left to right.

This is the most consequential thing in the codebase, and it is a sequencing question about the software rather than the parcels. Doormile assigns first and sequences second. Those are not two problems — they are one problem, and solving them in series throws away most of the available gain.

The expert move is to stop treating "AI" as one layer. Logistics decisions live on three clocks, and each clock wants a different technique. Doormile currently has a language model on the second clock, which is the one place it fits worst.

Per leg, what to build

• First — batch the window, solve once. Accumulate 10–15 minutes of open pickups and solve assignment and sequence together. Make the candidate set adaptive: widen the radius until k genuine candidates are found, instead of a fixed 10 km that returns ten near-identical riders at noon and nothing at 6 AM. Learn dwell time per pickup point — every arrivedat → pickup-complete pair is already a labelled example.
• Mid — auto-build the tripsheet. Parcel-to-truck given capacity, destination mix and cut-off is bin-packing with a clean objective. Then price hold-vs-go against sladueat, and consolidate thin lanes through a transfer hub rather than running half-empty direct trips — Batchkind's local/transfer split already anticipates this.
• Last — predict first-attempt success and sequence on it. Attemptcount and skip reasons are your training labels. Then resolve addresses with the pgvector you already run: embedding delivery addresses and snapping them to confirmed DeliveryProof coordinates turns your delivered history into a private geocoder that beats any general one inside your own zones.

Sequenced by ratio of effect to effort, not by ambition. The first two need no new infrastructure at all.

The model proposes. The solver decides. The system validates.

Every capability below is an application of that one sentence. A language model is exceptional at turning mess into structure — a dispatcher's sentence into a constraint, a WhatsApp forward into a booking, a photo into a condition code, a solver's output into an explanation a rider will actually read. It is poor and expensive at choosing the best of ten thousand arrangements, which is exactly what dispatch is.

So "auto-assign with GenAI" does not mean a model picking riders. It means a model doing the four things around the pick that were previously impossible to automate, while a solver does the pick itself in milliseconds and a validator refuses anything that breaks an invariant. That is a more capable system than an LLM choosing alone, and a cheaper one.

Ten capabilities, ranked by what they return for what they cost. Note how few of them are "the AI decides" and how many are "the AI turns something unstructured into something the system can already handle."

Four hubs across Coimbatore, Hyderabad, Bengaluru and Chennai means four language regions. Item 8 is not a nicety in that footprint — a rider who can speak a status update is a rider who actually files one.

This is the thing you asked about, drawn end to end. The deterministic spine runs down the left and never waits on a model. The three GenAI touch points sit beside it, feeding in out of band.

Why the constraint compiler is the sleeper

Dispatchers hold dozens of rules in their heads that never reach the system: which rider is slow at a particular gate, which client insists on the same face, which lane floods in monsoon. Today the only way to encode those is a developer ticket, so they stay in the dispatcher's head and the optimiser looks stupid. A model that turns a typed sentence into a reviewable constraint — which a human approves before it ever binds — converts tacit knowledge into solver input at conversational speed. That is a capability the solver cannot have on its own, and it is where generative AI is doing something genuinely irreplaceable.

// what the compiler emits — reviewed by a human, then stored
{
  "type": "exclude_miler_from_location_class",
  "miler_id": 412,
  "location_class": "mall_service_gate",
  "reason": "slow at gate handover",
  "author": "dispatcher:coimbatore:7",
  "expires_at": null
}

You do not need new infrastructure. Every piece below already exists in the estate; the work is contracts and placement.

One deliberate constraint: the agent layer never writes to the database directly. It calls the same internal endpoints a human operator would, so tenant scoping, idempotency, validation and audit apply identically whether the caller is a person or a model. If an agent can reach a table your dispatcher cannot, you have built two systems and will secure only one.

Every capability climbs the same four rungs, and each rung has a numeric gate. Nothing goes to the next rung on a good feeling.

This is the sharpest finding in the codebase, and it makes everything above cheaper.

• Closed-set selection, enforced server-side. A model returning chosen_miler_id must have that ID checked against the candidate set before commit. Models hallucinate identifiers; a validator costs three lines and removes the entire failure class.
• Keep the payload structured. Your current request to routemate carries no customer free text. The moment you pass raw Notes, address strings or client emails into a prompt that also drives actions, you have built a prompt-injection channel — anyone who can type into a booking form can try to instruct your dispatcher. If unstructured text must be read, do it in a separate call that only extracts, and never let that call's output reach an action without validation.
• Tenant isolation is an invariant, not a preference. HubStaffAccount.Tenantid already isolates partner freight. Agents must be scoped identically, and cross-tenant leakage should be a hard validator failure, not a scoring penalty. This is the one mistake that is a breach rather than a bad route.
• Every agent action is idempotent. You already have the Redis-backed key infrastructure. Agents retry more than humans do; a duplicated reassignment or a double COD entry is far worse than a slow one.
• Budget per booking, enforced. Set a token ceiling per decision and per day, with a hard cutoff to the deterministic path. Cost overruns in agentic systems come from retry storms, not from steady state.
• Mind what leaves the estate. Consignee phone numbers, COD amounts and precise home coordinates are in scope for whatever model endpoint you call. Decide deliberately what is sent, and prefer IDs over identities wherever the model does not need the human detail.
• Escalate rather than improvise. Give the exception agent an explicit "page a human" tool and reward using it. An agent with no honourable way to stop will invent an action instead.