Skip to main content

Logistics route optimization system

The shortest path can still be an infeasible route.

A logistics route optimization system compares feasible sequences for an approved set of jobs and resources, accounting for delivery windows, capacity, travel conditions and operating constraints. It helps dispatchers understand cost, service and stability tradeoffs. Werkon would validate candidate routes against execution evidence, while dispatchers and qualified safety owners retain release authority, exceptions and customer commitments.

Separate assignment from route planning

Accept approved worker, vehicle and job eligibility rather than silently swapping resources to make a route fit. Each pickup, delivery, break, charging or transfer stop needs an exact location, service time, window, precedence, quantity and relevant custody or specialist requirements. Requested windows and contractual commitments remain separate.

Validate changing loads, capacity by compartment, vehicle dimensions and limits, maintenance state, fuel or charge, access and owner-supplied work and rest constraints. Road, facility, border, ferry and charging conditions need source versions, freshness and coverage. Preserve local civil time across midnight and daylight-saving changes.

Show why a candidate is feasible

Make distance, travel and service time, tolls, energy, paid time, lateness, empty movement and stability costs visible with units and weights. Safety, legal and physical constraints must remain hard requirements. Where objectives conflict, compare feasible service-led, cost-led and stability-led options.

Record the solver, configuration, timeout and any available bound. Call a route optimal only when that claim is proven. Show unresolved or unassigned work, capacity after each stop, arrival ranges, binding constraints and contingency points. Route geometry and navigation output do not authorize dispatch or establish safe execution.

Control revisions and verify the journey

Recheck jobs, resource eligibility and current conditions before publishing. Preserve an acknowledged route when proposing a revision and show the changed sequence, assumptions, commitments and approval. Automatic replanning requires pre-approved low-impact conditions. Give workers an accessible correction and safe-stop route without pressure to interact unsafely.

Track dispatch, acknowledgment, departure, arrival, waiting, attempted service, completion and returns separately. A geofence does not prove service, and observations cannot justify tracking beyond purpose or inferring effort and fitness. Reconcile custody, condition, incidents, claims and recovery before attributing route improvements.

Route boundary

Optimize the approved movement without rewriting who, what, or why.

A route sits downstream of commitments and resource assignment. Four boundaries preserve feasibility and later service evidence.

01

Approved stops and assigned resource

Resolve current job set, stop identities, service commitments, precedence and loads plus the already assigned eligible driver, vehicle, trailer, equipment, start and end state without silently changing dispatch scope.

Required evidence: Tenant and region, business date and zone, plan and job versions, stop identifiers and coordinates, access points, windows and durations, precedence, quantities and units, cargo rules, assigned worker and relationship, vehicle, trailer, equipment, depot, start and end state, eligibility source and unresolved conflict.

02

Time-valid route and condition context

Version network, route engine, profiles, restrictions, matrix and current-condition sources; preserve coverage, observed and effective times, expiry and forecast uncertainty; and keep map data separate from legal or safe permission.

Required evidence: Provider and engine, dataset and matrix versions, travel mode and restriction profile, network coverage, coordinate reference, traffic, incident, closure, construction, weather, ferry, border, access, charging and fueling sources, observed time, effective interval, confidence, expiry, gap and conflict.

03

Feasible candidates and explicit tradeoffs

Enforce hard eligibility, capacity, access, safety, precedence and time rules, show cost components and weights, return multiple reviewable candidates and name infeasible work and solver limits.

Required evidence: Hard and soft constraint sets, capacity by stop, time arithmetic, objective components, currency and rates, normalization and weights, candidate sequences and path references, arrival and departure intervals, breaks and replenishment, binding constraints, soft breaches, assumptions, solver configuration, bound, timeout and unassigned stops.

04

Approved route, revision, and observed service

Preserve dispatcher approval and driver acknowledgment, safely deliver versioned changes, and reconcile planned legs and stops with authoritative movement, service, custody, exception, incident, claim and recovery evidence.

