🔒 Restricted

This page is gated

The Vani OS technical architecture reference. If you're meant to see this, you already have the passphrase.

Vani OS · System Architecture Reference

What happens between a call ringing and a fee accruing

Every voice call and WhatsApp message a prospect sends runs through the same guarded, auditable path before it ever touches a rupee of outcome fee. This is that path in full — plain language, the real technical sequence, the engine underneath it, and the two ways it can be deployed.

01

The flow, as the room sees it

Six stages. Every real conversation — voice or WhatsApp — passes through all six before it can affect an invoice. No stage is skippable, and none of them depend on the AI's own word for it.

Prospect reaches out call or WhatsApp, any time Vani OS responds qualifies, answers, in their language Guardrails hold the line no invented promises, sensitive topics → human Outcome is verified checked against your own systems, not claimed Fee applies to the increment only nothing charged for what would've enrolled anyway You see it live dashboard + full audit trail, real time 01 02 03 04 05 06
01
Prospect reaches out
A student or parent calls the admissions line, or messages on WhatsApp. There's no "office hours" — the same AI counsellor is available whenever the inquiry actually happens, which is when interest is highest and most likely to be lost to a competitor if nobody answers.
02
Vani OS responds
The AI counsellor (Tara for campus programs, Lucy for the online-sales persona) picks up immediately, in whichever language the prospect opens with — English or Hinglish today, with the same architecture supporting more Indian languages. It asks real qualifying questions and answers real ones about fees, programs, and eligibility.
03
Guardrails hold the line
Before any reply reaches the prospect, it's checked against a fixed set of category rules — no admission guarantees, no invented discounts or manufactured urgency, no advice on financial aid or anything involving a minor without a human in the loop. These are deterministic phrase-matched gates, not the model being asked nicely to behave — they fire the same way every time, on every call.
04
Outcome is verified
When a lead actually enrolls, that fact is confirmed against your own CRM stage, payment gateway, or LMS — never against what the AI itself claimed happened on the call. The AI's transcript is evidence for context; your own system of record is the source of truth for billing.
05
Fee applies to the increment only
Every admissions cycle has a locked baseline — the admits you'd have gotten with no AI involved at all, based on your own prior-year numbers. Only enrollments above that baseline are fee-bearing. An admit that would have happened anyway never generates a line item.
06
You see it live
Leads received, calls made, handoffs, admits, fees accrued, and the running ROI multiple are all visible on a live dashboard the moment an event lands — not at the end of the cycle. Every number traces back to a signed, timestamped, append-only event row your finance team can audit directly.
Verified live, Aug 30 2026
1,500 admits reconciled
Incremental (fee-bearing)
1,000
Incremental revenue
₹17.5 Cr
ROI multiple
10.23×
02

The same six stages, as a sequence

Five actors, nine steps, left to right in call order, top to bottom in time — this is what actually crosses the wire for one conversation.

Every event that can accrue a fee is HMAC-SHA256 signed and replay-protected (10-minute freshness window) before it's ever accepted, and every write is append-only with a full JSON audit payload per row — nothing is ever silently edited.
Prospect Channel LiveKit / Baileys Vani OS Runtime CDL guardrail engine Sheets Backend webhook + ledger Dashboard 01 calls or messages 02 voice / text stream 03 CDL guardrail check category-matched hard gates — e.g. no admission guarantees 04 response, real time 05 reply delivered 06 canonical event HMAC-SHA256 signed POST 07 atomic dedupe + append check and write share one lock — no partial-overlap duplicate ✓ race condition fixed & verified live · Aug 30 08 priced by fee band flat / micro-outcome / % of tuition — skipped entirely if baseline-excluded 09 live recalculation
Steps 07 and 08 are the two most load-bearing for the commercial model: 07 guarantees no admit is ever counted twice, and 08 guarantees a fee only accrues on a real, priced, non-baseline event.
03

The engine underneath

Step 02 of the runtime, expanded — what "Vani OS Runtime" is actually built from, layer by layer, from the moment audio or text arrives to the moment a reply is spoken or typed back.

