The data has to land where you already work

This is the event your system receives when a team changes position. The important part is not the coordinate: it is that the coordinate arrives with its quality attached, so whoever consumes it can decide how much to trust it.

{
  "event": "position.updated",
  "timestamp": "2026-03-11T09:41:07Z",
  "terminal": {
    "id": "TRM-0043",
    "team": "vigilancia-l2-turno-manana"
  },
  "position": {
    "zone": "station-014",
    "area": "platform",
    "direction": "north",
    "x": 128.4,
    "y": 22.7,
    "srs": "site-local"
  },
  "onboard": {
    "train": "4207",
    "car": 3
  },
  "quality": {
    "accuracy_m": 6.8,
    "source": "wifi-rtt",
    "nlos_suspected": false,
    "map_matched": true
  }
}

• zone and area are the operational reading: station and space. Usually all an incident manager needs.
• x and y are coordinates in the site-local system, for drawing on the layout.
• accuracy_m is the estimated uncertainty radius of that specific reading, not a system-wide constant.
• onboard appears only when the officer is aboard a train and the on-board layer is deployed. It is an exact identification, not an estimate: if the object is absent, no car beacon is being read.
• nlos_suspected warns that the measurement may have arrived reflected.
• map_matched indicates whether the position was snapped to walkable space.

• Versioned data contracts: schema changes are announced and coexist; they do not break your integration on a Tuesday.
• Configurable retention per data type, following operator policy.
• Anonymisation and pseudonymisation available for flows that do not need to identify a person.
• Portability: the full history is exported on request. The data belongs to the operator.