The second question exposes whether documentation is part of delivery or a task somebody remembers after release:
How does your team keep the bot’s answers updated when product workflows, permissions, or pricing change?
If the answer is “we periodically retrain it” or “support tells the docs person”, documentation rot is already built into the process.
The short answer
Make documentation a required output of the same change that alters the product. Keep reviewable source in Git when that suits your team, then use FAQ Hub to reconcile those changes safely into the customer-facing content system.
FAQ Hub does not currently watch GitHub or Azure Repos for you. Your client or pipeline still reads the repository and converts the selected Markdown into a content manifest. FAQ Hub removes the difficult plumbing after that point: product scope, dry-run planning, conflict detection, drafts, publishing authority, retries, audit, indexing, and portal refresh.
The Git-to-knowledge-base job is a good start
A team we spoke to stores Markdown in Git and runs a job that feeds its knowledge base and chatbot. That pattern has real strengths:
- documentation changes can be reviewed in pull requests;
- code and documentation can change together;
- history and ownership are visible;
- automated checks can reject broken links or invalid frontmatter;
- the repository can remain the writing source of truth.
The fragile part is usually everything the custom job must implement around the copy operation.
What happens when an article was edited in both systems? How are renames distinguished from deletes? Can a compromised job write into another product? Does a retry duplicate content? Who may publish pricing? What refreshes the portal and chatbot after publication?
What FAQ Hub adds to docs-as-code
FAQ Hub exposes a product-scoped Model Context Protocol endpoint over Streamable HTTP. A compatible agent can use the same content controls from an interactive coding session or a pipeline-owned process.
The normal workflow is deliberately staged.
- Export current state. The client reads the current content keys, external bindings, hashes, and revisions.
- Build a manifest. Repository-relative paths or durable documentation IDs become stable external IDs.
- Plan the sync. FAQ Hub reports creates, updates, moves, no-ops, conflicts, and archive candidates without changing customer content.
- Review the plan. A person or controlled workflow decides whether the proposed change matches the product release.
- Apply drafts. Accepted, non-conflicting changes are written as drafts with an idempotency key, so safe retries do not create duplicate work.
- Publish explicitly. Publishing uses a separate permission and checks the expected revision again.
- Handle retirement separately. Mirror mode can propose archive candidates, but it does not silently delete pages.
This is the difference between “copy these files” and “reconcile governed product documentation”.
How this keeps chatbot answers current
FAQ Hub chat does not rely on a separately uploaded, forgotten chatbot corpus. It searches the tenant and product’s published knowledge for each substantive question.
When an article is published, FAQ Hub updates keyword search, queues semantic indexing when configured and within budget, and sends signed cache invalidation to the relevant portal domains. The public portal and support assistant therefore converge on the same published content lifecycle.
If semantic indexing cannot run immediately, the article remains published and keyword-searchable. If cache invalidation is unavailable, normal cache expiry provides a fallback. Those are operational safeguards, not a promise that every external dependency is instantaneous.
GitHub and Azure DevOps fit the same control model
The MCP server is client-neutral. VS Code and GitHub Copilot can be configured as interactive MCP clients. A GitHub Actions or Azure Pipelines workflow can also invoke an MCP-capable client or a custom wrapper after checking out the repository.
Keep the product API key out of the repository:
- GitHub documents how to store values as Actions secrets and pass them through the
secretscontext. - Microsoft recommends secret variables, variable groups, or Azure Key Vault for Azure Pipelines, mapping secrets into environment variables rather than printing or passing them on a command line.
Use the narrowest FAQ Hub preset that works: read-only for inspection, draft sync for reconciliation, and publisher only where the release process genuinely needs it. Keys are individually revocable and product-bound; tenant and product IDs do not come from the manifest.
Make documentation part of the definition of done
A practical release policy can be simple:
- a workflow, permission, or pricing change requires a documentation change in the same pull request;
- CI validates Markdown, links, and metadata;
- the sync job creates and reviews a FAQ Hub plan;
- merge applies drafts;
- an authorised release step publishes the approved revisions;
- scheduled drift checks compare repository state with exported FAQ Hub state;
- unanswered support questions feed the next documentation backlog.
That turns documentation from an afterthought into a release artefact. The assistant improves because the underlying knowledge changes with the product, not because somebody remembers to “retrain the bot” weeks later.
Where FAQ Hub is better than a custom copy job
| Custom Git job concern | FAQ Hub control |
|---|---|
| Broad CMS credential | Product-scoped key and least-privilege scopes |
| Blind overwrite | Dry-run plan and revision conflict checks |
| Duplicate retries | Idempotency ledger and resumable operations |
| Source/CMS ownership collision | Stable external IDs and managed fields |
| Draft and live content mixed together | Draft-first apply and separate publish permission |
| Delete-by-absence | Explicit archive candidates and recoverable archive operation |
| Bot corpus refreshed separately | Shared publication, search, chat, and portal refresh lifecycle |
FAQ Hub is not the Git event listener or Markdown compiler. It is the safe content control plane your automation calls after those source-specific steps.
Start with the cleanup workflow in How to Clean Up a Knowledge Base Before Launching AI Support, then decide what happens when even current documentation does not contain the answer.
Next: When AI Support Cannot Answer: Human Handoff Without Starting Over.