A knowledge base template for people and AI agents must make trust machine-readable. A folder tree helps humans browse, but reliable retrieval also needs source identity, ownership, permissions, verification status, freshness, and citation-ready passages.

Status determines whether people and agents may treat a knowledge record as current and authoritative.

Copy this knowledge base template

Use related databases for Knowledge, Sources, Owners, Decisions, and Review Tasks.

Knowledge database

Sources database

Review Tasks database

Store review ID, knowledge ID, trigger, owner, due date, severity, required sources, decision, result, and verification timestamp.

The short answer

A trustworthy knowledge base needs seven contracts:

1. every important claim has a retrievable source;

2. every page has an accountable owner;

3. Draft, Verified, Stale, and Superseded are distinct states;

4. permissions are preserved during retrieval and answer generation;

5. verified content has a review window;

6. people and agents cite the canonical knowledge record;

7. expired or contradictory knowledge routes to review instead of silently answering.

The template should optimize for the moment someone asks, “Can I rely on this?”—not only for the moment an author creates a page.

Knowledge record template

[Knowledge title]

Answer

Write the direct answer in two to five sentences. State the scope, audience, effective date, and any important exception.

Applies to

• Audience:

• Product, system, or region:

• Effective from:

• Expires or next review:

• Sensitivity:

• Canonical owner:

Procedure or policy

1. [Step or rule]

2. [Step or rule]

3. [Step or rule]

Preconditions

• Required identity or role:

• Required system state:

• Required approval:

• Required source:

Exceptions

Use the reusable template

Use the verified knowledge inventory below to assign every article an owner, source, claim scope, access class, verification date, review date, and explicit agent-ready status.

Sources

Known contradictions

• [Source or observation]

• Resolution owner:

• Resolution due:

• Temporary guidance:

Verification

• Status:

• Verified by:

• Verification scope:

• Last verified:

• Next review:

• Review trigger:

• Supersedes:

• Superseded by:

Agent-use contract

Agent may

• retrieve this record for authorized users;

• quote or summarize supported passages;

• cite the canonical URL and source IDs;

• identify missing or stale fields;

• propose edits in Review status.

Agent must not

• expose content outside its permission boundary;

• treat Draft, Stale, or Superseded content as current policy;

• remove qualifiers or exceptions;

• invent a source;

• approve its own edit;

• answer from this record after a blocking contradiction without escalation.

Related knowledge

• [Canonical related record]

Knowledge lifecycle

Draft

The page is being written. Agents may help structure or propose content, but retrieval systems should not present it as approved guidance.

Review

The owner or verifier checks accuracy, completeness, scope, permission class, sources, and effective dates.

Verified

An authorized verifier confirms the page for a defined scope and review period. Notion page verification can mark important wiki pages as official, and verification can expire after a chosen period.

Stale

The review date passed, a source changed, or a trigger fired. The record remains visible for investigation but should be down-ranked, qualified, or excluded from authoritative answers according to risk.

Superseded

A newer canonical record replaced it. Preserve the link between versions so citations and decisions remain explainable.

Archived

The record is retained according to policy but is not active knowledge.

Verification is scoped, not absolute

“Verified” should answer:

• verified by whom;

• for which audience;

• against which sources;

• on what date;

• for how long;

• under which product, region, or policy version;

• what would invalidate it.

Avoid indefinite verification for frequently changing procedures, prices, APIs, or legal policies. Use a review window that matches the cost of being wrong.

Notion’s official verification guidance recommends focusing verification on essential, frequently referenced, decision-relevant sources of truth. It also supports temporary verification periods and owner notifications when verification expires.

Ownership model

Use three roles:

Author

Creates and maintains the content. The author may also be the domain expert, but authorship alone does not grant approval authority.

Owner

Accountable for accuracy, review cadence, and routing questions. Missing ownership should create an exception.

Verifier

Has authority to mark the knowledge current for its declared scope. High-risk policies may require a different verifier from the author.

For small teams, one person can hold multiple roles. Keep the fields separate so responsibility is still explicit.

Source-backed passages

Write pages in self-contained sections that remain correct when retrieved alone. Each passage should include the qualifiers needed to avoid a misleading answer.

Weak passage:

Reset links expire quickly.

Stronger passage:

For standard end-user accounts, password-reset links expire 30 minutes after issuance. Admin-assisted resets follow the privileged-access procedure in KB-1042.

Attach the source identity and effective date. Retrieval may separate a paragraph from its page title, so critical scope should not depend on distant context.

