Desirability
Do the intended users actually want this?
The /v4 chat-first Medicare intake and enrollment experience: a hybrid voice + text intake that captures doctors, medications, ZIP, budget, and Medicaid status, verifies providers against NPPES and drugs against RxNorm, recommends a coverage strategy (Medicare Advantage, Medigap + Part D, or D-SNP) with a specific plan, and hands off to a licensed advisor for enrollment.
Desirability is largely un-testable from code — as expected. The /v4 prototype itself is the artifact you would put in front of members to answer these questions. The strongest signal from the code is design commitment: caregiver support, 8th-grade language, and warm advisor handoff are wired in as first-class product decisions, not add-ons. The missing artifacts are research, not code.
Feasibility & Viability is a mixed picture. Voice/UX has real prompt-level guardrails (confidence ≥ 80 gate, ZIP gate, verification gate, 'not a licensed agent' disclosure). Handoff to a named licensed advisor is genuinely solid. The blockers are compliance and safety: no TPMO disclaimer in the chat surface, no audit trail, the full intake snapshot (including PII) is passed into every model call, and enrollment collects MBI/SSN/payment details into a browser-side store. Nothing in Measure or Manage is instrumented yet — no evals, no red-team, no SLOs, no drift alerts.
This is a well-crafted design-stage prototype, not a production-ready system. It punches above its weight on member-facing quality (persona, verification, handoff, strategy-first recommendation) and is honest about being a prototype (mock auth, demo data). Before real member exposure, three things have to move: (1) HIPAA-grade data handling for PII, (2) an eval + red-team suite gated in CI, and (3) CMS TPMO / marketing compliance surfaces. Everything else in Feasibility & Viability follows from those.
Do the intended users actually want this?