Filing Decision Tree

Read this before creating, moving, merging, or splitting any wiki page. This resolver answers one question: where does durable knowledge belong?

This is the directory-level filing brain for wiki/. It is not the action dispatcher. If the question is "which skill, tool, MCP, CLI, or service should I use?", read Skill Resolver and Capability Routing Map. If the question is "what should I load at session start?", read Agent Operations Hub.

Filing is a semantic decision. A page in the wrong directory becomes hard to retrieve, hard to maintain, and easy to duplicate. The goal is not to create more pages. The goal is to keep each durable subject in the one place future agents will naturally look.

Authority Stack

Use these pages together. Do not let any one of them become a private fork of the schema.

The extracted pages under wiki/resolver/ are retrieval companions, not independent authority; start at Filing Decision Tree when browsing them. Update this page first, then update those companions when a rule changes. Source: User request, 2026-07-01

Filing Algorithm

1. State the durable subject in one sentence.
2. Search before create: qmd search "{name}", likely aliases, and nearby slugs with rg.
3. Decide shape with Wiki Brain Operating Model: standalone page, section, ledger row, generated page, redirect, or no durable write.
4. If standalone, walk the decision tree below top-to-bottom and take the first true match.
5. Read the target directory README.md or resolver companion when it exists.
6. Create or update the page using Wiki Page Format.
7. Add related: links, inline [[wikilinks]], aliases, and meaningful entity timeline entries.
8. Rebuild and log through Index Logging Protocol.

If the durable subject cannot be stated clearly, do not create a page. Use wiki/inbox/ only when the capture is real knowledge and the current schema genuinely lacks a home.

Current Namespace Model

The current wiki has three kinds of directories. Treat them differently.

Schema-supported categories such as places/, patterns/, tensions/, eras/, and transitions/ may be created when a real page passes the same notability bar as any other category. Do not create a new directory for one weak note; fold it into an existing article, story, decision, or ledger first.

Decision Tree

1. Generated agent document, capsule, portable pack, or bundle output -> agent-docs/

   • Do not hand-edit generated packs. Update the source page, capsule definition, or script, then regenerate.
   • Read Agent Docs System Map before creating, merging, or splitting AGENT DOCS pages.
   • Hand-written agent-doc pages are allowed only when they document generated surfaces or provide portable operator quickrefs.

2. Root identity, Kevin model, or operating cadence expansion -> soul/, user/, or heartbeat/

   • wiki/SOUL.md, wiki/USER.md, and wiki/HEARTBEAT.md are the boot spine.
   • Use subdirectories for extracted articles that expand those roots without bloating the boot files.
   • For user/, read User Model Map before creating, merging, or splitting focused Kevin-profile pages.

3. Meta-knowledge about the wiki, agent config, schema, automations, sync, routing, or maintenance -> meta/

   • This includes protocols, setup, config sync, automation contracts, state semantics, quality gates, and generated-index documentation.
   • If it teaches a general concept rather than operating this wiki, use concepts/.

4. Filing resolver companion, filing extraction, or resolver comparison -> resolver/

   • Keep the canonical rule in this page.
   • Use resolver/ for compact retrieval pages such as People Filing, Merge Protocol, and Resolver vs Skill Resolver.

5. Skill/tool/action dispatcher companion -> skill-resolver/

   • Use for task-routing extracts from Skill Resolver.
   • Do not file page-placement rules here; those belong in this resolver.

6. Specific named person -> people/

   • Includes biography, preferences, beliefs, working style, relationships, and trajectory.
   • A person's philosophy stays on their person page unless Kevin has adopted and generalized it.

7. Specific project, product, company, institution, repo, or active operating context -> projects/

   • Use when there is a product surface, team, repo, organization, deliverable, or ongoing operational context.
   • Product theses tied to a project can live here; general principles split to concepts/ or philosophies/.

8. Developer tool, service, library, CLI, MCP, framework, platform, or vendor ecosystem -> tools/

   • Describes what the thing is, when it wins, setup, tradeoffs, alternatives, and verification.
   • If the page is a repeatable procedure for using the tool, update or create a skill too.

