# Ask QIEN — Roadmap **Last updated:** 2026-05-07 **Live at:** [quality-intelligence.co](https://quality-intelligence.co) The MVP core loop is shipped and live: line manager submits → AI triages → expert sees summary + draft → expert responds → KB learns. This document tracks what comes next. --- ## ✅ Shipped These items from the original roadmap are live in production. | Item | What shipped | |---|---| | 1.1 Expert close ticket | "Close ticket" button visible to experts on RESPONDED / AWAITING_REPLY tickets | | 1.2 PATCH /status endpoint | Validates transitions via state machine, optimistic concurrency, audit log | | 1.3 Line manager follow-up | Reply textarea shown when ticket is AWAITING_REPLY; re-queues for AI pipeline | | 2.1 Sentiment & urgency agent | Inngest Hook 2 writes `sentiment_analysis` artifacts and updates urgency, sentiment, and priority | | 2.2 Auto-tagging agent | KB-grounded tag suggestions run after triage; experts can edit tags inline | | 3.1 Soft-delete KB entries | KB delete sets `is_deleted = true` and removes entries from search/draft retrieval | | 3.2 KB revision history | `/knowledge/[id]` shows revision history from `knowledge_entry_revisions` | | 5.2 Rate limiting | Magic-link and ticket submission endpoints have rate limiting | | 6.1 Google SSO | Sign in with Google alongside magic link; account linking for existing users | | 6.2 Name collection | /onboarding page captures display name on first sign-in for both auth methods | | 6.3 Display name change | `/settings` lets users update their display name | | 7.1 Admin config UI | `/admin/config` lets admins edit tenant settings without YAML changes | | 7.2 User management UI | `/admin/users` supports invite/reactivate, role changes, disabling users, and last-login visibility | | 10 Full pipeline E2E test | Playwright covers ticket submission through expert draft/response workflow | | 11.1 Expert response email | Branded HTML email sent to line manager when expert responds | | 11.2 Deep-link reply | Email → login → back to ticket via callbackUrl; seamless round-trip | | RBAC via tenant memberships | Roles now live on `tenant_memberships`, allowing one user to have different roles in different tenants | | Multi-tenant switcher | Multi-tenant users can switch active tenant via `/switch-tenant`; session resolution honors the preferred tenant cookie | | Runtime tenant config in DB | Category abbreviations and notification flags are read from `tenant_configs` per tenant instead of YAML at request time | | Multi-tenant seeding | Production tenant config files can be seeded independently and idempotently | | Waitlist guard | Unknown sign-ins are captured in `waitlist` and blocked until invited | | Auth middleware | All authenticated routes protected; unauthenticated users redirected with callbackUrl preserved | | Expert redirect | Experts land on /inbox after login; line managers land on /submit | | P2 `loadTenantConfig` caching | Tenant config YAML is cached for the serverless container lifetime | | Role-aware nav | Experts see Inbox/Knowledge/Projects; line managers see Submit/My Tickets | | Responsive design | Mobile viewport, two-row nav on small screens, card lists replacing tables | --- ## Up next ### Must-do before wider user rollout #### P4 — Migration-before-deploy GitHub Actions workflow **What:** Move production deploys to a GitHub Actions workflow that runs checked-in Drizzle migrations against the production database using the direct/non-pooling connection string, then triggers or promotes the Vercel deployment only if migrations pass. Keep the current Vercel build-time migration guard as a fallback until this workflow is proven. **Why:** Google SSO exposed a production schema-drift failure: the deployed app expected `users.is_active`, but the production database had not applied the migration yet. Browser E2E tests against a correctly migrated test database would not catch that class of issue. The deploy pipeline needs a release-phase-style hook so schema and app code advance together. **Scope:** M #### Admin user search/filtering **What:** Add text filtering to `/admin/users` by display name and email address, with active/disabled counts reflecting the filtered result. Client-side filtering is enough for the current scale; move to server-side search if tenant user lists grow large. **Why:** Tenant admins will need to find invited users quickly once more line managers and experts are onboarded. **Scope:** S #### Engagement and usage observability **What:** Three-phase feature: (1) KB retrieval tracking — a new `kb_draft_retrievals` table that records which KB entries were pulled during response-draft generation; (2) admin platform health dashboard at `/admin/platform-health` covering adoption, ticket flow, draft quality, and KB health per tenant; (3) user engagement widgets on the navbar — line managers see a monthly ticket counter, week streak, and resolved count; experts see a KB articles-written counter and a cumulative "responses helped" pre-fill impact counter, with a per-entry impact stat on each KB article detail page. **Why:** Adoption failure is the pre-mortem's core risk. Without usage data the team cannot detect disengagement before it becomes critical. Without visible impact signals, line managers have no feedback that submission leads to outcomes, and experts have no signal that the KB articles they write are compounding. The KB article counter solves the cold-start seeding problem; the pre-fill impact counter creates a quality feedback loop that motivates curation without admin intervention. **Spec:** [docs/feature_engagement_and_usage_observability.md](feature_engagement_and_usage_observability.md) **Scope:** Phase 1 is S; Phase 2 is M; Phase 3 is M --- #### AI usage and cost visibility by tenant **What:** Capture token usage, model, provider, agent name, ticket id, tenant id, latency, success/failure, and estimated cost for every LLM call. Decide whether the first interface is an operator-only admin page, a tenant admin page, or an external dashboard such as Datadog. **Why:** Multi-tenant operations need monthly usage and cost visibility before customer volume grows. This is also the foundation for budgets, anomaly detection, and billing conversations. **Scope:** M #### LLM fallback provider/model **What:** Let the AI gateway retry selected failed calls against a configured fallback model/provider when the primary model is unavailable or rate-limited. Include clear logging so fallback usage is visible and auditable. **Why:** A single LLM provider outage should degrade the AI pipeline gracefully rather than blocking ticket triage or draft generation. **Scope:** M --- ### Later / when there's user demand #### 5.1 — Row-level security (PostgreSQL RLS) **What:** RLS policies on all tenant-scoped tables. Defense-in-depth beyond the ORM-level `WHERE tenant_id = ?` filter. **Scope:** M #### 5.3 — AI gateway: budgets and prompt-injection hardening **What:** Hard token caps per agent call, prompt-injection heuristics, tenant/month budgets, and graceful behavior when a budget is exhausted. **Scope:** M #### Tenant-specific LLM API keys **What:** Support LLM credentials per tenant, likely stored in the deployment secret manager or encrypted at rest and referenced from `tenant_configs`. The AI gateway should resolve the active tenant's credential before falling back to the platform default. **Why:** Some customers may want direct pass-through billing, separate provider-side usage reporting, or their own data-processing agreement with the model provider. This also makes tenant spend easier to reconcile against provider dashboards. **Scope:** M–L #### Regulatory standards-grounded guidance **What:** Ground expert guidance in relevant regulatory source packs such as FDA 21 CFR Parts 820, 803, 806, 11, 210; EU MDR; and, after licensing is resolved, ISO 13485:2016 and ISO 14971:2019. Roll out in stages: source registry, public FDA/EU retrieval, draft-agent integration, ISO support, and evaluation/governance. **Spec:** [docs/feature_regulatory_standards_guidance.md](feature_regulatory_standards_guidance.md) **Scope:** M–L — slow-roll due to source licensing, review, indexing, and token-cost implications. #### 4.1–4.3 — Attachment support **What:** File uploads on tickets (S3-compatible storage, AV scan, signed download URLs). Phased: store-and-forward first, AI-aware extraction later. **Spec:** [docs/feature_attachments.md](feature_attachments.md) **Scope:** Phase 1 is M — requested by Ramon; Phase 2–3 are M–L, deferred until evidence from Phase 1. #### 8 — Hook 7: Nightly KB batch enrichment **What:** Scheduled Inngest job that finds cross-ticket patterns across recently closed tickets and proposes KB consolidations. **Scope:** L #### 9 — Ticket linking **What:** Link tickets as `relates_to`, `duplicates`, or `blocked_by`. Expert-only UI on ticket detail. **Scope:** M #### P1 — Reference number race condition **What:** Replace `count() + 1` reference number generation with an atomic PostgreSQL sequence. **Why:** Two simultaneous submissions can get the same reference number. Acceptable at low traffic; fix before concurrent load. **Scope:** S #### P3 — Inbox pagination **What:** Cursor-based pagination on the inbox and ticket list; "Load more" UI. **Why:** All rows are returned with no `LIMIT` — fine at tens of tickets, slow at thousands. **Scope:** M #### 6.4 — SAML 2.0 **What:** Enterprise SSO via a SAML adapter; tenant-specific IdP metadata. **Scope:** L — defer until there is a concrete enterprise customer. #### KB — Knowledge graph visualization **What:** Force-directed graph view of KB entries and their relationships — explicit ticket links, semantic similarity edges, usage weight. Functional curation tool for experts; strong demo asset. **Spec:** [docs/knowledge_graph_visualization.md](knowledge_graph_visualization.md) **Scope:** M — data pipeline already exists, primarily a UI build. Best built after the generic knowledge library work.