Extending Support Chat

Audience: Developer, System Admin Related: Support Chat Architecture · Documentation Standards · Testing

Extend Support Chat by adding documentation and deterministic metadata before adding provider-specific intelligence.

Add or improve suggestions

Initial chips come from support_suggestions_service, using page/feature metadata and a small registry. Do not call an AI model simply to render the opening suggestions. Keep the list short and page specific.

Provider-returned follow-ups are optional and limited by the structured response contract. They must stay within Blackcap support scope.

Improve retrieval

Prefer improving canonical headings, feature terminology, tags, route weighting, and lexical ranking first. If a future benchmark demonstrates that semantic embeddings materially improve Blackcap-specific retrieval, add them behind the provider-independent retrieval service, generate them only when documentation changes, and preserve SQLite/PostgreSQL parity. Do not make a vector database a prerequisite without measured need.

Add provider support

Implement the normalized generate_text adapter contract rather than adding provider logic to Support Chat routes. Provider adapters own request syntax, structured output, timeout, usage extraction, and normalized failures. Support Chat owns Blackcap grounding, context, trusted source resolution, lifecycle, and escalation.

Testing additions

New behavior should include deterministic tests for retrieval, audience filtering, source URL resolution, context redaction, idempotency, lifecycle/cleanup, AI Usage correlation, transcript permissions, transcript email recipient enforcement, and provider parity. Live-provider evaluation is optional for routine regression and should be run separately with explicit configured credentials.