Platform Master vs Production: Current State Gap Analysis

Enterprise Architect Advisory + Voice Agent Product Manager Insights

Date: February 18, 2026 | Classification: Internal Advisory

Scope: Comparison of VitaraVox-Platform-Master (reference implementation, GitHub dev branch) against vitara-platform (production deployment, v4.0.1) with Canadian healthcare compliance overlay

---

Executive Summary

The VitaraVox Platform Master repository represents a LangGraph-based reference implementation for voice-enabled healthcare appointment scheduling. The vitara-platform (production) has evolved significantly beyond the Master into a multi-tenant SaaS platform with enterprise security, PIPEDA compliance, and a Vapi-native squad architecture.

This analysis identifies 23 significant gaps across architecture, security, compliance, and operational readiness. The gaps fall into three categories:

Category	Critical	High	Medium	Low
Architecture & Integration	2	3	2	1
Security & Compliance	3	2	2	0
Operations & Productization	1	2	2	1
Total	6	7	6	2

Key Finding

Platform Master's WS-Security configuration (hasTimeStamp: true, hasNonce: true) will fail on real OSCAR CXF instances. Production discovered this the hard way and fixed it to hasTimeStamp: false, hasNonce: false. This is the single most critical integration bug in the Master codebase.

---

1. Architecture Comparison

1.1 Conversation Engine

