Your supplier contract has a baseline assumption you haven’t verified 

When signaling data moves from an Infrastructure Manager to a supplier whether as part of an ERTMS rollout, a modernization program, or a system integration it becomes the baseline for everything downstream: design, verification, testing, acceptance, and commissioning. If that data is incomplete, inconsistent, or incorrect, the cost of discovery multiplies with every phase it passes through unchecked. 

The handover problem nobody prices correctly 

Supplier contracts typically define clear boundaries. The supplier is responsible for delivering in accordance with the data provided by the IM. If the data turns out to be wrong, the supplier reports it back. But reporting a defect takes time. Correcting it requires change control. Re-testing adds cycles. And by the time a data error surfaces during integration or FAT, weeks or months have passed, budgets have been consumed, and confidence in the delivery timeline has eroded. 

The IM remains accountable for the outcome. The supplier has a contractual out. 

The root cause lies with the IM’s data, not the supplier’s competence. Rail organizations increasingly understand this, but their responses are often too late. Validation happens after handover rather than before it — when correction costs have already compounded. 

In a Prover webinar on automating data preparation for rail control systems (recorded March 2025), participants were polled on their biggest project challenges. Two findings came in at the top: too much manual work in data creation, and errors found too late in the project lifecycle. The interface between IM data and signaling products ranked as a recurring friction point. 

These are not independent problems. They are the same problem seen from different phases of the same project. 

What makes handover data unreliable 

Configuration and application data for signaling projects are rarely held in a single, authoritative system. More commonly, it lives across spreadsheets, PDFs, drawings, legacy databases, and the working memory of experienced engineers. When a modernization or migration project begins, this fragmented knowledge must be extracted, structured, and validated before it can serve as a credible supplier baseline. 

That process takes time, requires specialist judgment, and carries real risk when done manually. The SA/GA/GP architecture of modern signaling systems makes this worse: while the Generic Application can be verified once, the Specific Application data must be verified for each deployment, project, and change. Every new installation or upgrade restarts the data preparation problem from scratch. 

The result is a structural mismatch. Supplier timelines assume the IM baseline is ready. The reality is that data readiness has not been confirmed before the clock started. 

Why ERTMS programs raise the stakes 

ERTMS modernization programs increase the number of supplier boundaries and handover points. National rules, country-specific data formats, and varying IM engineering practices mean that even when the system architecture is standardized, the data flowing into it is not. Infrastructure managers may use railML, LCF, RDF, IMX, SDEF, or proprietary formats. Each interface between IM data and a new supplier requires a verified translation, and each translation is a potential source of undetected errors until integration. 

McKinsey’s analysis of large infrastructure programs found that poor data quality and requirements ambiguity are among the leading drivers of cost overruns, with schedule impacts typically concentrated in integration and acceptance phases (McKinsey Global Institute, “Reinventing Construction,” 2017. Rail signaling projects follow the same pattern. When IM data enters a supplier workflow with known inconsistencies, both parties spend project time resolving something that could have been addressed before the contract began. 

What to do before the handover 

The standard for trusted handover data is not perfection. It is verifiability: the data has been structured, validated against IM rules and Generic Application constraints, checked for internal consistency, and assessed for completeness relative to its downstream purpose. 

Start by identifying the specific dataset, subsystem boundary, or station area most likely to generate supplier queries. Scope it tightly. Ingest the available data — PDFs, spreadsheets, drawings, legacy exports — and run it through automated validation to surface issues before the supplier baseline is fixed. 

The output is a structured issues log with correction proposals and a documented readiness verdict: usable as-is, usable with defined corrections, not yet usable. That verdict, made before supplier engagement rather than mid-integration, gives your program a concrete decision point: proceed, remediate, or rescope. Without it, the program inherits an unquantified assumption at its foundation. 

The practical first step 

A Data Readiness Sprint is a bounded 6-week engagement designed to answer one question for a selected signaling data scope: Is this data ready for its intended downstream purpose? 

The sprint covers data intake and structuring, automated validation against IM rules and GA constraints, issue analysis, correction proposals, and a readout with a clear decision outcome. It is scoped to a single dataset, subsystem, or migration boundary. 

If your organization is preparing for an ERTMS rollout, a legacy migration, a new supplier handover, or a modernization program where data quality has not yet been confirmed, run the sprint before the contract clock starts — not after the first supplier query arrives. 

Book a 30-minute conversation to scope a Data Readiness Sprint for your next handover boundary.