arscontexta 0.6.0

package/methodology/derived systems follow a seed-evolve-reseed lifecycle.md

@@ -0,0 +1,56 @@
+---
+description: Minimum viable seeding, friction-driven evolution, principled restructuring when incoherence accumulates — reseeding re-derives from first principles enriched by operational experience
+kind: research
+topics: ["[[design-dimensions]]", "[[maintenance-patterns]]"]
+methodology: ["Systems Theory", "Original"]
+source: [[knowledge-system-derivation-blueprint]]
+---
+
+# derived systems follow a seed-evolve-reseed lifecycle
+
+Knowledge systems derived from research claims do not follow a simple create-then-maintain trajectory. They move through three qualitatively different phases, and understanding which phase you are in determines what actions are appropriate.
+
+**Seeding** is initial derivation constrained by Gall's Law. Since [[complex systems evolve from simple working systems]], the derived system must start as a minimum viable configuration: two or three note types, a handful of MOCs, basic folder structure, and a context file that teaches the agent how to operate and — crucially — how to evolve. Because [[methodology traditions are named points in a shared configuration space not competing paradigms]], the seed can start from a tradition's pre-validated configuration rather than composing from raw dimensions, and because [[novel domains derive by mapping knowledge type to closest reference domain then adapting]], unfamiliar domains can use reference domains as seeding points with adaptation axes defining the initial evolution trajectory. The temptation is to derive the theoretically optimal configuration from the claim graph. But even a perfectly justified complex system will collapse under its own weight because the countless micro-adaptations that make a system work can only emerge through use. What makes this incremental adoption safe is that [[the no wrong patches guarantee ensures any valid module combination produces a valid system]] — enabling a module cannot break existing structure, so the seed phase can start minimal with confidence that each subsequent addition is non-destructive. The most accessible seeding mechanism is the use-case preset. Since [[use-case presets dissolve the tension between composability and simplicity]], presets bundle a curated module selection under a use-case label — the user selects "Research Vault" and gets thirteen modules covering the full pipeline, without composing the selection from scratch. The preset resolves dimension coupling and dependency chains at activation time, producing a minimum viable configuration that the user can evolve through friction-driven module toggling. The seed includes evolution guidelines: when to add a field, when to create a new MOC, when to adjust processing cadence. These guidelines are as important as the initial structure because they encode the conditions under which complexity is justified.
+
+**Evolution** is growth through observed friction. Since [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]], the evolution phase has concrete thresholds: add a module after five manual repetitions of the process it would automate, split a module when its description exceeds 500 characters, remove after three unused sessions, and cap active modules at fifteen to twenty. Because [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]], each capability is an independent module with explicit dependencies, so evolution means toggling modules on at these calibrated friction points rather than restructuring a monolithic configuration — the agent adds yaml-schema when structured metadata becomes necessary, processing-pipeline when manual workflows create friction, each addition resolving its own dependencies and composing with everything already active. The agent monitors which note types get used, which fields actually get filled, where navigation fails, where processing produces unlinked notes. Each adaptation traces back to a specific observation mapped to a knowledge graph claim — not intuition but evidence. Since [[schema evolution follows observe-then-formalize not design-then-enforce]], the concrete protocol for schema evolution is a quarterly review with five signals: add a field when 20% of notes manually include it, demote required fields that collect placeholder values, prune unused enums, formalize patterned free text, split MOCs that exceed navigation thresholds. Since [[bootstrapping principle enables self-improving systems]], this phase is bootstrapping in action: the system uses its current capabilities to identify and implement improvements, with each improvement becoming available for the next cycle. And since [[incremental formalization happens through repeated touching of old notes]], the notes themselves are evolving in parallel with the system — claims sharpen, connections densify, vague inklings crystallize — so the system and its content co-evolve. The encoding trajectory mirrors this: since [[methodology development should follow the trajectory from documentation to skill to hook as understanding hardens]], methodology patterns within the system follow their own seed-evolve cycle — seeded as documentation in the context file, evolved through friction encounters into skills, and hardened into hooks when understanding is sufficient.
+
+But evolution has a limit, and without the transition to reseeding, [[PKM failure follows a predictable cycle]] — over-engineering and analysis paralysis set in as people attempt to fix systemic incoherence with local adaptations. Small adaptations accumulate side effects. A field added here creates a query expectation there. A new MOC shifts navigation patterns that other MOCs assumed were stable. Because [[configuration dimensions interact so choices in one create pressure on others]], changes in one dimension create pressure on others, and accumulated incremental changes can drift the configuration into an incoherent region where individual choices are locally justified but globally contradictory. Schema drift, navigation degradation, processing pipelines that no longer match the content they handle — these are symptoms of a system that has evolved past its derived coherence without restructuring. And since [[module deactivation must account for structural artifacts that survive the toggle]], experimentation itself becomes a source of incoherence: each module that was enabled, tested, and then disabled leaves ghost YAML fields and orphaned MOC links that accumulate as structural debris proportional to the number of experiments attempted.
+
+**Reseeding** is the response: principled restructuring that re-derives the system using original constraints enriched by accumulated observations. This is fundamentally different from both incremental evolution and routine maintenance. Since [[backward maintenance asks what would be different if written today]], reweaving asks this question at the note level — what would this note say given current understanding? Reseeding asks it at the system level — what would this entire architecture look like given what we now know about how it gets used? The scale difference matters because systemic incoherence cannot be fixed by improving individual notes. You need to step back and reconsider the templates, the pipeline structure, the MOC hierarchy, the processing cadence — the framework that everything else depends on. And since [[every knowledge domain shares a four-phase processing skeleton that diverges only in the process step]], reseeding does not redesign the skeleton itself — capture, process, connect, verify remain invariant — but restructures the process step implementation, the schema definitions, and the navigation hierarchy that sit on top of it.
+
+What makes reseeding principled rather than ad hoc is that [[derivation generates knowledge systems from composable research claims not template customization]]. The same claim graph that produced the initial seed now has additional inputs: every observation logged during evolution, every tension discovered through use, every adaptation and its justification. Re-derivation traverses the enriched claim graph with tighter constraints: not "what does the research suggest for this use case?" but "what does the research suggest for this use case given these specific operational realities?" The output preserves all content, all links, all accumulated understanding — it restructures the framework around them.
+
+The lifecycle is not linear but spiral. After reseeding, a new evolution phase begins from the restructured base, accumulating new observations until the next reseeding is warranted. Each cycle produces a system that is both more adapted to its actual use patterns and more coherent in its configuration choices. The claim graph itself improves through this process: observations from deployed systems feed back as new claims or sharpened existing ones, making subsequent derivations — for this system or any other — more grounded.
+
+There is a tension in recognizing when evolution should give way to reseeding. Too early, and you discard adaptations that haven't had time to prove their value. Too late, and incoherence compounds until the system's behavior becomes unpredictable. The trigger signals are systemic rather than local: not "this field doesn't work" (that is an evolution-phase adaptation) but "our schema, navigation, and processing have drifted apart" (that requires reseeding). Since [[gardening cycle implements tend prune fertilize operations]], the gardening metaphor clarifies the distinction: tending and fertilizing are evolution-phase operations that maintain and connect existing plants. Reseeding redesigns the garden's layout — which beds exist, how paths connect them, what the irrigation system looks like — while preserving the plants themselves.
+
+The practical implication is that derived systems need to be designed for reseeding from the start. Since [[context files function as agent operating systems through self-referential self-extension]], the context file is the natural home for reseeding meta-documentation — not just how to operate but how to re-derive: what constraints were used, what trade-offs were made and why, what observations would trigger reconsideration. A system that lacks this meta-documentation can still be reseeded, but the re-derivation loses access to the reasoning behind the original choices, making it more likely to repeat mistakes the first derivation already resolved.
+---
+
+Relevant Notes:
+- [[complex systems evolve from simple working systems]] — provides the theoretical foundation: Gall's Law explains why seeding must start simple, but this note adds the reseeding phase that Gall's Law alone does not describe
+- [[bootstrapping principle enables self-improving systems]] — evolution is bootstrapping in action, but reseeding is a phase transition that bootstrapping alone cannot accomplish because the system must step outside itself to re-derive
+- [[backward maintenance asks what would be different if written today]] — reweaving operates at the note level while reseeding operates at the system level: both ask what current understanding would change, but at different scales
+- [[derivation generates knowledge systems from composable research claims not template customization]] — derivation is the mechanism that makes reseeding principled rather than ad hoc: the claim graph provides the substrate for re-derivation
+- [[incremental formalization happens through repeated touching of old notes]] — evolution phase works through incremental formalization at the note level, but reseeding recognizes that accumulated incremental changes can produce systemic incoherence that incremental approaches cannot fix
+- [[configuration dimensions interact so choices in one create pressure on others]] — dimension coupling explains why evolution eventually requires reseeding: small adaptations in one dimension accumulate pressure on others until the configuration drifts into an incoherent region
+- [[gardening cycle implements tend prune fertilize operations]] — tend and fertilize are evolution-phase operations while reseeding is a qualitatively different act: restructuring the garden's layout rather than maintaining its plants
+- [[evolution observations provide actionable signals for system adaptation]] — provides the specific diagnostic protocol for the evolution phase: six observation patterns map to structural causes, telling the agent whether accumulated drift is still incremental (evolution-phase correction) or has crossed into systemic incoherence (reseeding trigger)
+- [[methodology development should follow the trajectory from documentation to skill to hook as understanding hardens]] — the encoding trajectory is a lifecycle within the evolution phase: methodology patterns seed as documentation, evolve through friction, and reseed at the next encoding level when understanding hardens
+- [[schema evolution follows observe-then-formalize not design-then-enforce]] — the schema-specific instantiation of the evolution phase: the quarterly review protocol with five concrete signals is how schemas evolve through observation rather than upfront design
+- [[PKM failure follows a predictable cycle]] — the failure cascade is what happens when the evolution phase stalls and reseeding never occurs: over-engineering and analysis paralysis are symptoms of attempting local fixes for systemic incoherence
+- [[every knowledge domain shares a four-phase processing skeleton that diverges only in the process step]] — clarifies what reseeding actually restructures: the skeleton itself (capture-process-connect-verify) is invariant, so reseeding targets the process step implementation, templates, and MOC hierarchy rather than the pipeline shape
+- [[methodology traditions are named points in a shared configuration space not competing paradigms]] — traditions serve as pre-validated seeding points: a derived system can seed from a tradition's coherent configuration rather than composing from raw dimensions
+- [[novel domains derive by mapping knowledge type to closest reference domain then adapting]] — extends the seeding concept: reference domains function as seeds for novel domains, with adaptation axes defining the initial evolution trajectory
+- [[context files function as agent operating systems through self-referential self-extension]] — the context file is the substrate where reseeding meta-documentation lives: self-referential self-extension enables the context file to teach not just operation but re-derivation
+- [[premature complexity is the most common derivation failure mode]] — the complexity budget is the seeding constraint: minimum viable configuration at seed time with evolution guidelines encoding when to add complexity rather than front-loading it; the budget constrains initial deployment between the kernel floor and the locally-justified-but-globally-unsustainable maximum
+- [[configuration paralysis emerges when derivation surfaces too many decisions]] — configuration paralysis can prevent the seeding phase from completing: if the derivation interface surfaces every dimension as a question, the user never finishes setup, so the system never reaches the evolution phase where friction-driven learning begins
+- [[the no wrong patches guarantee ensures any valid module combination produces a valid system]] — the safety property that makes the seed-evolve cycle reliable: each module toggle during seed and evolution phases is non-destructive because the guarantee ensures valid combinations never corrupt data or break structure
+- [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]] — the implementation pattern that makes the lifecycle's module-level toggling possible: seeding activates a minimal module set, evolution toggles modules on at friction points, and reseeding reconfigures the module selection; composable architecture is the engineering substrate on which the lifecycle operates
+- [[use-case presets dissolve the tension between composability and simplicity]] — the most accessible seeding mechanism: presets bundle curated module selections under use-case labels so seeding requires one choice rather than individual module evaluation, with the composable substrate enabling friction-driven evolution after the preset provides initial configuration
+- [[module deactivation must account for structural artifacts that survive the toggle]] — deactivation debris as a reseeding trigger: experimentation during the evolution phase leaves ghost YAML fields and orphaned MOC links from disabled modules, accumulating structural debris that comprehensive cleanup during reseeding addresses as part of principled restructuring
+- [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]] — the evolution phase's specific mechanism: concrete thresholds (5-repetition addition, 500-char split, 3-session removal, 15-20 module cap) operationalize friction-driven toggling, preventing both premature adoption and configuration debt during the evolution phase
+
+Topics:
+- [[design-dimensions]]
+- [[maintenance-patterns]]

