Would Your Team Trust Its Own Wiki? A Practical Knowledge Base Audit

Pick an operational question your team answered last week. Something like "How do I request production access?" or "What should I check before restarting this service?"

Ask someone who did not write the documentation to find the answer in your wiki. Let them start wherever they normally start. Do not give them the page title.

Watch what happens after they find something.

Do they follow the instructions? Check the date? Ask a colleague whether the page is still accurate? Abandon the wiki and search chat?

That last step matters. A knowledge base can contain the correct answer and still fail if readers cannot tell whether they should use it. Once checking with a colleague becomes the default, the wiki is an extra stop on the way to getting help.

Before replacing your documentation platform, run this assessment. It works with whatever wiki you already have, including a folder of Markdown files. The goal is to measure whether people can find an answer they trust enough to act on.

Start with questions people actually ask

Build a test set of 10 questions from recent support tickets, onboarding conversations, or incident follow-ups. Ten is a manageable starting sample, not a statistical benchmark.

Use the language people used when they asked for help. A ticket asking "Who approves access to the billing database?" is a better search test than the exact heading "Billing Data Access Authorization Procedure."

Include a consequential question where following an outdated answer could cause trouble. Also include a question whose answer recently changed. These expose weaknesses that an easy lookup can miss.

For each question, identify the expected answer and who can verify it. If nobody can establish the correct answer, record that as a documentation gap before testing search.

Keep a worksheet:

Question	Expected answer or page	Verifier	Test reader	Result
Who approves billing database access?	Current approval path	Database service owner	Recent hire	Pending
What should I check before restarting the worker?	Current restart prerequisites	On-call maintainer	Adjacent-team engineer	Pending

Do not repair the pages yet. You need a baseline of what readers encounter today.

Test search without coaching the reader

Ask two people with different levels of familiarity to work through the questions independently. Include someone who does not already know the wiki's structure.

Have them use their normal accounts. An administrator finding a restricted page says little about whether its intended audience can find it.

Set a time limit before starting. Three minutes per question is a reasonable local experiment; adjust it to the task. Apply the same limit when you repeat the assessment.

Record:

• The first query and any reformulations.
• Whether a useful answer appears in the first five results.
• The page the reader ultimately chooses.
• Time until the reader says they have an actionable answer.
• Whether they would act on it or ask someone to confirm.

A correct page appearing somewhere in the results is not sufficient. Search succeeds when a reader can recognize it as relevant and distinguish it from plausible alternatives.

Classify failures before prescribing a fix:

Observed failure	What to investigate
Correct page never appears	Indexing, access permissions, query vocabulary
Correct page appears but gets skipped	Title, snippet, unclear scope
Several conflicting answers appear	Duplicate content, missing canonical source
Reader finds the answer but asks chat anyway	Accuracy, ownership, review evidence
No page answers the question	Missing documentation

This distinction prevents an expensive mistake: buying a different search experience to solve a content maintenance problem.

Some failures do belong to the platform. Search that consistently misses accessible, relevant pages deserves investigation. But changing an index will not resolve two pages that confidently prescribe different procedures.

Separate freshness from edit activity

Open the pages readers selected, including incorrect ones. For each, ask:

What evidence would let a reader judge whether this applies now?

A recent modification timestamp is weak evidence. Someone might have fixed a typo without checking the procedure. An old page can still be correct if the underlying system has not changed.

Look for review information tied to the content:

Owner: Database Operations
Last verified: 2026-08-20
Verified against: Current production access request workflow
Review trigger: Approval policy or request portal changes
Status: Current

These fields can be ordinary text. The assessment does not require built-in review workflows or automated reminders.

"Last verified" should mean someone checked the relevant claims. For a procedure, that might mean walking through it in an appropriate test environment. For a policy, it might mean confirming the page with the responsible policy owner. Do not execute a risky production operation merely to refresh a date.

Mark each page as:

• Verified: A responsible person checked it against the current system or process.
• Unverified: It may be correct, but there is no adequate review evidence.
• Known stale: Something material is wrong or no longer applies.

Do not quietly label an unreviewed page "current" to complete the spreadsheet. Visible uncertainty helps readers decide when to seek confirmation.

Review frequency should follow the consequences of being wrong and how often the subject changes. A historical architecture decision does not need the same schedule as an access procedure. Event-based triggers, such as a service migration, may be more useful than a blanket quarterly reminder.

Check whether ownership means anything

