Data Models

This section explains the data models behind the Praedico Integration Platform: what each resource represents in your rail network, how the models relate, and how the platform uses what you send. It covers the concepts, not every field.

Looking for fields and example payloads?

The complete, machine-generated schema lives in the API Reference: every field, type, and a runnable example per endpoint. Use this section to understand the models; use the reference to look things up and try requests.

Concepts that apply to every model

Imports are upserts

Every import inserts or updates by your identifier. Send a record whose id already exists and it’s updated; send a new id and it’s created. Re-sending an unchanged record is safe. There are no separate “create” and “update” calls: you describe the desired state and the platform reconciles it.

You own the identifiers

You identify records using your own external identifiers: the id field, plus references like parentId, assetId, and subAreaId. The platform maps these to its internal records. The same identifiers you send are the ones you reuse on later imports and from other models. Keep them stable and unique within a model.

Models reference each other by identifier

Most models depend on others: a defect belongs to an asset, an asset belongs to a sub-area, a prediction points at what it predicts. Those links use the identifiers you already imported. So order matters: import the referenced record before (or together with) the record that references it.

Geolocation is shared

Many models describe where something sits on the network through a shared geolocation concept: linear references, chainage/offset, and optional lat/long or X/Y coordinates. Every part is optional; provide whatever your source system knows. Because it’s shared, it behaves the same way everywhere it appears.

Most models are imported in bulk

Most models are sent as a JSON array, so one call can carry a single record or thousands. A few specialised models take a single object instead. Each model’s page notes which shape it expects.

Where problems surface

Request-shape problems (wrong type, missing required field) are rejected immediately. Problems that depend on other data, such as referencing an identifier the platform doesn’t recognise yet, pass the initial check and surface later in the job status. See Common Errors.

The models

Each page explains what the model represents and how to use it. Full field lists and example payloads live in the API Reference.

AssetsThe physical things on your network and their hierarchy — the backbone most other models reference.

NotificationsMaintenance notifications and the work recorded against assets.

DefectsFaults and conditions found against assets.

Track MeasurementsMeasurement runs and the geometry/condition values they produce.

Service OrdersPlanned and executed maintenance work.

WeldsRail welds and their locations.

The complete set of models is listed in the sidebar.