Permission-aware retrieval

The answer path should preserve authorization end to end:

1. identify the requesting user and workspace;

2. retrieve only records that identity may access;

3. apply status and freshness policy;

4. rank verified, current, canonical knowledge;

5. generate from authorized passages;

6. cite records the user can open;

7. log retrieval and answer provenance;

8. route blocked or contradictory cases to an owner.

Do not retrieve broadly and hide unauthorized citations afterward. Filtering belongs before or during retrieval, not only in presentation.

Authorization and trust filtering happen before generation; citations and audit prove the result afterward.

Agent answer contract

A production answer should return structured provenance:

{
  "answer": "For standard end-user accounts, reset links expire after 30 minutes.",
  "knowledge_ids": ["KB-1017"],
  "source_ids": ["SRC-204"],
  "verification": {
    "status": "verified",
    "verified_at": "2026-05-21",
    "review_due": "2026-08-21"
  },
  "scope": {
    "audience": "end_user",
    "region": "global"
  },
  "exceptions": ["Privileged accounts use KB-1042"],
  "confidence": 0.94
}

Validate IDs, status, dates, permissions, and citations. Confidence does not replace provenance.

Retrieval priority

A practical ranking policy can prioritize:

1. permission match;

2. canonical and Verified status;

3. scope match;

4. source quality;

5. freshness;

6. semantic and lexical relevance;

7. explicit relationships;

8. usage and feedback signals.

Never let popularity outrank permission or current policy.

Contradictions

A knowledge system should preserve disagreement until an authorized person resolves it.

When sources conflict:

• record both source IDs;

• state the exact conflicting claims;

• identify which audiences or dates differ;

• stop automatic verification;

• assign a resolution owner;

• set a due date and severity;

• provide a safe temporary answer if authorized;

• record the final decision and effective date.

An agent can detect and summarize contradictions. It should not choose the policy owner’s answer.

Agents surface conflicting claims, while the accountable owner resolves authority, scope, and effective date.

Review triggers

Review should start when:

• the next-review date arrives;

• a linked source changes;

• a product or policy version changes;

• an incident contradicts the procedure;

• repeated negative feedback appears;

• an owner or verifier leaves;

• permissions change;

• a newer record claims the same canonical topic;

• an answer cannot cite a valid source;

• a regulatory or contractual trigger occurs.

Time-based review alone is not enough for fast-changing knowledge.

Agent editing workflow

Level 0: Read and cite

Agents retrieve authorized Verified content and produce cited answers.

Level 1: Propose

Agents create proposed patches with old value, new value, reason, sources, scope, and risk. The record remains in Review.

Level 2: Execute approved changes

An agent applies the exact approved patch using a stable change ID, then reads the record back and confirms status, owner, sources, and dates.

Level 3: Bounded maintenance

Low-risk automation may flag stale pages, add missing-review tasks, or refresh derived indexes. It should not verify policy or change access classification without authority.

Change packet

{
  "change_id": "KB-1017-CHG-08",
  "knowledge_id": "KB-1017",
  "field": "procedure.step_2",
  "from": "Send a reset link",
  "to": "Confirm the account is not privileged, then send a reset link",
  "reason": "Privileged accounts require a separate approval path",
  "source_ids": ["SRC-219"],
  "risk_class": "high",
  "proposed_by": "agent:support-knowledge",
  "requires_approval": true
}

The reviewer should see the exact diff, affected audiences, citations, exceptions, and rollback.

Review queue

Create views for:

• review due in 14 days;

• expired verification;

• missing owner;

• missing source;

• unresolved contradiction;

• Draft older than 30 days;

• Verified content with changed source;

• agent proposals;

• broken canonical links;

• duplicated topic;

• permission-class mismatch;

• negative answer feedback;

• Superseded content still receiving traffic.

Each exception needs severity, owner, SLA, decision, and read-back verification.

Knowledge-base views

Start here

A curated entry point for people, organized by job and audience rather than org chart alone.

Verified knowledge

Current canonical records with owner, verifier, effective date, and next review.

By domain

Product, engineering, security, people, support, go-to-market, and operations.

Recently changed

Material changes with decision owner and effective date.

Review calendar

Records grouped by next review and risk.

Agent-ready

Verified records whose passages, sources, permissions, and canonical URLs pass the agent-use contract.

Restricted knowledge

High-sensitivity records with explicit owners and access review.

Contradictions

Open conflicts and temporary guidance.

Superseded map

Old records linked to current versions.