package/methodology/description quality for humans diverges from description quality for keyword search.md

@@ -0,0 +1,73 @@
+---
+description: Descriptions that pass prediction tests (5/5) can fail BM25 retrieval because human-scannable prose uses connective vocabulary that dilutes keyword match scores — two optimization targets, not one
+kind: research
+topics: ["[[discovery-retrieval]]"]
+methodology: ["Original"]
+---
+
+# description quality for humans diverges from description quality for keyword search
+
+The recite skill's dual-test architecture — prediction scoring followed by retrieval testing — exposed a gap that the vault's description philosophy hadn't anticipated. Notes can score 5/5 on prediction (an agent reading title and description accurately predicts the note's content) while completely failing BM25 retrieval (searching the description text returns zero results). This isn't a bug in either test. It reveals that "description quality" is actually two different optimization targets that can pull in opposite directions.
+
+## The Mechanism
+
+Human-scannable descriptions use connective prose: "lossy compression optimized for decision-making, not content summary" reads naturally and enables prediction because the connective words ("optimized for," "not") create logical structure. But since [[BM25 retrieval fails on full-length descriptions because query term dilution reduces match scores]], every word in a BM25 query competes for scoring budget. Those connective words dilute the matching — common words like "optimized," "not," "for" consume IDF weight without contributing to retrieval. The distinctive terms that would actually match ("lossy," "compression," "retrieval," "filter") get proportionally less influence.
+
+This is why since [[good descriptions layer heuristic then mechanism then implication]], the layering formula can paradoxically harm retrieval. A well-layered description spends character budget on three distinct information types connected by prose transitions. A retrieval-optimized description would strip those transitions and pack in more distinctive keywords. The formula that makes descriptions excellent for human scanning makes them worse for keyword search.
+
+## Why This Matters for the Vault
+
+The foundation claim that [[descriptions are retrieval filters not summaries]] assumes a single filter function. But this divergence reveals two distinct filter channels:
+
+1. **Human scanning channel** — an agent reads descriptions sequentially, using natural language comprehension to assess relevance. Here, prose quality, logical structure, and layered information all help. Descriptions optimized for this channel are well-written sentences.
+
+2. **Keyword search channel** — BM25 or similar search engines match query terms against description text. Here, keyword density, distinctive vocabulary, and minimal filler words help. Descriptions optimized for this channel are keyword-dense phrases.
+
+These channels make different demands. A description like "cognitive modes conflict so separating them in time preserves quality of both" works beautifully for channel 1 — you understand the claim, the mechanism, the implication. For channel 2, the same text is a poor query: "cognitive," "modes," "conflict," "separating," "time," "preserves," "quality" are all common words that match widely.
+
+Since [[narrow folksonomy optimizes for single-operator retrieval unlike broad consensus tagging]], the personal vocabulary problem compounds this. Idiosyncratic terms like "slip-box" or "agent-vault" or "systems-theoretic" are highly distinctive for human scanning — they immediately signal domain and perspective. But their very idiosyncrasy makes them sparse in the corpus, meaning BM25 has fewer documents to score against, and competing documents with more common vocabulary can outrank.
+
+## The Dual Optimization Problem
+
+Since [[metadata reduces entropy enabling precision over recall]], the entropy reduction argument assumes a unified retrieval mechanism. But the two channels reduce entropy differently:
+
+- **Scanning** reduces entropy through comprehension — the agent understands what makes this note different from alternatives by processing the description's meaning
+- **Keyword search** reduces entropy through term matching — the search engine narrows candidates by statistical co-occurrence of query terms and document terms
+
+The same description text cannot simultaneously maximize both. Connective prose helps comprehension but hurts term matching. Keyword density helps term matching but reduces readability. The current vault philosophy implicitly optimizes for channel 1 (human scanning) because descriptions are designed to "add new information beyond the title" in natural prose. Channel 2 (keyword retrieval) is an afterthought. This is a specific instance of the broader tension that [[sense-making vs storage does compression lose essential nuance]] — but here the compression loss is channel-dependent rather than absolute. The nuance "lost" for BM25 (connective prose structure) is the nuance "preserved" for human scanning, and vice versa.
+
+## Practical Resolution
+
+The resolution is not to choose one channel over the other but to recognize which channel matters when. Since [[retrieval verification loop tests description quality at scale]] runs both prediction and retrieval tests, the dual-test architecture already captures this divergence. The improvement is in how we interpret results:
+
+- **Prediction pass, retrieval fail** — description is well-written but keyword-sparse. This is the exact pathway where [[metacognitive confidence can diverge from retrieval capability]] — the description looks correct through the prediction test while failing the retrieval test. Consider: is keyword retrieval actually needed for this note, or will scanning and semantic search always find it? If BM25 matters, add distinctive keywords without destroying prose quality.
+
+- **Prediction fail, retrieval pass** — description has good keywords but poor information structure. Apply the layering formula.
+
+- **Both fail** — description needs rewriting on both dimensions.
+
+- **Both pass** — description is genuinely high-quality across channels.
+
+The deeper question is whether BM25 retrieval of descriptions even matters given that the vault has semantic search via qmd. Vector search (vsearch) finds meaning across vocabulary differences — exactly the divergence that BM25 misses. If the primary retrieval path is `qmd query` or `qmd vsearch`, then optimizing descriptions for BM25 is solving a secondary problem. The prediction test (channel 1) may be the only quality dimension that genuinely matters, with keyword retrieval as a degraded fallback that should not drive description design.
+
+But fallbacks matter precisely when primary systems fail. Since qmd has documented reliability issues (stale indices, segfaults, MCP disposal errors), BM25 via `qmd search` is often the only working retrieval. Descriptions that fail BM25 are invisible during qmd outages — creating a reliability gap at the description layer that compounds the infrastructure reliability gap at the search layer. This is also evidence that [[vault conventions may impose hidden rigidity on thinking]] — the prose description convention, while justified for scanning, creates an invisible constraint on fallback retrieval that only surfaces during infrastructure failures.
+
+---
+
+Source: /rethink session (2026-02-08), promoted from [[description quality for humans diverges from description quality for keyword search]]
+---
+
+Relevant Notes:
+- [[descriptions are retrieval filters not summaries]] — foundation that assumes one filter function, but this note reveals filtering splits into two distinct channels with different requirements
+- [[good descriptions layer heuristic then mechanism then implication]] — the layering formula optimizes for human scanning but may inadvertently harm keyword retrieval by consuming character budget with connective prose
+- [[retrieval verification loop tests description quality at scale]] — the dual-test architecture (prediction + retrieval) that first exposed this divergence; the loop correctly identifies it but the scoring conflates two separate quality dimensions
+- [[distinctiveness scoring treats description quality as measurable]] — measures inter-note confusion via similarity but doesn't distinguish whether distinctiveness serves human scanning or machine retrieval
+- [[metadata reduces entropy enabling precision over recall]] — the entropy reduction argument assumes a single retrieval channel, but BM25 and human scanning reduce entropy through different mechanisms
+- [[narrow folksonomy optimizes for single-operator retrieval unlike broad consensus tagging]] — personal vocabulary amplifies this divergence because idiosyncratic terms may be highly distinctive for human scanning while being sparse in the BM25 index
+- [[BM25 retrieval fails on full-length descriptions because query term dilution reduces match scores]] — provides the mechanism: IDF scoring explains WHY connective prose dilutes keyword retrieval, grounding this note's observation in specific search engine behavior
+- [[sense-making vs storage does compression lose essential nuance]] — the dual-channel divergence is a specific instance of this tension: what counts as essential nuance depends on which retrieval channel the compression serves
+- [[metacognitive confidence can diverge from retrieval capability]] — extends: prediction-pass retrieval-fail is a concrete pathway for the confidence-capability divergence where the system looks correct through one test while failing another
+- [[vault conventions may impose hidden rigidity on thinking]] — the ~150 char prose description convention implicitly optimizes for human scanning, imposing a hidden constraint on keyword retrieval that this note makes visible
+
+Topics:
+- [[discovery-retrieval]]

