Creating Missions

What this chapter covers

Dispatching a truck should take a tap. This chapter describes quick-assign — the flow that turns a client or a pickup-and-delivery pair into a fully-planned mission — the templates that make repeat runs one-tap, and convoy dispatch that sends several trucks down the same route as one group. It builds on corridors and feeds the driving rules a new mission inherits.

The picture

Quick-assign

Quick-assign has two entry points, chosen by whether the operator knows the client.

Client known — suggestions and one tap

When the operator picks a client — a record described in full in clients — Korido offers what that client usually ships:

• the client's default corridor, if one is set; and
• the client's saved pickup and delivery locations, which pre-fill the route's origin and destination by role; and
• the client's templates, ranked by usage — each template records how many times it has been used and when it was last used, so the routes this client actually runs float to the top.

Choosing a template applies its preset — corridor, travel direction, preferred vehicle, driver, and trailer, and default cargo — in a single tap. The operator confirms, and the mission is built.

No client — pickup, delivery, and inference

When there is no client, the operator names a pickup and a delivery place. Korido then runs corridor inference: it searches for the named corridor whose path covers both places. As described in the corridors chapter, a match can run in either travel direction and can be the corridor's endpoints or an interior sub-path of a longer corridor.

From the matched corridor, Korido derives the ordered waypoints between pickup and delivery, and trims them to exactly the requested span when the pair names an interior stretch. The derived waypoints become the mission's route; the corridor's roads resolve into the mission's ordered road segments; and their buffered polygons, unioned with the waypoint geofences, become the mission's frozen acceptance region.

An operator can also drop an ad-hoc place on the route map — an "add a place" mode where a map click names a new waypoint, gives it a type and a position in the sequence, and splices it into the route immediately.

Driving policy

The mission's driving policy is chosen in the same flow. The creation wizard carries a "Règles de conduite" selector whose default option is inherit — and the inherit option names the policy the resolution chain would apply, showing the template's or the client's rule set by name when one is set, and the plain tenant-default wording when neither is. An operator who wants a specific policy picks a named rule set instead; that explicit choice is validated to the tenant before it is accepted.

Whatever is chosen, the mission's rule set is resolved at creation through the precedence chain — explicit pick, then template, then client, then corridor, then the tenant default. A concrete rule_set_id is stored when the chain resolves to an explicit, template, client, or corridor policy, so a later change to which rule set that upstream object defaults to does not rewrite a mission already dispatched. When the chain falls all the way through to the tenant default, the mission stores null; runtime policy resolution then reads the tenant default that is current at the moment rules are applied. The full chain and how the resolved policy is applied live are the subject of driving rules.

Templates

A template is the full preset for a repeated run. It is what makes the client-known path a single tap. A template carries:

• an optional client scope — global to the tenant, or narrowed to one client;
• a corridor — required, because the corridor is the route preset. The origin, transit, and destination waypoints are derived from the corridor's ordered waypoints at apply time, honoring the template's travel direction (reverse folds the sequence). A route worth templating is worth naming;
• a preferred vehicle, driver, and trailer;
• default cargo — description, weight, and planned distance;
• an optional rule set recorded on the template.

Because the corridor is a real reference, the template's route carries full integrity: fix the corridor, and every template and mission built from it follows.

Convoy dispatch

Trucks on the Douala–N'Djamena corridor often travel together for security. A convoy is that grouping. Convoy dispatch is the same quick-assign flow run across N vehicles at once: it produces N independent missions — each with its own truck, driver, trailer, and engine state — plus one convoy grouping that ties them together for reporting and for the dispatcher's view. The convoy is a reporting and UX unit, not a shared state machine; each mission lives its own lifecycle.

Convoy dispatch is all-or-nothing. Before it creates anything, it validates the whole group at once and rejects the submit if any truck already holds an active mission — naming every busy truck, not just the first, so the operator fixes the group in a single pass instead of clearing clashes one at a time. And if a create fails partway — a truck picked up a mission in the instant between the check and the write — the missions already created and the convoy grouping are rolled back automatically. A convoy dispatches whole or leaves nothing behind: the operator never lands a half-formed group with some trucks committed and others rejected.

What creation writes

Building a mission writes the durable plan first, then enriches it. The order matters: routing and ETA both call an external service, and no external call should ever be allowed to hold a database write open. So Korido splits the work at the transaction boundary.

In one transaction Korido writes the mission contract — vehicle, driver, optional trailer, client, convoy, cargo, template, planned departure, origin, and destination — the ordered mission waypoints, the ordered mission road segments, the frozen acceptance region, and the resolved driving policy. The rule-set chain runs inside this same transaction, so a mission is never committed without its policy already decided. The mission is stamped as assigned and given a human reference number of the form KRD-000001. Route geometry and the first ETA estimate are computed after the transaction commits, so external routing work never holds the mission write open — and a routing hiccup can never lose a dispatch, only defer its first prediction.

Edge cases

• Vehicle already busy. Creation rejects any truck that already holds a non-terminal mission — the one-active-mission-per-vehicle rule is enforced at the moment of creation, not discovered later.
• Driver already busy. Creation likewise rejects a driver who already holds a non-terminal mission on another truck — one driver, one active mission. In convoy dispatch the picker enforces this up front: once a driver is chosen for one truck in the group, they drop out of the choices for the others, so the same person can never be assigned to two trucks in a single submit.
• Interior sub-path. When inference matches an interior stretch, the derived route is trimmed to exactly the pickup-to-delivery span, dropping the corridor's outer legs.
• Enrichment fails after commit. If the post-commit route or ETA work fails, the mission still exists — it simply carries no prediction until a later refresh fills it in. A dispatch is never lost to a routing hiccup.
• A corridor leg with no road. A mission can be built even when a leg has no curated road, but it will have an incomplete acceptance region, and Route Guard skips a mission with no corridor polygon. Curating the missing road repairs future missions.

How it connects

• Clients — the client record whose saved locations and defaults power the client-known path.
• Corridors — resolution and the inference that powers the no-client path.
• The mission lifecycle — where a newly-created mission goes from assigned.
• Driving rules — the rule-set chain a mission's policy resolves through at creation, and the wizard's driving-rules selector.
• Progression and ETA — the arrival estimate seeded at creation and refreshed as the truck moves.