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 of the vehicle’s systems — brakes, doors, bogies, and so on, each subdividing further. It is seeded from the EN 15380-2 standard when the type is created, or built by the fleet from scratch; either way each node carries an EN 15380 mapping.
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.

​
Defect reporting

Reports written in the reporter app, and their delivery to the maintainer’s system. Code lists hold the allowed values for five classification fields, per project. A report points at the entries it uses, so an entry in use cannot be deleted, only deactivated. Only LOCATION entries can be scoped to a vehicle type. A defect report carries the same fields as a defect, filled in during a conversation. Its session is that conversation; at most one session per report is open at a time, and each message is one entry of the transcript, including direct edits of the form. Submitting writes a defect row, linked one-to-one to the report, and an outbound sync row that delivers the report through the project’s maintainer integration — at most one per project. The defect row is created with an APP- identifier; on delivery it is replaced by the maintainer’s identifier, which the report keeps as its external reference. A submitted report is never changed again; a change is a new report.

​
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.
Three exceptions worth knowing. Vehicles and components are created in the application but carry an external identifier so imported rows can be matched to them. 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. And a defect submitted from the reporter app is created in the application, then taken over by the import once the maintainer’s file carries it — see Reported Defects.
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.