Dimension	Platform Master	Production (v4.0.1)	Gap
Engine	LangGraph state machine (19 nodes)	Vapi-native squad (9 assistants)	Fundamental architecture difference
LLM Routing	LLM-based intent detection within graph nodes	Prompt-driven with handoff tools	Master is more deterministic
State Management	In-memory Map<callId, GraphState>	Vapi manages state; server is stateless per tool call	Master loses state on restart
Protocol	Custom LLM server (/v1/chat/completions)	Vapi webhook tool calls (/api/vapi/*)	Different integration paradigm
Multi-turn	Full conversation history in graph state	Vapi maintains conversation; tools are atomic	Production is more resilient

PLATFORM MASTER                          PRODUCTION (v4.0.1)
==================                       ===================

Patient Call                             Patient Call
    |                                        |
    v                                        v
[Vapi] --POST /v1/chat/completions-->    [Vapi Squad]
    |                                        |
    v                                   +---------+----------+
[Custom LLM Server]                     |         |          |
    |                                   v         v          v
    v                              [Router]  [Patient-ID] [Booking]
[LangGraph State Machine]              |         |          |
    |  19 nodes                        v         v          v
    |  Conditional edges          [Handoff tools connect agents]
    |  In-memory state                 |
    v                                  v
[EMR Client Dispatcher]           [Vapi Webhook Handler]
    |                                  |
    +--- SOAP ---+                     +--- BookingEngine ---+
    |            |                     |                     |
    v            v                     v                     v
[REST Bridge] [OSCAR SOAP]       [OscarSoapAdapter]  [OscarBridgeAdapter]

Product Manager Insight

The LangGraph approach in Platform Master offers superior debugging and visualization (LangGraph Studio), but the Vapi-native squad approach in production provides better latency, scalability, and vendor-managed conversation state. For a healthcare product where reliability matters more than LLM creativity, the production architecture is the correct choice.

1.2 Database & Multi-Tenancy

Dimension	Platform Master	Production	Gap Severity
Database	SQLite (file-based)	PostgreSQL 14+	CRITICAL
ORM	Prisma 5.22	Prisma (production schema)	Compatible
Multi-tenancy	None (single clinic)	Full multi-clinic with isolation	CRITICAL
Tables	7 (basic CRUD)	12+ (clinics, config, hours, holidays, providers, waitlist, call logs, audit logs, users, onboarding)	HIGH
Clinic Config	Hardcoded in .env	Per-clinic DB config with encrypted credentials	HIGH
User Management	None	JWT-based with roles (vitara_admin, clinic_manager)	HIGH

Platform Master Schema (7 tables):

CallerId, Patient, PatientAddress, PatientClinicalMeta,
Clinic, Provider, Appointment, AvailabilitySlot

Production Schema (12+ tables):

clinics, clinic_config, clinic_hours, clinic_holidays,
clinic_providers, waitlist_entries, call_logs, audit_logs,
users, onboarding_progress, processed_tool_calls + more

1.3 EMR Integration

Dimension	Platform Master	Production	Gap
SOAP WS-Security	hasTimeStamp: true, hasNonce: true	hasTimeStamp: false, hasNonce: false	CRITICAL BUG in Master
SOAP Timeout	30s (configurable)	4s circuit breaker (under Vapi's 5s limit)	Master will cause Vapi timeouts
WSDL Services	4 (Demographic, Booking, Schedule, Provider)	4 (same services, different implementation)	Aligned
Availability Calc	Simple template subtraction	BookingEngine with overlap detection, buffer time, ScheduleSettings	HIGH gap
Schedule Codes	Basic char conversion	Full NON_BOOKABLE_CODES filtering + configurable bookable codes	MEDIUM
Patient Creation	Via SOAP addDemographic (listed but OSCAR doesn't support it)	Correctly noted: OSCAR DemographicService has NO addDemographic	Master has a phantom capability
Provider Lookup	Direct getProvider(id)	getProviders2(true) + filter (OSCAR has no single-provider endpoint)	Master will fail
Credential Source	.env file only	Per-clinic encrypted DB credentials (AES-256-GCM) with env fallback	HIGH

WS-Security Configuration Mismatch

Platform Master uses:

new soap.WSSecurity(username, password, {
  hasNonce: true,
  hasTimeStamp: true,
  hasTokenCreated: true
})

Production discovered through testing that OSCAR CXF rejects <wsu:Timestamp> elements because CXF has no Timestamp action configured. The correct config is:

{ passwordType: 'PasswordText', mustUnderstand: true, hasTimeStamp: false, hasNonce: false }

Impact: Platform Master's SOAP calls will fail with SecurityError on any real OSCAR instance.

1.4 Booking Intelligence

Capability	Platform Master	Production
True Availability	Simple slot subtraction	Interval overlap detection with buffer times
BookingEngine	bookInHardcode.ts (hardcoded providerId=101)	booking.service.ts (669 lines of logic)
Slot Finding	Basic day iteration	Multi-provider search with preferences, time-of-day, exclusions
Race Prevention	None	Advisory locking, book-then-verify pattern
Reschedule	Direct update	Book-first-then-cancel (safer: patient keeps original if new booking fails)
ScheduleSettings	None	Full config: buffer time, advance booking limits, same-day rules, weekend rules, per-patient limits
Provider Matching	Hardcoded ID	Fuzzy name matching, specialty/language/gender filters

---

2. Security & Compliance Gap Analysis

2.1 Authentication & Authorization

Layer	Platform Master	Production	Risk
Webhook Auth	None (CORS allow-all)	HMAC-SHA256 + API key + Bearer token (3 methods)	CRITICAL
Admin Auth	None	JWT with refresh tokens, role-based access	CRITICAL
CORS	origin: true (allow all)	Restricted to https://dev.vitaravox.ca	HIGH
Rate Limiting	None	Per-route rate limiting (auth, webhook, API)	MEDIUM
Replay Protection	None	HMAC timestamp validation (5-min window)	HIGH
Timing Attack Prevention	None	crypto.timingSafeEqual() for signature comparison	MEDIUM

2.2 Data Protection

Control	Platform Master	Production	Gap
Credential Encryption	Plaintext in .env	AES-256-GCM (iv:authTag:ciphertext format)	CRITICAL
PHI Redaction	Optional (Resk library)	Built-in logger redaction for 15+ PHI field types	HIGH
Audit Logging	EMR call tracing (LangSmith)	Full PIPEDA 4.1.4 audit trail (user, action, resource, IP, details)	HIGH
Data Retention	None	Auto-deletion job (configurable per-clinic: 90d transcripts, 365d call logs)	HIGH
Prompt Injection	Optional Resk filter	Server-side input validation + Vapi prompt boundaries	MEDIUM

2.3 Canadian Healthcare Compliance

This section synthesizes compliance requirements from PHIPA (Ontario), PIPA (BC/Alberta), HIA (Alberta), and PIPEDA (Federal) against both codebases.

Requirement	Platform Master	Production	Compliance Status
Privacy Officer (PIPEDA 4.1.1)	Not implemented	privacyOfficerName/Email/Phone in ClinicConfig	Production: Compliant
Agent/DPA Agreements (PIPEDA 4.1.3)	Not implemented	baaVapiSigned, baaHostingSigned flags with onboarding check	Production: Tracked
Audit Trail (PIPEDA 4.1.4)	EMR call logging only	Full AuditLog table with middleware auto-capture	Production: Compliant
Data Retention (PIPEDA 4.5)	No policy	Configurable per-clinic, auto-deletion job	Production: Compliant
Safeguards (PIPEDA 4.7)	Optional Resk	AES-256-GCM, HMAC auth, TLS, PHI redaction	Production: Compliant
Pre-launch PIA	Not addressed	10-point onboarding validation (7 mandatory)	Production: Partially addressed
Consent Mechanism	Not implemented	Pre-call AI disclosure in Router firstMessage	Production: Basic
BC Data Residency	Not addressed	OCI Toronto (Canadian DC), but Vapi/Deepgram transit US	Both: Gap
Alberta Written Consent	Not implemented	Not explicitly implemented	Both: Gap

Cross-Border Data Flow Risk (Both Platforms)

Both platforms share a critical compliance gap: real-time patient voice data is processed through US-based services (Vapi, Deepgram, ElevenLabs). This creates issues for:

• BC clinics: PIPA-BC requires health records stored on Canadian databases. Real-time voice processing in the US may violate this.
• Alberta clinics: HIA requires written consent for collection by "devices not visible to the individual." Voice AI qualifies.
• All provinces: PIPEDA requires transparency about cross-border transfers. Privacy policies must disclose US processing.
• US CLOUD Act: All AI vendors are US-headquartered. Even Canadian-hosted data may be accessible to US authorities.

Mitigation (Production): Enable Vapi HIPAA mode (zero retention), use Azure OpenAI Canada Central for LLM, and disclose US voice processing in pre-call consent.

2.4 IPC Ontario AI Scribe Guidance (January 2026)

The IPC released "AI Scribes: Key Considerations for the Health Sector" on January 28, 2026. While focused on AI scribes, this is the closest regulatory guidance for voice AI processing PHI. Key requirements:

IPC Requirement	Platform Master	Production
PIA before deployment	Not addressed	Onboarding includes compliance checks, but formal PIA template not provided
Strong governance framework	Not addressed	Privacy officer, BAA tracking, audit trail
Vendor contracts (use restrictions, security, breach reporting, audit rights)	Not addressed	BAA/DPA tracking flags; template provided in archive
Audio deletion after purpose fulfilled	Not addressed	Data retention job (configurable)
Patient consent before AI interaction	Not addressed	Router firstMessage discloses AI; no explicit opt-out mechanism

---

3. Operations & Productization Gaps

3.1 Deployment & Infrastructure

Dimension	Platform Master	Production	Gap
Process Manager	Manual (npm run dev)	PM2 with auto-restart, memory limits, crash recovery	HIGH
Reverse Proxy	None	Caddy (TLS termination, HTTPS)	HIGH
Health Checks	None	/health endpoint (DB, OSCAR, Vapi status)	MEDIUM
Monitoring	LangGraph Studio (dev only)	Uptime Kuma + structured logging	MEDIUM
Graceful Shutdown	None	Signal handlers with 10s drain timeout	LOW
SOAP Warmup	Cold-start on first call	Warm clients on PM2 startup (P1 item)	MEDIUM
TypeScript Build	tsx (JIT)	npx tsc → node dist/ (compiled)	LOW

3.2 Multi-Clinic Readiness

Feature	Platform Master	Production
Clinic Onboarding	None	4-step wizard with 10-point pre-launch validation
Phone → Clinic Routing	Single clinic	Vapi phone number → clinicId lookup
Per-Clinic Config	.env hardcoded	DB-driven with admin UI
Provider Management	Seed script only	Admin CRUD with OSCAR sync
Waitlist	None	Full waitlist management (when registration closed)
Call Analytics	LangSmith traces	CallLog table with intent, outcome, duration, cost
Admin Dashboard	Frontend UI (testing)	React admin portal with role-based access
Billing Tracking	None	Vapi cost per call in CallLog

3.3 Voice Agent Product Maturity

Capability	Platform Master	Production
Language Support	English only (graph)	EN + ZH dual-track (9-agent squad)
Handoff Architecture	Graph edges (deterministic)	18 squad handoff routes (Vapi-native)
Filler Phrases	LLM-generated	Tool-level request-start messages (audible/silent)
Transfer to Staff	Terminal graph node	transfer_call tool with transfer-destination-request webhook
Conversation Style	Prompt templates in prompts/	Per-agent CONVERSATION STYLE sections in prompts
Dynamic Greeting	Fixed greeting node	get_clinic_info tool → customGreeting from DB
Error Recovery	Graph re-routing	Agent-level error prompts + handoff-to-router escape

---

4. What Platform Master Has That Production Doesn't

While production is far more mature overall, Platform Master introduces several capabilities worth evaluating for back-port:

Capability	Value	Back-port Recommendation
LangGraph Studio	Visual graph debugging, state inspection, execution replay	Consider for dev/QA environment debugging
Resk-llm-ts Security	Prompt injection detection, content moderation, canary tokens	Evaluate as supplementary security layer
IEmrClient Interface	Clean TypeScript interface for EMR abstraction	Already implemented as IEmrAdapter in production (superior version)
Dual Protocol Dispatcher	Runtime REST/SOAP selection via env var	Production has this via EmrAdapterFactory (per-clinic, not per-env)
Frontend Testing UI	Visual patient/appointment/chatbot testing	Useful for demos; production uses admin dashboard
LangSmith Tracing	LLM call tracing and visualization	Consider for production LLM observability
Zod Request Validation	Schema validation on all endpoints	Production uses Zod for env config; extend to webhook payloads
Prisma Schema Design	PatientClinicalMeta, PatientAddress (normalized)	Production patient data flows through OSCAR (not local DB); different pattern

Product Manager Recommendation

The most valuable back-port candidates are LangSmith tracing (for production LLM observability) and Resk-llm-ts (as a defense-in-depth security layer). The LangGraph architecture itself should NOT be back-ported — the Vapi-native squad approach is the correct production architecture.

---

5. Gap Inventory (Prioritized)

5.1 Critical Gaps (Must Fix Before Production Use of Master)

#	Gap	Impact	Recommendation
C1	Master WS-Security uses hasTimeStamp: true, hasNonce: true — fails on real OSCAR CXF	SOAP calls will throw SecurityError	Fix to { hasTimeStamp: false, hasNonce: false, passwordType: 'PasswordText', mustUnderstand: true }
C2	Master has no webhook authentication	Any HTTP client can invoke tool handlers	Add HMAC-SHA256 verification (copy from production vapi-auth.ts)
C3	Master stores credentials in plaintext .env	Credential exposure if server compromised	Implement AES-256-GCM encryption (copy from production crypto.ts)
C4	Master has no multi-tenancy	Cannot serve multiple clinics	Fundamental architecture gap; not a simple fix
C5	Master's addDemographic and getProvider(id) calls do not exist in OSCAR SOAP	Patient creation and provider lookup will fail	Fix: use getProviders2(true) + filter; remove addDemographic
C6	Master has no PIPEDA compliance infrastructure	Cannot deploy in Canadian healthcare	Add privacy officer, audit trail, data retention, consent mechanism

5.2 High Priority Gaps

#	Gap	Impact	Recommendation
H1	Master BookingEngine is hardcoded (providerId=101)	Cannot book with real providers	Port production booking.service.ts logic
H2	Master has no circuit breaker for SOAP calls	OSCAR slowness causes cascading failures	Add opossum circuit breaker (4s timeout)
H3	Master uses SQLite (no concurrent write support)	Data corruption under load	Migrate to PostgreSQL
H4	Master in-memory call state lost on restart	Active calls fail on server restart	Persist to Redis or PostgreSQL
H5	Master has no PHI redaction in logs	Patient data exposed in server logs	Port production logger with PHI_KEYS redaction
H6	Master has no admin API or user management	No operational control	Port production admin dashboard
H7	Master has no data retention policy	PHI retained indefinitely	Add PIPEDA 4.5 compliant auto-deletion

5.3 Medium Priority Gaps

#	Gap	Impact	Recommendation
M1	Master has no rate limiting	DoS vulnerability	Add express-rate-limit middleware
M2	Master timezone hardcoded (America/Vancouver)	Wrong times for non-Pacific clinics	Load from clinic config
M3	Master has no health check endpoint	Cannot monitor service status	Add /health with DB + OSCAR + LLM status
M4	Master has no graceful shutdown	Active requests dropped on restart	Add SIGTERM handler with drain timeout
M5	Master frontend proxies to localhost:4000	Only works in local dev	Configure for production API URL
M6	Master has no PM2/process management	Manual restart, no crash recovery	Add PM2 ecosystem config

5.4 Low Priority Gaps

#	Gap	Impact	Recommendation
L1	Master uses tsx (JIT compilation)	Slower startup, higher memory	Compile to JS for production
L2	Master CORS allows all origins	Minor security risk in dev	Restrict origins in production

---

6. Convergence Roadmap

Phase 1: Master Bug Fixes (1-2 days)

Fix the Master codebase so it can connect to real OSCAR instances:

1. Fix WS-Security config (hasTimeStamp: false, hasNonce: false)
2. Remove phantom addDemographic call
3. Fix getProvider() to use getProviders2(true) + filter
4. Add SOAP circuit breaker (4s timeout)
5. Fix SOAP dateTime format (${date}T00:00:00)

Phase 2: Security Hardening (3-5 days)

Bring Master to minimum security posture for healthcare:

1. Add HMAC webhook authentication
2. Add AES-256-GCM credential encryption
3. Add PHI redaction to logger
4. Add rate limiting
5. Migrate from SQLite to PostgreSQL

Phase 3: Compliance Layer (1-2 weeks)

Add Canadian healthcare compliance infrastructure:

1. Add audit logging middleware
2. Add data retention job
3. Add privacy officer tracking
4. Add consent mechanism (pre-call disclosure)
5. Add PIA documentation templates

Phase 4: Production Features (2-4 weeks)

Port production intelligence to Master (if Master is to become the new production):

1. Port BookingEngine from production
2. Add multi-tenancy support
3. Add clinic onboarding flow
4. Add admin dashboard
5. Replace in-memory state with Redis

Strategic Decision Required

The question is whether Platform Master should evolve into the next production system (replacing current v4.0.1) or remain a reference/sandbox. The LangGraph architecture offers better debuggability but requires significant effort to reach production parity. The current Vapi-native approach is already production-proven and deployed.

Recommendation: Keep Platform Master as a development sandbox and demo environment. Production should continue on the Vapi-native squad architecture. Back-port selected Master capabilities (LangSmith, Resk, Frontend UI) to production.

---

7. Third-Party Vendor Compliance Matrix

Both platforms share these vendor dependencies. This matrix assesses Canadian healthcare compliance for the shared stack:

Vendor	Function	HIPAA BAA	SOC 2	Canada Data Residency	Risk for Canadian Healthcare
Vapi	Voice AI orchestration	Available	Unconfirmed	No Canadian endpoint	HIGH — audio transits US
OpenAI (via Azure)	LLM (GPT-4o)	Yes (Azure)	Yes (Azure)	Azure Canada Central available	LOW (if using Azure)
Deepgram	Speech-to-text	Yes	SOC 2 Type II	EU endpoint; no Canada	HIGH — voice data in US
ElevenLabs	Text-to-speech	Yes (Enterprise)	SOC 2	US, EU, India; no Canada	HIGH — response audio from US
AssemblyAI	Speech-to-text (alt)	Yes	SOC 2 Type II	Unconfirmed for Canada	HIGH
AWS	Cloud hosting	Yes	SOC 2, ISO 27001	ca-central-1 (Montreal)	LOW
OCI	Cloud hosting (prod)	Yes	SOC 2, ISO 27001	Toronto region	LOW

BC Deployment Blocker

BC's PIPA requires health records stored on Canadian databases. Real-time voice streaming to US-based Vapi/Deepgram/ElevenLabs likely violates this requirement. BC clinic deployment should be deferred until Canadian-hosted voice processing is available, or a formal legal opinion confirms compliance.

Mitigation Actions (Both Platforms)

Action	Effort	Impact
Enable Vapi HIPAA mode (zero retention)	Low	Eliminates persistent US storage
Use Azure OpenAI Canada Central (not direct OpenAI API)	Low	LLM stays in Canada
Execute DPAs/BAAs with all 5 AI vendors	Medium	Contractual PIPEDA protection
Add pre-call privacy disclosure	Low	Meets transparency requirement
Monitor for Canadian STT/TTS endpoints	Ongoing	Future data residency compliance
Self-host Whisper STT on Canadian GPU (future)	High	Eliminates STT cross-border flow

---

8. Summary Scorecard

Dimension	Platform Master	Production (v4.0.1)	Winner
Conversation Debuggability	9/10	5/10	Master
Production Reliability	3/10	8/10	Production
OSCAR Integration Correctness	4/10	9/10	Production
Multi-Tenancy	0/10	9/10	Production
Security Posture	2/10	8/10	Production
PIPEDA/PIPA Compliance	0/10	7/10	Production
Voice Agent UX	6/10	8/10	Production
Developer Experience	8/10	6/10	Master
API Design	8/10	7/10	Master
Data Model Richness	7/10	6/10	Master
Testing Infrastructure	7/10	5/10	Master
Deployment Readiness	2/10	9/10	Production

Overall Assessment:

• Platform Master excels as a developer sandbox and reference implementation — superior debugging, cleaner API design, richer data model, and better testing infrastructure.
• Production v4.0.1 is the correct deployment platform — battle-tested OSCAR integration, multi-tenant SaaS, healthcare compliance, and enterprise security.
• Convergence path: Back-port Master's developer experience tools to production, fix Master's OSCAR integration bugs, and maintain both for their respective purposes.

---

This advisory should be reviewed by qualified Canadian healthcare privacy legal counsel before making compliance decisions. Technical findings are based on code review as of February 18, 2026.

Generated by Enterprise Architecture + Voice Agent Product Management analysis swarm.