Skip to main content
This page shows the entities the platform stores and how they connect. For every column and every constraint, table by table, see the table reference. Two rules apply everywhere and are not repeated:
  • Everything belongs to a project. Almost every table carries a direct link to its project, and the few that do not inherit it from their parent.
  • Every record has a unique identifier and timestamps.

​
The fleet registry

This is the backbone. Everything else in the platform ultimately points at something here. Reading it in order:
1

A vehicle type describes a class of vehicle

Not an individual train — a model. Everything structural hangs off the type, so it is defined once and applies to every vehicle of that type.
2

Product groups organise the vehicle into functional groups

A tree following the EN 15380-2 standard — brakes, doors, bogies, and so on, each subdividing further. Standard top levels are seeded automatically; the rest is defined per vehicle type.
3

Slots are the mounting positions

A slot is a place where a component can sit — “bogie 1, axle 2, left wheel”. Each slot belongs to a product group and lists which component types are allowed in it. Slots can nest inside other slots.
4

Vehicles and components are the instances

A vehicle has a vehicle number and carries its current mileage and operating hours. A component has a serial number, a status, and its own lifetime mileage.
A component has no direct link to a vehicle. Which component is mounted where lives in a separate record with dates on it, so that mounting history is preserved rather than overwritten. That record is VehicleConfiguration, below.

​
Mounting and maintenance

Vehicle configuration is the mounting log. One row per mount event, with the dismount date left empty while the component is still fitted. Two rules are enforced by the database itself: a component can be mounted in only one place at a time, and a slot can hold only one component at a time. Maintenance plans belong to a vehicle type or a component type, never both. Each plan holds tasks, and a task defines an interval with a tolerance. Maintenance records are the preventative work that was performed, imported daily. Planned occurrences are projections of work not yet done, generated by the Planner.

​
What attaches to the fleet

The remaining modules all hang off a vehicle or a component.

​
Where each entity comes from

Whether a record is imported or created in the application determines whether you can edit it. Imported records are read-only in the platform — an edit would be overwritten by the next day’s file.
Two exceptions worth knowing. Vehicles and components are created in the application but carry an external identifier so imported rows can be matched to them. And on an imported maintenance task, the manhour and cost estimates are maintained in the application by the Planner role — the import does not touch them.
Each imported file has its own format, its own validation rules, and its own reasons a row might be rejected. Start with How ingestion works for the rules that apply to every file, then the individual file pages for the column-level contract.