Data window — what TRUST tells us, and what it cannot

Every figure published by Gauge Intelligence is a measurement of the railway as TRUST and NROD describe it. That description is rich, but it is not complete. This page sets out the boundary between three regimes: what we observe directly, what we deduce from partial evidence, and what the feed cannot see at all. Readers and licensees can then judge any number against its evidentiary basis.

The Great Eastern Main Line Period 13 2025-26 period report is the standing live example: Period 13 2025-26 (1–28 March 2026) is the inaugural published period under this methodology. The report header carries the data-window citation, the methodology footer links back to this page for cancellation handling and corridor assignment, and the Schedule 8 footnote calls out the counterfactual structure described under What is invisible to TRUST below.

This page is part of the standing methodology for the public archive (see also Methodology) and complements the voice-of-record positioning of the public register. For how the underlying feeds are connected, parsed, and corrected before any of this observation begins, see Data ingestion.

What we observe directly

The TRUST messaging system is the primary source of truth for in-flight freight performance. Gauge Intelligence ingests the full national NROD live feed and processes the following TRUST message classes:

• 0001 — Train activation. A schedule has been signed in to TRUST and is now live on the network, with an assigned TRUST identifier.
• 0002 — Train cancellation. A live activation has been cancelled, with a reason and a location.
• 0003 — Train movement. A train has been reported at a TIPLOC or STANOX location, with planned, gbtt, and actual timestamps.
• 0005 — Train reinstatement. A previously cancelled activation has been reinstated.
• 0006 — Change of origin. The starting location of a live activation has changed.
• 0007 — Change of identity. The TRUST identifier of a live activation has been replaced; the journey continues under the new identity.
• 0008 — Change of location. A scheduled location on a live activation has been changed.

Alongside these movement messages, we ingest the underlying schedule data through the CIF timetable feed, which describes what the railway intends to run. An activation links a real-world journey to a CIF schedule via the train_uid + schedule_start_date + schedule_type key.

Every published number whose evidence base is a sequence of these messages is observed directly. Examples: arrival-to-fifteen punctuality at the corridor exit, scheduled-vs-actual delay at any TIPLOC, cancellation counts keyed to a reason code.

What we deduce

A live network feed is not a clean record. Messages arrive late, out of order, or not at all. To reconstruct a complete picture of every freight journey we apply three classes of deduction. Each is conservative: we deduce only when the evidence permits a single, unambiguous reconstruction.

Synthesised activations for orphaned movements. A 0003 movement sometimes arrives for a train that has no matching 0001 activation — often because the activation message was lost in transit, sent outside our connection window, or dropped during a feed outage. We infer the activation from the movement payload. Without this, the journey would be invisible to the record despite physically running.

We mark these activations as deduced so that licensed users can isolate or exclude them.

Change-of-Identity (CoI) chain tracking. A single freight train can run under several TRUST identifiers in succession: re-signalling at an intermediate point, splits and joins, or operational re-platforming all generate a 0007 message that hands the journey from one identifier to another.

Gauge Intelligence follows the full chain (up to ten links) and treats the underlying journey as one continuous freight service from origin to destination, rather than as several disjoint activations. CoI chain tracking is a permanent operational requirement of the TRUST data model, not a transitional concern.

STP overlay resolution. A single calendar day can have several candidate schedules for the same train: a permanent schedule (P), a new short-term plan (N), an overlay (O), and a cancellation (C).

The Short Term Plan priority hierarchy (C beats O beats N beats P) determines which schedule a TRUST activation is matched against. We apply the priority resolution at lookup time so that performance is always measured against the schedule that was actually in force on the day.

What is invisible to TRUST

Three classes of event leave no trace in the live feed. The numbers we publish are correct for the population of services that TRUST sees; readers should understand that this population excludes the following:

