Manual / Diversions

Activations, and the figures they carry

An activation is the record that a diversion was actually in force over a period, and the service kilometres that period is estimated to have cost. This page is where those figures appear, what they are worth, and — the part most likely to surprise you — what this tab does and does not let you do with them.

What an activation is

A window: a start date, an end date, optionally a time of day, optionally a day-type filter such as weekdays only or school term only. Against it the app records how many scheduled trips would have crossed that window, how many service days it covered, and the estimated service-km not operated.

The sum is the kilometres of route each diverted trip skips, multiplied by the trips that would have passed the leave point inside the window, added up date by date.

Two details of that are worth knowing because they are invisible:

• a trip counts when it passes the leave anchor inside the window — that is the moment it would actually divert;
• the day-type filter uses the operating calendar, not the day of the week. A public holiday inside a "weekdays only" closure runs a Sunday timetable, so counting it as a weekday would overstate the loss.

An activation belongs to an approved record. A draft has no frozen plan for the figure to describe, so there is nothing to record a window against.

Where you see them

Reporting, in the toolbar. It opens Service-km lost by route and month:

with a Total row, and Download CSV and Download xlsx underneath. The same two downloads sit in the toolbar's Export menu as Service-km lost (CSV) and Service-km lost (xlsx).

Its subtitle states the arithmetic's honesty up front:

Summed from each activation's frozen estimate, so it is as good as those and no better. A closure spanning a month boundary reports each month in its own month.

A record's own document carries an Activations table — the window, its status, service days, trips and the figure — under the column heading Service-km lost (~ estimate). A window prints as a date range and its hours: 01/08/2026 – 14/08/2026, 22:00–02:00 +1, or all day where no hours were set. The +1 means the end time falls after midnight and belongs to the previous day's service, the same marker the timetable uses. The day-type filter is not printed in that column.

What this tab cannot do

There is no control anywhere in the Diversions tab that records an activation window. The register reads them, the report sums them and the documents print them, but nothing on any of these screens creates, edits or cancels one. A panel that did was taken out of this tab in August 2026 because it pushed the plan and the bulletin — the two things a controller opens a record to do — below the fold; nothing that was already recorded was touched.

So on a deployment that has never recorded one, Reporting says "No activations recorded yet, so there is nothing to report." and will keep saying it however many diversions are approved and activated.

Moving a record to Active does not record a window. It stamps the record as in force now. The two are separate on purpose: a record is in force or it is not, while a window is a period with dates on it.

Unknown — how a window gets recorded on a deployment that needs one. No screen in this app writes one, so before you promise anybody a figure, ask whoever administers your deployment whether windows are being recorded at all.

What the numbers mean

What they do not mean

It is an estimate, and the estimate is of the schedule. It measures what the timetable said would run against the plan as drawn. It does not measure what buses actually did: this app only knows that where an official record of running times has been loaded, and never for a diverted trip.

It is frozen at the moment the window was recorded, and never recomputed. That is deliberate. Recomputing it on reading would silently change what a past diversion is recorded as having cost, the first time the corridor was retimed or a trip left the timetable — the number would stop meaning "what we estimated this closure cost when it ran" and start meaning "what it would cost under today's timetable".

Two consequences follow, and both look like errors and are not:

• two windows on the same diversion in different months can report different kilometres, correctly, if the timetable changed between them;
• a figure cannot be corrected by editing it. A mistaken window is cancelled and the correction recorded; "this window was recorded and then withdrawn" is itself part of the record, and a deleted row cannot say it. Cancelled windows are left out of the report.

The report sums; it never re-derives. Each row is the sum of frozen per-window estimates, so it inherits their accuracy and nothing more.

A month boundary inside a closure is handled by date, not by start date. A closure running from late March into April reports March's kilometres in March.

A zero is a real answer, and worth checking. No scheduled trip crossing the window gives zero — which is correct for a closure outside service hours, and is otherwise a sign the window or the day-type filter is wrong.

Only one pattern's kilometres are counted. The figure comes from the pattern the diversion was planned against — the busiest one. Where a route's other patterns run the same stretch, Other patterns of this route on the record shows what they would miss, and those numbers are a check on the plan, not a second total to add on. The record's own figure stays the frozen one, because that is what the approved plan described.

There is no part-day proration. A trip either passes the leave point inside the window or it does not. A bus already past that point when the closure began is counted or not by that single test.

An empty report is not "no diversions ran". It means no windows have been recorded — see above.

None of this is contract data. Every kilometre figure on these screens is an operational estimate for planning and record-keeping, and prints with a leading ~ wherever a person reads it.