Signal/docs/production-readiness-whitepaper-2026-06-21.md

Signal — Production Readiness Whitepaper

Date: 2026-06-21 Author: Claude Code Companion to: pilot-e2e-validation-2026-06-21.md (validate the pilot first; this is the road from there to production) Purpose: Define exactly what it takes to move Signal from its current posture to (1) a controlled pilot and (2) full production where a supplier's own staff log in and rely on Signal with real patient identifiers. For Pi to design the sequence; Claude Code builds it.

---

1. Where we are today (verified 2026-06-21)

• Auth: Clerk migration is half-done and broken. Front-end deployed with a production key pointing at clerk.sttilsolutions.com, but that domain's DNS is wrong (CNAME'd to Vercel, not Clerk), so the live app is a blank screen. Backend still validates against the dev Clerk instance. (See pilot validation P0-1.)
• Database: Supabase Pro ($25/mo). No BAA. Reachable, 1 org.
• Host: Railway. No BAA available.
• MFA: not confirmed on any admin console.
• Data: synthetic / de-identified only. No live PHI has entered the system.
• Audit log: code exists but never writes to the DB.

The single most important framing: Signal has two very different finish lines, and conflating them is what produced the "100% ready" overstatement. Keep them separate.

---

2. Two finish lines

Finish line A — Controlled pilot (zero live PHI)

The supplier substitutes synthetic patient IDs and offsets dates before export, keeping the real crosswalk on their side. Because no PHI reaches STTIL, the full HIPAA Security Rule build is not triggered. Reference: docs/hipaa-deployment-analysis-v1.md (zero-PHI path) and docs/pilot-guide-v1.md.

Required for Finish line A:

• Clerk: A production instance is strongly recommended (dev pk_test_ instances carry usage caps, a dev banner, and can be reset — not appropriate for a real supplier's staff). Custom domain + full DNS are not strictly required at zero-PHI, but the front-end/back-end Clerk instances must match and the app must actually load. Fastest correct state: either finish the prod instance properly, or revert both halves to one working instance.
• BAA: not required (no ePHI). The LOI must state plainly that no live ePHI is transmitted.
• Host: Railway is fine.
• MFA: required on all admin consoles; any method acceptable at zero-PHI.
• Config: confirm ALLOWED_ORIGINS is locked to the real Vercel domain (today the regex accepts any *.vercel.app with credentials), CLERK_JWKS_URL and SIGNAL_API_KEY set, and the deployed URL serves the Clerk-gated React app (not the static demo in vercel.json).
• Trust copy: remove the false BAA claim from the privacy page.
• Operational proof: deletion test run, incident tabletop run, access scope documented.
• Paperwork: LOI + NDA executed (attorney-reviewed), FDA CDS exemption memo written.

Finish line B — Full production (real patient identifiers / ePHI)

This crosses into ePHI and turns on the entire Real-PHI gate. Reference: docs/hipaa-deployment-analysis-v1.md (Option B "HIPAA SaaS") and the Real-PHI checklist in CLAUDE.md.

Required for Finish line B (all mandatory):

1. Business Associate Agreements — per relationship: STTIL ↔ supplier (before any ePHI, §164.308(b)); STTIL ↔ host; STTIL ↔ Anthropic if any AI layer touches ePHI. Supabase Pro has no BAA — requires Supabase Team ($599/mo) or migration to AWS RDS.
2. BAA-capable host — Railway must be replaced (AWS ECS Fargate / Atlantic.Net / equivalent). Railway offers no HIPAA BAA.
3. Clerk production, properly — pk_live_, custom domain (clerk.sttilsolutions.com), and the full Clerk DNS set:
   • clerk → frontend-api.clerk.services ← this is the record currently wrong
   • accounts → accounts.clerk.services ← already correct
   • clkmail → mail.<id>.clerk.services
   • clk._domainkey → dkim1.<id>.clerk.services
   • clk2._domainkey → dkim2.<id>.clerk.services
   • and switch the backend CLERK_JWKS_URL to the production instance so both halves match.
4. Phishing-resistant MFA (FIDO2/WebAuthn) — mandatory under 2026 §164.312(d). SMS OTP does not satisfy it.
5. Encryption — AES-256 at rest confirmed/attested (RDS or Supabase Team), TLS 1.3 enforced.
6. Effective, immutable audit logging — DB-trigger immutability or nightly export to object storage with Object Lock (RLS alone is bypassed by the service role), AND the audit table must actually receive rows.
7. Governance — documented annual risk assessment (HHS SRA Tool), tested incident response, tested 72-hour restoration, continuous monitoring/alerting, full administrative-safeguards review with attorney.
8. FDA CDS exemption memo finalized and attorney-reviewed.

Timeline estimate (from hipaa-deployment-analysis-v1.md): ~6–11 weeks to compliant first-ePHI contact; critical path = host BAA execution + FIDO2 MFA rollout.

---

3. One-line distinction

Controlled pilot = paperwork + MFA + correct env config + corrected privacy copy on the existing zero-PHI stack. Full production = a new BAA-capable host, Supabase Team/RDS under a BAA, Clerk production with custom domain + DNS, phishing-resistant MFA, effective WORM audit logging, encryption attestation, and an attorney-reviewed Security Rule posture.

---

4. Recommended sequence (for Pi to design)

Phase 0 — Unbreak (today): restore the live app to one consistent, working Clerk instance (pilot validation P0-1). This is a prerequisite for any demo and must not wait on the full prod build.

Phase 1 — Production Clerk, done right: stand up the prod instance, fix the clerk CNAME → frontend-api.clerk.services, add the remaining DNS records, migrate the backend JWKS to prod, verify login end-to-end on signal.sttilsolutions.com. (This is the Clerk work Kisa is routing to Pi.)

Phase 2 — Trust & security hardening (no host change): correct privacy copy, delete the VITE_SIGNAL_API_KEY path, wire the audit log to write real rows, confirm MFA, lock CORS to the real domain.

Phase 3 — Compliance build for ePHI (the heavy lift): BAA-capable host migration, Supabase Team/RDS + BAA, FIDO2 MFA, effective WORM, encryption attestation, risk assessment, attorney review.

Phases 0–2 are reachable quickly and unlock a credible controlled pilot. Phase 3 is a 6–11 week project that should begin only when a real-PHI contract is in sight and funded.

---

5. Cost deltas to anticipate

Item	Today	Production
Database	Supabase Pro $25/mo	Supabase Team $599/mo (BAA) or AWS RDS
Host	Railway (no BAA)	AWS ECS Fargate / Atlantic.Net (BAA)
Auth	Clerk dev (free tier)	Clerk production (paid tier as users grow)
MFA	none	FIDO2 hardware/passkeys
Legal	—	BAAs, Security Rule review, FDA CDS memo

---

All technical claims here are corroborated by the live 2026-06-21 validation (pilot-e2e-validation-2026-06-21.md) and docs/hipaa-deployment-analysis-v1.md.