# 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..clerk.services` - `clk._domainkey` → `dkim1..clerk.services` - `clk2._domainkey` → `dkim2..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`.*