Segment analytics: what fleets learn from traversal records

What this chapter covers

Every time a truck crosses the road between two Tier-1 measurement boundaries, Korido records the crossing as a single, immutable fact. Those boundaries are city waypoints and mission origin/destination waypoints, not every curated place on the road. This chapter is about what a fleet learns once those facts accumulate: how one truck compares to another on the same road, how one driver compares to another, and — the most valuable comparison of all — how a truck compares to its own past, which is the earliest warning that something is wearing out. It explains the context dimensions that make a comparison fair, the cross-fleet corridor benchmarks the platform can see across every tenant, and the drill-down from a period down to a single journey.

The picture

The unit of measurement is the segment traversal: one row per completed road crossing by one truck, from one Tier-1 boundary to the next. It carries not just how long the crossing took, but everything needed to explain why it took that long and to compare it fairly against another crossing.

Analytics ship query-first: they are grouped queries over the traversal records and the indexes already built for them, not a separate warehouse. Materialised rollups and scorecards are an optimisation added only when a dashboard measurably needs them, never a precondition for asking a question.

What a traversal records

A traversal is closed the moment the truck enters the next waypoint, and at that instant Korido freezes a rich set of facts onto the row:

• Time. Total transit_seconds (wall clock from departure to arrival) and driving_seconds (engine actually moving), plus the stop, gap, and idle time that make up the difference.
• Motion. Distance covered, average and maximum speed.
• Attributable time. Three slices that explain lateness — border_crossing_seconds, breakdown_seconds, and slow_driving_seconds. The slow-driving slice counts only the time beyond what a slowdown zone already expected, so a chronically slow stretch is not charged twice — once as the zone's own drag and again as fresh slow-driving time.
• Fuel and money. Start and end tank percentage, litres consumed, efficiency in L/100km, the per-litre price at the time, tolls, and a total cost that folds fuel, driver wage, trailer rent, tolls, and overhead into one figure.
• Incidents. Counts of stops, gaps, idle spells, speeding events, and deviations during the crossing.

Because the row is immutable and self-contained, a comparison reads frozen facts exactly as they were true at the time.

The comparisons

Four comparisons fall out of the same records:

• Truck versus truck, same road. Pool every tenant's crossings of the same waypoint pair and rank the trucks. Two trucks on the identical stretch, one consistently slower or thirstier, is a signal worth acting on.
• Driver versus driver, same road. The same pooling, grouped by driver. Because the driver is stamped on every traversal, "show this driver's crossings over time" and "compare two drivers on the same segment" are direct groupings, read straight off the traversal row.
• A truck against its own history. The most operationally valuable line. A truck that is steadily getting slower or less fuel-efficient on a road it has driven many times is showing early wear. These self-degradation trends are exactly the early-warning signal that feeds fleet maintenance planning.
• Cross-fleet corridor benchmark. For platform administrators, the same records pooled across every tenant give a corridor-wide baseline: what a segment normally costs in time, regardless of who is driving it.

The fairness dimensions

A raw "truck A is slower than truck B" comparison is meaningless if A crossed in the wet season with a full trailer at night and B crossed dry, empty, and at noon. Korido stamps each traversal with the context that makes the comparison fair, so a query can hold those factors constant:

• Season — a four-bucket Sahel calendar: dry_cool, dry_hot, wet_early, wet_peak. The road is a different road in the wet peak.
• Weather — the nearest observed weather class at departure.
• Calendar — a class such as normal or a holiday, from the tenant calendar. A crossing on a public holiday behaves differently at borders and checkpoints.
• Cargo load — whether the truck was loaded and its cargo weight. A laden truck climbs slower and burns more.
• Driver fatigue — accumulated driving time: the driver's cumulative driving since 04:00 local that day, and over the trailing 7 days. Fatigue is a measurable input to how a segment was driven.
• Vehicle make, model, and year — stamped on the row so a comparison can hold the machine constant, or explicitly compare an old truck against a new one.
• Time of day — the local hour and day of the week, derived automatically from the departure time, so day-versus-night and weekday-versus-weekend distributions are first-class groupings.
• Segment experience — how many times this driver has crossed this exact pair before, so a first crossing is not judged against a veteran's.

