- Entry date
- 1 November 2025
- Category
- Tooling
- Lead over the world
- the proof, not the lead
- Access
- 🔓 Public
Eleven microservices, two hundred-plus endpoints, MQTT under the hood — proof that AI-assisted development can produce safety-critical software at real enterprise scale, not just prototypes.
- 11
- microservices
- 200+
- REST endpoints
- 500+
- pages of documentation
- 95%+
- test coverage (the team's own measured figure)
Honest evaluation
Production-ready and deployed at real enterprise scale; the 95%+ coverage figure is the team's own self-measured number, not an independent audit — stated as such.
What would prove or disprove it further
What would prove or disprove it further: an independent audit of the test-coverage figure, or a measured incident/uptime record from live operation over time, would either confirm or puncture the self-measured claim without touching the underlying architecture decision.
The evidence — full reasoning behind the verdict
Verdict: proven. The claim under test was whether AI-assisted development could produce genuinely enterprise-grade, safety-critical software rather than a polished prototype — and an 11-microservice, 200+ endpoint control centre, production-ready and deployed, is real evidence for that, not an aspiration.
The mechanism matters as much as the scale: MQTT was chosen over a REST-only design specifically because the real-time train-communications layer needed a latency and reliability profile REST alone doesn't offer. That's an architectural decision made correctly ahead of time, not a retrofit — and it's the kind of detail that separates a system built to actually run a control room from one that merely demos like it could.
One figure needs a caveat rather than a discount: "95%+ test coverage" is the team's own measured number, reported honestly here as self-measured rather than independently audited. That doesn't unmake the verdict — the system is deployed and production-ready regardless of who measured the coverage — but it's worth naming plainly rather than letting a precise-looking number imply third-party certification it doesn't have.
Runnable proof — see it work
Most of what "AI-assisted development" produces in a portfolio like this is a working prototype or a solid utility. This one is different: it's the system we'd point to first if asked whether the approach scales to genuinely enterprise, safety-critical software.
This report covers a centralised operations control centre for metro PA and PIDS, built for a global rail & metro operator (client identity withheld, per our no-client-names policy).
What it was
A centralised operations control centre for metro-train PA (Public Address) announcements and PIDS (Passenger Information Display System) management — the kind of system a control room actually runs on, not a demo of one.
What we built
Shipped & measuredEleven microservices, over 200 REST endpoints, built on Python 3.11+ and FastAPI with a React 18 frontend. Real-time train communications ran over MQTT (via EMQX) rather than REST alone — a lightweight publish/subscribe protocol built for exactly this latency and reliability profile, which a general-purpose REST design would not have met. PostgreSQL and Redis rounded out the data and caching layers, all containerised with Docker. The team's own documentation runs past 500 pages, with self-measured test coverage above 95%.
What we learned — including the honest negative
The headline lesson is the scale itself: this is real evidence that AI-assisted development can produce enterprise-grade, safety-critical software — not just a prototype that looks the part. The architectural decision that mattered most was picking MQTT for the real-time layer early; retrofitting a pub/sub protocol under a REST-only design after the fact would have been far more expensive than choosing correctly at the start.
Where it went / status
Production-ready and deployed, the strongest single proof point in the portfolio's rail-domain thread — which runs from an early 2022 tender-quoting prototype, through a 2023 light-rail PA/PIDS control frontend, through this system, and on into further passenger-information design work the same year.
What is still open — kept visible
The honest edges, next to the wins. This is what turns 🔬 into 🟢 — honestly.
- "95%+ test coverage" and "production-ready" are the team's own status claims, measured internally — not an independently audited certification, and this report doesn't pretend otherwise.
- A general-purpose REST-only design would not have met the real-time latency bar; MQTT was architecturally load-bearing, not incidental.
Proofs & sparks
We demonstrate rather than assert. Each ✅ proof is a visible result with a hard figure.
- The safety-critical / SIL4 lineagedesigned, unprovenseven safety-critical / SIL4 / DO-178C claims underlying real rail-and-metro delivery — recorded "designed, unproven" pending the stability gate; client identity redacted.
- Certifiable by construction — "Certifiable by construction" is a headline pillar, not a footnote — the bridge from the helpful-lab present to a frontier future, built on real safety-critical rail-and-metro delivery history.
Sources
- vocabotics project audit — rail PA/PIDS platform (11 microservices, MQTT), Nov 2025vocabotics internal project history · as of November 2025