# AI Support Bot — Go-Live Tech Plan (decision checklist)

**Purpose:** finalize everything needed to launch the AI support bot for users. Each item has a
**decision** and an **owner** so we stop discussing and start closing. Ram's asks (PII, transcripts,
handoffs) are folded in.

Legend: ✅ done · 🟡 agreed, to build · 🔴 open decision

---

## A. Launch scope (decide first, everything else follows)
Ram wants to launch for **technical queries first** and watch the UX.
- **Decision:** What is the v1 entry point? Options: (1) show the AI assistant as the first step in
  the existing support/chat flow for everyone, human coach always one tap away; (2) limit it to
  clearly technical/account topics at first.
- **Recommendation:** Launch it as the **first responder in the existing coach chat**, for all
  topics, with the human handoff always visible. The bot already declines/escalates anything it
  shouldn't answer, so "technical only" is not a code change, it is a positioning choice. Monitor via
  logging + thumbs, widen confidently. 🔴 Owner: Ram + Neel.

## B. Auth (biggest backend item)
- **Now:** shared `X-API-Key` header. ✅ works.
- **Prod target:** the app's own `accessToken` as `Authorization: Bearer`, verified per user. 🟡
- **Decision:** how is the app token verified — a JWT we validate with a shared secret, or an
  introspection endpoint we call? App/BE must give Neel the method. 🔴 Owner: App/BE → Neel builds.
- **Recommendation:** for the **first limited launch**, X-API-Key is acceptable if the app calls
  through a trusted path. For a full client-side rollout, ship **Bearer token** (a key baked into the
  client is extractable). Build Bearer in parallel; do not let it block the pilot.

## C. Hosting / deployment
- **Now:** live at `tweb.quitsure.app/support-ai` (test server), Apache strip-proxy + uvicorn. ✅
- **Decision:** is `tweb` the production host, or do we need a proper prod deployment (process manager
  with auto-restart, resource headroom, uptime)? Staging vs prod URLs. 🔴 Owner: Ram/BE.
- **Recommendation:** keep `tweb` for the pilot; define a prod host + auto-restart + basic uptime
  monitoring before a wide launch.

## D. Context: program_day mapping
- Day-gating (only share stage-appropriate concepts) depends on a correct integer **`program_day`**.
- **Decision:** confirm the app's `iActiveDayId` is the literal day number, or map it. 🔴 Owner: Avi.
- Also send `program`, `platform`, `subscription_status` when available (all already accepted).

## E. PII protection (Ram's ask)
- **Now:** we log `message`, `answer`, `user_id` to the **test** DB. 🟡 needs hardening before prod.
- **Decisions + recommendation:**
  1. **Where:** move logging to a **prod DB with restricted access** (not the shared test DB). 🔴 BE.
  2. **User id:** store a **pseudonymous id** (hash of iUserId), not anything directly identifying. 🟡 Neel.
  3. **Message redaction:** strip obvious PII (email, phone) from stored `message`/`answer` with a
     regex before insert. Cheap, high value. 🟡 Neel.
  4. **Retention:** auto-delete logs after a fixed window (propose **90 days**). 🔴 Ram to set the number.
  5. **Access:** only the analytics/coach-improvement role can read logs. 🔴 BE.
- Nothing here blocks the pilot except (1) using a non-shared DB; the rest can land in parallel.

## F. Handoff + data transcripts to coaches (Ram's ask)
- **Design (from Avi's doc, agreed):** on `escalate:true`, the **app** carries the conversation into
  the existing **Freshchat** coach thread. Backend returns `coach_summary` (one line) + the `answer`;
  the app pushes `ai_summary` + optional full transcript into Freshchat via
  `setUserProperties` / `sendMessage`. Backend never touches Freshchat (Ram's rule). ✅ verified.
- **Decisions:**
  1. Does the coach get the **full AI transcript** in-thread, or just the one-line summary + last
     message? 🔴 Owner: Ram + coaches (privacy vs context tradeoff). Recommendation: summary +
     transcript, so the user never repeats themselves.
  2. **Routing:** `escalate_reason` → channel is set (account_action/service_error → technical;
     everything else → coaching). ✅
  3. **P11 / LeanSure users:** gated **off the bot entirely** (KB is smoking-only). ✅ app enforces.

## G. API hardening (small backend fixes)
- **Enum-lock `escalate_reason`** so an unexpected value can't mis-route (Avi flagged this). 🟡 Neel, quick.
- Keep the graceful `service_error` → human handoff on any error. ✅
- Confirm client timeout 30s vs server 20s. ✅

## H. Monitoring
- Chat + thumbs feedback logging works; `scripts/monitor_chats.py` gives a live review. ✅
- **Decision:** add basic error alerting for prod (e.g., a spike in `service_error`). 🟡 BE, later.

## I. Content (not a launch blocker for technical queries)
- KB = support "Chat Shortcuts", ~487 approved answers. ✅
- Program content (6-day / 42-day / post-quit) pending from Ram — enhances concept answers and
  day-gating, add when available. 🟡 Ram.

---

## The short list of decisions that actually gate launch
| # | Decision | Owner |
|---|---|---|
| 1 | v1 scope + entry point (bot-first in coach chat, human always available?) | Ram + Neel |
| 2 | Auth for the pilot: X-API-Key now, Bearer token method for full rollout | App/BE → Neel |
| 3 | Prod host + auto-restart, or run the pilot on `tweb` | Ram/BE |
| 4 | `program_day` = `iActiveDayId` or mapped | Avi |
| 5 | PII: prod (non-shared) DB + retention window (propose 90 days) | Ram/BE |
| 6 | Coach handoff: full transcript or summary-only into Freshchat | Ram + coaches |

Everything else (redaction, hashing, enum-lock, alerting) we build in parallel and does not block a
supervised pilot.