# How to keep a Pylon knowledge base accurate after every release A release renames a setting, but the help center still shows the old name and steps. Customers and Pylon's AI agent can then use the stale instructions. KB articles are [one of the sources Pylon's AI features draw on](). Your support team may discover the mismatch only when a ticket or escalation arrives. EkLine provides the accuracy workflow around that help center: scheduled agents draft missing or corrected articles from Pylon tickets, while a custom scheduled prompt can check the product changes you specify against relevant articles. Your team reviews the proposed changes and controls when they reach Pylon. Keep the knowledge base under review from two directions. Tickets tell you what is missing or confusing. Releases tell you what may have become wrong. Start the release check from what is shipping and give each fix one named approver. Pylon's own guide recommends [updates with every significant product release and a quarterly audit of the full knowledge base](). ## TL;DR - Tickets show you which articles are missing or incomplete\. Releases show you which articles became wrong\. Each direction needs its own check\. - Pylon provides ticket-based gap signals. Add release context to find articles affected by changes before the next support issue. - A release\-time check starts from the list of user\-facing changes, searches the help center for every old name and step, and gives each fix one approver before customers see the release\. - Run three cadences with one owner: a weekly ticket check, a check for every release, and a quarterly sweep\. ## Tickets show what is missing, releases show what became wrong A knowledge base fails customers in two ways\. In the first, the article was never written, and customers keep asking a question the help center does not answer\. Your ticket queue shows this well, because repeat questions are the signal\. EkLine has written about how [your support tickets are a documentation backlog in disguise]()\. In the second, the article was right when you published it and a release changed the product underneath it. A support ticket may arrive later, when a customer follows the old steps and they fail. If that article is available to an AI agent, stale instructions can also enter its answers before your team notices. In a [Slite survey of 143 founders, operators, and engineers about internal docs](), 41% of respondents who had seen an AI tool surface a stale document and produce a wrong answer said the wrong information had reached a customer. That is a reported experience within Slite's survey group, not an industry-wide failure rate. Support teams have described release maintenance as manual work. In an [Intercom community feature request](), Audrey Ware asked for release notes to identify affected articles and suggest edits. Cassie Penatzer's April 16, 2026 reply described the time spent finding those articles. This is practitioner evidence of the task, not proof that the vendor still lacks a solution: Intercom now documents [Fin Operator's product-update-to-article workflow](), with proposed changes reviewed before they go live. ## How EkLine runs the accuracy workflow EkLine connects ticket evidence, specified product changes, and reviewable knowledge-base edits in one accuracy workflow. Use the ticket template for recurring gap discovery and configure the release check for the changes your team needs to validate. For the ticket side, the [Improve Pylon knowledge base scheduled agent]() reviews recent Pylon tickets for questions that the knowledge base should have answered, then drafts missing or corrected articles for review. This template delivers knowledge-base drafts in Slack by default rather than repository changes. Review its prompt and notification settings before enabling it. For the release side, configure a custom scheduled prompt. Each run executes the prompt against your connected repository. Specify the release context, managed Pylon articles, and draft output you want; the knowledge-base management guide illustrates a related check by comparing a billing FAQ with the latest pricing page. Set a recurring cadence, or use Run now before a release. Treat this as a configured workflow to test, not an automatic release-event trigger or a claim that the ticket template checks code. Keep publication approval with a named person. In the [documented knowledge-base workflow](), review the diff under View All Changes, then use Update KB to write the edits back. That action immediately changes a live article's content; for Pylon it does not change the article's published or unpublished status. Setup requires Docs Agent and knowledge-base management access, a Pylon API token, selected managed knowledge bases, editing permission, and a Default author for new articles. Before: the support lead reads tickets individually, chases the ship list, and searches for old setting names by hand. After: EkLine runs the configured ticket and release checks, drafts the corrections, and brings the changes to a reviewer. The reviewer checks each fix in View All Changes, and the authorized publisher uses Update KB. Pylon remains the article destination throughout. The ticket template is documented for ticket review; do not assume it also audits releases or code. A release check depends on the context and managed articles you make available, and it needs a test run before you rely on it. Scheduled agents require Docs Agent and a connected repository. Knowledge-base management is available on request. To evaluate this accuracy workflow, [follow the walkthrough for managing a Pylon knowledge base with EkLine](), then request access at [support@ekline.io]() with your organization name. Test one ticket batch and one release against a small set of managed articles before expanding the cadence. ## Pylon signals and publishing controls The table separates support-driven signals from the controls used to review and publish a correction. The release check connects the ship list to the articles that need to change. | Pylon feature | What starts it | What you get | | --- | --- | --- | | [Missing Content]() (under Insights) | A support agent sets an issue's Resource status to "Needs new article" or "Needs article update." | A queue where you select issues and generate drafts with Article Generation. | | Topics | Common questions absent from connected documentation. Suggestions begin after 300 logged issues; this AI Assistant feature is available on select plans. | Topics marked "Missing resources," "Needs update," or "Up to date." | | [Improvements]() | The AI agent's escalation reason, the issue topic, and how often it comes up. | A suggestion to write or update an article, with "AI suggested edits" you Accept or Reject. | | [Article Generation and Copilot]() | An issue conversation for generation; selected article text for Copilot edits. | A solution article draft, warnings about similar articles, and AI assistance revising text. | | [KB Analytics]() | Reader traffic, searches, and feedback. | Views, "Top searches with no results," feedback scores, and alerts to Slack or email. | | [Article Review]() | An author clicks Request Review. | Approvals, requested changes, and inline comments. | | [Synced Blocks]() | An author embeds a shared block in several articles. | "Edit the block once, and every article that embeds it updates automatically." | The first five rows use support activity or article usage; the last two cover review and shared edits. Pylon's [knowledge base page]() describes turning conversations across Slack, Microsoft Teams, email, and in-app chat into suggested articles and updates. Its AI resource access differs by feature: AI Assistants can use replies, internal notes, fields, KB articles, recordings, and training data; AI Agents use configured KB resources and selected training data, rather than historical issues. Pylon also supports [configurable Skills with connected tools](). The workflow here assigns recurring, repository-grounded accuracy checks and managed-KB corrections to EkLine; it does not assume Pylon is limited to the signals in this table. ## Why ticket signals need release context The ticket-based checks above can already produce drafts and suggested edits. Missing Content collects issues that agents flag, while Improvements uses the AI agent's escalation reason, topic, and frequency to suggest article work. Reviewing another routine costs time, so each release check should name the changed behavior and the articles it needs to verify. Use ticket evidence to prioritize corrections and release context to find affected pages that have not yet produced a support issue. Those issue-based queues need support activity to supply evidence, while search and feedback reports need reader activity. An Improvements suggestion can follow an escalation; a Missing Content entry can follow a flagged issue. Topic suggestions begin after 300 logged issues and require an eligible plan. A zero-result search can expose missing terminology, but it does not identify every existing article with old instructions. A feedback score also depends on someone rating the page. These signals help prioritize work; they do not replace checking a known product change against affected content. Pylon's guide recommends article updates with significant releases. To find affected content before customers encounter it, start the check from the release itself. ## How the release\-time check works ![Flow of five steps in the release-time check: get the ship list, list the old words, search the help center, assign one approver per fix, publish with the release]() The release\-time check, step by step\. The release check starts from the product change and looks for articles it may have made wrong. Run it for every release a customer can see, with enough time for review before rollout. The steps below define the check whether the team is testing an EkLine custom prompt or verifying its draft output. 1. Get the list of user\-facing changes before the release goes out, from the release notes, the changelog, or the product manager\. In a [September 11, 2024 community reply](), Intercom's senior knowledge manager Beth-Ann described getting involved before shipping and typically receiving at least four weeks to prepare new content. That is a historical operating example, not a required lead time or a claim about Intercom's current process. 2. For each change, write down the old words customers would have read: setting names, button labels, menu paths, limits, and steps that moved or disappeared\. 3. Search your help center for each old word and list every article that contains it\. Check your Synced Blocks too, since one edit there updates every article that embeds the block\. 4. Name one approver for each fix, usually the product manager or engineer who shipped the change, and add them as a reviewer under Review & Publish if using Pylon's review flow. The author drafts the edit and clicks Request Review. Require review before publishing where appropriate, and check publishing permissions: Pylon allows reviewers with publishing permission to publish without a separate approval. 5. Publish the approved edits when the release reaches customers\. [Knowmax's knowledge-ops guidance]() recommends reviewing content affected by launches, policy changes, pricing updates, or regulation within 24 to 48 hours after the change. Use publication with the release as the target for known changes, rather than treating that window as an acceptable delay for every update. Teams have done this by hand for years. In an [older HelpDocs roundup](), Front's support manager met the product team weekly and kept a running list of articles to update, while Wistia's team watched GitHub pull requests. In the 2024 Intercom reply above, Beth-Ann reported setting aside time from 13 support agents for product-change audits. These are historical examples of coordination work, not current staffing requirements. EkLine makes the repeated checks and draft preparation a configured routine, while the team retains review and release timing. Keep the old words from each release on a running list\. The next weekly ticket check can then show whether any article slipped through\. ## Owners, cadence, and checkpoints Assign one knowledge-base owner to coordinate the routine and its reviewers. Knowmax's guidance recommends a named person responsible for each article's accuracy. One knowledge-base owner coordinates the three checks below; subject-matter reviewers own individual fixes. | Check | When | Inputs | Done when | | --- | --- | --- | --- | | Ticket check | Weekly | Missing Content queue, Improvements suggestions, topics marked "Needs update," top searches with no results, feedback alerts | Each flagged issue has a draft, an approved edit, or a note that it is not knowledge base material | | Release check | Every release with a user-facing change | Release notes, changelog, or the product manager's ship list | Every article that names a changed setting or step is updated, with one approver per fix, before customers see the release | | Quarterly sweep | Every quarter | KB Analytics views and feedback scores, plus articles nobody touched since the last sweep | Every article has an owner and has been read against the current product | The release and quarterly rows follow Pylon's recommended cadence; the weekly row makes ticket review repeatable. The release row explicitly starts from a known change before rollout, while the quarterly sweep checks the wider inventory. Knowmax also recommends periodic review of evergreen content, giving 90 days as an example. These are operating targets, not a guarantee that every mismatch will be found. ## One worked cycle Take one illustrative week. On Monday, the support lead reviews EkLine's scheduled ticket drafts alongside Missing Content, Improvements, and searches with no results. They check issues that agents flagged for article updates, use Article Generation where needed, and accept or reject suggested edits. Each correction gets an owner before it is published. On Wednesday, a release will rename a setting. Earlier in the week, the product manager shares the ship list. The support lead gives EkLine's custom release check the changes and relevant managed articles, then runs it before rollout. The reviewer checks the drafts against the product and searches for the old name, including synced blocks. The product manager approves the corrections through the team's chosen review flow, and the authorized publisher applies the edits when the release reaches customers. The next Monday, the ticket check also tests the release check. If a ticket still quotes the old setting name, the support lead investigates a missed article, a saved copy, or another source before deciding what to fix. If an article was missed, they correct it and add the search term or context that would have found it to the next run. ## FAQ ### How do you know when a knowledge base article is outdated? Check from tickets and releases. A support agent can flag an issue for an article update, Improvements can identify articles needing revision from AI-agent experience, and readers can rate content unhelpful. Separately, a release can change a setting, label, or step that an article still describes. Checking the release before rollout gives the reviewer a chance to correct that mismatch before it produces a support issue. ### Can article view counts tell us which content needs updating? View counts help prioritize review, but they do not show whether instructions match the product. Pylon separates human and non-human traffic, so use the relevant traffic view when estimating customer exposure. Give heavily used articles priority in the quarterly sweep, and use release context to identify content affected by a specific change. ### How can AI improve my knowledge base? Pylon's Article Generation drafts from issues, Improvements suggests edits from AI-agent experience, and Topics groups uncovered questions. EkLine schedules drafts from ticket evidence and configurable checks against the product or release context you supply. Review the proposed fixes against that evidence before publishing; an AI system can use stale instructions if they remain in its accessible sources. ### Does EkLine replace Pylon? Pylon remains the destination where your team manages and publishes knowledge-base articles. EkLine replaces the fragmented accuracy work around it: reading ticket evidence, checking the product changes you specify, drafting corrections, and bringing those changes to a reviewer. Your team keeps publication control. Start with one release and one named reviewer. Use the EkLine setup walkthrough above to connect the evidence, inspect the proposed corrections, and verify the updated Pylon articles after publication. Expand the cadence only after that cycle produces changes your team can review and trust.