Skip to main content

Documentation Hierarchy & Source of Truth

Date: April 28, 2026
Phase: B (Standardize)
Initiative: T7.1 — Consolidate Source-of-Truth Docs
Reference: Factory + VideoKing combined documentation

Mission

Create one canonical structure for all documentation so every team member knows:
  • “Where do I find X?” (configuration, architecture, performance baselines, etc.)
  • “Is this doc current?” (last updated date, owner, SLA for updates)
  • “What changed?” (git history for changes, not just file date)
Goal: Single source of truth = fewer duplicate docs, no conflicting guidance, easier onboarding.

Part 1: Documentation Hierarchy

Tier 1: Root README (Landing Page)

Location: README.md (repo root)
Purpose: “I’m new; where do I start?”
Content: Links to Tier 2 docs by audience + quick-start checklist
Current State: Out-of-date; links to old docs
Action: Rewrite with new hierarchy links

Tier 2: Documentation Index (Organized by Domain)

Location: docs/DOCUMENTATION_INDEX.md
Purpose: “What docs exist? Where are they? Who maintains each?”
Content: Comprehensive listing of ALL docs (current state)

Tier 3: Domain-Specific Docs

Locations:
  • docs/runbooks/ — Step-by-step procedures (deployment, secrets, debugging)
  • docs/videoking/ — VideoKing-specific architecture + operations
  • docs/packages/ — Individual package documentation
  • packages/{pkg}/README.md — Package-level API docs
  • packages/*/docs/ — Package-specific guides
Example Structure:

Tier 4: Application-Level Docs

Location: App README at root of app folder (e.g., apps/admin-studio-ui/README.md) Content:
  • What is this app?
  • Local setup (how to run it)
  • Key directories
  • Common tasks
  • Troubleshooting
Example:
Debug styling:
  • Tailwind classes are case-sensitive
  • Use className (not inline styles)
  • Check tailwind.config.js for available tokens

Troubleshooting

Q: Styles not applying? A: Check that file is in src/ directory (Tailwind scans src/). If new custom class, add to tailwind.config.js or inline with @apply.

See Also

Example:

Content Checklist

Every doc should have:
  • Title & Purpose: “What is this doc for?”
  • Audience: “Who should read this?” (engineers, ops, designers, etc.)
  • Quick Summary: 1–2 paragraphs (TLDR for skimmers)
  • Table of Contents: If > 2,000 words
  • Examples: Code snippets, real-world scenarios (not just theory)
  • Troubleshooting Section: “What could go wrong + fix”
  • Related Docs: Links to related information
  • Version History: Last updated date + change log
  • Metadata: Owner, SLA, status

Code Samples in Docs

All code samples must:
  • Be copy-paste ready (not pseudocode)
  • Include error handling
  • Have comments explaining “why”, not just “what”
  • Link to full examples (don’t hide important logic)
Example (Good):

Part 3: Documentation Lifecycle

Creation Phase

When a doc is created:
  1. Place in correct location (Tier 2 index, domain, or app)
  2. Add metadata header (title, owner, SLA, status)
  3. Add to DOCUMENTATION_INDEX.md
  4. Create a GitHub issue: “Document created: [name]” (for tracking)
  5. Announce in #engineering Slack channel (link + 1-sentence summary)

Maintenance Phase

Every 3 months: Doc owner reviews for staleness When doc needs update:
  1. Owner updates doc + git commit: “docs(runbooks): update secret rotation SLA [reason]”
  2. Update last_updated date
  3. Announce in Slack if breaking change

Archive Phase

When a doc becomes obsolete:
  1. Mark as ❌ Stale in header (don’t delete; historical value)
  2. Add note at top: “This doc is deprecated as of [date]. See [new doc] instead.”
  3. Move to docs/ARCHIVE/ directory
  4. Remove from DOCUMENTATION_INDEX.md (but mention in archive section)
Example:

Part 4: Cross-Reference Guide

”I need to find…”


Part 5: Documentation by Audience

For New Team Members

Read in order (2–3 hours):
  1. README.md (5 min intro)
  2. Getting Started (30 min setup)
  3. Team Onboarding Pack (1 hour intro by role)
  4. Engineering Baseline (45 min overview)
  5. Your role’s guide:

For Frontend Developers

Daily Reference:
  • Frontend Standards (accessibility, performance, component patterns)
  • App-specific README (e.g., apps/admin-studio-ui/README.md)
  • Component library docs (e.g., apps/admin-studio-ui/docs/COMPONENT_LIBRARY.md)
Design Changes:

For Backend Developers

Daily Reference: System Changes:

For Operations / DevOps

Runbooks: Status Dashboards:

For Product / Design

Planning: Constraints:

T7.1 Exit Criteria (by May 29, 2026)

  • Documentation hierarchy defined (Tier 1–4)
  • Root README rewritten with hierarchy links
  • Documentation Index created (comprehensive listing)
  • Metadata header template created (title, owner, SLA, status)
  • Documentation standards documented (content checklist, code samples)
  • Lifecycle process documented (creation, maintenance, archive)
  • Cross-reference guide created (“I need to find…”)
  • Audience-specific guides created (new hire, frontend, backend, ops, product)
  • All existing docs migrated to new structure (May 5–12)
  • All docs updated with metadata headers (May 5–12)
  • Stale docs archived (May 8)
  • Team trained on doc navigation (May 12)

Version History


Status: ✅ T7.1 READY FOR IMPLEMENTATION
Next Action: Migrate existing docs to new structure (May 5–12); team training May 12