Required evidence: Selected candidate and rationale, approver and time, published version, delivery and acknowledgment, correction and hazard, old-new diff, revision reason, departure, arrival, waiting, attempt, service, custody and condition, delay, return, incident, claim, complaint, recovery and unresolved work.

Work-to-service path

Keep map output, operational approval, and physical service separate.

A route engine proposes a path through its available data. Operations must still prove feasibility, authority and execution.

  1. 01

    Freeze the decision context

    Capture tenant, region, local time, planning instant, horizon, approved jobs, assigned resource, current work state, customer commitments and source versions; reject missing units, identities or authority.

    Owner
    Dispatch, job, fleet and customer-commitment owners
    Evidence
    Decision identifier and time, plan and job versions, assignment, resource state, stops, windows, loads, priorities, dependencies, overrides, exclusions and input validation.
  2. 02

    Build the route state

    Retrieve network and provider versions, vehicle and cargo profiles, facility and civil-time rules, matrix and current conditions; normalize units and intervals; expose stale, conflicting and uncovered areas.

    Owner
    Routing, fleet, safety, facility, time and data owners
    Evidence
    Network, provider, engine and profile, capacities and units, road and access rules, local zones and dates, matrix, traffic and disruption inputs, observed and effective times, confidence, expiry, coverage and conflicts.
  3. 03

    Generate and validate candidates

    Apply hard constraints outside the model, compute load and time after every stop, solve under explicit objectives and produce feasible alternatives, tradeoffs, sensitivity, bounds and unassigned work.

    Owner
    Route-planning, operations research, safety and finance owners
    Evidence
    Candidate sequences, paths, leg and service intervals, capacity trace, breaks and replenishment, cost components and weights, hard and soft results, binding constraints, assumptions, solver configuration, timeout, bound and infeasibility reason.
  4. 04

    Approve and publish the route

    Let a named dispatcher inspect customer and safety effects, select or amend a candidate, preserve rationale, deliver the exact version and require driver acknowledgment or correction where policy requires.

    Owner
    Dispatcher, driver or field worker, customer and safety owners
    Evidence
    Selected route, comparison and rationale, manual changes, affected commitments, approval, publication, destination, delivery, failure, acknowledgment, correction, hazard, safe-stop path and fallback.
  5. 05

    Revise safely and reconcile service

    Re-read current jobs, resource and route state before change, show the exact diff, keep revision authority explicit and join later authoritative movement and service evidence without treating tracking as performance authority.

    Owner
    Dispatch, drivers, fleet, service, claims and recovery owners
    Evidence
    New decision time and sources, old-new sequence and path, changed times, reason and approval, delivery and acknowledgment, actual legs and stops, service and custody, delay, exception, return, incident, claim, complaint, recovery and residual work.

Authority map

Separate hard feasibility, route computation, and operational authority.

An optimizer can compare candidates. It cannot invent road law, assign a driver, accept a customer impact or prove a safe completed service.

01

Deterministic route controls

Software owns tenant and source boundaries, identities, schemas, units, clocks, eligibility inputs, hard constraints, capacity accumulation, precedence, interval arithmetic, permissions, route validation, versioning, publication and receipts.

  • Job, stop, worker, vehicle, equipment, route and source identifiers
  • Unit, time-zone, capacity, compatibility, precedence, access, restriction and hard-window checks
  • Objective components, rate versions, candidate contract and solver metadata
  • Approval, publish, delivery, acknowledgment, revision, execution and recovery receipts
02

Optimization and bounded AI assistance

Solvers and models can generate candidates, estimate under approved inputs, surface tradeoffs, explain binding constraints, identify infeasible work and draft dispatcher notes while source truth and authority remain outside them.

  • Feasible sequence and path candidates under declared limits
  • Travel, arrival, cost and capacity estimates with assumptions
  • Constraint, sensitivity, alternative and infeasibility explanations
  • Route comparison, change summary and handoff drafts
