Demonstration Project — prototype, pre-deployment
Chamber I · Opening
RingHarbor
A safety-first AI receptionist designed for HVAC and home-service companies — every missed call is a leaked job, and this system is engineered to catch them without ever giving dangerous advice. No live deployment yet; no real calls handled.
Chamber II · The problem
The starting point
Small trade shops — two to ten trucks — miss after-hours and overflow calls, and most callers who reach voicemail never call back.
An AI answering service for this niche has a hard constraint most chatbot projects don't: a caller might be reporting a gas leak. The design must be safe before it is clever.
Chamber III · The intelligence
What was designed and built
- Voice-agent configuration for a managed voice-AI platform: a complete call-flow state machine — greet → identify need → triage → route to book / transfer / message / emergency / decline → confirm → close → post-call — with an HVAC emergency triage tree.
- Verbatim safety scripts: gas leak means "leave the house right now," carbon monoxide means 911 — and the agent never improvises safety advice beyond approved scripts.
- Guardrails as code — seven non-overridable hard rules: mandatory AI disclosure on every call, never quote prices absent from config, never invent calendar availability, digit-by-digit callback-number confirmation, never take payment, owner notified within 60 seconds of any emergency classification.
- Deploy tooling with a validation gate: an idempotent, zero-dependency Node deploy script that creates-or-updates the agent and refuses to deploy unless the disclosure line, safety scripts, price guard, and data rules are all present in the config. The gate passes — verified by dry-run 2026-07-10.
- Layered architecture: a vertical-agnostic core call flow + a swappable industry module (HVAC first; plumbing and electrical next) + per-customer YAML config. New trade, new module; new customer, new config file.
- Production landing page: a fast, accessible, zero-dependency static site — light/dark, reduced-motion support, security headers — ready for edge deployment.
- A 20-case scripted call test grid, including 5 safety cases, with a regression rule: any prompt change requires a full re-run, and every future production error becomes a new test case.
Chamber III · The method
How it was built
The governing decision was to encode "do no harm" into the architecture rather than hoping the model behaves. Safety rules are machine-checkable at deploy time — configuration that omits them cannot ship, by construction.
Multi-trade reuse was designed in from day one: the core call flow knows nothing about HVAC; the industry module does. That separation is what makes the second vertical a module, not a rewrite.
Chamber IV · The evidence
Craft evidence
Real artifacts from the prototype — the service has handled no real calls, and nothing below implies otherwise.
Verified, not claimed
- Seven non-overridable hard rules — guardrails as code, enforced at deploy time rather than left to the model.
- Deploy gate verified passing — the safety gate refuses to ship config missing the disclosure line, safety scripts, price guard, or data rules; passed by dry-run 2026-07-10.
- 20-case scripted call test grid — including 5 safety cases, with a regression rule requiring a full re-run on any prompt change.
- Zero external dependencies — both the Node deploy script and the static landing page are self-contained.
Chamber V · Future vision
Where this is heading.
Future Vision · Concept RingHarbor is designed to grow beyond HVAC — the same safety-gated core answering for plumbing, electrical, and other trades as swappable modules, with each shop's receptionist provisioned from a single config file over its own line and calendar. This is a concept of the direction we are building toward, not a live service. It carries no metrics and no real-call outcomes, because the prototype has handled no real calls and there are none to claim yet.
Chamber VI · The foundation
What's measured next
Prototype, pre-deployment. The design, configuration, validation tooling, and landing page are complete; the service has not gone live and has handled no real calls. The call test grid is human-scripted, not automated. Call outcomes become this entry's numbers only after a real deployment produces them.
Want a receptionist that never sleeps — and never improvises safety advice?
This build maps to our Systems cluster — call flows designed around your real emergency cases, guardrails enforced in code, and a test grid you can hear working before a single customer calls. The AI Opportunity Diagnostic scores your after-hours response alongside eight other areas — and will tell you honestly whether an AI receptionist is even the right first purchase.