A phone line that calls you about a critical alarm and takes your acknowledgment
Nova — Alarm Voice Bridge
A real-time voice assistant that answers phone calls, transcribes live, and responds conversationally — and, more to the point, proactively calls a human when a natural-gas facility raises a critical alarm, describes the condition out loud, and records the verbal acknowledgment.
- Status
- Deployed · 76 commits
- Context
- 2026 · Independent work
- Role
- Sole designer & engineer
- Code
- Private — available on request
Alarm systems assume someone is watching a screen. At three in the morning, across a distributed gathering system, that assumption is doing an enormous amount of unexamined work.
The escalation path that reliably reaches a person is a phone call. But a call requires someone to place it, describe the condition accurately, and log the acknowledgment — exactly the sequence that degrades under fatigue and alarm volume, which is precisely when it matters most.
So the question worth answering is whether the alarm system can place the call itself, hold a real conversation about the condition, and produce an acknowledgment record that stands up to review.
- 01
Live audio in, live audio out
A Twilio Media Streams WebSocket feeds live call audio to Deepgram for streaming transcription; responses come back through an LLM and ElevenLabs, encoded to Twilio-compatible μ-law and pushed back down the same socket. Every call carries its own session state.
- 02
Turn detection, not fragment chasing
Finalized transcript fragments are aggregated into complete caller turns before a response is generated. Replying to every partial fragment produces an assistant that talks over people — which on a real alarm call is worse than useless, because the human hangs up.
- 03
Barge-in as measurable behavior
If the caller starts speaking while a response is still generating or playing, the bridge issues a Twilio clear event, invalidates the in-flight response, and keeps only the latest turn. Crucially it reasons about estimated audio playback time rather than merely whether text is still streaming — and exposes barge-in count and stale-responses-skipped as per-call metrics rather than a boolean.
- 04
The alarm monitor
A monitor polls a natural-gas facility MCP server for critical alarms, places an outbound call per new alarm with cooldown throttling keyed on alarm fingerprint, and walks the callee through a verbal acknowledgment flow. Alarm context rides along as Twilio stream parameters so the assistant knows what it called about. The fingerprint-based throttle is an alarm-management instinct rather than a software one — the same reasoning that keeps a control room from being buried by a chattering point.
- 05
Operational plumbing
Provider adapters isolate speech-to-text, text-to-speech, LLM, and MCP behind common interfaces. Runtime thresholds and toggles persist to Postgres so dashboard changes survive redeploys. A LAN-only admin dashboard proxies the bridge's admin API so the admin token never reaches a browser.
Design principle
“An alarm that depends on someone looking at a screen has a single point of failure, and the failure is human attention.”
It addresses a real failure mode in distributed operations — the alarm nobody happens to be looking at — rather than a hypothetical one.
Verbal acknowledgment produces an audit record, which is the part any compliance conversation about alarm response actually cares about.
Turn detection and barge-in handling are what separate a voice system a person will tolerate at 3 a.m. from a demo that impresses in a quiet room.
It is deployed and running, not a local prototype.
- Telephony
- Twilio Media Streamsμ-law audioWebSockets
- Speech
- Deepgram STTElevenLabs TTS
- Models
- OpenAI gpt-4o-miniMCP SDK client
- Service
- Node.jsExpressPostgreSQL
- Deployment
- RailwaysystemdLAN admin dashboard
Want the architecture in more depth, or a walk through the code? I'm glad to go there.
Get in touch