# Ask QIEN Project Pre-Mortem **Date:** 2026-05-09 This document imagines that Ask QIEN failed to become a durable, trusted product, then works backward to identify the most likely causes. The goal is not pessimism. The goal is to make the failure modes visible early enough that they can be designed around, tested, or consciously accepted. --- ## Failure Scenario It is 6 to 12 months from now. Ask QIEN technically works, but it has not become a reliable operating system for quality issue resolution. The demo flow still looks promising, yet real customer use has stalled. Line managers do not submit consistently because the form feels like extra work or they do not trust the follow-up loop. Experts still spend too much time reconstructing context, correcting AI drafts, and managing edge cases outside the tool. The knowledge base grows, but it is uneven: some entries are useful, many are duplicated, stale, or too generic to improve future drafts. Multi-tenant operations work in principle, but onboarding new tenants takes bespoke developer attention. Production incidents are rare but painful, especially around schema migrations, auth, email, AI jobs, and tenant config. The core risk: Ask QIEN becomes "an impressive ticket app with AI features" instead of the default shared workflow for line managers, experts, and customer admins. --- ## Top Risks ### 1. The product solves the demo workflow, not the daily workflow **What happened:** The shipped flow supports submit, triage, expert response, follow-up, and close. In real use, however, line managers have messy context, changing urgency, attachments, recurring equipment issues, and local communication habits outside the app. Experts still need calls, chats, photos, SOP references, and customer-specific context before responding. **Warning signs:** - Tickets are created only after someone reminds the line manager. - Experts reply outside the app and later backfill the ticket. - Many tickets use vague titles, incomplete R-fields/S-fields, or "see email" language. - The follow-up loop is rarely used. **Mitigations:** - Watch real usage sessions before adding broad features. - Add attachment support only after confirming the minimum useful file workflow. - Keep intake fields configurable per tenant, but protect against over-customization that makes each tenant a separate product. - Track time-to-first-expert-action, clarification rate, and tickets resolved without external channels. ### 2. AI quality is good enough for demos but not good enough for expert trust **What happened:** The AI pipeline produces summaries, tags, sentiment, drafts, and KB proposals, but experts learn that drafts often miss regulated nuance or overstate confidence. They stop reviewing drafts seriously, or they treat AI output as another thing to correct. **Warning signs:** - Experts frequently delete most of the draft before sending. - Draft acceptance improves only on narrow, repetitive cases. - KB retrieval cites semantically similar but operationally wrong entries. - Experts ask for "less AI" or ignore AI-generated fields. **Mitigations:** - Measure draft edit distance, draft regeneration rate, and expert rejection reasons. - Add AI usage and cost visibility by tenant, as already planned in `docs/roadmap.md`. - Add prompt-injection hardening, provider/model allowlists, and token caps before wider rollout. - Keep expert approval as a hard product invariant. - Use KB proposal review as a quality gate, not an automatic learning mechanism. ### 3. The knowledge base becomes clutter instead of compounding value **What happened:** Every resolved ticket can generate knowledge, but entries overlap, drift, and encode local assumptions. Search returns many plausible entries without clear authority. Drafts become more verbose rather than more accurate. **Warning signs:** - Experts create duplicate KB entries for the same recurring issue. - KB proposals are accepted without revision because review is tedious. - Older entries contradict newer process or regulatory guidance. - Search results look relevant by keywords but fail operationally. **Mitigations:** - Add review queues, revision hygiene, and stale-entry indicators. - Track KB entry usage in drafts and whether experts keep or remove cited guidance. - Prefer fewer, higher-quality entries over automatic accumulation. - Build nightly KB consolidation only after review workflows are trusted. - Keep provenance visible: ticket source, author, revision history, and last use. ### 4. Multi-tenancy works technically but remains operationally fragile **What happened:** Tenant isolation, membership RBAC, tenant switching, and DB-backed config are in place, but onboarding each new customer still requires hand-held seeding, manual checks, and developer context. Production tenant config becomes a source of subtle drift. **Warning signs:** - New tenant setup requires a developer every time. - Operators are unsure whether YAML seed config or DB runtime config is authoritative. - Admin UI changes and seed files diverge. - Multi-tenant users see confusing redirects or the wrong active tenant. **Mitigations:** - Treat `docs/multi_tenancy_onboarding.md` as an operational checklist and keep it current. - Add automated smoke tests for tenant switching, membership isolation, and admin invite flows. - Make tenant config provenance clear in the admin UI: seeded defaults vs runtime DB values. - Add an operator-only tenant health page before scaling customer count. ### 5. Deployment and migration drift causes avoidable production outages **What happened:** The app code and database schema get out of sync. A deploy reaches production before migrations run, or a migration runs against the wrong database URL. The app works locally and in tests, but production auth, tickets, or admin pages fail. **Warning signs:** - Developers manually run production migrations from local shells. - Vercel build-time checks are the main safety net. - Migration status is not visible before deploy promotion. - Production failures mention missing columns, enum mismatches, or stale config. **Mitigations:** - Prioritize the roadmap item for migration-before-deploy GitHub Actions. - Use direct/non-pooling database URLs for migrations and pooled URLs for runtime. - Add a production smoke test checklist after every migration-bearing deploy. - Keep migration commands documented but reduce reliance on manual execution. ### 6. Auth, email, and onboarding issues block trust before users see product value **What happened:** The product is invite-only and email-driven. If magic links, Google SSO, callback URLs, waitlist behavior, or membership resolution fail, users cannot even reach the workflow. Early users experience the product as unreliable before seeing the AI loop. **Warning signs:** - "I cannot log in" becomes the most common support issue. - Unknown users land in confusing states after sign-in attempts. - Magic-link emails land in spam or deep links fail after auth. - Multi-tenant users land on the wrong starting page. **Mitigations:** - Keep auth and invite flows covered by integration and e2e tests. - Monitor magic-link send failures and waitlist events. - Smoke test login flows after changing Auth.js, callbacks, env vars, or domain settings. - Keep dev conveniences like `AUTH_DEV_EMAIL_MODE=dev-link` clearly out of production. ### 7. Regulated-domain expectations outpace product safeguards **What happened:** The product is used for medical-device quality work, but customers infer a level of compliance, auditability, validation, or regulatory grounding that the product does not yet provide. The risk is not just legal. It is loss of credibility with the exact expert audience the product needs. **Warning signs:** - Customers ask whether AI guidance is "approved" or "compliant." - Ticket exports, audit logs, and retention policies become sales blockers. - Users paste sensitive or regulated content before data-processing boundaries are clarified. - Regulatory source grounding is requested before licensing and review workflows are ready. **Mitigations:** - Be explicit in product copy and contracts: AI assists experts; experts remain accountable. - Preserve audit trails for ticket state transitions, expert responses, and KB revisions. - Add data retention, export, and deletion decisions before larger rollouts. - Roll out regulatory-source grounding slowly, with source licensing and expert review. ### 8. Cost, latency, and reliability of AI jobs become invisible product debt **What happened:** Inngest and LLM calls are central to the product. Under real use, jobs fail, time out, retry, or cost more than expected. Because usage is not visible enough, the team reacts only after customers notice delays or bills spike. **Warning signs:** - Tickets sit in AI-processing states without clear operator visibility. - Provider rate limits or outages block draft generation. - No one can answer "what did this tenant cost this month?" - Retry behavior creates duplicate artifacts or confusing status changes. **Mitigations:** - Add tenant-level AI usage, cost, latency, and failure tracking. - Add fallback provider/model support for selected failures. - Give operators a simple job-health view before high-volume usage. - Make AI failure states useful: expert can continue manually, and the ticket explains what is missing. ### 9. Security and privacy controls lag behind customer trust **What happened:** The product stores sensitive operational data, expert guidance, emails, and customer-specific knowledge. ORM-level tenant scoping works, but deeper defense-in-depth, secret hygiene, log redaction, and incident playbooks are not mature enough for broader adoption. **Warning signs:** - Logs contain ticket bodies, prompts, credentials, or user emails unnecessarily. - Access-control tests cover happy paths but not cross-tenant negative cases. - There is no clear answer for backup, restore, data deletion, or incident response. - Production secrets are copied around manually without rotation discipline. **Mitigations:** - Add PostgreSQL row-level security before customer count grows. - Run secret scanning before production releases and after local-machine migrations. - Add negative tests for cross-tenant access on every tenant-scoped route. - Define backup, restore, deletion, and incident-response runbooks. ### 10. The engineering loop slows as the app becomes more interconnected **What happened:** The product has Next.js routes, Auth.js, Drizzle, Inngest, pgvector, email, tenant config, and e2e tests. As features accumulate, changes require too much local ceremony, tests become slow or flaky, and developers hesitate to refactor. **Warning signs:** - Small changes require manual setup debugging. - E2E tests fail because of environment drift rather than product bugs. - Developers skip full verification because it is too slow or memory-heavy. - Test data and seed data no longer represent real workflows. **Mitigations:** - Keep the devcontainer and README fresh for new-machine setup. - Split tests by risk while preserving a reliable full-suite path. - Keep prompt templates in `prompts/` and long workflow specs in `docs/`. - Regularly prune obsolete docs and reconcile roadmap/spec drift. --- ## Highest-Leverage Preventive Work 1. **Migration-before-deploy workflow:** Prevent schema/app drift before it causes another production incident. 2. **AI observability:** Track cost, latency, failures, provider/model, tenant, ticket, and agent for every LLM call. 3. **Knowledge quality loop:** Measure which KB entries improve drafts, which are ignored, and which need consolidation. 4. **Tenant onboarding checklist:** Make new-tenant setup repeatable without developer memory. 5. **Auth/email smoke tests:** Treat login and invite flows as product-critical, not plumbing. 6. **Cross-tenant negative tests:** Prove users cannot access another tenant's tickets, KB entries, config, users, or projects. 7. **Operator health surface:** Show stuck jobs, failed emails, tenant config status, and recent deploy/migration state. 8. **Customer workflow interviews:** Validate whether the app is replacing outside coordination or merely documenting it afterward. --- ## Metrics To Watch | Area | Metric | Why it matters | |---|---|---| | Adoption | Tickets submitted per active line manager per week | Measures whether the workflow is becoming habitual | | Intake quality | Clarification rate and missing-field frequency | Shows whether the form captures enough context | | Expert workload | Time from ticket submission to first expert action | Measures operational responsiveness | | AI value | Draft edit distance and draft send-through rate | Shows whether AI output saves expert time | | Knowledge value | KB entries used in drafts and retained after expert edits | Shows whether the KB compounds | | Reliability | AI job failure rate and stuck ticket count | Prevents invisible pipeline degradation | | Cost | LLM cost by tenant, agent, and ticket | Protects margins and flags anomalies | | Security | Cross-tenant access test coverage and failures | Protects the core trust boundary | | Onboarding | Time to seed and verify a new tenant | Measures operational scalability | --- ## Open Decisions - What is the minimum evidence that Ask QIEN has replaced an existing customer workflow rather than added another place to type? - Which usage thresholds trigger investment in pagination, RLS, AI cost dashboards, and operator tooling? - How much customer-specific customization is allowed before the product becomes expensive to maintain? - What data-retention and export commitments are acceptable for early regulated-domain customers? - Which regulatory source packs can be used safely, and who approves their interpretation in AI-assisted drafts? - What is the expected human fallback when AI jobs fail, timeout, or are disabled by tenant consent? --- ## Review Cadence Review this pre-mortem before: - A wider external user rollout - Onboarding a second customer tenant - Adding attachment support - Adding regulatory-source grounding - Changing auth, tenant membership, or deployment migration flows - Moving from manual operator checks to automated production release workflows At each review, mark risks as accepted, mitigated, or newly urgent, then update the roadmap with the highest-leverage next action.