QDat.io is one thing wearing a four-word name. Every read, every event, every sensor sample is anchored to a When, a What, and a Where — and kept as history, not overwritten as state. On top of that memory sits an API-first, agent-ready surface: everything the platform can do is reachable over a documented REST API and a native MCP server. Systems integrate through one; agents reason and act through the other; both read the same source of truth.
The name is not marketing. It is a build order. Read it left to right — Spatiotemporal, then Intelligence, then Automation, then Plane — and it describes, in sequence, what has to be true before the next word is even possible.
01
Spatiotemporal — every fact carries a time and a place.
Most operational data records what, and maybe how much. The plane refuses to store a fact without also storing when it was observed and where. A tag read, a temperature sample, an ERP posting, an operator action — each becomes an event stamped with a millisecond timestamp and a physical position: GPS inherited from the reader, a portal ID, a known station. And it is kept. The plane holds the full history of a Thing, not just its last known state, so any actor can ask where a Thing has been — not only where it is right now. When and Where are the two coordinates most systems throw away; here they are the primary key.
02
Intelligence — reconciled truth, not raw telemetry.
Raw reads are not intelligence. The plane verifies every event — time-stamped validation rules, confidence scoring, tamper-evident and cryptographically signed records in an immutable audit log — then reconciles that ground truth against ERP, WMS, and planning systems to surface drift before it compounds across handoffs and sites. The output is a per-Thing truth an operator, an auditor, or a model can trust: what actually happened, where and when, with the provenance to prove it. Every decision made on that truth becomes training data for the next one.
03
Automation — the loop closes without a human in it.
Once truth is spatiotemporal and reconciled, action can be automatic. The plane scores, alarms, and triggers workflows and API callbacks in time — when a threshold is crossed, an excursion begins, or a Thing arrives where and when it should not. Robots, machines, and agents subscribe and act on their own; humans are pulled in only where judgement is genuinely required. This is the point the name builds toward: automation that runs on proven physical reality instead of stale records and assumptions.
04
Plane — one horizontal layer under every actor.
A plane is not an app and not a dashboard. It is a horizontal layer that sits under everything acting on your Things and speaks to all of them through one interface. It has no preferred actor: software or steel, autonomous or operator-driven, an LLM agent or a forklift — each talks to the same Thing through the same spatiotemporal surface. Add a new system, a new robot, a new copilot, and it plugs into the plane; it does not get its own private, divergent copy of reality. One memory of truth, many consumers.
API-first
API-first is not a feature. It is how the whole thing is built.
The rule at QDat.io is simple: if the platform can do it, the public API can do it. The Desktop Dashboard is the proof — it reaches near-parity with the web dashboard, and 100% of what it shows and does rides on the same documented REST API that is published to every customer. Nothing is reachable through a private back door.
That has a direct consequence for integration. If you can see it in the QDat.io web dashboard, and you can see it in the desktop app, then the same view and the same action can be brought into any WMS, ERP, MES, or BI tool — because they are all consuming the same OpenAPI-described endpoints. The interface is authenticated, paginated, versioned, and generated from the live OpenAPI specification, so the reference never drifts from what the server actually does.
One surface for everything — no capability is hidden behind a private endpoint the public API cannot reach.
OpenAPI-described, versioned, and paginated — wire it in once; consume Things, events, and locations like any other resource.
The reference is generated from the live spec, so the documentation cannot drift from the running server.
The MCP interface — the same plane, exposed to agents.
Model Context Protocol is the open standard for connecting AI agents to data sources. QDat.io exposes a native MCP server alongside the REST API, over the same spatiotemporal data and the same authentication. An MCP-aware agent — Claude, Cursor, Copilot, any of them — can read a NuroVault's temperature log, query active alerts, fetch recent organization-level activity, and reason over a Thing's full history without anyone writing a custom integration first. The agent does not scrape a UI or learn a bespoke schema; it speaks MCP to a server that already knows every Thing.
In a real session an operator can ask, in plain language, for every out-of-range temperature interval on a single tag over the last six hours — in Eastern time, with the total time above 8 °C summed up — and the agent calls the MCP server, pulls the full reading set, groups the intervals, and answers in one turn. REST remains the recommended surface for systems integration; MCP is the recommended surface for agents and copilots; both read from the same source of truth.
Two interfaces, one plane
Systems on REST, agents on MCP — one truth underneath.
The same spatiotemporal data — Things, sensors, events, alerts, locations, history — is exposed through two equivalent surfaces. Pick whichever fits the consumer. Back-office systems and AI agents read from the same source of truth, with the same authentication and the same per-Thing history; neither gets a privileged or a degraded view.
RESTful API
OpenAPI-described endpoints for ERP, WMS, MES, BI, and any system that already speaks HTTP. Authenticated, paginated, and versioned — wire it in once and your stack consumes Things, events, and locations like any other resource.
MCP server
A native Model Context Protocol interface so Claude, Cursor, Copilot, and any MCP-aware agent can read sensors, query alerts, and reason over Thing-level history without writing a custom integration. Agentic workflows plug in directly.
No preferred actor
Agents, Robots, Machines, and Humans — on one plane.
Whatever is acting on a Thing talks to it through the same spatiotemporal interface, exposed equivalently as a RESTful API for systems and as an MCP server for agents. The plane does not care whether the consumer is an algorithm or a person.
Agents
LLM agents, copilots, and orchestration logic query the plane over REST and MCP for the live state of each Thing — identity, location, history, current alarms — and write decisions back.
Robots
AMRs, pickers, drones, and arms subscribe to spatiotemporal events to know what Thing they are facing, where it has been, and whether it is in spec before they grasp, move, or sort it.
Machines
Production lines, scanners, printers, conveyors, and refrigeration equipment publish state changes and consume per-Thing context, closing the loop between automation hardware and the items it processes.
Humans
Operators, drivers, technicians, and inspectors meet the plane through handheld reader clients (QDatDroid) and dashboards. They see the same Thing-level history the agents and robots see.
Inside the plane
Four layers, from the edge to the decision.
Capture
Secure connectors for sensors, ERP feeds, RFID/NFC scans, and operator events, with edge-to-cloud ingestion, automatic schema detection, and buffered delivery so nothing is lost when a device goes offline.
Verification
Time-stamped validation rules, confidence scoring, and tamper-evident records. Every event is cryptographically signed and stored in an immutable audit log.
Action
Trigger workflows, alerts, and API callbacks when thresholds or anomalies are detected, closing the loop between the physical world and downstream systems.
Spatiotemporal storage
Every reading carries time and place, and the full history is retained, so you can query what happened, where, and when across the whole fleet — not just the last ping.
Fixed-reader deployments
Fixed RFID readers, unattended at every chokepoint.
The plane does not require a person holding a handheld. QDat.io fully supports deployments built on fixed RAIN UHF readers — the Zebra FX9600 and FX7500 — through QDatFX, a reader client that runs as an application directly on the reader itself. Mounted over a dock door, a conveyor, a packing line, or a portal, a fixed reader interrogates every tag that passes and turns each read into a spatiotemporal event with no operator in the loop. Where a handheld inherits GPS at the moment of the scan, a fixed reader anchors the Where to a surveyed, known position — the station is the location — so continuous, hands-free capture streams into the same plane the mobile fleet feeds.
Zebra FX9600
QDatFX runs on the reader
QDatFX runs on-device on the Zebra FX9600 and FX7500 fixed readers — the same arming and reading workflows as the handheld QDatDroid client, in a fixed footprint. There is no PC or middleware box beside the reader: the reader itself is the edge node.
Unattended capture at chokepoints
Mounted at dock doors, packing lines, conveyors, and portals, a fixed reader reads every RAIN UHF tag in its field continuously — pulling a NuroVault's full temperature log, or just its alarm flag, wirelessly, without anyone pulling a trigger.
WSS MQTT into the plane
The reader client wraps each raw RFID exchange into structured stream messages and publishes them to QDat.io over MQTT on secure WebSockets — TLS-encrypted, NAT-friendly, and resilient to intermittent links. The broker writes time-series storage, fires alarm and exception workflows, and exposes it all through the same REST and MCP surfaces.
Where = the reader station
A fixed reader's position is surveyed once and known forever, so its reads anchor the Where to a precise station rather than an inherited GPS fix. Fixed and mobile capture land in one plane: portals and dock doors give continuous coverage; handhelds and phones fill in everywhere a reader is not.
A fixed reader owns its chokepoint and never leaves it. But not everything comes to a chokepoint — so the plane also reads on the move.
Portable-reader deployments
Portable RFID readers, capture in motion.
Where a fixed reader waits at a chokepoint, a portable reader goes to the Thing. QDatDroid is QDat.io's Android reader client: it turns any RAIN RFID handheld — a Zebra RFD40 sled, an MC33xR, a TC53e, a TC22R, an EM45 phone — into a fully-paired reader on the plane. An operator pulls the trigger, and QDatDroid reads the tag over UHF RAIN and NFC, configures and arms sensors, captures a GPS-stamped spatiotemporal event, and publishes it live to QDat.io over MQTT — online or offline. Where a fixed reader anchors the Where to a surveyed station, a handheld inherits GPS at the instant of the scan, so location travels with the operator across the yard, the dock, and the field.
QDatDroid
QDatDroid on any Android reader
QDatDroid runs across the full Zebra range with native RFID SDK support — RFD40 / RFD40 Premium / RFD90 sleds and MC33xR / TC53e / TC22R / EM45 / WS50 handhelds. The same arming and reading workflows as QDatFX on the fixed readers, now in the operator's hand.
Multi-protocol reads, on the move
Long-range, high-throughput UHF RAIN for sweeping a whole field of tags, plus built-in NFC for close-range interactions and provisioning. A live signal meter with a peak marker that never falls back helps an operator home in on any single tag, instantly.
Where = inherited GPS
The handheld stamps every read with GPS coordinates at the moment of the scan, so the Where travels with the operator — the mobile complement to the fixed reader's surveyed station. Space, usually the missing field in operational data, becomes part of every record.
Live MQTT, online or offline
QDatDroid streams every event to QDat.io over MQTT on public or private 5G; when the link drops, scans queue in an encrypted offline cache and sync when connectivity returns — the same WSS MQTT wire format QDatFX uses at the portal.
Fixed and mobile are not two architectures — they are two ways of feeding one plane. QDatFX at the portal and QDatDroid in the hand publish the same structured events, over the same WSS MQTT wire format, into the same When / What / Where history.
Multimodal capture
Visual identifiers: one Thing shows all its faces at once.
A Thing has more than one name. There is the RFID tag tucked inside the carton, the barcode or QR Code printed on the label, and the simplest answer of all — what it looks like, the photograph the eye takes the instant it sees it. A barcode names a kind of thing; an RFID tag names this specific thing; a photograph shows its condition — sealed or torn, full or empty, pristine or dented. None of those, alone, is the whole truth. On a Zebra TC22R or a Dragonwing TC501, a single pull of the scan trigger captures all of them at once — the picture, the 1D/2D code, and the RFID — bound together, stamped with the same GPS coordinates and the same millisecond time, because they happened in the same instant. The plane ingests that as one unified record: one identity with several personalities, a far better source of truth than any single mode could be on its own.
Visual identifiers, read in the same pass
The imager does not just read a barcode — it decodes the 1D or 2D symbol (barcode, QR Code, Data Matrix) and photographs the product at the very same time, on the same item. Visual identity and radio identity are captured in one action, not stitched together later from three passes and three timestamps.
The picture travels inside the scan
The photograph is not an attachment filed away in another system. It rides inside the scan itself as a small, low-resolution payload — so there is no separate upload, no cloud login at the edge, no half-captured record waiting on a flaky link. Condition becomes part of the identity.
One identity, several personalities
Barcode, RFID, and appearance arrive fused into a single record — what it is, which one it is, where and when you met it, and what it looked like when you did. Query it later and you do not get 'a barcode scan' or 'an RFID read' — you get the Thing.
Ingested live over MQTT
The whole bundle — identity, barcode, RFID, the When / What / Where stamp, and the picture — lands in QDat.io as a single live MQTT message, and is exposed through the same REST and MCP surfaces as every other event on the plane.
This is what ingesting multimodal information means in practice: the plane does not care whether a Thing announces itself by radio, by printed code, or by sight — it captures every face it shows and reconciles them into one truth. QSeq mints those identities correct by construction, EcoCir prints them sustainably, and QDat.io resolves and remembers them — across RAIN, NFC, QR, and 1D/2D codes alike.
Next
See the plane against your own operation.
Bring your asset flows, your system stack, and the decisions that keep arriving too late. We will map where a spatiotemporal, API-first, agent-ready plane fits — and instrument one workflow end to end: When, What, Where, and condition.
