The 3 Types of Rail Data

Most Infrastructure Managers struggle with Asset Master Data because they treat all data as equal. They try to "flatten" everything into a single spreadsheet. But in reality, your asset data comes from three fundamentally different sources, each with its own behavior and lifecycle.

1. Static Sources (The Inventory)

Examples: GIS, SAP, IBM Maximo

This is what most people think of as "database". It is a snapshot of the network at a specific point in time. It is often structured, officially sanctioned, and used for reporting.

The Problem: It is almost always outdated. It represents "what we thought we had" at the moment of the last survey or manual entry. It rarely captures the dynamic lifecycle of the asset.

2. Project Data ( The Future)

This is where the network changes. Projects introduce new assets, modify existing ones, or decommission old ones. This data is rich in engineering context and usually high quality (if caught early).

The Integration Challenge: Project data lives in the future (until it's built). It often uses temporary IDs ("Signal 12 on Plan B") instead of network-wide UUIDs. To use this for Asset Master Data, you must capture it before it becomes a pdf in a dusty archive.

3. Measurements & Observations (The Reality)

Examples: Measurement Trains, IoT Sensors, Field Technician Reports, MODBR

This is the ground truth. A measurement train scans the track coordinates. A technician reports a broken balise. This data is messy, unstructured, and massive in volume.

The Reality Check: This source doesn't care about your database rules. If the train measures track gauge at 1435mm, but your database says 1668mm, you have a conflict. This isn't just "data entry"—it's an observation that needs to be validated and reconciled.

The Kapernikov Infra Data Integration Strategy

You cannot just "merge" these three. You need a Reconciliation Engine. our Kapernikov Infra Data approach treats each of these as a distinct input stream:

• A
  Validate at Source: We apply rules to Project Data before it enters the system (e.g. demanding UUIDs).
• B
  Treat Changes as Observations: A new measurement isn't an overwrite; it's a piece of evidence.
• C
  Time Travel: We manage Valid Time and Transaction Time. We know that the Project Data became valid last Tuesday, even if we only received the file today.