Information architecture

Use a shallow entry layer and structured databases behind it:

• Company home

• Start here

• Teams and domains

• Policies

• How-to guides

• Product knowledge

• Decisions

• Runbooks

• Review queue

Notion’s large-team knowledge-hub guidance recommends a home page for each team, standardized Docs and Meeting Notes databases, page links and backlinks, synced content, and explicit sharing controls.

Do not create deep navigation as the only retrieval path. People browse differently, and agents retrieve passages. Both need stable metadata and canonical records.

Measurement

Track:

• successful search rate;

• zero-result queries;

• answer citation-open rate;

• stale-answer incidents;

• time to verified update;

• percentage with owner and sources;

• review SLA;

• contradiction resolution time;

• permission-denied correctness;

• negative-feedback rate;

• duplicate-topic rate;

• Superseded content traffic.

A knowledge base is healthy when people and agents reach correct, current, authorized answers—not when page count rises.

Common template mistakes

Categories without ownership

Taxonomy does not keep content correct. Assign owners and review triggers.

Everything is Verified forever

Use verification periods that reflect risk and change frequency.

Drafts appear in authoritative answers

Status must influence retrieval and answer policy.

Sources are links without claim mapping

Record which source supports which claim.

Agents can edit but not propose

Create a Review state and exact change packet.

Permissions are checked after generation

Filter before or during retrieval.

Stale content disappears

Preserve it with a clear status and link to the replacement.

Verification has no scope

Record audience, region, product version, sources, and effective dates.

Search relevance is the only ranking signal

Permission, canonical status, freshness, and verification are stronger trust constraints.

No read-back after agent edits

A successful write response does not prove the durable knowledge record matches the approved patch.

When Notion is enough

Notion can support a team knowledge hub with wikis, standardized databases, templates, links and backlinks, synced sections, page sharing, and page verification. Verified pages can be highlighted in search and Notion AI responses, while verification expiry supports a review rhythm.

Add dedicated search, governance, or knowledge infrastructure when you need connector-scale ingestion, complex ACL synchronization, automated passage indexing, formal retention, advanced audit, or high-volume evaluation. Keep the canonical owner, sources, status, and review contract connected regardless of where retrieval runs.

Frequently asked questions

What should a knowledge base template include?

Include stable IDs, type, audience, domain, owner, sources, status, verifier, effective date, next review, sensitivity, canonical URL, related knowledge, and agent-use policy.

What makes a knowledge base AI-ready?

Permission-aware retrieval, self-contained passages, canonical records, source identity, current verification, explicit scope, citation-ready URLs, and safe behavior for stale or contradictory content.

Should AI agents write knowledge-base articles?

Agents can draft, structure, find gaps, and propose changes. Domain owners should verify consequential guidance, policy, permissions, and exceptions.

How often should knowledge be reviewed?

Match cadence to risk and change frequency. Use event triggers as well as dates. Frequently changing procedures may need monthly review; stable background material may need less.

What should happen when content is stale?

Mark it Stale, reduce or block authoritative use according to risk, route it to an owner, preserve the previous version, and cite temporary guidance if authorized.

How should contradictions be handled?

Preserve both sources, state the conflict, assign an authority, set a due date, suspend automatic verification, and record the resolution.

What is the difference between a wiki and a knowledge base?

A wiki emphasizes collaborative pages and navigation. A knowledge base adds structured ownership, sources, lifecycle, retrieval, verification, and measurement. A wiki can implement those contracts.

Can an AI agent verify a page?

An agent can check required fields and evidence mechanically. Authority to declare consequential knowledge official should come from an accountable human or explicit policy.

Sources

• Notion: Verify knowledge your teammates can trust

• Notion: Creating a knowledge hub for large teams

• Notion: Free knowledge base templates

• Notion: How to build a help center

• Notion: Sharing and permissions

• Notion: Relations and rollups

Product facts were verified on July 21, 2026.

Put the knowledge base into use

1. Assign an owner, authority level, audience, and verification date to every critical page.

2. Record contradictions instead of silently overwriting them.

3. Route stale or ownerless knowledge into a review queue.

4. Test retrieval as ordinary users and verify that agents cite the exact authorized source.

Where Dokki fits

Dokki can connect the knowledge document to owners, structured inventories, review queues, evidence, and agent work. This makes freshness and authority visible instead of treating the wiki page as permanently correct.

• Product roadmap template with evidence and decision gates

• PRD template for AI-native product teams

• What is enterprise search?