How do we make internal knowledge searchable?

Choose one question and one collection.

An illustrative internal support search could answer: “Which checklist applies to this type of release?” The collection might contain current operating notes and approved product help. Start there before including every old document, conversation, or personal drive.

The initial examples should include an ordinary answer, a question that needs two sources, and a question the collection cannot answer. Keep the expected evidence beside each example. That makes it possible to judge search quality without rewarding whichever answer sounds most confident.

Some tasks need a searchable list and a good excerpt. Others benefit from a draft explanation. Those are separate decisions; a language model is not required merely to make documents findable.

Make source identity and ownership explicit.

Keep a stable document identity, title, owner, version or update date, and a route to its original. Preserve headings or sections when splitting a long document so an excerpt can be interpreted in context.

Agree how corrections, deletions, and withdrawn guidance reach the search collection. A nightly update may be adequate for one task and misleading for another. A result should expose the freshness relevant to the question rather than imply that every source is live.

An old document can remain useful history without being current instructions. That distinction must survive indexing and summarisation; otherwise a retired policy may become the easiest answer to retrieve.

Resolve conflicts through evidence.

Consider an invented conflict: an older checklist says artwork is optional for a draft, while a current submission guide requires artwork before review. Both can be true because they describe different workflow states. An answer should identify the stage before deciding that one source overrides the other.

Apply access before retrieving context.

The application should limit candidate sources to the current user’s permitted collection before sending material to a model. Hiding a source link after generating an answer would not repair disclosure of the source’s content.

Test search, excerpts, summaries, and generated answers with more than one role. A person who lacks access should not receive a hint about a private record simply because the system found it. Document content is evidence to interpret, not authority to change access or execute an action.

A public-help collection and a private account query are different surfaces. Keep their sources and permitted actions distinct, and recheck authority when a proposed tool action would change a record.

Our product uses a bounded knowledge collection.

In Velveteen’s committed knowledge-base code, a generated corpus combines FAQ material, guide extracts, help inputs, and selected Markdown documents. Each item retains a source identifier. A router selects relevant items; the answer preparation supplies their text and selects scoped tools for an information request.

The guide extractor reads direct answers and FAQs rather than automatically ingesting every word of every guide. That is an important coverage limit. We do not claim that all product documentation is searchable or that every answer displays a citation.

This is implementation evidence from our own product, not a client knowledge-search deployment. The example shows why source coverage should be documented before promising that an assistant can answer any question about a business.

Evaluate evidence quality and the unsupported case.

For each representative question, check that the correct source is found, the excerpt contains the needed context, its version applies, and the user has access. If an answer is generated, compare its claims with that evidence. Also test an unrelated question and a withdrawn source.

When the evidence does not support an answer, return useful next steps: show the sources that were searched, identify the missing fact where appropriate, or route the question to its owner. Avoid claiming that absence from the collection proves absence from the business.

The AI-failure guide covers the broader recovery experience. This guide’s acceptance condition is narrower: people can locate permitted, relevant evidence and understand what it does and does not establish.