03

Dispatcher and qualified owner authority

Dispatchers and qualified safety, fleet, customer, finance, compliance, sustainability and people owners set priorities and rules, approve exceptions and routes, manage revisions and customer effects, and decide incidents, claims and recovery.

  • Assignment, eligibility, customer commitment and operational-priority decisions
  • Legal, safety, vehicle, cargo, access, labor, toll and environmental interpretation
  • Objective weights, rates, soft breaches, manual changes and final route approval
  • Hazard, incident, service failure, customer remedy, claim and recovery decisions

Route-system components

Build a versioned route decision, not a colored line on a map.

Feasibility comes from linked work, resource, network and time evidence. Four components keep those sources inspectable.

01

Work, stop, and assignment ledger

Bind approved jobs, durable stops, windows, durations, precedence, loads, customer commitments and priorities to the accountable assigned driver, vehicle, trailer, equipment, depot and start state.

Operating contract: Address is not access point, coordinate is not service location, request is not commitment, priority is not safety, calendar is not availability, named driver is not eligible, vehicle label is not capacity and assigned work is not accepted work.

02

Network, restriction, and condition ledger

Version route provider, engine, dataset, network, travel and vehicle profiles, road and facility restrictions, matrix, observed traffic, incidents, closures, construction, weather, ferry, border, charge and fuel context with coverage and expiry.

Operating contract: Map path is not legal route, historic duration is not current traffic, forecast is not observation, traffic feed is not complete, geofence is not road access, restriction absence is not permission, routing response is not safe passage and current now is not current at arrival.

03

Constraint, objective, and candidate ledger

Preserve hard and soft rules, capacity trace, civil-time arithmetic, cost components and units, rate versions, normalization and weights, solver and configuration, candidate sequences, paths, intervals, binding constraints, sensitivity and infeasibility.

Operating contract: Soft penalty is not legal rule, low cost is not safe, shortest is not fastest, fastest is not feasible, feasible is not robust, heuristic is not global optimum, planned cost is not realized cost and unassigned stop is not completed work.

04

Approval, revision, and execution ledger

Link selected candidate, dispatcher rationale, publication, delivery, driver acknowledgment, corrections, old-new revisions and actual movement, stop, service, custody, exception, incident, claim and recovery evidence.

Operating contract: Published is not delivered, delivered is not acknowledged, acknowledged is not executed, geofence is not arrival, arrival is not service, service event is not customer acceptance, route completion is not claim resolution and ticket closure is not recovery.

Delivery path

Prove one depot, resource class, and route family before scaling.

Begin where source authority, hard constraints, dispatcher decisions and physical service can be reconciled end to end.

  1. 01

    Choose one bounded route family

    Select one region, depot, vehicle and load class, service-window pattern, route provider, dispatcher group and job family with observable execution and no hidden assignment authority.

  2. 02

    Map sources, rules, and objectives

    Inventory stop, window, duration, load and assignment sources; resource and road rules; local time; condition feeds; coverage; costs and rates; objective weights; approvals; revisions; and service evidence.

  3. 03

    Build replayable route decisions

    Implement versioned inputs, unit and time normalization, deterministic hard constraints, capacity traces, multiple candidates, explicit solver metadata, reviewable tradeoffs, dispatcher approval, publication, acknowledgment and receipts.

  4. 04

    Test infeasible and changing conditions

    Exercise missing stops, bad coordinates, unit mismatch, DST, cross-midnight windows, capacity peaks, precedence, restricted roads, vehicle change, closure, weather, stale matrix, charge outage, solver timeout, route conflict and unsafe revision.

  5. 05

    Release advisory-first and reconcile service

    Compare suggested and dispatcher routes, corrections, rejected plans, revision churn, predicted and actual travel, windows, cost components, service, exceptions, incidents, claims and human effort before expanding route authority.

Release controls

Six controls before a route can become an instruction.

A plausible path is not an operating plan. These controls preserve constraints, ownership and safe revision.