Holding these constant is what turns a number into an insight: on the same road, same season, same load, at the same time of day, this truck is 20% slower than the fleet is a claim a dispatcher can act on.

The drill-down

The analytics surface reads top-down, from the widest view to a single journey:

A user starts at a period — 7, 30, or 90 days — sees the fleet-wide scorecards and trend lines, and narrows to a mission, then to a single segment (one waypoint pair), and finally to the journey detail of one traversal with all of its frozen facts. Each level is a grouping of the same records at a different granularity.

At the segment level, the numbers are percentiles, split by time of day: the median (p50) and near-worst (p90) of both driving time and wall-clock time, bucketed into day, night, and overall. Percentiles rather than averages, because a single customs day should not drag the typical crossing.

Cross-fleet corridor benchmarks

Platform administrators see a Segment Analytics surface that reads across every tenant at once — the only place in Korido where tenant boundaries are deliberately crossed, because a road segment belongs to the corridor, not to a fleet. It answers two questions:

• The corridor overview — one row per curated road segment, pooling every tenant's crossings of that segment's waypoint pair. Segments with no samples yet still appear, so the corridor map is complete rather than only showing roads that happen to have traffic.
• The segment detail — for one segment, the day / night / overall p50 and p90 of driving and wall-clock time, the same percentile shape a tenant sees for its own trucks, but computed over the whole platform.

This cross-tenant view is reachable only by an authenticated administrator; a tenant never sees another tenant's rows.

Predicted versus actual

Every traversal also freezes the estimate that was standing when the crossing began: the predicted duration at that moment, and how confident that prediction was. Because the prediction travels on the row, a dashboard can compute predicted-versus-actual gaps across many crossings without re-joining the prediction tables — the raw material for asking whether Korido's own ETAs are calibrated.

Edge cases

• A segment with no samples. The corridor overview keeps a curated segment visible even before any truck has crossed it, so a fresh corridor already shows its full map of segments.
• A crossing with no planned segment. When a Tier-1 boundary pair is not part of a planned route, it can still record against the pair itself, so ad-hoc city-to-city or origin-to-destination crossings are measured rather than dropped. Non-Tier-1 places such as customs yards, fuel stations, and weighbridges remain stop and hotspot context; they do not create segment traversal rows by themselves.
• Double-counted lateness. The slow-driving slice subtracts what a slowdown zone already expected, so a chronically slow stretch is never charged twice — once as the zone's drag and again as slow-driving time — and a crossing with no zone coverage counts its full elapsed time honestly.
• GPS jitter at a waypoint. Rapid enter–exit–enter flapping at a boundary cannot produce duplicate traversal rows — a closed crossing is unique per arrival.
• Geometry edited after the fact. A traversal freezes the waypoint positions and radii it was measured against, so an operator moving or resizing a waypoint later never silently rewrites historical crossings — a dashboard can even detect that the geometry changed since a row was written.

Known limitations

• A fair comparison needs enough matched crossings. Percentiles, day-versus-night splits, and context-held comparisons are only meaningful once a bucket holds enough samples. A thin bucket — a rarely-driven segment, an unusual season-and-load combination — falls back to a coarser overall baseline rather than reporting a confident figure from one or two crossings.
• Analytics read the live records directly. The surface runs as grouped queries over the traversal rows and their indexes rather than a separate warehouse, which keeps every figure current and avoids a staleness gap — at the cost of heavier queries on the widest multi-month windows.

How it connects

• Traversals are produced as missions progress — see Segments and traversals for how a journey becomes measurable segments and Progression and ETA for how the ETA layers are built.
• The slowdown zones, hotspots, and anomalies whose expected drag the attributable-time slices net out are described in Spatial intelligence.
• Self-degradation trends feed maintenance planning — see Fleet assets for the asset side.
• The fuel figures on each traversal originate in the engine's fuel path — see Fuel.