• Services cancelled before activation. A path booked in the timetable but cancelled before the train signs in to TRUST never produces a 0001 message, and therefore never produces a 0002 cancellation either. These pre-activation cancellations are visible only in CIF schedule changes and operator records, not in the TRUST stream. Our cancellation rates are post-activation rates. Services that receive a 0002 cancellation message after activation are excluded from A2F punctuality calculations entirely; they appear in the cancellation rate but do not count as late in the on-time denominator.
• Services not signed in to NROD. A small minority of freight workings run outside the NROD signing-in regime: certain test trains, internal Network Rail movements, and some short-notice paths. These are out of scope for the published archive.
• Schedule lookup failures. When a TRUST activation cannot be matched to a CIF schedule (typically because the schedule has been withdrawn, the lookup key collides, or the activation references a train_uid not yet present in our schedule database), the journey is recorded as run but is excluded from punctuality calculations that depend on a planned comparison. We monitor the lookup-failure rate and treat any sustained rise as a data-quality incident.

Reference data freshness

Every number we publish depends on reference datasets that are refreshed on different cadences. The following four feed into virtually every calculation:

• BPLAN geography. Network Rail’s track topology, mapping STANOX codes to physical routes, signalling areas, and engineer’s line references. We refresh BPLAN weekly from Peter Hicks’s RDM product using a transactional truncate-and-reload, with the last-import date surfaced in our internal ingestion-health dashboard against a ten-day staleness threshold.
• CIF timetable. The Common Interface File giving scheduled timings against which actual performance is measured. CIF is updated whenever Network Rail publishes a revised schedule.
• STANOX tables. The mapping between STANOX numeric codes, TIPLOCs, and human-readable location names. Refreshed periodically.
• Schedule 8 rate tables. The Control Period 7 payment rates and benchmark thresholds used to estimate bilateral exposure (see the Methodology Schedule 8 section for the rate values and direction).

Where reference data is allowed to go stale, the code remains correct but the outputs drift silently. We treat reference-data freshness as a first-class quality dimension and surface staleness alongside the figures that depend on it, so that licensed users can audit provenance.

Domain rules that affect every number

Five domain rules apply at ingest time to every TRUST message we process. Without them, individual figures would be subtly but consistently wrong. We document them here because they are not visible in the published figures themselves; the figures are clock-time correct because these rules are applied automatically.

British Summer Time timestamp adjustment. During BST, raw TRUST timestamps for several event fields are issued one hour ahead of the correct clock time. Gauge Intelligence applies a one-hour subtraction to each affected field at ingest, before any performance calculation. Every published timestamp is clock-time correct.

FOC identification by toc_id, not atoc_code. All freight operating companies share the ATOC code “ZZ”, because ATOC was not designed to distinguish between freight operators. We identify the operator of a freight movement using TRUST’s toc_id field, which carries a unique numeric code per FOC. Operator-level analysis would be meaningless without this rule.

STP priority hierarchy. When several candidate schedules exist for the same train on the same day, we resolve to the one that was actually in force using the Short Term Plan hierarchy. Cancellation (C) beats overlay (O), which beats new (N), which beats permanent (P). Performance is always measured against the schedule that ran, not against an outdated permanent baseline.

Schedule type O/P swap. TRUST activations carry a schedule_type field whose O and P values are swapped relative to the CIF schedule database. We invert the field at lookup time so that overlays match overlays and permanents match permanents. Without this correction, the schedule lookup would silently return the wrong record for any day that has both an overlay and a permanent schedule.

Schedule unique key. Schedules are uniquely identified by the combination train_uid + schedule_start_date + schedule_type. We use this composite key everywhere a journey is matched to its plan; matching on train_uid alone would conflate overlapping schedules and produce incorrect delay figures.

Versioning

This page is part of the standing methodology and is versioned alongside the Methodology reference. When the data window boundaries change (for example, when a previously invisible class of event becomes observable, or when a new deduction rule is introduced), the change will be dated and recorded here. Where a change affects previously published figures, a correction notice will be posted on the corrections page with full provenance.