FIG. 4 — 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. The part that matters: when a natural-gas facility raises a critical alarm, it calls a human, describes the condition out loud, and records the verbal acknowledgment.
- Status
- Deployed · 76 commits
- Context
- 2026 · Independent work
- Role
- Sole designer & engineer
- Code
- Private — on request
Nova is a backend system — there's no screen to screenshot. The call path drawn instead: a critical alarm flows through the fingerprint-throttled monitor into the voice bridge's transcribe-reason-speak loop. During the call the bridge makes MCP tool calls — PI historian, SCADA, SOP library, route/GIS — so the assistant speaks with live plant context, reaches the on-call human by voice and SMS, and the acknowledgment lands in the audit record.
The problem
Alarm systems assume someone is watching a screen. At three in the morning, across a distributed gathering system, that's a big assumption.
The escalation path that reliably reaches a person is a phone call. But a call needs someone to place it, describe the condition accurately, and log the acknowledgment, and that's exactly the sequence that degrades under fatigue and alarm volume.
I wanted to know whether the alarm system could place the call itself, hold a real conversation about the condition, and produce an acknowledgment record that stands up to review.
How it works
- 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
Waiting for the whole turn
Finalized transcript fragments are aggregated into complete caller turns before a response is generated. Reply to every partial fragment and you get an assistant that talks over people, and on a real alarm call the person just hangs up.
- 03
Barge-in, measured
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. It reasons about estimated audio playback time, since text can finish streaming while audio is still playing, and it reports barge-in count and stale-responses-skipped as per-call metrics.
- 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 throttle comes straight from alarm management — the same thinking that keeps a control room from being buried by a chattering point.
- 05
Tools on the line
The assistant doesn't just talk — it consults. MCP tool servers give it live plant context during the call: PI historian trends, SCADA state, the standard-operating-procedure library, and route optimization for getting the right person moving toward the site. Alongside voice, an SMS channel carries what's better read than heard — tag values, directions, procedure steps.
- 06
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.
General note
An alarm that depends on someone looking at a screen has a single point of failure, and the failure is human attention.
Why it matters
It exists because of a real failure mode in distributed operations: the alarm nobody happens to be looking at.
Verbal acknowledgment produces an audit record, which is what a compliance review of alarm response will ask about.
Turn detection and barge-in handling are what make a voice system tolerable at 3 a.m. A demo in a quiet room tests neither.
It's deployed and running.
Stack
- 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