package/methodology/descriptions are retrieval filters not summaries.md

@@ -0,0 +1,112 @@
+---
+description: Note descriptions function as lossy compression enabling agents to filter before loading full content, which is information-theoretically sound
+kind: research
+topics: ["[[discovery-retrieval]]"]
+methodology: ["Cornell"]
+---
+
+# descriptions are retrieval filters not summaries
+
+The primary purpose of a note description is not to summarize what the note contains, but to help agents decide whether to load the full content. This is the retrieval filter function, and it maps directly to Cornell Note-Taking's cue column pattern.
+
+## The Information-Theoretic Basis
+
+Description as filter is information-theoretically sound: it's lossy compression that preserves decision-relevant features while discarding detail. The description answers "should I read this?" not "what does this say?" This is exactly what Shannon's rate-distortion theory predicts: optimal compression for a given task throws away information that doesn't help with that task.
+
+Aggregating descriptions creates a pre-computed low-entropy representation of the system. Scanning 50 descriptions costs fewer tokens than reading 5 full notes to find the relevant one. The description layer enables efficient filtering.
+
+## The Cornell Cue Column Pattern
+
+Cornell Note-Taking has three sections:
+- **Notes**: detailed content
+- **Cue column**: questions or keywords that trigger recall
+- **Summary**: synthesis across notes
+
+The cue column is explicitly designed as a retrieval aid. You write cues that help you find and recall content later. This is the same function descriptions serve: helping future retrieval by capturing what makes this note distinctive. Since [[wiki links are the digital evolution of analog indexing]], the cue column was an early form of the same indexing pattern that wiki links now implement digitally — both create navigable pointers that serve as entry points into content. Cornell actually has two compression mechanisms operating at different points: because [[summary coherence tests composability before filing]], the summary section tests structural coherence at filing time (is this unit singular?), while descriptions enable retrieval filtering at query time (should I load this?). Both compress, but for different purposes.
+
+The pattern validates that descriptions work as filters: humans need them too, not just agents. The difference is that agents can read YAML frontmatter programmatically, while humans read cue columns visually.
+
+## Progressive Disclosure Pattern
+
+The discovery layers implement this:
+
+1. **File tree**: titles only (highest compression)
+2. **Descriptions**: titles + descriptions (medium compression)
+3. **Outline**: headings structure (low compression)
+4. **Full content**: everything (no compression)
+
+Each layer adds fidelity but costs more tokens. Since [[progressive disclosure means reading right not reading less]], this isn't about minimizing tokens — it's about curating what deserves the full-depth treatment. [[spreading activation models how agents should traverse]] implements this as decay-based context loading, and descriptions occupy a specific position: high-decay traversal stops at the description layer. An agent scanning descriptions activates many concepts at low depth. Loading full files activates fewer concepts at high depth. The description layer is the sweet spot for filtering: enough context to decide, low enough cost to scan many at once. And since [[AI shifts knowledge systems from externalizing memory to externalizing attention]], the description layer is not merely a retrieval optimization — it is an attention externalization mechanism. The system pre-computes which notes deserve deeper attention by encoding decision-relevant features into descriptions, directing the agent's finite focus rather than merely helping it recall what it stored.
+
+## The Anti-Pattern: Description as Summary
+
+When descriptions just restate the title in different words, they waste the agent's context. This is the same failure mode as vague claims: since [[claims must be specific enough to be wrong]], descriptions that merely paraphrase add nothing to disagree with or build on. This maps directly to [[the generation effect requires active transformation not just storage]]: paraphrase is not generation. Writing a description that restates the title produces nothing new — no cognitive hooks, no new information, no retrieval value. A good description generates something: mechanism, implication, or scope that the title doesn't contain. That generation is what creates the filter value. The experiment [[verbatim risk applies to agents too]] tests whether agents commit this anti-pattern at scale — producing well-structured outputs that reorganize content without genuine synthesis. If that experiment validates, description writing becomes a specific detection point: descriptions that merely paraphrase are evidence of the verbatim failure mode. This happens when you treat description as "mini-summary" rather than "retrieval cue."
+
+Since [[testing effect could enable agent knowledge verification]], the paraphrase anti-pattern becomes testable. When an agent reads only title and description, then predicts note content, paraphrase descriptions should fail — they don't contain enough distinct information to enable accurate prediction. The testing effect experiment's first pre-registered prediction directly tests this: notes flagged by recite as poorly-retrievable should have descriptions that merely paraphrase titles. If validated, this provides an objective diagnostic for the anti-pattern rather than relying on subjective judgment about whether a description "adds enough."
+
+Bad:
+- Title: "vector proximity measures surface overlap not deep connection"
+- Description: "Semantic similarity captures surface-level overlap rather than genuine conceptual relationships"
+
+This description adds no new information. It just paraphrases the title. An agent scanning descriptions can't use this to filter.
+
+Good:
+- Title: "vector proximity measures surface overlap not deep connection"
+- Description: "Two notes about the same concept with different vocabulary score high, while genuinely related ideas across domains score low — embeddings miss what matters"
+
+This description adds mechanism (vocabulary vs concepts) and implication (cross-domain connections fail). Now an agent knows: this note is about limitations of embedding-based search, specifically the cross-domain problem.
+
+## Implications
+
+Since descriptions function as retrieval filters, the quality standard is: does this help an agent decide whether to load the full note? Not: does this summarize the note accurately? An active experiment, [[question-answer metadata enables inverted search patterns]], tests whether an explicit `answers:` YAML field would extend this further — storing not just retrieval cues but the specific questions the note answers. If validated, question-matching would become an even faster filter than description scanning.
+
+But the compression that enables filtering may lose exactly what makes complex ideas valuable. Since [[sense-making vs storage does compression lose essential nuance]], some knowledge types may resist the ~150-character filter format: contextual knowledge whose meaning depends on situation, procedural nuance where tacit judgment matters, or ideas whose distinctive features ARE the subtle details that don't compress well. The description layer works when it preserves enough distinctiveness for correct filtering — but for ideas where distinctiveness IS the nuance, compression may create systematic retrieval failures that go undetected because we never find what we're missing.
+
+### Distinctiveness Over Comprehensiveness
+
+The information-theoretic framing implies a specific design criterion: descriptions should maximize distinctiveness within the corpus rather than maximize comprehensiveness. Since [[metadata reduces entropy enabling precision over recall]], the goal is pre-computing low-entropy representations that shrink the search space. A description that tries to cover everything a note contains dilutes its filter value. A description that captures what makes this note different from similar notes creates high information content relative to the corpus.
+
+This is the difference between:
+- **Comprehensive**: "Discusses how descriptions work and why they matter for retrieval" (could apply to many notes)
+- **Distinctive**: "Two notes about the same concept with different vocabulary score high, while genuinely related ideas across domains score low" (immediately identifies this specific note)
+
+The discriminating question when writing descriptions: "Would this description help an agent choose THIS note over similar notes on related topics?" If the description could plausibly apply to multiple notes in the system, it lacks distinctiveness and fails as a filter.
+
+This changes what makes a good description:
+- Add NEW information beyond the title
+- Capture scope, mechanism, or implication
+- Include distinctive keywords for semantic search
+- Enable filtering decisions without reading full content
+- Maximize what distinguishes this note from related notes
+
+Since [[good descriptions layer heuristic then mechanism then implication]], an effective structure emerges: lead with the actionable heuristic (what to do), back with mechanism (why it works), end with operational implication (what this means for practice). This layered formula operationalizes the distinctiveness criterion — each layer adds information that the previous layers don't contain.
+
+But the description schema itself is a convention that may constrain. Since [[vault conventions may impose hidden rigidity on thinking]], the ~150-character limit forces a particular condensation style. Visual insights, procedural knowledge, or context-dependent ideas might resist this format — they can't be reduced to a sentence without losing something. The experiment tracks whether YAML metadata requirements accumulate into hidden rigidity.
+
+The description layer becomes more valuable as descriptions improve, because better filters mean fewer wasted full-note loads. Since [[throughput matters more than accumulation]], this directly serves the success metric: filtering speed determines processing velocity from capture to synthesis. Every millisecond saved on filtering compounds across every retrieval operation. But the existence of descriptions doesn't guarantee they function as filters: since [[metacognitive confidence can diverge from retrieval capability]], a vault with complete description coverage may produce false confidence that the filtering layer works while actual retrieval systematically fails. This is the organized graveyard at the filtering layer — descriptions exist but don't enable filtering decisions.
+
+Since [[retrieval verification loop tests description quality at scale]], this gap between "descriptions exist" and "descriptions work" becomes empirically testable. Systematic prediction-then-verify cycles across all notes with scoring reveal which descriptions fail as filters, common failure modes, and whether description quality correlates with note type or age. The loop turns the filter assumption into measurable infrastructure health.
+
+The filter function itself splits across retrieval channels. Descriptions optimized for agent scanning — prose with connective tissue, layered information, natural flow — work well when agents read descriptions sequentially. But since [[BM25 retrieval fails on full-length descriptions because query term dilution reduces match scores]], those same prose descriptions fail keyword search because common words dilute the distinctive terms that would identify the right note. The filter works for one retrieval channel while failing another, and since [[description quality for humans diverges from description quality for keyword search]], this split reveals that "description quality" is not one dimension but two separate optimization targets. Human scanning and keyword matching make opposing demands on the same ~150 characters, so the single filter function this note assumes is actually a dual filter serving channels with different requirements.
+---
+
+Relevant Notes:
+- [[progressive disclosure means reading right not reading less]] — articulates the philosophy: disclosure layers enable curation for quality, not token savings
+- [[good descriptions layer heuristic then mechanism then implication]] — provides the structural formula: lead with actionable heuristic, back with mechanism, end with operational implication
+- [[spreading activation models how agents should traverse]] — positions descriptions as the high-decay layer: agents can activate many concepts at description depth without loading full files
+- [[processing effort should follow retrieval demand]] — descriptions enable JIT processing by providing efficient filtering before full retrieval
+- [[queries evolve during search so agents should checkpoint]] — at each checkpoint, descriptions enable fast reassessment without loading full notes
+- [[throughput matters more than accumulation]] — filtering speed directly serves the success metric: faster filtering means faster processing velocity
+- [[the generation effect requires active transformation not just storage]] — explains why paraphrase fails as a description: generation creates value, restatement doesn't
+- [[vault conventions may impose hidden rigidity on thinking]] — tests whether the description schema and other conventions accumulate into constraints that certain thinking styles can't fit
+- [[testing effect could enable agent knowledge verification]] — tests whether the paraphrase anti-pattern causes measurable retrieval failures, providing objective diagnostic for description quality
+- [[retrieval verification loop tests description quality at scale]] — operationalizes the testing effect as systematic vault-wide assessment: scoring across all notes turns description quality from assumption to measured property
+- [[verbatim risk applies to agents too]] — the broader experiment testing whether agents produce well-structured outputs without genuine insight; description-as-paraphrase is a specific manifestation of this failure mode
+- [[metacognitive confidence can diverge from retrieval capability]] — tests whether description coverage produces false confidence: descriptions may exist without functioning as filters, creating the organized graveyard at the filtering layer
+- [[sense-making vs storage does compression lose essential nuance]] — the open tension: lossy compression is theoretically sound, but some knowledge types may resist the format in ways that create silent retrieval failures
+- [[AI shifts knowledge systems from externalizing memory to externalizing attention]] — paradigm frame: description-based filtering is a form of attention externalization; the system pre-computes what deserves deeper focus rather than merely helping agents recall what was stored
+- [[narrow folksonomy optimizes for single-operator retrieval unlike broad consensus tagging]] — explains why description optimization works: single-operator systems can tune ~150-char descriptions entirely to one agent's retrieval patterns without accommodating diverse users, making the filter layer maximally effective for the operator who will actually use it
+- [[BM25 retrieval fails on full-length descriptions because query term dilution reduces match scores]] — reveals that the filter function splits across channels: prose descriptions that work for agent scanning fail keyword search because connective words dilute IDF scoring
+- [[description quality for humans diverges from description quality for keyword search]] — develops the full consequence: the filter function is not one dimension but two, with human scanning and keyword matching as separate optimization targets that can pull in opposite directions
+
+Topics:
+- [[discovery-retrieval]]

