The Data Warehouse

Strategic modelling needs something to measure against. That something is the data warehouse: every plan the operation has run, kept in one place and open to query. It does no analysis of its own - the workbench compares over it, the agent reads it, and a scenario comparison is only as credible as the record it is measured against - but nothing else in strategic modelling works without it.

What It Holds

The unit of capture is a plan. Each one is kept as the dataset it ran against and the optimised snapshot it produced, with:

• Route-level detail - trips, shipments, vehicles, sites, and the timings that tie them together, the same detail the dashboard renders as routes, maps and timelines.
• Snapshot KPIs - cost to serve, CO₂ to serve, vehicle utilisation, driver hours and feasibility, summarised per snapshot so plans compare at a glance.

Because it accumulates rather than overwrites, the warehouse becomes a record of how the operation has actually run over time - a representative month, a peak season, a year of work - not just the most recent plan. That is what makes historical replay a credible basis for a strategic decision, which scenario comparison sets out in full.

How You Reach It

You do not query the database directly. That boundary is deliberate: it keeps each customer’s data isolated and keeps the warehouse from becoming an uncontrolled way into the operation. There are two supported routes in, and a third option for taking the data away:

• The workbench. The strategic workbench reads the warehouse to give you multi-dataset summaries, ad-hoc pivot analysis, and side-by-side snapshot comparison, no SQL required.
• The agent. The experimental AI agent turns a plain-language question into a read-only, automatically scoped query and hands back a table you can pivot or plot. It can only read, and only the datasets your permissions already allow.
• A data dump. If you want the raw record on your own systems - for a bespoke analysis, a BI tool, an archive - a PostgreSQL dump can be supplied on request.

Access in every case follows your Optrak project and directory permissions. Opening the warehouse to more people through the workbench or the agent does not open more data to any one of them.

Worked Example: Finding the Uneconomic Tail

A commercial manager suspects a long tail of customers is being served at a loss but has never had the evidence. In the workbench she pivots the last quarter’s captured plans by customer, with cost to serve and drop count as measures - or she asks the agent for the same thing in a sentence. The result is a table she can sort: the handful of customers whose cost to serve runs well ahead of their drop volume, the rounds they sit on, and how often they forced an awkward routing. None of it needed a new data-collection exercise; it was already in the record of plans the operation had run. The number she leaves with is grounded in the same optimiser that plans the operation, not in a separate costing model.

What It Will Learn

The record is also the raw material for performance prediction, a machine-learning capability in active development. Mining the warehouse to estimate travel, dwell, service and energy-consumption times from an operation’s own history, rather than from generic defaults, will make both daily plans and strategic scenarios more accurate where it counts, at feasibility and cost.

Performance prediction is in active development and available soon. It draws on a live source of those actual times - Optrak’s real-time capability - and will feed the optimiser better numbers without replacing it. See AI in route optimisation for where it fits.

How This Compares

Plenty of planning suites expose reporting over yesterday’s plans. The distinction here is not the reporting; it is that the warehouse is the same record the operational optimiser produces, queried through the same engine that runs the operation - so the baseline a strategic decision is measured against carries operational fidelity rather than a separate, drifting abstraction.