Purpose

This recipe builds a complete knowledge management system for a startup — from wiki platform selection and information architecture design through decision log templates, lessons learned capture, content ownership assignment, and automated review cycles. The output is a fully configured wiki with structured navigation, standardized templates for decisions and retrospectives, designated page owners, and search/discovery optimized for a growing team. [src1]

Prerequisites

Team size and growth plan — current headcount and 12-month hiring projection
Existing documentation inventory — list of where knowledge currently lives (Google Docs, Slack, email, individual notes)
Top 10 new-hire questions — the questions asked most often in the first week
Wiki platform account — Notion, Confluence, Slite, or Almanac
Slack or Teams workspace — for wiki integration (search, notifications, knowledge capture)
Admin access — ability to create workspaces, set permissions, and install integrations

Constraints

Information architecture must be designed before content migration — unstructured document dumps create unsearchable knowledge graveyards within 3 months. [src3]
Every wiki page needs exactly one designated owner — unowned pages decay to irrelevance within 60-90 days. [src1]
Decision logs must be written within 48 hours of the decision — reconstructing rationale later produces unreliable records. [src4]
Keep taxonomy to 3-4 levels maximum — deeper hierarchies reduce content discovery. [src3]
Review cycles must be enforced through automated reminders, not manual tracking. [src2]

Tool Selection Decision

Which platform?
├── Team is 1-10 AND wants all-in-one (wiki + projects + databases)
│   └── PATH A: Notion Free/Plus — flexible blocks, databases, multiple views
├── Team is 5-50 AND uses Atlassian stack (Jira, Trello)
│   └── PATH B: Confluence — deep Jira integration, structured spaces, permissions
├── Team is 3-25 AND values simplicity + AI search
│   └── PATH C: Slite — clean interface, AI-powered Ask, doc verification
└── Team is 10-50 AND Slack-first workflow
    └── PATH D: Tettra/Guru — Slack-native Q&A, auto-surfaces answers

Path	Tools	Cost (10 users)	Setup Time	Best For
A: Notion	Notion Free or Plus	$0-100/mo	2-4 hours	Startups wanting one tool for everything [src5]
B: Confluence	Confluence Free or Standard	$0-54/mo	3-5 hours	Atlassian shops, engineering-heavy teams [src5]
C: Slite	Slite Free or Standard	$0-67/mo	1-3 hours	Remote teams wanting simple, searchable docs [src6]
D: Tettra/Guru	Guru Self-Serve	$250/mo (10-seat min)	2-4 hours	Slack-first teams, customer-facing knowledge [src6]

Execution Flow

Step 1: Platform Setup and Workspace Configuration

Duration: 30-60 minutes · Tool: Chosen wiki platform

Create the workspace and configure basic settings. Set up authentication (SSO/Google sign-in), configure default member permissions, invite founding team members, and install core integrations (Slack, Google Drive, Calendar).

Permission Model (by team size):
1-10 people:  Everyone can edit everything. Trust > control.
10-25 people: Team-level spaces with edit access. Company-wide read.
25-50 people: Team spaces + private spaces for HR, finance, legal.
50+ people:   Space-level admins, page-level permissions, audit logs.

Verify: All team members can log in, create pages, and search. Slack integration returns results. · If failed: Check SSO domain matches company email domain. Retry Slack installation from wiki admin panel.

Step 2: Design Information Architecture

Duration: 1-2 hours · Tool: Wiki platform

Build the taxonomy before adding content. Use 5-9 top-level categories (Company, Handbook, Engineering, Product, Sales & Marketing, Decision Log, Lessons Learned, Meeting Notes). Keep hierarchy to 3-4 levels maximum. [src3]

Naming Conventions:
• Pages: "[Type] Title — Date" (e.g., "ADR-017 Switch to Postgres — 2026-03")
• Tag pages with team, status (draft/active/archived), and review date
• Prefix templates with [Template] for discoverability

Verify: A new hire can find the onboarding checklist in under 3 clicks. An engineer can find the deployment runbook without searching. · If failed: Flatten by merging subcategories or split the largest sections.

Step 3: Set Up Decision Log

Duration: 30-45 minutes · Tool: Wiki platform

