How to Build an Internal AI Knowledge Base That Stays Current

Verdict

Build the governance loop before adding AI answers. Give every canonical process, policy, or decision one record, one accountable owner, a visible state, a review rule, revision history, and a retirement path. Let AI find conflicts and draft changes; require a human owner to approve high-impact knowledge. Guru fits designated verifiers and configurable automated verification, Slite for a simpler maintained wiki, and Tettra for a lightweight Slack-centered knowledge base.

This workflow is about owning company knowledge after it is written. It is separate from choosing a workplace-search vendor, searching company knowledge with AI, and configuring answers across Slack, Drive, and Notion. Those jobs retrieve distributed material. A governed knowledge base decides which answer is canonical and what happens when it changes.

Define what can become canonical

Do not ingest every chat, meeting note, and project file as equal truth. Start with recurring knowledge that has a decision-maker: policies, standard operating procedures, product facts, escalation paths, approved messaging, system runbooks, and durable decisions. Slack threads and meeting notes can supply evidence or reveal gaps, but they should not silently become policy.

Use one canonical record per process or decision. Each record needs enough metadata to govern it:

If two active records answer the same question differently, the system has a governance failure. Do not ask the model to average them.

Make every change recoverable

Use a draft → review → publish lifecycle. A published revision should retain its author, approver, timestamp, change summary, and previous version. Product launches, policy changes, migrations, incident follow-ups, and organizational changes should include a documentation check in their definition of done. This event-driven trigger catches drift earlier than a quarterly cleanup.

Guru's Card history can compare revisions and revert a draft. Slite's document history records a version after five minutes of inactivity and can restore an older document, although restoring an earlier collection version is not supported. These are recovery controls, not editorial review: a reversible wrong answer is still wrong until an owner checks it.

Review by risk and change rate

A single annual reminder is too slow for access procedures and too noisy for stable principles. The following intervals are suggested starting points, not vendor defaults or compliance requirements. Set the interval from consequence and volatility:

Guru verification exposes the verifier, last verification, and intervals from 30 days to one year or “Does not expire.” Its Knowledge Agents can run daily quality checks, with auto-verify enabled by default for Knowledge Agents created after January 2026 and auto-unverify off by default. A verified state alone does not prove a human reviewed that revision. Slite verification gives verified docs more weight in Ask and Search and distinguishes expired verification from content marked Outdated: Outdated docs are ranked lower in Ask and excluded from Slite Agent. Treat these states as routing signals. For high-impact records, “verified” must mean a named expert reviewed the current revision.

Retire knowledge without erasing history

Retirement needs its own workflow. Trigger it when a system is replaced, a policy expires, a team dissolves, an owner leaves, or a newer record supersedes the old one. Before archiving:

1. Link the successor from the old URL and update incoming links.
2. Record the retirement reason, owner, date, and retention requirement.
3. Remove the record from default AI-answer sources and active search.
4. Preserve the last approved revision for audit or rollback.
5. Delete only when the retention policy permits irreversible removal.

Guru supports scheduled Card archival, warns authors to check incoming links first, and restores only the last published version. Synced Cards must be removed at their source. Slite archives retain original access controls and can be restored; permanent deletion cannot be undone. Slite can also search archived docs when that source type is deliberately selected, so test default answer scope instead of assuming “archived” means unreachable everywhere.

Pick the operating model, then the product

Pricing and product behavior checked October 23, 2026.

Choose Guru when designated ownership and configurable verification controls are operating requirements and the implementation package is useful. Choose Slite when the team will consolidate durable knowledge in a clean wiki and wants public pricing. Tettra is the lighter third option. For retrieval across a large existing app estate, compare Glean vs Guru before forcing distributed material into a new authoring system.

Run a pilot that can fail

Use 30–50 real records from one function, including a superseded policy, an orphaned page, a future-dated change, two contradictory answers, and a record that must be archived. Require these acceptance criteria:

• Every active record has exactly one owner, status, effective date, evidence link, and review rule.
• A departure test reassigns every owned record before account removal.
• Ten representative questions cite active canonical records; conflicts or missing evidence produce an abstention, not a blended answer.
• A changed record creates a reviewable revision, and an operator can restore a known prior version.
• A superseded URL points to its successor; archived content disappears from default AI answers within the measured product-specific refresh window.
• At least 90% of due high-impact reviews finish inside the agreed SLA; overdue items are visibly downgraded or removed from answer sources.
• The owner can export active records plus lifecycle metadata and explain the recovery path after cancellation.

This site has not run that pilot. Permission leakage and revocation belong in the separate cross-source permissions test, but they remain go-live blockers.

What practitioners add

In a February 8, 2025 r/sysadmin thread, u/spacesheep10 described a small team whose wiki went stale while repeat questions returned to Slack. In the discussion, u/0w1Knight described rotating wiki duty, converting service-desk discoveries into update tasks, and feeding organizational and software-purchase changes into the same queue. That is one anonymous practitioner report, not measured evidence. Its useful lesson is operational: scheduled review catches age, while work-system events catch change.

For role-specific delivery of that maintained knowledge, use the new-hire knowledge-assistant guide.

Sources & further reading

• Guru pricing
• Guru content verification
• Guru Card history
• Guru Card archiving and deletion
• Slite pricing
• Slite doc verification
• Slite document history
• Slite knowledge maintenance
• Slite doc archiving
• Tettra pricing
• Tettra knowledge-management dashboard
• Knowledge-base maintenance discussion by u/spacesheep10