Work and assignment are source-bound
Accept only approved jobs and accountable resource assignments; version stops, commitments, priorities and start state; validate identifiers and units; expose revoked, conflicting and unassigned work; and never let routing silently reassign people or assets.
Hard feasibility stays outside the model
Enforce current eligibility, capacity by compartment and stop, compatibility, access, precedence, civil time, road, vehicle, cargo, safety and qualified work constraints deterministically; keep unknown or missing rules visible and block unsafe candidates.
Conditions are time-valid and covered
Version provider, network, engine, profile, matrix and feeds; separate historic, observed and forecast inputs; show observed and effective times, confidence, expiry, gaps and conflicts; and never present uncovered or stale context as current.
Objectives and tradeoffs are explicit
Name every cost and service component, unit, currency, rate version, normalization and weight; distinguish hard from soft; provide feasible alternatives and sensitivity; report timeout, bounds and infeasibility; and never label a heuristic globally optimal without proof.
Release and revision require authority
Require named dispatcher approval, preserve rationale and manual changes, publish the exact version, capture delivery and driver acknowledgment, support correction and hazards, re-read current state before revision and show every changed stop, path, time and commitment.
Execution proves service, not tracking alone
Limit location use by purpose and retention, distinguish planned and actual movement from arrival and service, reconcile authoritative job, custody, condition, exception, incident, claim and recovery evidence and prohibit employment conclusions from route adherence alone.

Outcome evidence

Measure feasible released routes and observed service, not shorter lines.

Distance can fall while lateness, driver burden or missed constraints rise. Proof must join the route decision to actual work.

Baseline

  • Regions, depots, route and job families, drivers and vehicles, load and capacity units, route providers, network and condition coverage, restriction profiles, window types, objective versions, dispatchers and revision policies
  • Current dispatcher and driver effort from job and assignment review through route comparison, correction, approval, delivery, acknowledgment, revision, service, exception, claim and recovery
  • Current invalid inputs, infeasible jobs, capacity and rule failures, provider gaps, stale matrices, manual route changes, rejected suggestions, acknowledgment failures, revision churn, late and failed stops and unsafe suggestions
  • Current planned and actual distance, travel and service time, approved cost components, windows, stop attempts and service plus exceptions, incidents, claims, complaints, returns and recovery

Outcome evidence

  • Correct job, stop, assignment, network, restriction, condition, capacity, time, objective, candidate, approval and execution handling against authoritative evidence
  • Feasible candidate, dispatcher acceptance, driver acknowledgment, stable revision and completed service by route family, resource class, condition coverage and demand mix
  • Wrong assignment, overload, invalid access, stale condition, hidden hard breach, unsupported optimum, unsafe route, unapproved revision, false arrival and false service prevention
  • Dispatcher and driver effort, planned and actual travel, service-window performance, approved cost components, route churn, exceptions, incidents, claims, complaints and recovery against the prior process with demand and conditions visible

Guardrails

  • Wrong tenant, job, stop, worker, vehicle or unit; bad coordinate; private-location exposure; expired assignment; missing cargo or access rule; unavailable correction; and tracking reused for unsupported worker surveillance or employment consequence
  • Soft penalty substituted for law or safety, capacity not traced after every stop, naive local time, stale network or condition, forecast called observation, uncovered route called current, impossible work hidden and shortest or fastest called safest
  • Unversioned objective or rate, unexplained weight, one opaque candidate, heuristic called optimum, provider result called permission, dispatcher approval invented, route published without acknowledgment path and uncertain dispatch retried blindly
  • Geofence called arrival, arrival called service, route completion called delivery, technical estimate called realized saving, missed stops or driver effort omitted, incident or claim disconnected and lower distance presented as safety, compliance, emissions or satisfaction

Fit test

Use this pattern when route feasibility and release authority are inspectable.