9. Executable agent procedure, reusable prompt workflow, or skill-source view -> skills/

   • Executable source lives under top-level skills/{engineering,productivity,personal,misc,in-progress,deprecated}/<slug>/SKILL.md.
   • Browseable wiki skill pages are generated under wiki/skills/<category>/; readable synthesis belongs in Skill Registry and wiki/concepts/*-skills.md.
   • Do not recreate hand-written root wiki/skills/<slug>.md mirrors.

10. Specific system architecture or technical design -> architecture/

    • Service boundaries, infrastructure, data flow, auth, billing, deployment architecture, technical comparisons.
    • Reusable ideas behind the system may also deserve concepts/.
    • Read Architecture System Map before creating or splitting an architecture page; it owns the current family map, merge decisions, and boundary/invariant/proof contract.

11. Code style guide, language convention, lint rule, naming rule, or engineering convention -> style/

    • Code-level writing, TypeScript/Python patterns, API shape, comments, naming, linting, and formatting.
    • Visual/product experience belongs in design/.

12. Design system, UI/UX, visual design, motion, typography, or art direction -> design/

    • Includes component systems, design references, dashboard patterns, visual taste, motion language, and brand/UI decisions.
    • Implementation-level code rules belong in style/.
    • Read Design System Map before creating, merging, or splitting a design page; it owns the current family map, no-merge decisions, and design-page contract.

13. Development workflow, operational runbook, sync flow, or human/team process -> workflows/

    • Git flow, release process, debugging process, capture flow, CI/CD procedure, source compile, recurring operating steps.
    • If an agent should execute it repeatedly, route to skills/ as well.

14. Research brief, academic paper, dataset, method, or experiment -> research/

    • Use when methodology, literature, data, or experimental evidence is the durable subject.
    • If the main value is a transferable model, file the model in concepts/ and cite the research.

15. Reusable concept, mental model, pattern, explanation, or theory -> concepts/

    • Must have transfer value beyond one person, project, or source.
    • Prefer this for teachable abstractions such as The Resolver Pattern and The Brain-Agent Loop.
    • Read Concept System Map before creating, merging, or splitting a concept page; it owns the current families, no-merge decisions, generated skill-family rule, and concept-page contract.

16. Kevin's articulated philosophy about work, life, building, taste, or relationships -> philosophies/

    • Use for Kevin's generalized beliefs.
    • Attributed external views stay on the source person's page unless Kevin has adopted them.

17. Career artifact, professional positioning, job search, recruiter strategy, or public content backlog -> career/

    • Resume, LinkedIn, portfolio positioning, applications, outreach, content calendars, offer analysis.
    • Interview rounds and study plans belong in interview-prep/.

18. Interview preparation -> interview-prep/

    • Round tactics, study plans, debriefs, question banks, company-specific interview notes, live exercise prep.
    • Job tracking and recruiter strategy go to career/.

19. Incident, outage, exploit, failed process, or retrospective with corrective action -> postmortems/

    • Something went wrong, a root cause was identified, and future behavior should change.
    • A lesson without an incident usually belongs in concepts/, workflows/, or philosophies/.

20. Explicit choice with reasoning and consequences -> decisions/

    • Use for inflection points, architecture/product/process decisions, and recorded tradeoffs.
    • The decision page should say what was chosen, why, what it supersedes, and what changes if evidence changes.

21. First-person story, exemplar run, source narrative, or memorable proof -> stories/

    • Use when the narrative is the point.
    • If the durable point is a reusable rule, file the rule elsewhere and link the story as evidence.

22. Place with narrative or operational relevance -> places/

    • Cities, offices, venues, campuses, neighborhoods, and recurring locations.
    • Create the directory only when a real page passes the notability bar.

23. Recurring behavioral cycle -> patterns/

    • Trigger -> mechanism -> outcome.
    • Use only when the cycle is stable enough to diagnose or reuse.

24. Unresolvable tension between values -> tensions/

    • Stable conflicts, not one-time problems to solve.

25. Biographical phase or state transition -> eras/ or transitions/

    • eras/ for sustained periods.
    • transitions/ for liminal movement between states.

26. Image, diagram, screenshot, transcript media, rendered artifact, or asset provenance -> assets/

    • Binary assets live under wiki/assets/.
    • Text pages about assets should explain provenance, use, and related pages.

27. Nothing fits -> inbox/

    • Temporary holding area only.
    • A real page here is a schema bug, a pending classification decision, or a signal to improve this resolver.

Ambiguity Table

Create, Merge, Or Fold

A page is worth creating when it has at least one of these:

• a durable subject agents will search for later
• a reusable decision, protocol, or mental model
• an entity Kevin actively interacts with
• an entity that appears across multiple sources
• a workflow, tool, or rule that changes future behavior
• an evidence trail that would be expensive to reconstruct

Do not create a page when the content is only:

• a sentence with no durable retrieval value
• a duplicate under a new slug
• a temporary task note better suited to session context
• a raw source summary with no synthesis
• a category that would contain only one weak stub

When in doubt, use Wiki Brain Operating Model: fold weak fragments into stronger articles, preserve old retrieval with aliases or redirects, and keep generated inventories generated.

Filing Checklist

Before creating or moving any page:

1. Search exact and fuzzy duplicates.
2. Check aliases and canonical slugs.
3. Decide page shape with Wiki Brain Operating Model.
4. Walk this decision tree.
5. Read the directory README or resolver companion when present.
6. Use Wiki Page Format frontmatter and body shape.
7. Cite new facts inline.
8. Link related pages.
9. Add entity backlinks when meaningful.
10. Update generated/source surfaces instead of hand-editing generated output.
11. Run npx tsx scripts/build-index.ts.
12. Run qmd update && qmd embed.
13. Run the narrow doctor/routing check when schema, routing, skills, tools, or agent behavior changed.
14. Append wiki/log.md.

---

Timeline

• 2026-07-01 | Tightened the agent-docs filing rule around Agent Docs System Map, generated surfaces, and portable operator quickrefs. Source: User request, 2026-07-01
• 2026-07-01 | Rebuilt the filing decision tree around the current wiki state: active article categories, operational namespaces, generated surfaces, dormant schema-supported categories, and the authority stack connecting resolver, brain model, page format, entity identity, memory routing, and index/log protocols. Source: User request, 2026-07-01
• 2026-06-27 | Linked filing decisions to Wiki Brain Operating Model so future page creation follows the compiled-brain model before adding more fragments. Source: User request, 2026-06-27
• 2026-06-18 | Expanded the filing resolver into a full page-creation protocol with decision procedure, category semantics, ambiguity table, quality bar, and done checklist. Source: User request, 2026-06-18; AGENTS.md; Wiki Page Format
• 2026-05-31 | Prior resolver clarified page filing vs skill/tool routing and added disambiguation rules. Source: AGENTS.md