The knowledge base chat lets you ask questions about your product and get answers grounded in the generated guides.

How it works

The chat assistant has access to the current feature's guide (sections, claims, and facts) and can search across all features. Every answer is grounded — behavioral sentences carry citation markers linking to specific claims or guide sections.

Asking questions

The chat handles several question types:

Factual lookups: "How does the daily repayment process work?" → answers from the guide with citations.

Comparisons: "How does the credit limit calculation differ from the coverage threshold?" → comparison table widget.

Enumerations: "Show me all the scheduled jobs" → fact table widget with real data from the mechanical facts.

Cross-feature questions: "Does the signup flow affect the credit application?" → loads the other feature's guide bundle.

Edge cases: "What happens when a repayment fails and the user's bank account is unlinked?" → synthesizes from multiple sections.

Grounding and trust

Every behavioral sentence carries a [[claim:id]] or [[section:id]] citation marker
Answers that can't be grounded say so: "The knowledge base doesn't cover this"
Uncited sentences are rendered visually weaker (lower opacity)
The assistant NEVER fills gaps from general knowledge — a clean "I don't know" is the right answer

Widgets

Instead of inline markdown tables, the chat emits interactive widgets:

Fact table — real data from mechanical facts (routes, jobs, parameters, entities). Server-resolved, so the values are guaranteed correct.
Comparison table — model-authored conceptual comparison
Diagram — Mermaid diagrams for flow visualization
Claim list — a set of specific product rules with trust badges
Linear ticket draft — a ticket for the user to edit and approve

Linear ticket drafting

When the chat detects intent to change product behavior, it proactively offers a Linear ticket draft. This happens for:

Explicit requests: "File a ticket to add partial repayments"
Implicit intent: "We should add a notification when repayment fails"
Bug reports: "The late fee calculation seems wrong"
Feature exploration: "What if we changed the cron schedule?"

The draft is categorized as bug, improvement, or feature, each with a comprehensive template:

Bug tickets include: what's broken, expected behavior, current behavior (from the KB), impact, steps to reproduce.

Improvement tickets include: what to improve, proposed change, business justification, affected components, risks.

Feature tickets include: what to build, user story, acceptance criteria, business context, technical surface, open questions.

The draft is NOT created — it's a proposal the user can edit title, description, and affected claims before clicking "Create ticket." Only then does it hit Linear.

A created ticket also opens a pending change in the knowledge base. From there it becomes a PR two ways: an engineer runs /kanon:work ENG-42 in their terminal, or — with a worker daemon online — anyone clicks Run with worker on the Changes page and watches the live session trace until the PR link lands.

Tips

Ask about specific features by name for the most grounded answers
Use "show me as a table" to get fact table widgets
Mention "all" to get enumerations: "all routes", "all cron jobs", "all feature flags"
The assistant can load other features — ask cross-feature questions freely
If the answer seems wrong, check the citations — they link to the source

AI chat