CHANNELS Voice — LiveKit WebRTC real-time audio, full-duplex, barge-in supported WhatsApp — Baileys bridge text, same guardrail + state machine as voice ORCHESTRATION Pipecat pipeline — voice-activity detection, turn-taking, interruption handling PERCEPTION Speech-to-text cloud (Sarvam) or self-hosted (Whisper / IndicWhisper, 22 Indian languages) — deployment-dependent, see §04 REASONING LLM local (Ollama) or cloud via LiteLLM proxy — deployment-dependent, see §04 CDL Guardrail Engine category-matched hard gates — every reply checked before it can leave this layer every LLM turn passes through the gate before speaking RESPONSE Text-to-speech (voice) / message send (WhatsApp) cloud TTS or self-hosted (Kokoro / IndicParler-TTS, 23 Indian languages) TELEMETRY & PRICING Sheets Backend canonicalevent → signed dedupe+ lock Event_Logappend price byfee band FeesLedger ✓ append-only · HMAC-SHA256 signed · every event auditable end to end VISIBILITY Live Dashboard leads, calls, handoffs, admits, fees, ROI multiple — recomputed the moment an event lands
Everything below the "Reasoning" layer is identical no matter how the call started — this is the same pipeline for a voice call and a WhatsApp message, which is why a hard gate that fires on a call fires the same way on chat.
04

Cloud or On-Prem — the same engine, two homes

The layered engine in §03 doesn't change. What changes is where each layer physically runs — and therefore who touches the audio and data, what it costs to stand up, and how fast it can go live.

MODE A

Cloud — managed

  • TransportLiveKit SFU on a GCP VM — needed because on-prem NAT/Docker networking can't reliably return WebRTC's UDP media traffic
  • STTSarvam (cloud API)
  • LLMOllama or a cloud model, routed via the LiteLLM proxy
  • TTSCloud TTS
  • HardwareNone — nothing for the institution to own or maintain
  • DataCall audio and transcripts touch Vani OS's managed cloud infrastructure
  • Go-liveFastest — this is what's running today for the pilot
MODE B

On-Prem — sovereign

  • TransportDirect PSTN via Plivo/Exotel, bidirectional WebSocket straight to the on-site server — no SFU dependency
  • STTSelf-hosted Whisper / IndicWhisper (AI4Bharat) — 22 Indian languages, on-GPU
  • LLMSelf-hosted, Unsloth-quantized (4-bit GGUF) model on owned hardware
  • TTSSelf-hosted Kokoro / IndicParler-TTS — 23 Indian languages
  • HardwareOne owned GPU server, sized to the seat count (see below)
  • DataNot a single byte of audio or transcript leaves the institution's own network
  • Go-liveSlower — hardware procurement + on-site setup before the first call
DimensionCloudOn-Prem
One-time hardware₹0~₹4–4.5L (RTX 4090 tower or equivalent, sized for a 10–12 seat closer floor)
Recurring AI computeCloud API / compute cost, scales with usage~₹0 — self-hosted inference
TelephonyBundled into the platform fee — pooled/shared capacityBilled directly to the institution, ~₹0.60–1.20/min via its own Plivo/Exotel account — raw telecom only, no AI processing leaves the site
WhatsApp Business AccountInstitution's own Meta Business/BSP account either way — ~₹0.11–0.86/message, typically ₹1K–10K/moSame — WABA verification is entity-specific, so this is never bundled behind the platform fee in either mode
Data residencyVani OS's managed cloudInstitution's own network, end to end
Setup timeDaysWeeks — hardware lead time + on-site install
Who maintains itVani OSInstitution's IT, with Vani OS supporting the software layer
Best fitFast pilot, no IT overhead, standard data-handling policyStrict data-sovereignty requirements, or a multi-year deployment where owning the hardware pays for itself
The setup fee and outcome-fee guarantee in §01 (fee only on the verified increment, §05) hold exactly the same way in both modes. What genuinely differs is who carries the recurring infrastructure cost: Cloud bundles telephony and compute into the platform fee via pooled/shared capacity across customers; On-Prem shifts hardware and telephony to the institution directly, which brings the platform fee down accordingly (scoped once hardware is quoted). See the Investment Brief for the exact numbers this implies.