Documentation Hierarchy & Source of Truth
Date: April 28, 2026Phase: 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)
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.mdPurpose: “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 + operationsdocs/packages/— Individual package documentationpackages/{pkg}/README.md— Package-level API docspackages/*/docs/— Package-specific guides
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
- Tailwind classes are case-sensitive
- Use
className(not inline styles) - Check
tailwind.config.jsfor available tokens
Troubleshooting
Q: Styles not applying? A: Check that file is insrc/ directory (Tailwind scans src/). If new custom class, add to tailwind.config.js or inline with @apply.
See Also
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)
Part 3: Documentation Lifecycle
Creation Phase
When a doc is created:- Place in correct location (Tier 2 index, domain, or app)
- Add metadata header (title, owner, SLA, status)
- Add to
DOCUMENTATION_INDEX.md - Create a GitHub issue: “Document created: [name]” (for tracking)
- Announce in
#engineeringSlack channel (link + 1-sentence summary)
Maintenance Phase
Every 3 months: Doc owner reviews for staleness
When doc needs update:
- Owner updates doc + git commit: “docs(runbooks): update secret rotation SLA [reason]”
- Update
last_updateddate - Announce in Slack if breaking change
Archive Phase
When a doc becomes obsolete:- Mark as
❌ Stalein header (don’t delete; historical value) - Add note at top: “This doc is deprecated as of [date]. See [new doc] instead.”
- Move to
docs/ARCHIVE/directory - Remove from
DOCUMENTATION_INDEX.md(but mention in archive section)
Part 4: Cross-Reference Guide
”I need to find…”
Part 5: Documentation by Audience
For New Team Members
Read in order (2–3 hours):README.md(5 min intro)- Getting Started (30 min setup)
- Team Onboarding Pack (1 hour intro by role)
- Engineering Baseline (45 min overview)
- Your role’s guide:
- Frontend dev → Frontend Standards
- Backend dev → Factory Package Matrix + Database
- DevOps → Deployment + Secrets
- Designer → Design Rubric + Journey Maps
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 Quality Rubric (quality checklist)
- RFC & Design Review (process before coding)
- Journey Maps (user goal + instrumentation)
For Backend Developers
Daily Reference:- Factory Package Matrix (which pkg for what)
- Package-level README (e.g.,
packages/stripe/README.md) - Database Guide (schema, migrations, queries)
- RFC & Design Review (proposal template)
- Engineering Baseline (current architecture)
For Operations / DevOps
Runbooks:- Deployment (how to release)
- Secret Rotation (managing secrets)
- SLO Framework (targets + monitoring)
- On-Call Runbook (incident response)
- Implementation Dashboard (roadmap + phases)
- Phase 6 Checkpoint (infrastructure status)
For Product / Design
Planning:- Journey Maps (8 critical flows)
- Design Quality Rubric (quality standards)
- RFC & Design Review (process)
- Implementation Dashboard (roadmap)
- Definition of Ready/Done (quality gates)
- Factory Package Matrix (what’s available)
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