Switch Conditions

A switch condition is a restriction imposed against a switch (turnout) — for example, a speed restriction applied while a fault is being managed. Each condition records why it was put in place, when it started, and, once resolved, when it was lifted. Conditions let your team track the constraints currently in force across the network and the history of those that have come and gone.

At a glance

Represents: a restriction imposed against a switch asset
Body: a JSON array of switch-condition objects
Keyed by: id — your external identifier, and the upsert key
Belongs to: an asset (assetId)

What it represents

Each switch condition is anchored to the asset it restricts. The asset must exist (or be imported alongside it) for the reference to resolve — see how models reference each other by identifier.

A condition follows a lifecycle. It is imposed on a date by someone and later lifted on a date by someone. A condition still in force has no lifted date, which is how the platform tells a current restriction from a historical one.

Descriptive classifiers say what kind of restriction it is and why: a condition type, a direction and switch position it applies to, the train type it affects, and a cause (grouped, then specific). Comments capture operational and inspection notes. A condition can also point at a related work or maintenance order, tying the restriction back to the job that addresses it.

Using it

Import the asset a condition relates to first, or its assetId resolves to nothing. That surfaces at job time, not at request time.
Leave the lifted date empty for conditions still in force; set it when the restriction is removed.
Re-importing is safe. A condition with an existing id is updated in place, so you can re-send the same record to mark it as lifted.
Keep identifiers stable across imports. Changing a condition’s id creates a new record instead of updating the existing one.