A name at the top of a page is not an ownership system.

For every tested page, find the person or team responsible for accepting corrections. Send them one concrete question about its accuracy. You are checking whether responsibility works in practice.

An author who left the company is not a current owner. A broad department label is not useful if nobody knows where a correction should go.

For shared ownership, name a team and a reachable route. That could be an existing issue queue or another established internal channel. The important property is that a reader can report a problem without investigating the organization chart.

Ask the owner:

• Does this page still belong to your team?
• What change would make it need review?
• Where should readers submit a correction?
• Which page should win if another document disagrees?

Ownership needs time attached to it. If maintaining documentation is always work someone should do after everything else, adding an owner field will not change the outcome.

For pages without an owner, make an explicit decision: assign responsibility, archive them, or label them as unverified reference material. Avoid leaving abandoned instructions indistinguishable from maintained procedures.

Inspect the moment before someone acts

Search tests reveal discovery problems. Now examine whether the selected page supports the reader's decision.

Take the most consequential procedure in your sample. Read it as someone unfamiliar with the system.

Can you tell which environment it applies to? Are prerequisites stated before the instructions that depend on them? Does it explain how to recognize a successful result?

A restart guide, for example, should establish whether it concerns a development worker or a production service. If work must drain before restarting, that prerequisite belongs before the restart command. Readers also need to know when to stop and escalate.

Keep this proportional. A page explaining an expense code does not need an incident runbook template.

Pay particular attention to duplicated instructions. If onboarding material copies an access procedure, every future change creates another place that can fall behind. A short explanation linking to the maintained procedure may be easier to keep accurate, provided the intended readers can access it.

When retiring a duplicate, preserve a clear path to its replacement where possible. Readers may still arrive through old bookmarks or ticket links.

Measure use without confusing traffic with value

Page views alone cannot tell you whether documentation helped. Repeated visits might mean a page is useful, or that the reader keeps returning because it is confusing.

For your test set, count:

• Questions answered correctly within the time limit.
• Correct answers readers were willing to use without additional confirmation.
• Pages with a reachable owner and meaningful verification evidence.
• Questions that still required another person.

Keep correctness separate from confidence. A reader confidently following obsolete instructions is a more serious failure than a reader who notices uncertainty and asks for help.

If usage analytics are unavailable, the worksheet is enough to begin. You can also ask ticket handlers to note whether an existing page resolved a question, needed correction, or did not exist.

Do not set a target that discourages necessary escalation. Some decisions should involve another person. Documentation succeeds when it explains that boundary and identifies the appropriate route.

Repair a small slice, then retest

Choose a manageable batch from the findings. Prioritize failures where a wrong answer has meaningful consequences or where the same question repeatedly consumes staff time.

Give each repair an acceptance condition. "Improve the access documentation" is vague. "A new engineer can identify the current approver and request path using their normal account" is testable.

After repairing the pages, repeat the original questions. Use a new reader if possible so familiarity does not masquerade as improvement.

Keep the original wording even if your titles changed. Otherwise, you may accidentally make the test easier instead of improving discovery.

Expect tradeoffs. Archiving content can reduce competing answers but disrupt old links. Tighter permissions can protect information while making discovery harder for legitimate readers. Review requirements consume maintainer time. Record those costs alongside the benefit.

The useful outcome is a demonstrated improvement on real questions, plus a repeatable way to catch regression.

Where our own product lands on this

Adaptive Knowledge is a self-hosted Confluence alternative in the Hub division and part of the Adaptive Reservoir platform. It provides structured wiki and documentation with spaces, permissions, and version history, authored by your team and hosted behind your own wire. Migration off Confluence Server/Data Center is handled as a service.

Those are platform characteristics. They do not establish that a page has a responsible owner, that its instructions were verified, or that readers can find the answer using their own vocabulary.

If you are evaluating Adaptive Knowledge, bring this same question set to the evaluation. Test discovery and reader trust directly. For any platform, confirm whether the review practices you need require native features, manual conventions, or additional tooling.

Self-hosting also brings operational responsibility. Clarify who will maintain the deployment and handle recovery as part of the buying decision.

Moving documentation is an opportunity to identify stale pages and competing answers. That work still needs explicit ownership. Otherwise, the same unresolved questions follow the content into its new home.

Disclosure: I work at Adaptive IP Services, a Dallas based IT and security firm.

David J. Boggs
Founder and CEO, Adaptive IP Services

Adaptive Knowledge