Wiki Organization Models

5 ways to restructure the UnitCycle wiki (52 pages). Pick the one that makes sense for how you think about the project.

Current Problem

Pages are grouped by type (concepts/, entities/, summaries/, analyses/) — but this doesn't match how anyone thinks about the project. You think "I'm working on invoices" not "I need a concept page." The sidebar is a flat alphabetical list with no hierarchy, no starting point, and no reading order. Everything feels equally important.

Criterion	1. PARA	2. Diataxis	3. MOCs	4. Domain	5. Johnny.Decimal
Best for	Sprint-focused work	Product documentation	Obsidian power users	Multi-team projects	Large stable wikis
Where to start reading	projects/ (active work)	tutorials/getting-started	_home.md (hub page)	_index.md (domain map)	00.01 wiki-home
19 features organized?	Scattered across P/A/Ar	Scattered across quads	Single MOC page	ai-platform/features/	20-24 numbered by phase
Cross-cutting pages	Awkward	Awkward	Natural (multi-MOC)	Needs shared/ folder	Fixed location
Migration effort	Move all 52 pages	Move all 52 pages	Add 5-6 pages only	Move all 52 pages	Move + rename all 52
Maintenance burden	High (migrate on done)	Medium	Medium (curate MOCs)	Low (domains stable)	Low (numbers stable)
Works outside Obsidian	Yes	Yes	Needs wikilinks	Yes	Yes
Scales to 200+ pages	Poorly	Moderately	Well	Well	Very well

PARA

Tiago Forte — "Building a Second Brain" (2017)

Not great fit

How it works

4 buckets by actionability: Projects (active, has deadline) → Areas (ongoing, no deadline) → Resources (reference) → Archives (done).

Your wiki would look like

projects/ f3.2-invoice-processing.md ← active feature invoice-processing-plan.md invoice-design-research.md areas/ ai-roadmap.md ← ongoing, no end date tech-stack.md, branding.md, ... resources/ collections-research.md ← reference material openrouter-llm-research.md, ... archives/ f1.1-lifecycle-state-engine.md ← completed features f1.2-renewal-intelligence.md f1.3-smart-collections.md

Start here: projects/ → shows only what's active right now

Pros

Forces "what am I working on NOW?"
Completed features move to archives — small working set
Sprint-oriented, maps to how dev work flows

Cons

Every shipped feature = pages migrate between folders
Entity pages (Yardi, Rafael) don't fit any bucket
Loses bird's-eye "all 19 features" view
Areas vs Resources boundary is fuzzy for tech content

Diataxis

Daniele Procida — Used by Django, Python, Ubuntu

Not great fit

How it works

4 quadrants: Tutorials (learning, practical) → How-To (doing, practical) → Reference (looking up) → Explanation (understanding, theory). Designed for product docs, not project wikis.

Your wiki would look like