package/methodology/design MOCs as attention management devices with lifecycle governance.md

@@ -0,0 +1,318 @@
+---
+description: MOC best practices for derived knowledge systems — hierarchy patterns, lifecycle management, and health metrics adapted across domains
+kind: guidance
+status: active
+topics: ["[[note-design]]", "[[maintenance-patterns]]"]
+---
+
+# design MOCs as attention management devices with lifecycle governance
+
+MOCs (Maps of Content) are attention management devices. Since [[MOCs are attention management devices not just organizational tools]], they don't just organize notes — they tell agents where to focus, what connects to what, and where synthesis opportunities exist. Every derived vault needs MOCs, but different domains need different MOC patterns.
+
+This doc tells the plugin HOW to generate MOC structures for each domain.
+
+## Why MOCs Are Non-Negotiable
+
+Without MOCs, agents face navigational vertigo. Since [[navigational vertigo emerges in pure association systems without local hierarchy]], a flat vault of interconnected notes provides no starting point for orientation. MOCs solve this by creating curated entry points — the agent doesn't read everything; it reads the MOC and follows relevant links.
+
+Since [[MOC construction forces synthesis that automated generation from metadata cannot replicate]], MOCs carry intellectual value beyond navigation. The act of curating which notes appear in a MOC and writing context phrases for each link IS synthesis. Automated MOCs generated from metadata tags lack this synthesis — they're address books, not maps.
+
+Since [[complete navigation requires four complementary types that no single mechanism provides]], MOCs fill the local navigation role — the "what's nearby?" question that search, hub navigation, and inline links cannot answer. Missing this one type creates a predictable blind spot: agents can find things (search) and follow connections (links) but cannot orient within a domain.
+
+## The Dump-Lump-Jump Construction Process
+
+Nick Milo's construction pattern has three phases that do fundamentally different cognitive work:
+
+### Phase 1: Dump (Gather Everything)
+
+Pull every note that might belong to the MOC's territory. This is exhaustive collection without judgment — cast the net wide. Automated tools handle this well: tag queries, semantic search, and link graph traversal can identify candidate notes reliably.
+
+### Phase 2: Lump (Classify and Context)
+
+Group notes by relationship, write context phrases for each link explaining WHY to follow it. This is where since [[basic level categorization determines optimal MOC granularity]], the builder exercises categorization judgment — deciding which notes cluster together, what the groupings mean, and whether the current granularity is right.
+
+Context phrases are mandatory. Every link in a MOC must explain its relationship:
+
+**Good:** `- [[mood patterns predict trigger sensitivity]] — connects daily mood ratings to identified triggers, showing which moods lower the threshold`
+
+**Bad:** `- [[mood patterns predict trigger sensitivity]]` (bare link — address book entry, not a map)
+
+The context phrase tells the agent: "If you're looking for X, follow this link." Without it, the agent must read every linked note to decide if it's relevant.
+
+### Phase 3: Jump (Synthesize)
+
+Identify tensions between notes, write the orientation synthesis, capture insights that emerge from seeing the collection as a whole. The Jump phase is where the MOC transcends its index function. Two clusters might be in tension. A gap might become visible. A higher-order claim might emerge from the arrangement.
+
+**Why the Jump phase matters for agents:** Since [[the generation effect requires active transformation not just storage]], the cognitive value accrues to whoever does the construction. Even if an automated system could produce identical output, the act of construction produces understanding that informs future reasoning.
+
+**Why manual synthesis matters:** Automated MOC generation can produce the Dump phase flawlessly and approximate the Lump phase through clustering. But it cannot perform the Jump because the Jump requires judgment about what matters, what conflicts, and what the collection means as a whole. The resulting MOC is structurally valid but functionally hollow — it satisfies the navigation need without providing genuine orientation, so the agent never looks further.
+
+## Seven MOC Types
+
+Different organizational needs call for different MOC structures. The plugin recognizes seven types:
+
+### 1. Hub MOC
+
+Entry point for the entire vault. Pure navigation, under 100 lines. Links to domain MOCs with brief orientation.
+
+**Example:** `index.md` — one per vault, rarely changes, highest traffic.
+
+### 2. Domain MOC
+
+Entry point for a research area. Contains cross-cutting synthesis and links to topic MOCs.
+
+**Example:** `knowledge-work.md` — links to graph-structure, agent-cognition, processing-workflow, etc.
+
+### 3. Topic MOC
+
+Active workspace for a specific subdomain. Core ideas, tensions, gaps, agent notes. This is where most intellectual work happens.
+
+**Example:** `graph-structure.md` — 15-40 notes about graph topology, navigation, linking patterns.
+
+### 4. Self MOC
+
+Agent identity and operational memory. Flat peer structure, no hierarchy between peers.
+
+**Example:** `identity.md`, `methodology.md`, `goals.md` — facets of agent state.
+
+### 5. Operational MOC
+
+Procedure tracking with atomic entries in subdirectories. Groups operational notes by category.
+
+**Example:** `observations.md` — categorizes observation notes by type (methodology, process gap, friction).
+
+### 6. Content Hub MOC
+
+Domain workflow hub combining navigation with operational guidance. Lives at the root of a domain folder.
+
+**Example:** `twitter.md` — navigation to drafts, published content, people, plus workflow instructions.
+
+### 7. Entity MOC
+
+Per-person, per-project, or per-character tracking. Accumulates context about a specific entity across time.
+
+**Example:** `people/angie-bowen.md` — interaction history, relationship context, follow-up items.
+
+**When to use which:**
+
+| Need | MOC Type | Why |
+|------|----------|-----|
+| Vault-wide orientation | Hub | Single entry point, rare changes |
+| Research area overview | Domain | Cross-cutting synthesis across topics |
+| Active knowledge work | Topic | Working surface for claims, tensions, gaps |
+| Agent self-knowledge | Self | Flat peers for identity facets |
+| Operational logging | Operational | Categorized atomic entries |
+| Workflow + navigation | Content Hub | Domain that needs both process and map |
+| Tracking entities | Entity | Accumulating context about people, projects, characters |
+
+## Three Hierarchy Patterns
+
+The plugin chooses from three patterns based on domain characteristics:
+
+### Pattern A: Three-Tier Research
+
+```
+Hub (index.md) -> Domain MOCs -> Topic MOCs -> Claim Notes
+```
+
+**Best for:** Domains with deep conceptual structure, many interconnected ideas, and synthesis as a primary value. The hierarchy provides layered orientation: hub for broad navigation, domain for area context, topic for active workspace.
+
+**Domain examples:** Research and Academic, Legal (precedent hierarchies), Engineering (architecture domains), Student Learning (course and concept hierarchies)
+
+**Plugin generates:**
+- One hub MOC linking domain MOCs
+- Domain MOCs for major knowledge areas
+- Topic MOCs when 20+ notes cluster around a subtopic
+- Auto-split suggestion when topic MOCs exceed 50 notes
+
+### Pattern B: Flat Peer
+
+```
+MOC-A | MOC-B | MOC-C | MOC-D  (no hierarchy, equal peers)
+```
+
+**Best for:** Domains with distinct areas that don't nest hierarchically. Each area is a self-contained workspace. No area is "parent" to another.
+
+**Domain examples:** Personal Assistant (life areas), Health and Wellness (fitness / nutrition / sleep / symptoms as peers), Trading (strategy areas as peers)
+
+**Plugin generates:**
+- One MOC per life area or dimension
+- No hub MOC — each area is a direct entry point
+- Cross-area links in Agent Notes sections to surface correlations
+
+### Pattern C: Hub-Plus-Entities
+
+```
+Hub MOC -> Entity MOCs (person/project/character)
+            -> Entity-specific notes
+```
+
+**Best for:** Domains centered around entities (people, projects, characters, cases) where each entity accumulates its own context over time.
+
+**Domain examples:** People and Relationships (person MOCs), Creative Writing (character/location MOCs), Product Management (feature/customer MOCs), Project Management (project MOCs), Legal (case MOCs)
+
+**Plugin generates:**
+- One hub MOC with overview and quick reference
+- Entity MOCs created dynamically as entities are added
+- Entity subdirectories for clean organization
+- Relationship-between-entities tracking
+
+**Decision framework:** Active research -> Three-Tier. Agent identity -> Flat Peer. Domain workflow with entities -> Hub-Plus-Entities. Never exceed 4 tiers.
+
+## MOC Content Rules
+
+The plugin generates MOCs with these structural rules:
+
+### Context Phrases Are Mandatory
+
+Every link in a MOC must have a context phrase explaining WHY to follow that link. Since [[context phrase clarity determines how deep a navigation hierarchy can scale]], the quality of these phrases directly determines how far the MOC hierarchy can scale. Ambiguous phrases force agents to load linked notes to assess relevance, converting attention savings back into attention cost.
+
+### Synthesis Lives in Notes, Not MOCs
+
+When a MOC section starts containing developed arguments (multi-paragraph analysis, detailed reasoning), that content should be extracted into a synthesis note and the MOC should link to it.
+
+MOCs navigate. Notes argue. The plugin flags when MOC sections exceed ~200 words as a signal to extract.
+
+### Agent Notes Section
+
+Every MOC should end with an Agent Notes section containing:
+- Navigation shortcuts (e.g., "Start with note X if you're looking for Y")
+- Dead ends documented (e.g., "Note Z looks relevant but doesn't lead anywhere for this topic")
+- Productive combinations (e.g., "Notes A and B together form a complete argument about...")
+
+Since [[agent notes externalize navigation intuition that search cannot discover and traversal cannot reconstruct]], agent notes provide strategic attention management — while the synthesis paragraph orients to WHAT the topic contains, agent notes orient to HOW to navigate it.
+
+Agent notes are updated during reflect/reweave passes. They encode the navigation intuition that search alone cannot provide.
+
+## Staleness Risk
+
+Since [[stale navigation actively misleads because agents trust curated maps completely]], MOC staleness is the single most dangerous maintenance failure in agent-operated systems.
+
+**Why staleness is worse than absence:** A missing MOC causes vertigo — disorienting but honest. The agent falls back to search, which accesses current content. A stale MOC is deceptive. It presents an outdated view as current, and the agent has no mechanism to suspect otherwise. Notes created after the last MOC update are invisible — not because they're hard to find, but because the agent never looks for them. The curated map satisfies the navigation need, so no further search occurs.
+
+**Why agents are especially vulnerable:** Humans retain cross-session memory that might trigger doubt ("I remember writing something about this"). Agents have zero such intuition. Each session loads the MOC and treats its contents as authoritative.
+
+**Detection mechanisms:**
+- Reconciliation checks: compare notes with matching topics to MOC entries
+- Coverage metrics: percentage of topic notes actually linked from their MOC
+- Staleness signals: MOC last-updated date vs newest note in its territory
+
+**Prevention:**
+- Pipeline integration: /reflect updates MOCs as part of standard processing
+- Batch-level checks: after processing batches, verify new notes appear in relevant MOCs
+- Periodic MOC review: flag MOCs not updated in 90+ days for active topics
+
+## Domain-Specific MOC Adaptations
+
+Each domain adapts the MOC structure to match its natural organizing principles. See the domain examples in `examples/` for complete illustrations.
+
+| Domain | Hierarchy | Key MOC Features |
+|--------|-----------|-----------------|
+| Research | Three-tier | Topic MOCs have Tensions and Explorations Needed sections |
+| Therapy | Flat peer | Pattern MOC links to all detected patterns with date ranges |
+| PM | Hub + entities | Project MOCs have Decision Log and Risk sections |
+| Creative | Hub + entities | Character MOCs track arc evolution across scenes |
+| Learning | Three-tier | Concept MOCs have prerequisite dependency information |
+| Personal | Flat peer | Area MOCs have health indicators and review frequency |
+| People | Hub + entities | Person MOCs track interaction recency and follow-ups |
+| Engineering | Three-tier | System MOCs have dependency maps and ADR links |
+| Trading | Flat peer | Strategy MOCs track win rate and drift metrics |
+| Health | Flat peer | Each dimension MOC has correlation analysis links |
+| Product | Hub + entities | Feature MOCs link to customer feedback and experiments |
+| Legal | Three-tier + entities | Matter MOCs have precedent chains and deadline tracking |
+
+**Domain-specific MOC sections beyond Core Ideas:**
+
+| Domain | Extra Sections | Purpose |
+|--------|---------------|---------|
+| Research | Tensions, Explorations Needed | Track intellectual conflict and gaps |
+| Therapy | Active Patterns, Strategy Effectiveness | Track therapeutic progress |
+| PM | Decisions, Open Risks, Action Items | Track project health |
+| Creative | Canon Facts, Continuity Notes | Track worldbuilding consistency |
+| Learning | Prerequisites, Mastery Progress | Track learning dependencies |
+| Trading | Active Theses, Performance Metrics | Track strategy effectiveness |
+
+## MOC Lifecycle Management
+
+The plugin generates lifecycle triggers:
+
+### Creation Triggers
+- 20+ notes cluster around a topic (detected via topic field analysis)
+- Navigation friction reported: "I can't find notes about X"
+- New domain area activated by user
+- Mental squeeze point: the builder notices orientation within a topic has become effortful
+
+### Split Triggers
+- MOC exceeds 50 notes (since [[basic level categorization determines optimal MOC granularity]])
+- Distinct sub-clusters emerge with different update frequencies
+- Agent notes section exceeds 30 lines (too much navigation knowledge for one level)
+
+**How to split:** Create sub-MOC(s) named `parent-subtopic.md`. Move Core Ideas for the sub-cluster. Parent becomes domain-style with synthesis and links to sub-MOCs. Update all affected notes' Topics footers.
+
+### Merge Triggers
+- Two MOCs have < 30 combined notes with significant overlap
+- Same update frequency and related topics
+- Since [[community detection algorithms can inform when MOCs should split or merge]]
+
+### Archive Triggers
+- < 5 notes and stagnant for 6+ months
+- Topic absorbed into a broader MOC
+- Domain area deactivated by user
+
+## Health Metrics
+
+The plugin monitors MOC health through these metrics:
+
+| Metric | Healthy | Warning | Action |
+|--------|---------|---------|--------|
+| Notes per topic MOC | 10-40 | >50 | Suggest split |
+| Orphan notes | 0 | Any | Flag for MOC addition |
+| Context phrase coverage | 100% | <80% | Flag bare links |
+| Agent notes length | 5-20 lines | >30 lines | Suggest observation extraction |
+| Last updated | <30 days | >90 days | Flag for review |
+| Cross-MOC membership | >10% of notes | <5% | Notes may be too siloed |
+| Coverage (notes in topic vs MOC entries) | >95% | <80% | MOC is going stale |
+
+## Compounding Returns
+
+Since [[MOC maintenance investment compounds because orientation savings multiply across every future session]], maintenance is not overhead but investment. A single context phrase update costs seconds but saves orientation time in every future session that loads the MOC. If the MOC loads fifty times, a thirty-second investment returns minutes of cumulative savings.
+
+**Prioritize by traffic:** Hub MOCs that load every session have the highest temporal multiplier. Topic MOCs that load in domain-specific sessions have moderate multiplier. Entity MOCs that load when that entity is active have the lowest but still positive multiplier. Maintenance effort should flow toward the highest-traffic MOCs.
+
+**The hidden second return:** MOC maintenance forces genuine intellectual engagement — the maintainer reads notes in context, notices tensions, writes synthesis. Since [[the generation effect requires active transformation not just storage]], the act of maintaining IS thinking. The return is double: measurable orientation savings plus synthesis opportunities that emerge from reconsidering arrangements.
+
+## Domain Examples
+
+These domain compositions demonstrate MOC patterns in practice:
+
+- [[academic research uses structured extraction with cross-source synthesis]] — Three-tier research pattern: Hub -> Literature Review MOCs -> Topic MOCs; demonstrates split triggers when topic MOCs exceed 50 claims
+- [[personal assistant uses life area management with review automation]] — Flat peer pattern: life areas (Career, Health, Relationships, Finance, Growth) as equal MOCs with area health indicators
+- [[people relationships uses Dunbar-layered graphs with interaction tracking]] — Hub-plus-entities pattern: hub MOC with quick reference table, individual person MOCs accumulating interaction context over time
+- [[creative writing uses worldbuilding consistency with character tracking]] — Hub-plus-entities with mixed types: character MOCs track arc evolution, location MOCs serve as worldbuilding reference, plot thread MOCs track foreshadowing-to-resolution
+- [[health wellness uses symptom-trigger correlation with multi-dimensional tracking]] — Flat peer with cross-dimensional links: fitness, nutrition, sleep, and symptom MOCs are peers, but Agent Notes sections surface correlations across dimensions
+- [[student learning uses prerequisite graphs with spaced retrieval]] — Three-tier with prerequisite awareness: concept MOCs include dependency information, enabling the agent to identify prerequisite gaps
+
+## Grounding
+
+This guidance is grounded in:
+- [[MOCs are attention management devices not just organizational tools]] — MOCs as attention management
+- [[MOC construction forces synthesis that automated generation from metadata cannot replicate]] — why curation matters
+- [[navigational vertigo emerges in pure association systems without local hierarchy]] — why MOCs are necessary
+- [[basic level categorization determines optimal MOC granularity]] — optimal MOC size
+- [[community detection algorithms can inform when MOCs should split or merge]] — algorithmic split/merge signals
+- [[MOC maintenance investment compounds because orientation savings multiply across every future session]] — why MOC investment pays off
+- [[stale navigation actively misleads because agents trust curated maps completely]] — the danger of unmaintained MOCs
+- [[complete navigation requires four complementary types that no single mechanism provides]] — MOCs fill the local navigation role
+- [[context phrase clarity determines how deep a navigation hierarchy can scale]] — context phrase quality constrains hierarchy depth
+- [[the generation effect requires active transformation not just storage]] — why manual construction produces understanding
+
+---
+
+Topics:
+- [[index]]
+- [[index]]
+---
+
+Topics:
+- [[note-design]]
+- [[maintenance-patterns]]