Create a standardized decision log template capturing: Decision ID, Date, Decision Maker(s), Status, Context, Options Considered (with pros/cons/cost table), Decision with rationale, Consequences, and Review Date. Backfill at least 3 decisions. [src4]

First Entries to Create:
DEC-001: Choice of wiki platform (document why you picked it)
DEC-002: Information architecture structure (document the taxonomy)
DEC-003: Most recent strategic decision (backfill to set the pattern)

Verify: Decision log has at least 3 entries, all fields populated, linked from sidebar navigation. · If failed: Simplify template — remove Options table for quick decisions, keep it for decisions with >$1K impact.

Step 4: Create Lessons Learned Repository

Duration: 30-45 minutes · Tool: Wiki platform

Build a structured template capturing: Lesson ID, Date, Author, Category (Incident/Project/Process/Product/Hiring), Severity, What Happened, What Went Well, What Went Wrong, Action Items (with owner and due date), and Key Takeaway (one-sentence summary for search).

Trigger Points (when to write a lessons learned):
• After any production incident (mandatory)
• At end of every project or milestone (mandatory)
• After a failed hire or departure (recommended)
• After losing a deal >$10K (recommended)
• Quarterly: review all open action items

Verify: Template saved and tagged as [Template]. At least one backfilled entry exists. · If failed: Start with a blameless format — remove individual names from "What Went Wrong" and focus on systemic causes.

Step 5: Establish Content Ownership and Review Cycles

Duration: 45-60 minutes · Tool: Wiki platform + spreadsheet

Assign every knowledge area an owner with review frequency. Configure automated review reminders through the platform (Notion date properties, Confluence page properties, Slite doc verification) or via Slack/Zapier. [src1] [src2]

Ownership Map Fields:
| Knowledge Area | Owner | Backup Owner | Review Frequency | Next Review |

Automated Review Setup:
Notion:      Database with "Next Review" date property + filtered view
Confluence:  Page properties macro + saved search for overdue reviews
Slite:       Built-in doc verification with interval settings
All:         Monthly "Knowledge Health" Slack reminder

Verify: Every top-level section has an assigned owner. A test reminder has been received. · If failed: If team is 1-5 people, assign founder as default owner with quarterly reviews.

Step 6: Build Search and Discovery Layer

Duration: 30-45 minutes · Tool: Wiki platform + Slack

Enable full-text search, add consistent tags (team, type, status), create "Start Here" pages for each team, pin critical pages in Slack channels, and install wiki search commands in Slack.

