A wiki without editorial process drifts: inconsistent voice, stale content, contradictory pages. A wiki with too much process becomes painful: contributions slow; people give up.
The right balance varies by wiki type. This page covers the patterns.
Anyone edits. Quality from peer review and active maintainers. No formal review process.
Works at scale (lots of editors). Doesn't work for small wikis (no critical mass).
Editors propose; curators review/merge. Quality controlled.
Common for: technical documentation, policy wikis, regulated content.
Limited authors; formal review; publishing workflows.
For: corporate official content, customer-facing docs, legal/medical info.
One author. No workflow needed.
Pages in development, not yet ready for general consumption.
Mechanisms:
Drafts visible to authors and editors; not in main navigation/search.
Before a page is published, someone else reviews. Catches errors; ensures consistency.
Patterns:
For technical content, reviews catch real errors. For general content, the cost-benefit varies.
The transition from draft to published. Formal in some workflows; implicit in others.
For "edit on save" wikis, publishing is just saving. For curated wikis, publishing is a deliberate step.
Pages need refreshing. Old content misleads.
Patterns:
Pages that are obsolete. Don't always delete (history matters); mark.
Mechanisms:
Each page has a designated owner. Updates flow through them.
For technical wikis with subject-matter experts, this works well.
A section of the wiki has an owner. Pages within move through them.
For larger wikis, section ownership scales better than per-page.
A small group reviews proposed changes. Group ownership rather than individual.
For high-stakes wikis where consistency is critical.
Anyone updates anything. Quality from community norms.
For small wikis with engaged contributors, this works. For large or stakes content, it doesn't.
status: draft | published | needs-review | deprecated | archived
Clear signal about page state. Different from "is this page good" — about lifecycle.
last_reviewed: 2026-04-26
reviewed_by: alice
Indicates currency. Pages reviewed recently are more trusted.
Standard structures for common page types. See WikiPageTemplates. Reduces variance; speeds creation.
Automated detection of old pages. Flags pages not edited or reviewed recently. Periodic review queue.
For systematic changes (rename, link update, format change), bulk tooling. Avoid manual edits across hundreds of pages.
Quick check: does this make sense; spelling correct; obvious errors.
For low-stakes content; fast turnaround.
Subject-matter expert reads carefully. Verifies facts; suggests improvements.
For technical accuracy; takes longer.
Style; tone; consistency with other pages.
For voice and craft; orthogonal to technical accuracy.
For mature wikis: combination of all three at different stages.
Some wikis have built-in workflows: draft, review, publish states.
For wikis without: external tools or processes.
Pull request review is the workflow. Standard developer tooling.
Page edits flow through external review system (Notion + Slack; Confluence + Jira).
For content with periodic publishing (newsletter, blog), explicit calendar of what's coming when.
For most internal wikis:
The patterns above are generic. Wikantik is a Markdown wiki with a PostgreSQL-backed page store and structured frontmatter, and it builds several of them in:
update_page tool takes the expectedContentHash returned by read_page, and a stale hash returns the latest content to rebase against.draft, active and archived; archived is Wikantik's deprecation marker. Other values such as published or deprecated are tolerated with a warning that suggests a canonical one. The field is a label: the server does not hide or gate a draft page (see Frontmatter Conventions).last_reviewed or reviewed_by field. Use verified_at and verified_by, stamped by the mark_page_verified MCP tool. Wikantik derives a confidence from them: stale when verified_at is absent or older than wikantik.verification.stale_days (default 90 days).GET /admin/agent-grade-audit lists pages with no verified_at or a stale verification. The Wiki Audit Skill and the Wiki Audit Demand and Freshness Loop add a sweep of tool-practice clusters for pages unverified for 12 months.canonical_id so a rename keeps it. On first save the owner is the author frontmatter value when it names a real login, otherwise the agents service account (wikantik.page_ownership.default_owner); administrators reassign owners at /admin/page-ownership. Ownership records accountability only. Who may view or edit a page is decided by permissions and page ACLs such as [{ALLOW edit Admin}]().rename_page (with link rewriting) and rename_cluster (returns a plan until confirm=true) cover systematic changes, and every page keeps a version history (get_page_history, diff_page).Cluster Hub: Wikantik Platform Development Hub: Architecture, MCP Protocols, and Agent Briefings (wikantik-development)