Wiki search found the page. It missed the answer.

A support lead once asked a question that should have taken thirty seconds: “Why do exports stop at 10,000 rows?” The wiki search did exactly what it promised. It returned the help page, with the limit highlighted. Then the real work began.

The help page did not explain the reason. A repository issue blamed an old memory constraint. Farther down the search results, a decision note said that constraint no longer applied. The API reference still documented the limit, and nobody could find a release record that settled the matter. Four useful records; no safe yes-or-no answer.

This is where I draw the line between finding a page and searching company knowledge. When I already know that an export guide exists, a wiki result is perfect. When I need to tell a customer whether the guide is still true, keywords are only the start. I need dates, ownership and the links between the records.

The honest answer in this case is slightly awkward: the published limit is 10,000 rows; the original technical reason may be obsolete; there is no approved evidence that the product behaviour changed. That wording is less satisfying than “the limit was removed.” It is also much less likely to create a bad support promise.

A system can only produce that answer if it keeps the disagreement intact. Newer is not automatically better. A recent Slack message does not overrule an approved specification, while a current release note may legitimately supersede an old design decision. I want to see which passage supports each claim and when it was written, not a confident paragraph assembled from all four.

There is a second, easy-to-miss test: access. Suppose the repository issue came from a private incident review. If the person asking cannot read that review, its text must stay out of retrieval altogether. Removing the citation after the answer is generated is too late; the answer may already reveal the restricted fact.

None of this argues against a wiki. Policies, playbooks and the instructions people should follow belong in maintained pages with named owners. The trouble starts when we pretend those pages contain the whole history. Product decisions also live in tickets, code, release notes and discussions. Useful knowledge search shows the maintained answer beside that operational trail.

I test this with a small, deliberately messy set of questions. One asks for a known procedure. One asks why a recent decision was made. One crosses two sources. The last asks about something the sources simply do not establish. A reviewer opens every citation and notes how long verification takes.

That last question catches more problems than a polished demo. “No approved source explains this decision” is not a failed search. It tells the team exactly what is missing. An invented bridge between two documents looks more helpful for a minute, until somebody acts on it.

Wiki search gets you to the page. Company knowledge search is useful when the page is not enough—especially when the evidence disagrees.