Internal knowledge search and wiki search solve different jobs

A wiki and retrieval answer different questions. A wiki is good at publishing an authored page with an owner, a stable place to follow and instructions people are expected to use. Search inside that page helps when you know the terms or already suspect which page is canonical.

Retrieval helps when the question is easier to ask than the document is to locate. In Krynia today, that means importing one public GitHub repository or a bounded set of Markdown, text or CSV files, waiting for indexing and asking over that material. It does not mean searching every company system or silently adding Slack, Google Drive or private repositories.

Consider a labeled hypothetical: an export guide says the limit is 10,000 rows, an older issue says a memory constraint once forced a lower limit, and a release note says the export path changed. Retrieval can bring these passages together, but the team still has to check which record is approved and current before promising a limit.

The citation makes the result inspectable, but it does not make it true by itself. Open the exact passage, read the surrounding section and check the document version or GitHub commit that was indexed. If the published document has changed, refresh the source and ask again; an older citation records earlier evidence rather than guaranteeing today's wording.

Conflicts need the same care. An approved policy, a draft proposal and a release note may all mention the same rule. A useful retrieval result keeps those passages visible so a reviewer can consider authority and dates. It should not flatten disagreement into a single sentence just because that sentence sounds more decisive.

This is why retrieval complements a wiki. The wiki can remain the maintained home for the policy. Retrieval can help someone find that policy, connect it to a related repository explanation and expose the exact passage to verify. When the answer is missing, the gap is a prompt to improve the authored source, not a reason to replace it with generated prose.

The workflow also has a hard boundary: answers stay within the imported source scope and the access granted to the workspace. A private conversation, an unimported ticket or an unsupported provider is not evidence Krynia can use. Put a stable decision into a supported published source before relying on it.

Evaluate the combination with a few real questions: one known procedure, one cross-document question, one conflict and one question the sources do not answer. Reviewers should open every citation, check its version and record whether the result led them to the canonical page. Verification time matters as much as a fluent summary.

Use a wiki to author and maintain what the team should follow. Use retrieval to locate and compare evidence across the supported material you have imported. The two jobs reinforce each other when the final answer points people back to a source they can read and update.