Viv GovChat & Knowledge Management — Product Roadmap

Cheap, demo-visible engagement win that teaches residents what the bot can answer and steers them toward well-covered content.

Replace the on-page MSA Handbook search (?s2=) with a Typesense-backed search, reusing the same handbooksection index introduced for the chunking work in #39.

Parent epic for the real admin console (spec ) — the strategic control layer that the demo only glimpses.

Parent epic for observability (spec /) — the audit trail and the analytics it feeds.

Parent epic for production-grade indexing + retrieval quality (spec, ) — the backend side of ingestion and answer quality, beyond the demo-spine slice.

Parent epic for the productionization foundation (spec /) — everything that must exist before a second agency can be served and before a public endpoint is exposed.

For MMA.org, AI answers should not end at a generated response. The assistant should provide human-created next steps, with site feedback as a primary next step when the answer is weak, missing…

Per-tenant: volume, deflection, fallback rate, CSAT, usage/cost; content-gap list (questions with no confident answer) to guide editorial.

Append-only, per-tenant audit of every interaction: question, retrieved chunks, sources, answer, fallback/escalation outcome. No cross-tenant visibility. Feeds content-gap + analytics.

Risk-averse government clients need a safe verification path; standard in mature AI-agent consoles.

The spec calls this the Phase-2 "wow feature" the citation chips were designed for; without an issue it silently falls off the plan.

A public performance promise with no engineering item behind it.

Cheap to build and exactly the failure a government client judges harshly.

Per-tenant token/request metering (billing backbone); per-tenant spend ceiling with alerting + graceful 'service paused'; per-tenant and per-IP/session rate limits on the public widget endpoint;…

Collection-per-tenant in Typesense; tenantid on every relational row; tenant resolved server-side from the widget's site key, never client-supplied. Site-key issuance + per-tenant deletion…

Table-stakes in gov chatbot RFPs and marketed on our own site, yet tracked nowhere.

Biggest single answer-coverage gap vs competitors: municipal answers disproportionately live in PDFs the WP-post pipeline never sees (fee schedules, agendas, or

The pricing page is a contract — the product needs to enforce what it sells.

Part of #13 (Indexing & Retrieval Quality). Spec — the production ingestion pipeline (backend side).

No OpenAI-specific format should leak past a single internal interface, so Azure OpenAI / Bedrock can be swapped via one adapter.

Gov-specific trust feature few vendors handle well — a small build on the existing append-only audit log with big procurement credibility.

Connect site / issue site key; indexed post-types/fields/taxonomies; guardrails (out-of-scope, threshold, canned responses); escalation config; off-site allowlist + referral directory;…

Part of #13 (Indexing & Retrieval Quality). Spec — production-grade answer quality.

The product's headline efficiency claim, nearly free to build on the existing RAG pipeline.

A core privacy-forward differentiator written in the PRD but not scheduled.

A contractual-sounding promise municipal procurement will test; cheap to honor from KM-owned tables.

Every second deployment needs these knobs.

Agent reply composer: write a reply that goes out via the email round-trip (Epic: Email), move the ticket to awaitingresident, and mark a ticket resolved when the matter is answered — handing it…

Ticket queue/inbox for agents: list open/assigned tickets for the current tenant, with assignment (pick up / route), filtering, and the current state badge. Respects role (Agent/Reviewer/Admin)…

Marketed as "Unique to Viv KM" on every tier — currently one-third built.

Article lifecycle vs. source content: handle re-review/expiry when underlying policy changes (reuse GovChat effective-date filtering, spec ), and decide version history on edit/re-approval for…

Consent record + revocation: store affirmative consent (who, exact version approved, when, channel) for the consent gate; support later revocation that moves a published article to withdrawn and…

Parent epic. Two required gates and the writer that puts an approved answer into the RAG corpus.

Parent epic. The interface a real government agent uses to pick up an escalated ticket, read the originating GovChat conversation, and reply to the resident.

Citations are GovChat's trust spine — KM-authored answers currently have nothing for a citation to point at.

Publish-to-KB writer: index the approved, redacted Q&A as a document in the tenant's existing Typesense collection (the same one GovChat searches), tagged sourcetype: "kmarticle" for…

Ticket detail view: render the originating GovChat conversation (from viv-typesense wpvivtsmessages / ?vts= token, referenced not copied), the captured contact info, retrieved sources, and the…

Consent over email: deliver the proposed redacted Q&A with clear approve/decline actions, and record the resident's decision as the consent gate input (PRD, ). Approval/decline is captured with…

Consume viv-chatbot #7 escalation payload as the ticket-creation input (conversation summary, captured contact, source citations), instead of a parallel capture path (PRD ). Map the payload onto…

Parent epic. Run the agent↔resident loop over email so residents don't have to stay in the chat. Outbound agent replies / consent requests carry a signed, opaque, per-ticket+tenant token; inbound…

Parent epic. Wire KM into the existing stack without duplicating it.

Inbound email ingestion: receive resident replies (provider webhook or mailbox poll — PRD Q1), verify sender/token binding, strip quoted history + signatures, sanitize HTML, enforce…

Outbound email: send agent replies and consent requests from a per-tenant sender identity. Each message embeds a signed, opaque, single-purpose, expiring token binding it to one ticket + tenant…

Tenant isolation + deletion guarantees for KM data: tenantid on every KM row; KM tickets/articles/KB documents never cross tenants; a published article for Town A is never retrievable by Town B;…

REST surface + provider routing: expose KM endpoints under a parallel viv-km/v1 namespace reusing viv-typesense/viv-chatbot auth + tenant-resolution conventions; route every KM LLM call (PII…

Trace URL: https://d2mma.wpenginepowered.com/?vts=92f28afdf38751cef83543ab20bff76d