Anti-Search-Rot Practices:
• Archive (don't delete) outdated pages
• Add "Supersedes: [old page]" links when updating
• Use canonical naming — one page per topic, not five drafts
• Merge duplicate pages monthly

Verify: Search for 3 common questions — each returns the correct page in top 3 results. Slack integration returns results within 3 seconds. · If failed: Fix page titles (no "Untitled"), add summaries, archive stale duplicates.

Step 7: Seed Initial Content and Prevent Knowledge Rot

Duration: 2-4 hours (spread across first week) · Tool: Wiki platform

Populate in priority order: Week 1 (critical) — onboarding checklist, tool access guide, company values, current OKRs, decision log with 3 entries. Week 2 — deployment runbook, roadmap, ICP/pricing, time-off policy, first lessons-learned entry. Week 3 — team-specific process docs and templates.

Knowledge Rot Prevention:
• "Last verified" date visible on every page
• Automated Slack alert when any page exceeds its review date
• Quarterly "Wiki Gardening" session (30 min, all-hands)
• Sunset rule: pages not viewed in 6 months get archived

Verify: Wiki has at least 10 substantive pages. At least 3 team members have created or edited a page. Slack channel notified that wiki is live. · If failed: Answer the #1 Slack question in the wiki, redirect future questions there.

Output Schema

{
  "output_type": "knowledge_management_system",
  "format": "configured wiki + templates + ownership map",
  "columns": [
    {"name": "wiki_platform", "type": "string", "description": "Platform name", "required": true},
    {"name": "top_level_spaces", "type": "number", "description": "Number of top-level sections", "required": true},
    {"name": "templates_created", "type": "number", "description": "Standardized templates created", "required": true},
    {"name": "pages_seeded", "type": "number", "description": "Initial content pages", "required": true},
    {"name": "owners_assigned", "type": "number", "description": "Knowledge areas with owners", "required": true},
    {"name": "review_automation", "type": "boolean", "description": "Automated reminders configured", "required": true},
    {"name": "slack_integration", "type": "boolean", "description": "Wiki search in Slack", "required": false},
    {"name": "adoption_rate", "type": "number", "description": "Team members active in first 2 weeks", "required": false}
  ],
  "expected_row_count": "1",
  "sort_order": "N/A (single row)",
  "deduplication_key": "wiki_platform"
}

Quality Benchmarks

Quality Metric	Minimum Acceptable	Good	Excellent
Initial pages seeded	> 10 pages	> 20 pages	> 30 pages with templates
Content ownership coverage	> 60% sections have owners	> 80%	100% with backup owners [src1]
Team adoption (2-week)	> 50% logged in	> 70% created a page	> 90% active contributors
Search success rate	> 60% useful results	> 80%	> 90% with AI search [src2]
Decision log entries	> 3 backfilled	> 5 with ongoing capture	All decisions logged within 48h [src4]
Review cycle compliance	> 30% on schedule	> 60%	> 80% with automated reminders

If below minimum: Focus on adoption first. A wiki with 5 great pages that people use beats 50 pages nobody reads. Identify the top 3 Slack questions, write wiki answers, redirect future questions to wiki links.

Error Handling

Error	Likely Cause	Recovery Action
Team ignores wiki, keeps using Slack/email	No clear value demonstrated; content is stale or hard to find	Answer the #1 repeated Slack question in the wiki and redirect all future questions there. [src1]
Wiki becomes a document graveyard	No ownership or review cycles configured	Run Step 5 immediately. Assign owners, set review dates, archive pages not updated in 6 months.
Search returns irrelevant or duplicate results	Poor naming, duplicate pages, no taxonomy	Deduplicate pages, enforce naming conventions, add tags and summaries. [src3]
Decision log not being maintained	Template too complex, too much friction	Simplify to 4 fields: Decision, Date, Rationale, Review Date. Add as a section in meeting note templates.
IA becomes outdated as team grows	Structure designed for smaller team size	Schedule architecture review at every team doubling (5→10, 10→20). Add new spaces, split crowded sections.
Sensitive info exposed to wrong members	Flat permissions without access controls	Move sensitive content to private spaces. Review permissions monthly. Enable audit logs if available.

Cost Breakdown

Component	Free Tier	Starter	Growth (25 users)
Notion	Free (unlimited pages, 10 guests)	$10/user/mo Plus	$250/mo [src5]
Confluence	Free (up to 10 users, 2GB)	$5.42/user/mo Standard	$136/mo [src5]
Slite	Free (50 docs)	$6.67/user/mo Standard	$167/mo [src6]
Guru	N/A (10-seat minimum)	$250/mo minimum	$625/mo [src6]
Almanac	Free (limited)	$12/user/mo	$300/mo
Total (10 users, recommended)	$0 (Notion/Confluence)	$50-100/mo	$136-250/mo

Anti-Patterns

Wrong: Dumping all existing documents without organizing first

Migrating 500 Google Docs into the wiki with no taxonomy, tagging, or ownership. Result: unsearchable mess that the team abandons within 30 days. [src3]

Correct: Design information architecture first, then selectively migrate

Build the taxonomy (Step 2) before importing anything. Migrate only the top 20 most-used documents first. Every migrated page gets an owner, tags, and a review date.

Wrong: Requiring consensus on every wiki update

Creating approval workflows where multiple people must sign off on every page edit. Nobody contributes because friction is too high.

Correct: Default to open editing with lightweight review

Let everyone edit. Use page history to revert mistakes. Reserve approval workflows for policies, legal content, and public-facing documentation only.

Wrong: Building a wiki without Slack integration

Expecting people to open a separate app to search for knowledge. People continue asking in Slack because it is faster. [src1]

Correct: Make the wiki accessible where work happens

Install Slack integration on day one. When someone asks a Slack question answered in the wiki, reply with the wiki link instead of typing the answer.

When This Matters

Use this recipe when the agent needs to build a knowledge management system from scratch for a startup — including wiki platform selection, information architecture, decision logs, lessons learned capture, and content ownership. Requires team size, existing documentation inventory, and admin access as inputs.

Knowledge Management Setup