One shared source of truth, and the services that act on it.

VDA 5050 connector & warehouse simulator

The data has to come from somewhere. yantrabridge consumes VDA 5050 v2.1 state messages — live from MQTT, or replayed from a JSONL recording — and translates them into the shared schema: a robots row per vehicle (upserted), alerts rows derived from the message's errors[] array and from low battery, and a connector heartbeat so the console can tell the difference between "no robots" and "nothing is feeding me". Writes are retry-safe by construction: the robot upsert merges duplicates and the alert insert ignores them.

It also imports recordings you already have (JSONL, or MCAP with the optional extra), so a fleet's historical data can be loaded into the platform rather than starting from an empty table.

When there are no robots to hand, the bundled deterministic simulator (yantrasim) publishes the same VDA 5050 traffic for a 10-robot fleet across 3 simulated vendors on an 8×5 warehouse grid — which is what makes the three-command quickstart, the demo sandbox and the test suites possible without hardware.

---

Live fleet console

A single-file web console (console/index.html, no build step) with a live map, per-robot detail panel, an alerts feed, an incidents view with recorded-telemetry replay, a mission board, and a command palette. It's what an operator watches all day — and it's exactly one static HTML file you can open directly or serve from any web server.

---

Human-in-the-loop command approval

Robot commands — pause, send-to-charge, e-stop — never execute directly from the console. They're inserted as pending rows in a commands table. An operator with the right role approves or rejects each one from an "Pending approvals" queue, and the simulator (or a real robot connector) only acts once a command is approved. Every request records who asked, and every decision records who decided and when — a full audit trail, not a fire-and-forget button.

---

Automatic incident detection

The detector (detector/, package yantradetect) polls the robots table and maintains an incidents table using patterns borrowed from production alerting systems:

• PagerDuty-style dedup — one open incident per robot, with deterministic INC-XXXX ids so a retried write is idempotent rather than creating a duplicate.
• Prometheus-style pending/clear windows — a fault has to persist before an incident opens, and clear before it resolves, so single noisy samples don't flap the incident list.
• Flap-window re-opening — a robot that clears and re-faults quickly re-opens the same incident with a flap count instead of spawning a new one.
• Stale auto-resolve — incidents with no corroborating signal for long enough close themselves.

Recorded telemetry around an incident can be replayed in the console — map, scrubber, and charts driven from the robot's actual samples at that time, not a scripted demo.

---

Predictive maintenance

The detector's maintenance mode (--maintenance) reads a rolling robot_telemetry window per robot and runs three independent heuristics:

Each finding carries a human-readable explanation, an estimated remaining-useful-life, and a confidence score — and clears itself (rather than silently vanishing) once the underlying trend resolves.

---

Real alert delivery

The notifier (notifier/, package yantranotify) polls unacknowledged critical/serious alerts and open incidents and pushes them out through the console, a generic webhook, or WhatsApp (via Twilio) — with per-event dedup so the same event doesn't spam a channel repeatedly.

---

Sarathi, the AI copilot

Ask questions about your fleet in plain language. Sarathi answers are grounded in your fleet's live data with cited sources, and degrade gracefully through tiers: grounded (LLM plus live tool calls) → llm_only → offline (template-based answers, no LLM key required at all). It always works — it just gets smarter with a key.

---

Role-based access control

Yantrika ships demo-open by default (one shared key, zero setup) so you can evaluate it immediately. For production, an opt-in migration enables full RBAC: four hierarchical roles, scoped per site, enforced in Postgres itself — not just in application code.

Command approval, in particular, goes through a dedicated SECURITY DEFINER database function rather than a direct table write — a hand-crafted API request can't bypass it. See Security and docs/SECURITY.md for the full model, including exactly which enforcement is done in the database versus the application layer.

---

VDA 5050 conformance tester

Speaking an open protocol only helps if the vehicles on your floor actually implement it. yantra-conform is a standalone command-line tester that points at your MQTT broker, watches your vehicles, sends them the standard commands the specification requires them to answer, and writes a graded HTML report across 52 checks covering connection, state, orders, action states, instant actions, the factsheet, the visualization topic and protocol hygiene.

Every finding names the clause, what the specification expects, what your vehicle actually did (with counts and examples), and what to change in the firmware — so the report is forwardable to a vendor rather than just a red label. --passive publishes nothing at all, for grading a fleet you do not own; --capture records a session as plain JSON that anyone can replay offline with no broker, which is the path for the common case where nobody can grant an outsider access to production MQTT.

It is free, MIT licensed, needs no account, and does not require Yantrika itself to be running. It has 188 tests of its own, including a meta-test that fails the build if a check is ever added without a case that makes it fail on purpose.

What it tests, how to run it, and what the report gives you →

---

Operator academy

A single-file learning app (academy/index.html, same zero-build philosophy as the console) that teaches fleet operation against a live fleet rather than screenshots. Lessons, a searchable rail, printable single-lesson views, and practicals and checkrides whose "Verify" step is checked against the actual backend — so passing means you really did the thing, not that you clicked "next". It falls back to an embedded starter pack when opened with no backend, so it works offline too.

---

Zero-signup live demo

A deployment can offer visitors a real fleet with no account, no email and no form. One POST to a small loopback-bound HTTP door mints a throwaway sandbox — its own site id, its own small simulated fleet, its own expiry — and redirects straight into the console. It reads nothing from the request: TTL, fleet size and site id are operator configuration, so a caller cannot aim a mint at somebody else's data. Sandboxes are confined by row-level security, expire on their own, and are purged (database rows and simulator processes) by a systemd timer.

It is off by default and stays off until an operator deliberately applies the migration that grants anonymous visitors that access — the whole thing is documented, with its threat model, in supabase/0009_demo_sandbox.sql and the two cloud deploy guides. On this site, it is the Try it button on the home page.