tutorials/ getting-started.md ← NEW (doesn't exist yet) adding-an-ai-feature.md ← NEW how-to/ invoice-processing-plan.md collections-improvements.md ai-development-plan.md reference/ ai-technical-spec.md, database-map.md, tech-stack.md, ... explanation/ ai-roadmap.md, ai-vision-plan.md, project-brief.md, ...

Start here: tutorials/getting-started.md → links to all quadrants

Pros

Battle-tested for software docs (Django, Python)
Clear page purpose — "am I teaching or referencing?"
Separates "what" (reference) from "why" (explanation)

Cons

Designed for user-facing product docs, not internal project wiki
Each feature is simultaneously how-to + reference + explanation
No place for status tracking (active-context, progress)
Would need to write tutorials from scratch

Maps of Content (MOC)

Nick Milo — "Linking Your Thinking" (2020). Obsidian community standard.

Recommended

How it works

All pages stay flat (no folders or minimal folders). Navigation through curated hub pages (MOCs) that link to related notes with narrative context. Structure from links, not folders. A page can appear in multiple MOCs without duplication.

Your wiki would look like

wiki/ _home.md ← entry point, links all MOCs _moc-ai-features.md ← 19 features by phase + status _moc-architecture.md ← tech stack, patterns, DB, workflows _moc-specs-and-plans.md ← all specs, research, implementation plans _moc-people-and-tools.md ← entities: Rafael, Yardi, LlamaParse (5 new MOC pages added) concepts/ ← existing folders stay as-is ai-roadmap.md, lifecycle-state-engine.md, ... entities/ unitcycle.md, rafael.md, yardi.md, ... summaries/ ai-technical-spec.md, collections-research.md, ... analyses/ project-health-2026-04-06.md

_home.md would look like

UnitCycle Wiki Start Here [[active-context]] — What's happening right now [[progress-tracker]] — 3/19 features complete [[_moc-ai-features]] — All 19 features by phase Deep Dives [[_moc-architecture]] — How the system is built [[_moc-specs-and-plans]] — Specs, research, plans Reference [[_moc-people-and-tools]] — Entities: people, companies, services [[project-brief]] — Business context and vision

Start here: _home.md → curated landing page with narrative sections. You always know where you are.

Pros

Zero migration — existing 52 pages don't move. Just add 5 MOC pages.
A page can appear in multiple MOCs (invoice-processing in AI features AND in specs)
Perfect for Obsidian — leverages wikilinks and graph view natively
MOCs provide narrative ("here's the reading order") that folders can't
Graph view shows MOCs as natural hub nodes connecting clusters

Cons

MOCs need manual curation — can drift out of sync
File explorer is still flat alphabetical within folders
Only works well with wikilinks (Obsidian, wiki server)

Domain-Driven

Eric Evans — Domain-Driven Design (2003). "Bounded contexts" applied to docs.

Strong option

How it works

Organize by business domain, not document type. Each domain folder has ALL its content — specs, research, features, plans. A "foundation" folder holds cross-cutting concerns.

Your wiki would look like

foundation/ ← cross-cutting architecture tech-stack.md, system-patterns.md, database-map.md companion-table-pattern.md, navy-gold-branding.md workflow-tree.md, platform-blueprint.md ai-platform/ ← the 19-feature AI system roadmap.md, vision.md, technical-spec.md, product-spec.md features/ f1.1-lifecycle-state-engine.md f1.2-renewal-intelligence.md f1.3-smart-collections.md f1.4-portfolio-command-center.md f2.1-turnover-orchestration.md f3.2-invoice-processing.md ← active ... all 19 features collections/ ← deep enough for its own domain spec.md, research.md, improvements.md invoices/ ← current active work processing-plan.md, design-research.md, llm-research.md mapping/ comparison.md, showcase.md entities/ unitcycle.md, rafael.md, yardi.md, llamaparse.md, ... status/ active-context.md, progress-tracker.md, project-health.md

Start here: _index.md → domain map showing each bounded context, purpose, and status.

Pros

Working on invoices? Everything about invoices in one folder.
Mirrors how you actually think about the project
f1.1- prefixes give natural reading order within features/
Scales well — new domains get their own folder
Works in any tool (filesystem, VS Code, GitHub)

Cons

All 52 pages must move and be re-pathed
Cross-cutting pages (openrouter-research) span multiple domains
Domain granularity is subjective (is Collections its own domain?)
~8-10 top-level folders feels heavy for 52 pages

Johnny.Decimal

Johnny Noble (2019). Numbering system for file organization.

Overkill for now

How it works

Numbered areas (10-19, 20-29...) with categories and decimal IDs. Every page has a unique address like 22.02 = invoice-processing. The number IS the location.

Your wiki would look like

00-09 Navigation/ 00.01 wiki-home.md 00.02 active-context.md 00.03 progress-tracker.md 10-19 Architecture/ 10.01 tech-stack.md 11.01 database-map.md 12.01 navy-gold-branding.md 20-29 AI Features/ 20 Phase 1/ 20.01 lifecycle, 20.02 renewal, 20.03 collections 21 Phase 2/ 21.01 turnover, 21.02 pricing, 21.03 maintenance 22 Phase 3/ 22.01 photo-ai, 22.02 invoices, 22.03 chat 23 Phase 4/ 23.01-23.06 staging through onboarding 24 Phase 5/ 24.01-24.04 listings through vendors 30-39 Specs/ 30.01 ai-technical-spec.md, 30.02 ai-product-spec.md, ... 40-49 Research/ 40.01 collections-research.md, 41.01 openrouter-llm.md, ... 50-59 Entities/ 50.01 unitcycle.md, 51.01 yardi.md, ...

Start here: 00.01 wiki-home.md → always first in every file listing

Pros

Every page has a speakable address: "check 22.02"
Perfect sort order in any file explorer
Numbers are stable — renaming doesn't change the ID
Phase grouping (20-24) maps directly to the 5-phase roadmap

Cons

All 52 pages move AND rename — highest migration effort
Numbering system is an abstraction everyone must learn
Wikilinks become unwieldy: [[20-29 AI/22 Phase 3/22.02 invoices]]
Overkill for 52 pages — shines at 200+

Recommendation

Model 3 (MOC) for quick wins now. Model 4 (Domain) if you want a deeper restructure.

MOC is the lowest-effort, highest-impact option: add 5 hub pages, zero existing pages move, and you immediately get a clear entry point (_home.md), a reading order, and topic clustering. It works perfectly with Obsidian's graph view and the wiki web server.

Domain-Driven is better long-term if the wiki grows past 100 pages — "everything about invoices in invoices/" is intuitive for any newcomer. But it requires moving all 52 pages and updating every wikilink.

Hybrid option: Start with MOCs now (5 minutes, zero risk). If it outgrows that, restructure to Domain-Driven later — the MOC content becomes the README in each domain folder.