# 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`.*
