An RTLS deployment delivers a dot on a map. That dot has an x-coordinate, a y-coordinate, a timestamp, and an identifier. By itself, the dot is worth nothing. The reason most RTLS programmes underperform isn't the technology — it's that the system stops at the dot.
The value lives in the layers above the position event. Five of them, specifically. This piece walks through each in the order they get built, what most teams get wrong, and where the operational ROI actually shows up.
Layer 1 — Raw events
This is what the radio infrastructure produces: position updates at some interval, plus zone-entry, zone-exit, and proximity events. In a well-tuned UWB system you'll see updates every 100–500 ms. In RAIN RFID it's per-read, gated by reader cycle and tag dwell. In BLE 5.x AoA, every 1–5 seconds.
Three things go wrong at this layer. First, the update rate is over-specified, so the cost goes up without operational benefit. Second, the coordinate system isn't tied to a real-world reference (you have x/y in metres but no map calibration). Third, the event stream is left in whatever proprietary format the platform emits.
The fix is to treat raw events as a transport-only layer and immediately normalise them into a vendor-neutral event schema. We use a simple JSON envelope with asset_id, position (x, y, z, zone), timestamp, confidence, and a free-form tags object. Everything downstream consumes that. When the platform vendor changes — and they will — only the adapter changes.
Layer 2 — Derived states
The next layer answers: what is this asset doing? Not where it is. What it is doing. Examples:
- Dwell: "in zone X for Y minutes" — the basic input for SLA tracking, hand-hygiene attestation, FOD investigation, dock dwell.
- Transition: "moved from zone A to zone B at time T" — the basic input for patient flow, WIP cycle time, build genealogy.
- Co-location: "asset A within X metres of asset B" — the input for tool-on-job, tool-with-operator, and contact-tracing patterns.
- Idle / active: derived from movement velocity over a window — the input for utilisation analytics.
These derived states are where most RTLS vendors lose interest. Their UI shows the dot. Their SDK gives you the raw events. The derived-state engine is on you, and that's exactly where the value engineering happens.
Layer 3 — Business events
A derived state is technical. A business event is meaningful. The translation between them is the most important piece of work in a location-intelligence programme, and it's the place where the consulting hours actually pay back.
Example: an infusion pump that is in a storeroom for 12 minutes is a derived state. The same pump leaving the storeroom toward ward 4B for the first time today is a business event: "infusion pump 4F-217 entered service rotation." The clinical CMMS cares about the second one, not the first.
This translation isn't free, and it's not generic. It is, in every successful programme we've delivered, the place where domain expertise (clinical workflow, MES, WMS, biomed, OR scheduling) gets encoded into rules. The output of layer 3 is the input to every downstream system.
Layer 4 — Decisions and automations
Once a business event exists, three things can happen:
- It updates a metric on a dashboard.
- It triggers an alert, ticket, work order, or hand-off in another system.
- It feeds an analytics or ML model.
This is the layer that determines whether your programme is observed or operational. An observed programme has dashboards everyone admires for the first week. An operational programme has the location signal driving ServiceNow incidents, CMMS work orders, nurse-call escalations, andon, MES interlocks, and HR exception reports.
The technical bar for the integration is low — webhooks, REST calls, message queues. The hard part is institutional: the operations team has to trust the source of truth enough to act on it. The way you earn that trust is by getting layers 1–3 right.
Layer 5 — Learning
The last layer is the one that compounds. Every business event is logged. Every derived state is logged. Over weeks and months you accumulate a time-series of what your operation actually does — not what it says it does on the SOP.
That data feeds three kinds of model:
- Anomaly detection. What's a normal dwell, normal flow, normal cycle? Surface deviations before they hit a KPI report.
- Predictive. Combine location with vibration / thermal / sensor data to predict equipment failure 1–12 weeks out.
- Simulation / digital twin. Use the recorded movement history as input to "what if we move this assembly cell?" / "what if we open a new ED bay?" / "what if we re-route this AGV?" type questions.
This is also where LLM-powered operations copilots become useful: when a senior nurse, line lead, or facilities manager can ask "where was the gauge last calibrated, and by whom?" and get an evidenced answer from the spatial event history, you've moved past dashboards into something fundamentally new.
The sequencing trap
The single most common failure mode in enterprise RTLS deployments is trying to do layer 5 before layer 3 is real. Vendors will sell you the digital-twin module before your business-event layer exists. The simulation is then running on artefacts of an under-engineered middle layer, and nobody trusts the output.
Sequence: get layer 1 vendor-neutral and stable. Get layer 2 instrumented and validated. Spend time on layer 3 with the operational team that has to use it. Then open layer 4 (decisions / alerts) and only after those have run for 60–90 days, open layer 5 (analytics / ML).
What this means for procurement
If you are buying an RTLS platform, ask the vendor three questions:
- "Show me the event schema and what derived states the platform produces out of the box."
- "What's the integration pattern with ServiceNow / Epic / SAP / your-MES-here?"
- "Can I export the full event history at any time in a vendor-neutral format?"
If the answer to any of those is hand-wavy, the platform is selling you layer 1. The ROI lives in 3 and 4. Optimise for those.
Want a working version of this for your programme? We build the event-schema, derived-state, and business-event layers as a fixed-fee package.