Good reason to begin

  • One operation has durable job, stop, assignment, worker, vehicle and equipment identifiers, time-safe windows and durations, normalized load units and current eligibility and capacity sources.
  • Qualified owners maintain road, vehicle, cargo, access, safety and work constraints, and route, matrix and condition providers expose versions, coverage, observed times, expiry and honest gaps.
  • Objectives, costs, rates, units, weights, hard and soft rules, solver limits, alternatives, dispatcher approval, driver acknowledgment, correction and revision paths can be versioned and replayed.
  • Actual movement, stop attempts, service, custody, condition, exceptions, incidents, claims, complaints and recovery can be reconciled without turning location into unsupported performance authority.

Resolve before beginning

  • Job or stop identity, assignment authority, load units, capacity, service windows, local time, road and access rules, route coverage, condition freshness, objectives, approval or actual service evidence is undefined.
  • The process cannot distinguish assignment from routing, request from commitment, map path from permission, forecast from observation, soft penalty from hard rule, approval from acknowledgment, geofence from arrival or arrival from service.
  • Success is defined by route distance or solver score without feasibility, dispatcher and driver corrections, route churn, total cost, service windows, safety, incidents, claims and physical outcomes.
  • The system is expected to invent road or labor rules, assign workers, hide infeasibility, treat a heuristic as proven optimum, route through unknown constraints, publish unsafe changes or guarantee cost, time, safety, compliance or service.

Source basis

Sources behind the control model.

  • 01

    Open Geospatial Consortium

    Draft OGC API: Routes, Part 1 Core

    OGC explicitly labels this work as a draft Web API for requesting routes independently of the underlying routing dataset, engine or algorithm. A draft route-service contract does not prove provider coverage, current network state, geocode correctness, legal or safe passage, vehicle and cargo feasibility, capacity, service-window feasibility, optimization quality, approval, execution or outcome.

  • 02

    International Organization for Standardization

    ISO 19133:2005: Tracking and navigation

    ISO lists this standard as published and confirmed in 2022. Its public abstract covers data types and operations for tracking and navigation services, including web-service use. It does not validate a stop, route dataset, current road condition, legal or safe restriction, driver or vehicle eligibility, capacity, cost, service window, dispatch authority, delivery or outcome.

  • 03

    International Organization for Standardization

    ISO 39001:2012: Road traffic safety management systems

    ISO lists this published standard with a 2024 amendment and marks it to be revised. Its public abstract covers road-traffic-safety policy, objectives and action plans for factors an organization can control or influence. It does not provide a safe route, current restriction, vehicle rule, driver-duty rule, route risk score, control implementation, certification status or reduced-injury proof.

  • 04

    RFC Editor

    RFC 5545: Internet Calendaring and Scheduling Core Object Specification

    This standards-track specification defines exchange of events, tasks, free or busy information and local-time or time-zone forms and has later updates. Calendar data does not prove a customer commitment, facility access, service duration, driver availability, legal work interval, travel feasibility, arrival, time worked, service completion or compliance.

[ WORKFLOW / SYSTEMS AUDIT ]
THE FIRST ENGAGEMENT

Start with one real workflow

A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.

Show Us the WorkflowStart with the free automation readiness checklist

OBSERVEQUANTIFYDECIDEBUILD

Continue with the work

Choose the next useful path.

Stay with the operating question. The technology can wait until the work is clear.

01

Driver communication agent

Connect route changes to driver messages, acknowledgement, and dispatcher escalation.

Open path02

Explore governed AI agents

Compare other bounded agent patterns and the evidence, authority and recovery contracts they require.

Open path03

Design logistics and transport operations

Frame movement identity, dispatch, routes, tracking, custody, exceptions and service around accountable evidence.

Open path04

Prepare governed dispatch plans

Assign work and resources under time-correct capacity, eligibility, safety, priority and dispatcher authority before route planning.

Open path05

Connect supply-chain and logistics decisions

Join demand, inventory, movement, exceptions and realized service without turning forecasts or events into operational truth.

Open path