Canonical source for synced help content: what to edit and what to sync

The canonical source for synced help content is the one copy of an article where an authorized editor makes and approves changes. Every other copy is a destination: a help center page, an AI assistant’s knowledge, or an internal search result. If you can’t name the editing home, you don’t have a source. You have competing drafts.

When a feature changes and the copies in a repository, a support platform, and a knowledge tool disagree, that is documentation drift in practice. Sync rarely fixes it alone. Below: how to find the source, which systems are destinations, and what keeps the source current.

What counts as the canonical source

The canonical source is where edits are made and approved, and destinations then receive them. It isn’t necessarily the first version written, or the page customers see.

Code changes, release notes, and tickets are different. They tell you an article needs work, but they aren’t the article. A merged pull request signals that the authoritative copy must be revised. It doesn’t replace revising it.

How to identify the authoritative article when copies disagree

When copies conflict, don’t ask which one is newest. Ask where edits actually persist. A change made in a destination either gets overwritten on the next sync or silently forks the content. Neither outcome makes that system the source.

Find the editing home

A repository isn’t the source just because product code lives there. It’s the source when edits persist there. Intercom, for example, requires edits to its GitHub-synced Markdown articles to be made in GitHub.

Check the authority signals

• Only authorized editors can change the article here
• Approvals and version history are recorded
• The article keeps a stable identity across updates
• Changes have a defined direction to reach other systems

A worked example (illustrative)

Say a team renames a setting. The repository Markdown says “Settings > Access,” the public help center says “Settings > Team,” and the AI assistant gives a third path.

1. Identify the authority. Edits to these articles are made through pull requests, and the help center copy is synced from the files, so the repository is canonical.
2. Route the fix there. Edit the Markdown, not the help center page or the assistant’s answer.
3. Have someone verify and approve it. A reviewer checks the steps against the product and merges.
4. Sync to destinations.
5. Check what updated. Open the public page, then ask the assistant the same question. Both should show the new path.

Which systems are destinations, not sources?

A destination consumes an article without owning its edits. Roles are assigned per article, not per tool. Your help center can be canonical for billing articles and a destination for API articles that originate in a repository.

• Public help center: customers browse or search the article to complete a task themselves.
• Support assistant or in-app help surface: an AI agent or widget retrieves the article to answer a question inside the product.
• Internal search: support agents find the article during a live conversation.

Availability to an assistant isn’t the same as visibility to customers. Intercom’s GitHub sync shows this. Synced Markdown can be used by Fin, but those articles are unlisted and can’t be added to a browsable Help Center collection.

Why sync, import, and search access are different from an update workflow

Each of these moves content. None of them detects that content is wrong. An update workflow has to notice that the product changed and that a specific article no longer matches it.

• Sync carries source edits. It propagates a change made at the source and nothing more. If nobody edits the source, sync faithfully distributes stale content. Intercom’s internal-content sync reflects source edits, and its GitHub sync applies changes when edits to synced Markdown are merged.
• Import creates a copy to maintain. In Intercom, imported internal articles become editable native copies and stop syncing with the external source. That suits a migration, but the imported copy is now yours to keep current.
• Search access makes content available, not current. Website re-crawling retrieves changed pages but never edits the original. Guru’s MCP connection can expose search plus drafting or editing tools to an AI client. Access alone still doesn’t create a product-change trigger, a source edit, and a review step.

What keeps help content current when features ship?

If you’re asking which tools update help center articles automatically when you ship features, here’s the short answer. Teams use code and pull-request signals, ticket signals, scheduled reviews, and AI generation inside the helpdesk. What matters is where each change lands and who approves it.

The maintenance mechanism has three parts, and all three must touch the canonical copy:

• Detect a relevant product change, such as a merged pull request, a changelog entry, or recurring tickets.
• Propose a specific change to the canonical article, not to a destination.
• Review and publish, so every destination receives the approved version.

A connector that only copies or retrieves content supplies none of the first two steps. It is plumbing, not maintenance.

Match the maintenance approach to the editing home

• Release-linked manual review: fits teams that want full editorial control and check affected articles each release. The limit is ongoing writing work that grows with shipping pace.
• Git-backed documentation automation: fits teams whose docs already live in a repository. Mintlify says its automations can propose updates when product code changes, with edits landing in a version-controlled repository. The limit is that your editing home stays a repo, which suits developer docs better than support-owned help centers.
• Help-center-first maintenance: fits teams whose canonical articles live in the help center. Ferndesk connects to a GitHub repo, and Fern monitors commits, tickets, and changelogs, then drafts edits to existing articles or new ones. A person approves before anything publishes. GitHub stays evidence, and the help center stays the editing home. Scheduled content audits catch what signals miss. The limit is that you still review drafts. That’s a review task, not a writing task.

Ferndesk’s one-click migration imports your existing help center, but that import is only the starting copy. The monitoring and approval loop is what keeps it current afterward. Not every integration is two-way sync: the GitHub connection gives Fern evidence to draft from, and nothing publishes without approval.

Ferndesk example: commits reveal gaps in existing help articles

RightMessage keeps its 30,000-word help center current using git commits, with Ferndesk drafting the updates. As Brennan Dunn, Founder, RightMessage, puts it: “It sees in our git commits that there’s a gap and it’ll help us effectively write the content for that.”

Frequently asked questions

Can two systems both be canonical for the same article?

No. Two independently edited copies create conflicting authority, and one will eventually be wrong. Separate audience or language versions can have different owners. Each version still needs exactly one clear editing home.

Is a canonical URL the same as a canonical content source?

No. A canonical URL tells search engines which page to index when duplicates exist. It says nothing about where editors maintain the article or which copy wins when versions disagree.

Does connecting GitHub automatically update public help articles?

It depends on the connection and the destination. Syncing already-edited Markdown into an answer tool is different from automation that proposes edits after product changes. Intercom’s GitHub-synced articles, for instance, aren’t browsable Help Center articles at all.

Conclusion

The canonical source is the one approved editing home for an article. Destinations display or retrieve it. Staying current also takes a reliable way to turn product changes into reviewed source edits. For the full picture, see the guide to AI-powered help center maintenance.