arscontexta 0.6.0

package/methodology/metacognitive confidence can diverge from retrieval capability.md

@@ -0,0 +1,42 @@
+---
+description: Well-organized vault structure with good descriptions and dense links can feel navigable while actual retrieval fails—appearance diverges from function
+kind: research
+topics: ["[[agent-cognition]]"]
+source: TFT research corpus (00_inbox/heinrich/)
+---
+
+# metacognitive confidence can diverge from retrieval capability
+
+Metacognition is thinking about thinking — including one's beliefs about one's own knowledge retrieval abilities. The "illusion of knowing" is well-documented in cognitive science: people believe they understand or can recall material when they actually can't. Since [[vivid memories need verification]], flashbulb memory research demonstrates the purest form of this divergence — memories that feel vivid and certain drift from reality while subjective confidence remains high, and only external verification against recorded facts reveals the gap. This extends to knowledge systems: a vault with well-organized folders, good descriptions, and dense links may feel navigable while actual retrieval fails.
+
+In agent-operated vaults, structural quality signals (descriptions exist, links are dense, MOCs are organized) can produce false confidence that masks actual retrieval failures. A system can appear functional through surface metrics while failing the real test: does needed content get found when needed? The divergence becomes particularly insidious at the traversal layer because since [[implicit knowledge emerges from traversal]], repeated navigation through the same paths builds intuitive confidence that bypasses explicit retrieval entirely. The agent feels it knows where things are — but that feeling was trained by path frequency, not retrieval success. Familiar paths feel right without being tested.
+
+This matters because vaults often measure themselves by structure (link density, description coverage, MOC organization). But these metrics measure what's buildable, not what's findable. Since [[descriptions are retrieval filters not summaries]], the description layer exists specifically to enable retrieval — but existence doesn't guarantee effectiveness. The human may look at coverage metrics and feel confident, while actual agent traversal fails to locate relevant notes. This is the "organized graveyard" at the retrieval layer — since [[structure without processing provides no value]], the Lazy Cornell anti-pattern shows that drawing structural lines without doing the processing work produces no benefit. Here the structural lines are "descriptions exist, links are dense" but the processing work that would make them effective (ensuring descriptions actually enable filtering, ensuring links actually enable traversal) may not have happened.
+
+This is WHY retrieval testing exists: to test whether descriptions enable retrieval, not just whether descriptions exist. Since [[testing effect could enable agent knowledge verification]], recite implements the testing effect as a quality gate — it forces prediction-then-verification rather than assumption-from-structure. The divergence between confidence and capability is exactly what recite detects. Since [[retrieval verification loop tests description quality at scale]], this verification extends to systematic vault-wide assessment: scoring prediction accuracy across all notes, detecting which types of notes have worse descriptions, and identifying common failure modes. The loop closes the confidence-capability gap by testing empirically whether the description layer functions, not just whether it exists.
+
+Since [[distinctiveness scoring treats description quality as measurable]], a complementary validation approach exists: test whether descriptions distinguish notes from each other, not just whether they exist. Both recite (prediction success), distinctiveness scoring (pairwise similarity), and the retrieval verification loop (systematic scoring with retrieval testing) close the gap between "descriptions present" (structural metric) and "descriptions work" (retrieval metric).
+
+Since [[progressive disclosure means reading right not reading less]], the system assumes disclosure layers enable curation. If descriptions exist but don't enable accurate prediction, the progressive disclosure mechanism breaks: agents can't curate what to read deeply because the filtering layer has false confidence built in. The diagnostic protocol in [[evolution observations provide actionable signals for system adaptation]] provides a complementary anti-divergence mechanism that operates at the system level: instead of testing whether individual descriptions work (recite) or whether individual schemas are valid (validation), it tests whether the system's structural decisions -- which types exist, which fields are required, how navigation is organized -- still match operational reality. A note can pass every schema check and still be evidence of system-level metacognitive divergence if it belongs to an over-modeled type that nobody uses.
+---
+
+Relevant Notes:
+- [[testing effect could enable agent knowledge verification]] — tests whether recite works as verification mechanism; this note explains why verification is necessary because structure alone produces false confidence
+- [[retrieval verification loop tests description quality at scale]] — the mechanism that closes the confidence-capability gap: systematic scoring turns description quality into measurable property, exposing where structural completeness masks retrieval failures
+- [[descriptions are retrieval filters not summaries]] — the theory that descriptions enable retrieval decisions; this note addresses what happens when enable fails in practice
+- [[PKM failure follows a predictable cycle]] — if stage-specific metrics produce false confidence (system appears healthy when cascade is active), early intervention becomes unreliable; metacognitive divergence is a threat to predictive maintenance
+- [[structure without processing provides no value]] — the Lazy Cornell anti-pattern: structural markers (descriptions exist, links present) can exist without the semantic work that makes them effective; this is the retrieval-layer manifestation of that pattern
+- [[progressive disclosure means reading right not reading less]] — assumes disclosure layers enable curation; this note addresses the failure mode where that assumption breaks because filtering layer information doesn't predict what's being filtered
+- [[distinctiveness scoring treats description quality as measurable]] — complementary validation approach: tests whether descriptions distinguish notes from each other (retrieval ambiguity), while testing effect tests whether descriptions predict content (retrieval accuracy); together they close the metrics-to-capability gap
+- [[verbatim risk applies to agents too]] — parallel failure pattern: agent outputs can look structured while lacking genuine insight; systems can look well-organized while lacking genuine navigability; both are appearance vs reality failures
+- [[community detection algorithms can inform when MOCs should split or merge]] — structural instance: stale MOC boundaries create exactly the organizational false confidence this note describes, where the system appears well-organized while actual community structure has drifted
+- [[evolution observations provide actionable signals for system adaptation]] — anti-divergence mechanism: the navigation failure and processing mismatch diagnostics test functional capability rather than structural appearance, catching system-level failures that metrics like link density and schema compliance would miss
+- [[description quality for humans diverges from description quality for keyword search]] — concrete divergence pathway: descriptions that pass prediction tests (5/5) can fail BM25 retrieval, making confidence-capability divergence channel-dependent; the system looks correct through one test while failing another
+- [[confidence thresholds gate automated action between the mechanical and judgment zones]] — system-level instantiation: poorly calibrated confidence scores in automated maintenance produce the same divergence between self-assessment and actual capability; the system believes its 0.9 threshold means 90% accuracy when calibration may not support that
+- [[observation and tension logs function as dead-letter queues for failed automation]] — the most dangerous divergence mechanism: when detection scripts themselves fail silently, the system loses its ability to self-monitor without knowing it has; the dead-letter queue for detection failures is the meta-monitoring layer that prevents this specific class of metacognitive collapse
+- [[vivid memories need verification]] — cognitive science grounding: flashbulb memories demonstrate the purest form of confidence-capability divergence at the individual level — subjective vividness decouples from objective accuracy, and only external verification closes the gap; the same pattern scales to system-level structural confidence
+- [[implicit knowledge emerges from traversal]] — traversal-specific divergence risk: repeated path exposure builds navigation confidence that feels like understanding, but the open question is whether this is genuine cognition or illusion of familiarity; implicit knowledge is the precise mechanism by which structural confidence forms without retrieval verification
+- [[provenance tracks where beliefs come from]] — grounding mechanism for closing the confidence-capability gap: if the agent knows a belief is inherited rather than observed, it has structural grounds for reducing confidence rather than relying on subjective certainty
+
+Topics:
+- [[agent-cognition]]

package/methodology/metadata reduces entropy enabling precision over recall.md

@@ -0,0 +1,91 @@
+---
+description: Without metadata agents rely on full-text search which returns many irrelevant matches; YAML frontmatter pre-computes low-entropy representations that shrink the search space before retrieval
+kind: research
+topics: ["[[discovery-retrieval]]"]
+---
+
+# metadata reduces entropy enabling precision over recall
+
+This is the information-theoretic justification for YAML frontmatter, descriptions, and structured metadata in agent-operated knowledge systems. Without metadata, agents must search the full corpus — high recall (find everything that might match) but low precision (most matches are irrelevant). Metadata inverts this tradeoff by pre-computing compressed representations that enable precision-first retrieval.
+
+## The Entropy Reduction Mechanism
+
+In information theory, entropy measures uncertainty. A vault without metadata has high entropy from the agent's perspective: given a query, the agent can't narrow possibilities without reading content. Full-text search returns everything containing keywords, but keywords appear in irrelevant contexts. The agent must load and evaluate each match.
+
+Metadata reduces entropy by pre-computing decision-relevant features:
+- **Descriptions** compress a note's identity into ~150 characters
+- **Type/status fields** partition notes into queryable categories — since [[type field enables structured queries without folder hierarchies]], these fields provide a query axis orthogonal to wiki link topology, enabling "find all synthesis notes about X" without requiring folder trees
+- **Topics links** create explicit membership in conceptual clusters
+
+Each metadata field removes uncertainty. Crucially, since [[faceted classification treats notes as multi-dimensional objects rather than folder contents]], these fields are independent classification dimensions -- Ranganathan's facets. Independence means their entropy reduction composes multiplicatively, not additively. An agent querying "experiments about retrieval" can filter to `type: experiment` before semantic matching — the search space shrinks by an order of magnitude before any content loads. Combining two facets (type + topic) shrinks it by two orders. This multiplicative composition is the formal justification for maintaining multiple metadata fields rather than relying on a single rich description.
+
+## Precision Over Recall as Design Choice
+
+This is a foundational decision, not an experiment. The system prioritizes precision (finding the right thing) over recall (finding all things). This maps to the core philosophy: since [[throughput matters more than accumulation]], false positives waste more tokens than false negatives. Missing a relevant note is recoverable; loading ten irrelevant notes pollutes context.
+
+Full-text search optimizes for recall: "don't miss anything that might be relevant." Metadata enables precision: "only surface things likely to be relevant." The shift happens because LLM context is finite — we can't load everything and let the model sort it out. Since [[LLM attention degrades as context fills]], pre-retrieval filtering is not optional, it's mandatory at scale. Every irrelevant note that loads wastes attention in the smart zone.
+
+## Why This Justifies Frontmatter Ceremony
+
+The system requires YAML frontmatter with descriptions. This ceremony has costs: slower capture, format constraints, additional editing. The information-theoretic argument justifies these costs. But entropy reduction is not the only function these fields serve: since [[module communication through shared YAML fields creates loose coupling without direct dependencies]], the same YAML fields simultaneously function as inter-module communication channels where one module writes a field and another reads it without direct coupling. The entropy reduction is a beneficial side effect of fields designed for inter-module coordination — disciplined field design for the communication contract produces the structured values that also enable precision retrieval. But since [[schema templates reduce cognitive overhead at capture time]], the cost is lower than it appears: pre-defined fields shift decisions from "what metadata should I record" to "fill in these boxes." The schema externalizes the structural decision, reducing the cognitive load of creating metadata in the first place. Schema templates are the capture-side mechanism that ensures entropy-reducing metadata actually gets created:
+
+1. **Frontmatter is pre-computation.** Writing a description once enables unlimited precision queries later. The amortized cost is low.
+
+2. **Metadata is lossy compression optimized for filtering.** Since [[descriptions are retrieval filters not summaries]], description quality determines filter efficiency. Good descriptions lose the right information.
+
+3. **Structured fields partition the space.** Type, status, methodology — each field creates a dimension agents can filter on before loading content. Without them, every query searches the entire corpus.
+
+The alternative — full-text search only — works at small scale. At 50 notes, an agent can read everything. At 500 notes, precision matters. At 5000 notes, precision is survival.
+
+However, entropy reduction through compression raises a tension: since [[sense-making vs storage does compression lose essential nuance]], the same ~150-character constraint that enables precision filtering may strip essential features from complex ideas. Contextual knowledge, procedural nuance, and relationship-dependent meaning may resist compression in ways that cause systematic retrieval failures — the precision we gain comes at the cost of missing notes whose value lies exactly in what the compression discards. And the entropy reduction itself is not uniform across retrieval channels: since [[description quality for humans diverges from description quality for keyword search]], scanning reduces entropy through comprehension while keyword search reduces entropy through term matching. A description that maximally reduces uncertainty for an agent reading it sequentially may leave high entropy for a BM25 engine because the connective prose that creates logical structure for comprehension adds noise for term matching.
+
+There is a deeper tension. Since [[controlled disorder engineers serendipity through semantic rather than topical linking]], Luhmann's information theory insight reveals that entropy is not uniformly bad — different cognitive operations want different entropy levels. Precision retrieval (answering a specific question) wants low entropy: filter aggressively, surface exact matches. Exploratory discovery (finding unexpected connections) wants higher entropy: follow semantic links that cross topical boundaries, encounter surprising neighbors. The resolution is modal: the same vault supports both by switching between focused retrieval (high-decay traversal through metadata filters) and exploratory traversal (low-decay activation through semantic cross-links). Entropy reduction via metadata and productive disorder via semantic linking serve complementary operations, not competing ones.
+
+## Connection to Progressive Disclosure
+
+Since [[progressive disclosure means reading right not reading less]], metadata occupies a specific position in the disclosure hierarchy:
+
+```
+File tree      → ~10 bits per note  (title only)
+Metadata       → ~100 bits per note (frontmatter)
+Outline        → ~500 bits per note (headings)
+Full content   → ~5000+ bits per note
+```
+
+Each layer increases information but costs more tokens. Metadata sits at the critical inflection: enough to filter effectively, cheap enough to scan broadly. An agent can query descriptions across 100 notes for the cost of reading 2 full notes. This is where entropy reduction pays dividends.
+
+## The Index-First Pattern
+
+Metadata as entropy reduction is not just a retrieval optimization -- it is one layer of what since [[markdown plus YAML plus ripgrep implements a queryable graph database without infrastructure]] argues is a complete graph database architecture. YAML fields function as node properties in a graph where wiki links are edges and ripgrep is the query engine. The entropy reduction this note describes is what makes the property-query layer work: each YAML field narrows the search space the way a WHERE clause narrows a database query, but without any database server.
+
+This justifies the pattern: search metadata first, load content second. Not as a heuristic but as information-theoretically sound design.
+
+```
+Query → filter by type/status → semantic match descriptions → load top candidates
+```
+
+Each stage reduces entropy before the next. By the time content loads, uncertainty is low — we've pre-filtered to high-probability matches. This is precision over recall in action: accept missing edge cases in exchange for accurate core results.
+---
+
+Relevant Notes:
+- [[markdown plus YAML plus ripgrep implements a queryable graph database without infrastructure]] — synthesis: positions metadata as the property-query layer of a four-layer graph database architecture where YAML fields function as queryable node properties
+- [[descriptions are retrieval filters not summaries]] — the companion claim: descriptions work as filters because they're lossy compression optimized for decisions
+- [[progressive disclosure means reading right not reading less]] — the philosophy that disclosure layers enable quality through curation, which metadata makes possible
+- [[throughput matters more than accumulation]] — the success metric that justifies precision focus: false positives waste processing capacity
+- [[retrieval utility should drive design over capture completeness]] — the overarching design orientation that metadata precision serves: optimize for finding, not filing
+- [[LLM attention degrades as context fills]] — the cognitive constraint that makes precision mandatory: context is scarce, entropy reduction preserves the smart zone
+- [[spreading activation models how agents should traverse]] — positions metadata at a specific decay level: high-decay traversal stops at descriptions, which this note grounds information-theoretically
+- [[queries evolve during search so agents should checkpoint]] — at checkpoints, agents reassess using the description layer; entropy reduction makes this efficient
+- [[good descriptions layer heuristic then mechanism then implication]] — the structural formula that operationalizes entropy-reducing descriptions: each layer adds decision-relevant information
+- [[distinctiveness scoring treats description quality as measurable]] — validates the entropy reduction principle: pairwise similarity detects when descriptions fail to distinguish
+- [[type field enables structured queries without folder hierarchies]] — develops how type metadata specifically enables structured queries: category-based retrieval without folder hierarchies
+- [[schema templates reduce cognitive overhead at capture time]] — the capture-side mechanism that ensures entropy-reducing metadata gets created: pre-defined fields reduce the cognitive cost of metadata creation
+- [[sense-making vs storage does compression lose essential nuance]] — the shadow side: entropy reduction is lossy compression, and some knowledge types may lose exactly the features that make them valuable in the compression that enables filtering
+- [[faceted classification treats notes as multi-dimensional objects rather than folder contents]] — formal framework: Ranganathan's independent facets explain why combining metadata fields produces multiplicative entropy reduction, not merely additive; two orthogonal facets with 5 values each reduce search space by ~25x
+- [[narrow folksonomy optimizes for single-operator retrieval unlike broad consensus tagging]] — precision amplifier: personal vocabulary achieves higher precision than consensus vocabulary because it reflects one operator's conceptual distinctions rather than averaged understanding; the entropy reduction from metadata is compounded when the vocabulary itself is tuned to the operator's mental model
+- [[controlled disorder engineers serendipity through semantic rather than topical linking]] — productive tension: entropy reduction serves precision retrieval, but Luhmann's information theory shows some entropy is generative for exploratory discovery; the resolution is modal — different operations want different entropy levels
+- [[description quality for humans diverges from description quality for keyword search]] — reveals that the entropy reduction mechanism operates differently across retrieval channels: scanning reduces entropy through comprehension (agent understands what makes a note different), while keyword search reduces entropy through term matching (search engine narrows by co-occurrence); the same metadata text cannot maximally reduce entropy for both
+- [[module communication through shared YAML fields creates loose coupling without direct dependencies]] — dual function: the same YAML fields that reduce retrieval entropy simultaneously serve as the inter-module communication bus; disciplined field design for the communication contract incidentally produces the structured values that enable precision retrieval
+
+Topics:
+- [[discovery-retrieval]]

package/methodology/methodology development should follow the trajectory from documentation to skill to hook as understanding hardens.md

@@ -0,0 +1,80 @@
+---
+description: The three encoding levels -- instruction, skill, hook -- represent increasing guarantee strength, and methodology patterns should migrate upward as the pattern becomes understood well enough to
+kind: research
+topics: ["[[processing-workflows]]", "[[agent-cognition]]"]
+methodology: ["Original"]
+source: [[hooks-as-methodology-encoders-research-source]], [[composable-knowledge-architecture-blueprint]]
+---
+
+# methodology development should follow the trajectory from documentation to skill to hook as understanding hardens
+
+When a knowledge system discovers a new best practice, there is a temptation to encode it immediately at the highest guarantee level. If hooks fire unconditionally and since [[hook enforcement guarantees quality while instruction enforcement merely suggests it]], why not skip straight to hook encoding? Because the level of encoding should match the level of understanding. A pattern that is not yet well-understood will be encoded incorrectly, and incorrect automation is worse than no automation -- it creates confident, systematic errors.
+
+The trajectory has three levels, each with a different guarantee profile. Instruction-encoded methodology lives in context files like CLAUDE.md. It depends on agent attention, which means it works reliably in the first 40% of context (the smart zone) and degrades as context fills. The guarantee is aspirational: the agent should do this if it remembers. Skill-encoded methodology lives in executable workflow files that contain quality gates, phase boundaries, and verification steps. Since [[skills encode methodology so manual execution bypasses quality gates]], the guarantee is reliable: when invoked, the skill enforces the methodology consistently. But the agent must still choose to invoke the skill. Hook-encoded methodology lives in infrastructure that fires on lifecycle events. The guarantee is structural: the check happens on every qualifying event regardless of agent state, attention, or intent.
+
+The progression from instruction to skill to hook maps onto how understanding develops through use. A new best practice starts as a documentation entry because you do not yet know exactly when it applies, what edge cases exist, or whether it is even correct. Documentation is cheap to write and cheap to revise. You might add "always check for duplicates before creating notes" to CLAUDE.md and watch what happens. If the agent follows the instruction inconsistently, that itself is informative -- it reveals which contexts make the instruction hard to follow, which is data about what the skill version needs to handle.
+
+The move from instruction to skill happens when the pattern has been exercised enough to reveal its internal structure. Since [[complex systems evolve from simple working systems]], the skill cannot be designed correctly on the first attempt. It needs the experience of manual or instruction-guided execution to reveal what the quality gates should be, where phase boundaries belong, and which verification steps actually catch errors rather than producing false positives. Since [[incremental formalization happens through repeated touching of old notes]], the same crystallization principle applies to methodology: vague instructions sharpen into precise workflows through accumulated friction encounters. Because [[friction reveals architecture]], the friction of following an instruction inconsistently is not a failure but a signal — it reveals what the skill version needs to handle, making operational discomfort the input to methodology evolution.
+
+The move from skill to hook happens when the pattern has been exercised enough to confirm it is deterministic. Since [[the determinism boundary separates hook methodology from skill methodology]], only operations that produce identical results regardless of input content, context state, or reasoning quality belong in hooks. This is a high bar. You cannot know whether an operation is truly deterministic until you have seen it run many times across varied inputs. A schema validation check might seem deterministic until you encounter a note type where the schema is ambiguous. A naming convention check might seem deterministic until you discover that some titles legitimately break the convention for good reason. The skill phase reveals these edge cases; the hook phase encodes only the cases that have been confirmed.
+
+Since [[hooks are the agent habit system that replaces the missing basal ganglia]], the trajectory mirrors how human expertise develops. A novice follows explicit rules (instruction-encoded). A practitioner applies structured workflows (skill-encoded). An expert has internalized the pattern so deeply that it fires automatically (hook-encoded, or habit-encoded in the human case). The parallel is not perfect -- human expertise also involves judgment that improves with practice, while hooks only handle the deterministic subset -- but the temporal progression from deliberate to automatic is the same. The trajectory's endpoint -- hook-level encoding -- is made reliable by a structural property of agent systems: since [[agent session boundaries create natural automation checkpoints that human-operated systems lack]], hooks fire at discrete boundary events rather than requiring continuous monitoring, which means the investment in promoting methodology to hook-level encoding pays off more reliably than in continuous systems where triggers depend on scheduling infrastructure that someone must remember to maintain.
+
+The trajectory is also a bootstrapping loop. Since [[bootstrapping principle enables self-improving systems]], each level of encoding builds on the previous. Instruction-encoded methodology generates the operational experience needed to design the skill. Skill-encoded methodology generates the execution data needed to confirm which operations are deterministic enough for hooks. Hook-encoded methodology generates the context window savings needed to tackle more complex methodology patterns at the instruction level. The system lifts itself.
+
+Not all methodology can complete the full trajectory. Connection finding, description quality evaluation, and synthesis across domains require semantic judgment that varies with each invocation. These operations should stay at the skill level permanently -- encoding them as hooks would produce rules applied uniformly to tasks that require contextual judgment. The trajectory describes the maturation path for methodology patterns, not a mandate that everything must become a hook. The question for any pattern is: has this been exercised enough that we understand it well enough to encode at the next level? If the answer is no, premature promotion creates brittle automation that is harder to fix than instruction-level methodology that simply gets followed inconsistently. There is also a safety filter: since [[automated detection is always safe because it only reads state while automated remediation risks content corruption]], detection-side methodology patterns can move through the trajectory faster because their failure mode is bounded -- a wrong detection hook produces false alerts, not corrupted content. Remediation-side patterns require more accumulated evidence before each promotion because their errors are self-concealing and compound through the system. And since [[skill context budgets constrain knowledge system complexity on agent platforms]], there is also a capacity constraint on the middle tier: even methodology that is well-understood enough for skill encoding may stay instruction-encoded longer than understanding warrants because the platform's description budget cannot accommodate another skill. The budget forces triage -- which patterns earn their skill slot, and which remain in the context file despite being ready for promotion.
+
+There is a category of knowledge that cannot enter the trajectory at all, not just one that stalls at the skill level. Since [[operational wisdom requires contextual observation]], tacit understanding of how a platform's community talks, what engagement patterns exist, or how a specific person communicates does not harden into encodable methodology — it accumulates as dated observations and builds toward pattern-matched intuition. The trajectory assumes knowledge can be stated as a rule, then encoded as a workflow, then automated as a check. Operational wisdom is not rule-shaped. It is the kind of understanding that improves agent behavior without ever becoming a deterministic procedure, and attempts to encode it prematurely would produce the same confident systematic errors that premature hook encoding creates — except at an earlier stage, because the understanding was never formalizable in the first place.
+
+The trajectory has a spatial counterpart in the vault's architecture. Since [[four abstraction layers separate platform-agnostic from platform-dependent knowledge system features]], the convention layer (instruction-encoded standards) maps to the first trajectory level, and the automation layer (hooks and skills) maps to the second and third. The trajectory describes temporal evolution through these layers -- a methodology pattern moves from convention to automation as understanding hardens. This is why since [[knowledge system architecture is parameterized by platform capabilities not fixed by methodology]], initial parameterization should favor instruction-level encoding even on platforms capable of full automation. The trajectory determines the starting point; the platform determines the ceiling. And since [[platform capability tiers determine which knowledge system features can be implemented]], the ceiling itself varies: tier-one platforms can complete the full trajectory from instruction to skill to hook, tier-two platforms can reach skill-level but lack the hook infrastructure for the final promotion, and tier-three platforms are permanently instruction-bound. The trajectory is universal but the reachable endpoint is tier-dependent. And since [[self-extension requires context files to contain platform operations knowledge not just methodology]], the context file must teach construction competencies layered by encoding level -- instruction writing, skill creation, and hook configuration are distinct competencies that the trajectory sequences.
+
+Since [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]], the trajectory becomes concrete at the module level. In a composable system, modules fall into four categories -- foundation, convention, automation, orchestration -- and each category has a characteristic shipping format that maps directly onto the trajectory. Foundation modules (yaml-schema, wiki-links, atomic-notes) ship as files and naming guides because they are just conventions that any file-reading agent can follow -- pure documentation-level encoding. Convention modules (MOCs, inbox-pipeline, agent-memory) ship as methodology instructions that require a context file but no platform infrastructure -- still instruction-encoded, one step above raw files. Automation modules (validation, processing-pipeline, hooks) ship as blueprints that teach the agent to build platform-specific implementations -- skill-level encoding where the blueprint replaces manual construction. Orchestration modules (health-checks, agent-definition, context-file generation) require the most advanced platform features and ship as generated configurations -- the hook level, where the system itself produces the artifacts. The shipping format gradient IS the trajectory applied to module delivery: each layer encodes at a level that matches how well the pattern is understood in that domain.
+
+This module-level application names a specific failure mode. Since [[premature complexity is the most common derivation failure mode]], the "premature orchestration" variant occurs when automation modules are added before the manual process is understood -- the processing pipeline produces false positives, validation rules catch non-issues, and the system generates confident errors because the pattern was encoded before its edge cases surfaced. The fix is to start with convention-layer encoding and promote to automation only after five or more manual executions confirm the pattern, which is why [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]] -- the five-repetition threshold operationalizes the trajectory's patience at the module level. Start with zero modules (just markdown files), add one at a time, and let each addition demonstrate its value before reaching for the next level of encoding. The composable architecture calls this "Graceful Addition" and grounds it in Gall's Law -- which is the same theoretical warrant the trajectory already draws from, now applied to the specific question of when and how modules should mature.
+
+The patience principle has a mechanism: since [[hook-driven learning loops create self-improving methodology through observation accumulation]], it is observations accumulated at each trajectory level that generate the understanding needed for promotion to the next. Instruction-level methodology generates friction observations. Skill-level methodology generates execution data. The learning loop converts operational experience into evidence for or against promotion. Without this evidence pipeline, the trajectory would be an abstract principle rather than a grounded practice.
+
+The trajectory also operates within levels, not just between them. Since [[nudge theory explains graduated hook enforcement as choice architecture for agents]], even after methodology reaches the hook level, enforcement strength should start at nudge and migrate toward block as evidence accumulates. This is the same patience principle applied at finer grain: a new hook warns before it blocks, because the understanding of which violations are structural versus qualitative hardens through the same observational process.
+
+This patience matters because since [[over-automation corrupts quality when hooks encode judgment rather than verification]], premature trajectory completion IS the mechanism that produces over-automation. Jumping from instruction to hook without the intermediate skill phase -- where edge cases surface, where the deterministic subset becomes visible, where false positives get identified -- creates the kind of confident, systematic errors that corrupt the knowledge graph while metrics look healthy. And since [[hooks cannot replace genuine cognitive engagement yet more automation is always tempting]], each successful promotion creates pressure for the next one, making the trajectory's requirement that understanding must harden first a structural safeguard against the gravitational pull of automation.
+
+The trajectory also maps onto a larger lifecycle. Since [[derived systems follow a seed-evolve-reseed lifecycle]], the encoding trajectory is a lifecycle within the evolution phase — methodology patterns seed as documentation in the context file, evolve through friction encounters into skills, and harden into hooks when understanding is sufficient. But when accumulated encoding decisions produce systemic incoherence (hooks that conflict with each other, skills that encode outdated understanding, documentation that no longer matches practice), the system needs reseeding at the methodology level: re-evaluating which patterns belong at which encoding level given everything learned through use. The trajectory's patience principle operates within a single evolution cycle; reseeding resets the trajectory for a new cycle with enriched understanding.
+
+The practical implication is patience. When a new best practice is discovered, document it. When documentation proves insufficient (the agent skips it under load), encode it as a skill. When the skill has been exercised enough to confirm its deterministic subset, extract that subset into a hook. This patience is not slowness -- it is the recognition that each encoding level requires understanding that only the previous level can generate.
+
+---
+---
+
+Relevant Notes:
+- [[skills encode methodology so manual execution bypasses quality gates]] -- covers the skill-vs-manual binary; this note extends to the full three-level spectrum and adds the temporal progression dimension
+- [[the determinism boundary separates hook methodology from skill methodology]] -- defines WHERE the boundary falls between hook and skill encoding; this note adds WHEN methodology should cross that boundary
+- [[hooks are the agent habit system that replaces the missing basal ganglia]] -- provides the cognitive science foundation: hooks replace habit formation, which means the trajectory mirrors expertise development where deliberate practice becomes automatic
+- [[hook enforcement guarantees quality while instruction enforcement merely suggests it]] -- grounds the guarantee gradient: instructions degrade under load, skills require invocation, hooks fire unconditionally
+- [[complex systems evolve from simple working systems]] -- Gall's Law provides the theoretical warrant: methodology should not jump to hooks prematurely because premature encoding creates brittle automation
+- [[bootstrapping principle enables self-improving systems]] -- the trajectory IS bootstrapping applied to methodology: each level of understanding enables encoding at the next level of guarantee
+- [[incremental formalization happens through repeated touching of old notes]] -- the same crystallization pattern applied to infrastructure rather than content: methodology patterns sharpen through use before being encoded
+- [[four abstraction layers separate platform-agnostic from platform-dependent knowledge system features]] -- the spatial architecture that the trajectory moves through temporally: convention layer maps to instruction-encoded, automation layer maps to skill and hook-encoded, and the trajectory describes evolution upward through these layers
+- [[knowledge system architecture is parameterized by platform capabilities not fixed by methodology]] -- applies the trajectory to system generation: initial parameterization should favor instruction-level encoding and evolve upward, making the trajectory the temporal axis of parameterized design
+- [[hook-driven learning loops create self-improving methodology through observation accumulation]] -- the learning loop generates the understanding that enables each trajectory step: observations accumulate until patterns emerge, providing the data that justifies promotion from instruction to skill or skill to hook
+- [[nudge theory explains graduated hook enforcement as choice architecture for agents]] -- extends the trajectory within the hook level itself: enforcement strength should start at nudge and migrate toward block as evidence accumulates, applying the same patience principle at a finer grain
+- [[over-automation corrupts quality when hooks encode judgment rather than verification]] -- the failure mode when the trajectory is rushed: premature promotion to hook encoding IS the mechanism that produces over-automation, making patience a quality safeguard not just a development preference
+- [[hooks cannot replace genuine cognitive engagement yet more automation is always tempting]] -- the living tension the trajectory's patience principle resists: each encoding level generates pressure to promote further, and the requirement that understanding must harden first is what prevents erosion of the agent's cognitive role
+- [[self-extension requires context files to contain platform operations knowledge not just methodology]] -- the context file must teach construction competencies layered by encoding level: instruction writing, skill creation, and hook configuration are distinct competencies that the trajectory sequences
+- [[platform capability tiers determine which knowledge system features can be implemented]] -- sets the ceiling for how far the trajectory can reach: tier-one platforms complete the full path, tier-two reach skills but not hooks, tier-three are permanently instruction-bound
+- [[context files function as agent operating systems through self-referential self-extension]] — the self-extension framing: the trajectory IS how self-extension unfolds temporally; each encoding level represents self-extension at a different guarantee strength, with the context file as both the starting point (instruction-encoded methodology) and the substrate that teaches how to migrate upward
+- [[configuration dimensions interact so choices in one create pressure on others]] — the trajectory is an automation-level progression with internal structure: different encoding levels create different pressure profiles on schema density and processing intensity, making the trajectory itself subject to dimension interaction constraints
+- [[evolution observations provide actionable signals for system adaptation]] — concrete trajectory candidates: the six diagnostics partition naturally along the determinism boundary, with count-based diagnostics (unused types, N/A field rates, manual addition percentages) as hook-promotable and judgment-requiring diagnostics (navigation failure, processing mismatch) as permanently skill-level
+- [[derived systems follow a seed-evolve-reseed lifecycle]] — the trajectory is a lifecycle within the evolution phase: methodology patterns seed as documentation, evolve into skills, harden into hooks, but accumulated encoding decisions can produce systemic incoherence requiring methodology-level reseeding
+- [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]] — the composable architecture instantiates the trajectory at the module level: foundation modules ship as files (documentation-level), convention modules as instructions, automation modules as blueprints (skill-level), and orchestration modules as generated configs (hook-level); the shipping format gradient IS the trajectory applied to module delivery
+- [[premature complexity is the most common derivation failure mode]] — premature orchestration is the module-level variant: adding automation modules before the manual process is understood produces the same confident systematic errors that premature hook encoding creates; the complexity budget constrains the trajectory's endpoint at derivation time
+- [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]] — operationalizes the trajectory's patience principle at the module level: the five-repetition threshold requires demonstrated friction before module promotion, just as the trajectory requires hardened understanding before encoding-level promotion
+- [[skill context budgets constrain knowledge system complexity on agent platforms]] — capacity constraint on the middle tier: even well-understood methodology may stay instruction-encoded because the platform's description budget cannot accommodate another skill, forcing triage of which patterns earn their skill slot
+- [[automated detection is always safe because it only reads state while automated remediation risks content corruption]] — provides a safety filter for trajectory progression: detection operations can move faster through the trajectory because read-only operations have bounded failure modes at every encoding level, while remediation operations require more accumulated evidence before promotion because write errors are self-concealing and harder to recover from
+- [[idempotent maintenance operations are safe to automate because running them twice produces the same result as running them once]] — adds a second prerequisite for the hook-promotion step: beyond confirming determinism, the operation must also be idempotent or guarded before it can safely fire as a hook, because hooks fire on events that inevitably repeat
+- [[agent session boundaries create natural automation checkpoints that human-operated systems lack]] — structural foundation for the trajectory's endpoint: hook-level encoding pays off reliably because discrete session boundaries guarantee hooks fire at every qualifying event without depending on scheduling infrastructure or operator memory
+- [[friction reveals architecture]] — the input signal that drives trajectory progression: friction of following instructions inconsistently reveals what the skill version needs to handle, and friction of invoking skills reveals which deterministic subsets are ready for hook encoding
+- [[operational wisdom requires contextual observation]] — pre-trajectory boundary: some knowledge cannot enter the trajectory at all because it is not rule-shaped; tacit contextual understanding accumulates as observations and builds pattern-matched intuition rather than hardening into encodable methodology
+
+Topics:
+- [[processing-workflows]]
+- [[agent-cognition]]

package/methodology/methodology traditions are named points in a shared configuration space not competing paradigms.md

@@ -0,0 +1,64 @@
+---
+description: Zettelkasten, PARA, Cornell, Evergreen, and GTD each make different choices along the same dimensions (granularity, linking, processing intensity, maintenance cadence) — mapping them as
+kind: research
+topics: ["[[design-dimensions]]"]
+methodology: ["PKM Research", "Zettelkasten", "Cornell", "Evergreen", "GTD"]
+source: [[knowledge-system-derivation-blueprint]]
+---
+
+# methodology traditions are named points in a shared configuration space not competing paradigms
+
+The PKM landscape presents methodology traditions as competing approaches. Zettelkasten advocates argue for atomic notes and bidirectional linking. PARA proponents insist on four-folder hierarchical organization. Cornell Note-Taking prescribes structured processing phases. The community debates which is "best" as though choosing a methodology means accepting it whole. But this framing is wrong — these traditions are not competing paradigms but named configurations in a shared space, each making different but internally consistent choices along the same underlying dimensions.
+
+Since [[eight configuration dimensions parameterize the space of possible knowledge systems]], mapping the five major traditions onto their configuration choices makes the pattern visible:
+
+| Tradition | Granularity | Organization | Linking | Processing | Navigation | Maintenance |
+|-----------|-------------|-------------|---------|------------|------------|-------------|
+| Zettelkasten | Atomic | Flat | Explicit, bidirectional | Heavy formulation + linking | Emergent hubs | Continuous |
+| PARA | Coarse | Hierarchical (4 folders) | Minimal (folder membership) | Light (progressive summarization) | Folder browsing | Weekly review |
+| Cornell | Medium (per session) | Temporal | Implicit (cue columns) | Structured (5 Rs) | Index-based | Spaced review |
+| Evergreen | Atomic | Flat | Explicit, contextual | Continuous rewriting | Link browsing | Continuous |
+| GTD | Task-sized | Hierarchical (contexts) | Minimal | Light (capture + route) | Context lists | Daily/weekly review |
+
+Each row is a point in configuration space. No row dominates the others because each optimizes for different purposes. And since [[scaffolding enables divergence that fine-tuning cannot]], choosing a tradition's configuration point is simultaneously choosing what kind of agent the system produces — agents operating under Zettelkasten-style scaffolding develop different retrieval intuitions, different connection patterns, and different synthesis capabilities than agents under PARA-style scaffolding, even when running identical base weights. Zettelkasten maximizes connection density at the cost of heavy processing. PARA maximizes project organization at the cost of cross-domain synthesis. Cornell balances processing structure with temporal capture. These are trade-off choices, not quality rankings.
+
+The configuration view dissolves several persistent confusions. The Zettelkasten-vs-PARA debate, for instance, is not about which methodology is superior but about which dimension values serve a given use case. Since [[storage versus thinking distinction determines which tool patterns apply]], the upstream classification determines which configurations are even viable — PARA's hierarchical filing optimizes for storage while Zettelkasten's associative linking optimizes for thinking. Debating them as competitors is like debating whether a hammer or a saw is the better tool without asking what you are building.
+
+The deeper consequence is that derived systems can mix choices across traditions. Because [[derivation generates knowledge systems from composable research claims not template customization]], a researcher might combine Zettelkasten atomicity (one claim per note), Cornell processing phases (the 5 Rs adapted for agents), and PARA project folders (for active deliverables) — each choice justified independently by the research claims that inform that dimension. Since [[knowledge system architecture is parameterized by platform capabilities not fixed by methodology]], the platform adds a second layer of parameterization on top of the methodology choices. The derivation engine considers both: which tradition's dimension values serve this use case, and which of those values the target platform can support.
+
+This mixing is not eclecticism — it is principled composition. Since [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]], each tradition decomposes into a set of independently toggleable modules — Zettelkasten activates atomic-notes, explicit-linking, and deep-navigation modules while PARA activates hierarchical-folders with lightweight-processing — so mixing across traditions means enabling specific modules from each tradition's set, with the dependency resolver ensuring that cross-tradition combinations satisfy their requirements. Each choice along each dimension can be justified independently by the research claims that inform that dimension. Choosing Zettelkasten-level granularity is justified by the composability research. Choosing Cornell-style processing phases is justified by the generation effect and elaborative encoding research. Choosing PARA-style project folders for a specific component is justified by the storage-system analysis. The justifications are independent because the dimensions themselves are partially independent, though since [[configuration dimensions interact so choices in one create pressure on others]], the derivation engine must also check for incompatible combinations.
+
+The configuration view shares a deep structural parallel with [[faceted classification treats notes as multi-dimensional objects rather than folder contents]] — just as Ranganathan showed that documents have independent classification axes rather than single folder assignments, methodologies have independent configuration dimensions rather than single paradigm labels. Both insights argue against mono-classification: one document, one folder is as impoverishing as one methodology, one tradition.
+
+The Zettelkasten and Evergreen traditions appear similar in the table (both atomic, flat, explicit-linking) but diverge on processing philosophy: Zettelkasten emphasizes careful formulation at creation time, while Evergreen emphasizes continuous rewriting over time. This reveals that even traditions occupying similar regions of configuration space can differ on dimensions that the coarse mapping does not fully capture. The processing dimension itself has sub-dimensions — when processing happens (at capture vs. over time), how much transformation is required, whether the goal is stable formulation or living evolution. And because [[every knowledge domain shares a four-phase processing skeleton that diverges only in the process step]], traditions share more than dimension values — they share the same pipeline shape. Zettelkasten's formulation, PARA's progressive summarization, Cornell's structured cue generation, and GTD's task routing are all different implementations of the same structural position in a universal capture-process-connect-verify skeleton. The configuration space parameterizes the process step's depth and character, but the skeleton itself is invariant across traditions.
+
+Since [[three capture schools converge through agent-mediated synthesis]], the configuration view extends to capture philosophy too. The Accumulationist, Interpretationist, and Temporal schools are really different configurations of the capture-processing dimension: when does transformation happen, how much friction is acceptable, what role does time play in organization? Agent mediation dissolves their apparent incompatibility by distributing the configuration across actors — human captures with Accumulationist values, agent processes with Interpretationist values. The same dissolution applies at the methodology level: an agent-operated system can implement Zettelkasten synthesis depth with PARA organizational efficiency because the agent handles the processing that makes heavy synthesis viable even when capture is fast.
+
+Since [[associative ontologies beat hierarchical taxonomies because heterarchy adapts while hierarchy brittles]], the organization dimension is not neutral — the research favors flat-associative for thinking systems. But the configuration view insists this is a recommendation, not a law. Storage-oriented use cases genuinely benefit from hierarchical organization. The dimension has poles, the research informs which pole to choose, but the choice depends on purpose. And since [[enforcing atomicity can create paralysis when ideas resist decomposition]], even strong research findings about a dimension pole need qualification — pure atomicity serves composability but can fracture ideas that need compound expression, which is why granularity is a spectrum with a recommended region rather than a single correct value.
+
+The configuration view transforms how we think about methodology evolution too. Since [[derived systems follow a seed-evolve-reseed lifecycle]], when a community develops "modified Zettelkasten" or "PARA 2.0," what they are really doing is evolving specific dimension values while preserving others — the tradition serves as the seed, community practice is the evolution phase, and a major revision like "2.0" is a reseeding event. This makes evolution legible: you can describe exactly which dimensions changed and why. And when someone invents a genuinely novel approach, it registers as a new point in configuration space rather than a competing paradigm — interesting because of where it sits relative to existing traditions, not because it claims to replace them. This framing extends to entirely novel domains too: since [[novel domains derive by mapping knowledge type to closest reference domain then adapting]], traditions and reference domains serve the same function as pre-validated coherence points that seed new configurations rather than templates to copy wholesale.
+
+---
+
+Source: [[knowledge-system-derivation-blueprint]]
+---
+
+Relevant Notes:
+- [[storage versus thinking distinction determines which tool patterns apply]] — the upstream classification before configuration: storage vs thinking determines which dimension values are even valid, so methodology-as-configuration operates within the space that the storage/thinking decision opens
+- [[knowledge system architecture is parameterized by platform capabilities not fixed by methodology]] — extends this from platform-level to methodology-level parameterization: platform determines what can operate, methodology tradition determines what to aim for, both are parameterization at different scales
+- [[associative ontologies beat hierarchical taxonomies because heterarchy adapts while hierarchy brittles]] — illustrates a specific configuration choice: Zettelkasten and Evergreen choose flat-associative while PARA and GTD choose hierarchical, and the research suggests when each pole wins
+- [[three capture schools converge through agent-mediated synthesis]] — agent mediation dissolves capture-school divergence the same way configuration thinking dissolves methodology divergence: both reveal that apparent conflicts are trade-off choices along shared dimensions
+- [[enforcing atomicity can create paralysis when ideas resist decomposition]] — maps a specific failure mode to a dimension pole: pure atomic granularity from Zettelkasten tradition can fail when ideas need compound expression, which is why granularity is a spectrum not a binary
+- [[configuration dimensions interact so choices in one create pressure on others]] — explains WHY traditions cohere where they do: each tradition resolved dimension coupling through practice, and the interaction constraints explain why mixing must be principled not arbitrary
+- [[eight configuration dimensions parameterize the space of possible knowledge systems]] — concretizes the configuration space this note claims traditions are points within: granularity, organization, linking, processing intensity, navigation depth, maintenance cadence, schema density, automation level
+- [[derivation generates knowledge systems from composable research claims not template customization]] — the operational consequence of the configuration view: if traditions are points in a shared space, then derivation can compose new points by traversing research claims rather than copying existing traditions
+- [[faceted classification treats notes as multi-dimensional objects rather than folder contents]] — structural parallel: Ranganathan's insight that documents have independent classification axes mirrors the claim that methodologies have independent configuration dimensions; both argue against mono-classification
+- [[every knowledge domain shares a four-phase processing skeleton that diverges only in the process step]] — deeper invariant: traditions share not just dimension values but the same pipeline shape; each tradition's process step (Zettelkasten formulation, PARA summarization, Cornell cue generation, GTD routing) is a different implementation of the same structural position in a universal skeleton
+- [[novel domains derive by mapping knowledge type to closest reference domain then adapting]] — extends the configuration-point framing to novel derivation: reference domains function like traditions as pre-validated coherence points, and novel domain derivation starts from a tradition-like seed rather than raw dimensions
+- [[derived systems follow a seed-evolve-reseed lifecycle]] — methodology evolution IS the lifecycle: traditions seed as coherent configurations, communities evolve them through practice, and major revisions (PARA 2.0, modified Zettelkasten) are reseeding events where the configuration is restructured
+- [[configuration paralysis emerges when derivation surfaces too many decisions]] — traditions reduce the configuration surface beyond dimension inference: instead of navigating raw dimensions, defaults can derive from tradition-tested coherence points that have already resolved coupling constraints through practice
+- [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]] — makes mixing concrete: traditions decompose into module selections, so Zettelkasten activates atomic-notes, explicit-linking, and deep-navigation modules while PARA activates hierarchical-folders with lightweight-processing, and composable architecture enables mixing across traditions by treating each as a named set of independently toggleable modules
+- [[scaffolding enables divergence that fine-tuning cannot]] — agent-level consequence of configurations-as-traditions: choosing a tradition's configuration point simultaneously determines what kind of agent the system produces, because different dimension settings create genuinely different cognitive architectures, not just different workflows
+
+Topics:
+- [[design-dimensions]]

package/methodology/mnemonic medium embeds verification into navigation.md

@@ -0,0 +1,46 @@
+---
+description: Notes could include self-test prompts encountered during traversal so verification becomes ambient rather than a scheduled maintenance phase
+kind: research
+topics: ["[[maintenance-patterns]]"]
+methodology: ["Evergreen"]
+source: [[tft-research-part1]]
+---
+
+# mnemonic medium embeds verification into navigation
+
+Andy Matuschak's mnemonic medium embeds spaced repetition prompts directly into content. As readers navigate through material, they encounter verification questions that test comprehension. The prompts are part of the narrative flow, not a separate review system layered on afterward.
+
+The insight for agent-operated vaults: verification could happen during traversal rather than as a distinct maintenance phase. When an agent navigates from note A to note B, it encounters a verification prompt. If the agent fails the prompt, the note gets flagged for attention. This makes verification ambient rather than scheduled. The cognitive science case for ambient verification is strengthened by the finding that [[vivid memories need verification]] — if even subjectively vivid, high-confidence memories drift from reality without external checking, then any system that defers verification to scheduled maintenance windows risks accumulating confident-but-wrong content between checks.
+
+The existing vault approach separates verification into discrete phases. Since [[testing effect could enable agent knowledge verification]], the recite skill runs prediction-then-verify cycles as a quality gate. Since [[retrieval verification loop tests description quality at scale]], this extends to systematic vault-wide assessment. But both treat verification as something done TO the vault, not something that happens WHILE using the vault.
+
+The mnemonic medium inverts this. Verification happens as a side effect of navigation. Every traversal is a verification opportunity. This has several implications:
+
+First, it distributes verification across usage rather than concentrating it in maintenance sessions. Since [[LLM attention degrades as context fills]], dedicated verification sessions may run on degraded attention. Ambient verification during normal traversal would happen while the agent's context is still fresh, focused on whatever task motivated the navigation.
+
+Second, it creates natural prioritization. Notes that get traversed frequently face more verification. Notes that never surface never get checked, but they also never mislead anyone. The verification effort automatically follows retrieval demand, which aligns with the principle that [[processing effort should follow retrieval demand]].
+
+Third, it reveals which notes fail in context. A note might pass isolated verification (description predicts content) but fail contextual verification (the transition from the linking note doesn't prepare you for what you find). Ambient verification tests notes in their actual usage patterns. Since [[backlinks implicitly define notes by revealing usage context]], the backlinks provide a map of these usage patterns — each incoming link represents a context where the note is expected to deliver certain value, making backlinks themselves a verification resource.
+
+The implementation question: what form would embedded verification take? The mnemonic medium uses explicit prompts ("What is X?"). For agent vaults, the prompts could be implicit in link context. A link like `since [[claim X]]` creates an expectation. If the linked note doesn't actually support that "since" relationship, the agent notices the mismatch during traversal. The link context becomes the verification prompt.
+
+This transforms wiki links from just navigation into navigation-with-verification. Every contextual link (`extends [[X]]`, `contradicts [[Y]]`, `because [[Z]]`) creates a testable expectation. The agent traversing that link can verify whether the relationship holds. No separate verification phase needed. And since [[implicit knowledge emerges from traversal]], the same traversal that verifies also trains — repeated verification encounters build intuitive familiarity with which relationships hold and which paths lead to genuine understanding. Ambient verification and implicit learning are two side effects of the same traversal act, making navigation a dual-purpose cognitive substrate.
+
+The risk is overhead. If every traversal triggers verification, navigation slows. But the verification could be probabilistic rather than universal. Sample traversals for verification. Or verify only when the agent is explicitly learning rather than executing a known workflow.
+
+Since [[spreading activation models how agents should traverse]], the traversal mechanism already loads context proportional to connection strength. Embedding verification into that mechanism means the same spreading activation that brings relevant content into context ALSO tests whether the relationships hold. Link types annotated in prose (`since [[X]]`, `extends [[Y]]`, `contradicts [[Z]]`) become verification prompts that spreading activation naturally encounters. The activation isn't just loading content — it's testing expectations against reality as it spreads.
+---
+
+Relevant Notes:
+- [[testing effect could enable agent knowledge verification]] — the foundation this extends: testing effect reveals quality through prediction-then-verify; mnemonic medium embeds this into the reading/traversal itself
+- [[retrieval verification loop tests description quality at scale]] — systematic verification as separate phase; mnemonic medium offers an alternative where verification is ambient during use
+- [[backlinks implicitly define notes by revealing usage context]] — provides additional traversal context: when landing on a note, backlinks reveal where the concept has been used, complementing content verification with usage verification
+- [[processing effort should follow retrieval demand]] — ambient verification naturally follows demand because frequently-traversed notes face more checks
+- [[LLM attention degrades as context fills]] — cognitive grounding for why distributed verification during traversal might outperform concentrated verification sessions
+- [[spaced repetition scheduling could optimize vault maintenance]] — sibling approach to verification timing: scheduling optimizes WHEN separate verification happens, mnemonic medium asks WHETHER verification needs to be separate at all
+- [[spreading activation models how agents should traverse]] — the traversal mechanism this embeds verification into: link context phrases become verification prompts that activation naturally encounters while loading content
+- [[vivid memories need verification]] — cognitive science motivation: flashbulb memories demonstrate that even high-confidence recall drifts without external checking, strengthening the case for ambient verification woven into traversal rather than deferred to scheduled maintenance
+- [[implicit knowledge emerges from traversal]] — the learning complement to ambient verification: traversal produces both implicit knowledge (learning side effect) and verification opportunities (testing side effect), making navigation a dual-purpose cognitive substrate
+
+Topics:
+- [[maintenance-patterns]]

package/methodology/module communication through shared YAML fields creates loose coupling without direct dependencies.md

@@ -0,0 +1,44 @@
+---
+description: YAML frontmatter functions as an event bus where one module writes a field and another reads it, so modules never call each other — the file format IS the communication protocol
+kind: research
+topics: ["[[design-dimensions]]"]
+methodology: ["Original", "Systems Theory"]
+source: [[composable-knowledge-architecture-blueprint]]
+---
+
+# module communication through shared YAML fields creates loose coupling without direct dependencies
+
+Knowledge system modules need to coordinate, but direct dependencies between modules create the tight coupling that composability is supposed to prevent. If a processing-pipeline module calls a validation module directly, changing the validation interface breaks the pipeline. If an MOC-management module is hardcoded to fire after reflection, removing reflection breaks MOC updates. The question is how modules communicate without knowing about each other.
+
+The answer is shared file conventions. One module writes a YAML field, another reads it, and neither knows the other exists. The processing-pipeline writes `topics: ["[[graph-structure]]"]` in a note's frontmatter. The MOC module reads that field to determine which navigation structure should include the note. The validation module reads the same field to verify topic references resolve to existing MOCs. The semantic-search module reads it to weight topic membership in retrieval scoring. Four modules, one field, zero direct dependencies between them. The file format IS the communication protocol.
+
+This is the knowledge system equivalent of the event bus pattern in software architecture — and more precisely, since [[stigmergy coordinates agents through environmental traces without direct communication]], it is stigmergy applied to module coordination. Modules publish state changes to a shared medium (YAML frontmatter in markdown files) and other modules subscribe by reading that medium. The advantage is extreme loose coupling — since [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]], adding or removing a module doesn't break the others because no module has a reference to any other module. The processing-pipeline doesn't fail if validation is disabled. The MOC module doesn't fail if semantic-search isn't running. Each module reads what it needs and ignores the rest.
+
+The schema becomes the contract layer. Since [[schema enforcement via validation agents enables soft consistency]], the template's `_schema` block specifies which fields exist, what values are valid, and implicitly which modules are responsible for writing versus reading each field. This is Design by Contract applied to knowledge files: the note template defines preconditions (required fields), postconditions (what processing produces), and invariants (constraints that must hold throughout the note's lifecycle). When the `_schema` says `topics` is required and must be an array of wiki links, that's simultaneously documentation for humans, enforcement for validation, and a contract between the module that writes topics and every module that reads them. And since [[progressive schema validates only what active modules require not the full system schema]], the contract is scoped to the active module set — fields belonging to inactive modules are not enforced, which means the communication bus itself adapts to module activation state.
+
+The reframing matters because it changes how you design YAML fields. If you think of `topics` as metadata about a note, you design it for the note — whatever format feels natural, whatever values seem descriptive. If you think of `topics` as a message from the processing module to the MOC module to the validation module to the search module, you design it for the communication contract — format must be parseable by consumers, values must be meaningful across module boundaries, changes must respect backward compatibility. The same field, designed from two different perspectives, produces different results. The inter-module lens produces more disciplined, more stable field definitions because every field change is understood as an interface change that affects all readers.
+
+This connects to how [[metadata reduces entropy enabling precision over recall]], but from a different angle. That note establishes YAML frontmatter as pre-computed low-entropy representations that shrink the search space. This note shows those same fields simultaneously serve as the communication bus between system modules. The entropy reduction is a beneficial property of fields designed primarily for inter-module coordination -- when the processing module writes a well-typed `methodology` field for the benefit of downstream consumers, it incidentally creates a queryable facet that reduces retrieval entropy. The dual function is not coincidental: both uses require the same discipline (structured values, consistent formats, defined vocabularies), so designing for one achieves the other. There is actually a third function: since [[markdown plus YAML plus ripgrep implements a queryable graph database without infrastructure]], the same YAML fields that serve as inter-module communication AND entropy reduction also function as queryable node properties in a graph database where wiki links are edges and ripgrep is the query engine. The triple-duty nature of YAML fields -- communication bus, entropy reducer, and graph database properties -- is why their design discipline matters so much: each field must satisfy three different consumers simultaneously.
+
+There is a shadow side. Event bus architectures share well-documented failure modes. Modules can't rely on write ordering — if two modules modify the same field, the last writer wins and the first writer's intent is lost. Conflicting writes must be resolved by convention (field ownership), not by the architecture itself. And since [[hook composition creates emergent methodology from independent single-concern components]], the emergent behavior that arises from multiple modules reading and writing shared fields can be as opaque as hook composition: when the MOC module produces unexpected results, diagnosing whether the problem is in the field the processing module wrote, the field the reflect module modified, or the field the validation module flagged requires understanding the full communication graph. The loose coupling that makes composition easy makes debugging hard, because the information flows through shared state rather than explicit function calls. The same tradeoff appears in microservices: event-driven architectures compose freely but produce distributed behavior that no single service's code explains. And the communication mechanism that makes composition elegant makes decomposition messy — since [[module deactivation must account for structural artifacts that survive the toggle]], disabling a module leaves orphaned field values in the shared YAML surface that no module reads anymore but that persist in every note touched during the module's active period. The most dangerous variant is that since [[implicit dependencies create distributed monoliths that fail silently across configurations]], the event bus itself becomes a vector for undeclared coupling — a module that reads a field another module writes is supposed to handle the field's absence gracefully, but developers who test with both modules active never encounter the absence, so the implicit dependency forms through testing context rather than design intent.
+
+Because [[the no wrong patches guarantee ensures any valid module combination produces a valid system]], this loose coupling is safe — no module can corrupt data through unexpected field interactions when each operates independently on a common surface. But the guarantee covers structural validity, not semantic coherence, which means the practical consequence for knowledge system design is a field ownership discipline. Each YAML field should have exactly one primary writer and potentially many readers. The `description` field is written by the note creator and read by search, validation, retrieval, and progressive disclosure. The `topics` field is written by the processing pipeline (or manually) and read by MOC management, validation, and navigation. When a field has multiple writers — say, both manual editing and automated enrichment can modify `relevant_notes` — the architecture needs conflict resolution conventions, not just schema definitions. This is the knowledge system equivalent of the event sourcing pattern: rather than overwriting state, append contributions and let a reconciliation pass produce the final value.
+
+---
+---
+
+Relevant Notes:
+- [[markdown plus YAML plus ripgrep implements a queryable graph database without infrastructure]] — triple duty: the same YAML fields that carry inter-module signals and reduce retrieval entropy also function as queryable node properties in the graph database; field design discipline must satisfy all three consumers
+- [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]] — parent architecture: loose coupling through shared fields is the mechanism that makes independent toggleable modules compose without knowing about each other
+- [[metadata reduces entropy enabling precision over recall]] — reframes the same YAML fields from an information-theoretic lens: metadata reduces retrieval entropy, while this note shows those same fields also carry inter-module signals
+- [[hook composition creates emergent methodology from independent single-concern components]] — structural parallel at the automation layer: hooks compose through shared file events just as modules compose through shared YAML fields, both achieving emergent behavior from independent components that never call each other
+- [[schema enforcement via validation agents enables soft consistency]] — the enforcement side of the contract: validation reads the same fields that other modules write, making schema checking itself a module that participates in the shared-field communication pattern
+- [[inline links carry richer relationship data than metadata fields]] — complementary scope: YAML fields carry structured inter-module signals (type, status, topics), while inline links carry semantic relationship data that resists field encoding; both are communication channels operating at different abstraction levels
+- [[stigmergy coordinates agents through environmental traces without direct communication]] — theoretical foundation: the shared-YAML event bus is stigmergy applied to module coordination; modules leave traces (YAML field writes) that other modules respond to without direct communication, making the file the coordination medium just as the nest is the coordination medium for termites
+- [[the no wrong patches guarantee ensures any valid module combination produces a valid system]] — safety consequence: the guarantee depends on shared-state communication because modules cannot create destructive interactions through unexpected calling sequences when there are no calling sequences, only reads and writes to a common surface
+- [[progressive schema validates only what active modules require not the full system schema]] — downstream consumer: progressive schema determines which shared fields get validated based on which modules are active, scoping the communication contract to match the module activation state
+- [[implicit dependencies create distributed monoliths that fail silently across configurations]] — the shadow side's worst case: undeclared field reads through the shared-YAML event bus form the primary vector for implicit dependencies; a module tested with both writer and reader active never encounters field absence, so the dependency forms through testing context rather than design intent
+- [[module deactivation must account for structural artifacts that survive the toggle]] — the decomposition cost of loose coupling: because modules coordinate through shared YAML rather than direct calls, deactivation leaves orphaned field values that no module consumes but that persist in every note touched while the module was active
+
+Topics:
+- [[design-dimensions]]

package/methodology/module deactivation must account for structural artifacts that survive the toggle.md

@@ -0,0 +1,49 @@
+---
+description: Enabling a module creates YAML fields, MOC links, and validation rules that persist after deactivation — ghost infrastructure accumulates as structural debt unless modules define both activation and
+kind: research
+topics: ["[[design-dimensions]]", "[[maintenance-patterns]]"]
+methodology: ["Original", "Systems Theory"]
+source: [[composable-knowledge-architecture-blueprint]]
+---
+
+# module deactivation must account for structural artifacts that survive the toggle
+
+Composable knowledge systems celebrate the toggle. Enable a module, get its capabilities. Disable it, lose them. The promise is symmetric — addition and removal are both clean operations that leave the system in a valid state. But the reality is asymmetric in a way that matters: enabling a module creates structural commitments in the vault's content, and disabling the module does not undo those commitments. The structural artifacts survive the toggle.
+
+Consider what happens when the processing-pipeline module is enabled. It writes `methodology` fields into note frontmatter. It adds `relevant_notes` arrays with typed relationships. It creates processing metadata that downstream modules consume. Now disable the module. The YAML fields remain in every note that was processed while the module was active. No module reads them anymore, but they persist — ghost fields that consume attention during manual inspection, appear in grep queries as false positives, and suggest to future agents that the processing-pipeline module is active when it is not. Since [[module communication through shared YAML fields creates loose coupling without direct dependencies]], the communication mechanism that makes composition elegant is exactly what makes decomposition messy. Loose coupling means no module knows about any other, which means no module knows to clean up after another's departure.
+
+The problem extends beyond YAML fields. MOC links created by a navigation module persist after the module is disabled — notes still list `topics` references to MOCs that the navigation module would have maintained, but without the module, those MOCs stagnate while notes continue referencing them. Validation rules established by a schema module leave expectations in the template's `_schema` block that persist even after the module that justified those rules is gone. Each structural artifact type — fields, links, validation rules, processing metadata — has its own persistence pattern and its own failure mode when orphaned.
+
+Since [[progressive schema validates only what active modules require not the full system schema]], the validation layer at least stops complaining about fields from deactivated modules. This is necessary but insufficient. Progressive schema prevents false violations, which means deactivated module fields do not create errors. But the absence of errors is not the same as the absence of debris. The fields exist, occupy space in frontmatter, appear in metadata queries, and mislead anyone who reads the YAML expecting that every field has a purpose. Progressive schema is the correct validation response, but it solves the enforcement problem while leaving the information hygiene problem untouched.
+
+The deeper issue is that since [[the no wrong patches guarantee ensures any valid module combination produces a valid system]], the guarantee covers structural validity — no data corruption, no broken links, no module malfunction. A system with ghost fields from three deactivated modules is structurally valid. But "valid" and "clean" are different properties. The guarantee was designed for composition safety, and it succeeds at that. What it does not address is decomposition hygiene — whether the system accurately reflects its current configuration after modules have been removed. This is not a flaw in the guarantee so much as a gap in its scope. The no wrong patches principle needs a companion: no ghost patches, where deactivating a module removes the artifacts it created.
+
+The fix has two complementary parts. First, every module must define both activation and deactivation behavior. The activation side is well-understood: since [[dependency resolution through topological sort makes module composition transparent and verifiable]], the activation sequence already declares dependencies, contributes schema fields, and registers processing steps in a computationally resolved order. The deactivation side is the mirror: specify which fields to remove (or mark as deprecated), which MOC entries to flag for review, which validation rules to retract — and resolve the cleanup order through the same dependency graph in reverse. This is the knowledge system equivalent of database migrations having both `up` and `down` methods — a composable system that only handles `up` accumulates irreversible structural debt with every experiment. Second, activation should surface the structural commitments being made. When a user enables the processing-pipeline module, the system should communicate: "This will add methodology and relevant_notes fields to all processed notes. Disabling this module later will require cleaning up these fields from N notes." Informed consent prevents surprise when the deactivation cost becomes apparent.
+
+Since [[complex systems evolve from simple working systems]], Gall's Law encourages experimentation — add modules at friction points, see if they help, remove them if they do not. But experimentation without clean rollback is not truly experimental. If every module trial leaves permanent artifacts, the evolutionary cycle that Gall's Law prescribes accumulates debris proportional to the number of experiments attempted. The most adventurous systems — the ones that try the most modules — end up with the most ghost infrastructure. This inverts the intended dynamic: experimentation, which should lead to simplicity through selective retention, instead leads to complexity through artifact accumulation.
+
+There is a practical tension between thoroughness and cost. Full deactivation cleanup — scanning every note for orphaned fields, removing them, verifying nothing breaks — is expensive, especially for modules that were active long enough to touch hundreds of notes. Since [[evolution observations provide actionable signals for system adaptation]], the diagnostic protocol provides structured detection: ghost fields from deactivated modules surface as the "field consistently filled with N/A" and "note type unused for 30+ days" signals, making deactivation debris diagnosable through the same observation framework that monitors system health generally. The pragmatic response is tiered cleanup: immediate retraction of validation rules and schema contributions (cheap, prevents future false compliance), deferred cleanup of content-level artifacts with a manifest of what needs attention (medium cost, enables gradual remediation), and full backfill removal only when the accumulated debris triggers reseeding. Since [[derived systems follow a seed-evolve-reseed lifecycle]], the reseeding phase is the natural point for comprehensive deactivation cleanup — when the system is being restructured anyway, removing ghost infrastructure from previous module experiments is part of the principled restructuring rather than an additional cost.
+
+The relationship to [[tag rot applies to wiki links because titles serve as both identifier and display text]] is structural rather than obvious. Tag rot describes vocabulary drift in active infrastructure — tags that nobody searches for anymore because the vocabulary evolved. Deactivation artifacts describe abandoned infrastructure — fields that no module reads because the module was removed. Both produce noise that degrades the knowledge graph's signal-to-noise ratio, but through different mechanisms. Tag rot is gradual decay of relevance. Deactivation artifacts are sudden orphaning through configuration change. The mitigation strategies differ accordingly: tag rot requires vocabulary maintenance and synonym detection, while deactivation artifacts require lifecycle management and cleanup protocols. But both point to the same underlying truth: knowledge systems accumulate structural debt not just through growth but through the gap between what the system's state implies and what its current configuration actually uses.
+
+---
+---
+
+Relevant Notes:
+- [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]] — parent architecture that this note identifies a lifecycle gap in: the composable architecture describes activation and composition but not the reverse operation of clean decomposition
+- [[the no wrong patches guarantee ensures any valid module combination produces a valid system]] — the guarantee covers adding modules but is silent on removal: a system with ghost fields from deactivated modules is structurally valid but operationally misleading, which means the guarantee's scope needs extending to cover the full module lifecycle
+- [[progressive schema validates only what active modules require not the full system schema]] — the validation-side mitigation: progressive schema stops checking fields from deactivated modules, but stopping checks is not the same as cleaning up the fields; notes still carry ghost YAML that no module reads, creating noise in manual inspection and grep queries
+- [[module communication through shared YAML fields creates loose coupling without direct dependencies]] — the communication mechanism that creates the artifact problem: because modules coordinate through shared YAML rather than direct calls, deactivation leaves orphaned field values that no module consumes but that persist in every note that was touched while the module was active
+- [[derived systems follow a seed-evolve-reseed lifecycle]] — reseeding is the system-level response to accumulated deactivation debris: when multiple module experiments leave enough ghost infrastructure, the system needs principled restructuring rather than incremental cleanup
+- [[tag rot applies to wiki links because titles serve as both identifier and display text]] — a different kind of structural artifact decay: tag rot is vocabulary drift in active infrastructure, while deactivation artifacts are abandoned infrastructure; both produce noise that degrades the signal-to-noise ratio of the knowledge graph
+- [[complex systems evolve from simple working systems]] — Gall's Law encourages experimentation by adding modules at friction points, but experimentation implies some modules will be removed; without clean deactivation, the evolutionary add-and-remove cycle accumulates debris that contradicts the simplicity Gall's Law prescribes
+- [[schema evolution follows observe-then-formalize not design-then-enforce]] — the temporal complement: schema evolution adds fields when evidence justifies them, while deactivation cleanup removes fields when the module that justified them is no longer active; both follow the observe-then-act pattern
+- [[implicit dependencies create distributed monoliths that fail silently across configurations]] — the activation-direction twin: implicit dependencies form through undeclared reads during activation while deactivation artifacts persist through undeclared writes after removal; both reveal that the dependency graph must track what modules consume and produce, not just which modules must be co-active
+- [[each module must be describable in one sentence under 200 characters or it does too many things]] — reduces deactivation cost upstream: a focused module that passes the single-sentence test writes fewer fields and creates fewer structural commitments, so its deactivation footprint is proportionally smaller and cleanup is tractable
+- [[evolution observations provide actionable signals for system adaptation]] — the detection layer for deactivation debris: ghost fields from deactivated modules trigger the unused-type and N/A-field diagnostics, making the evolution observation protocol the structured mechanism for surfacing artifacts that progressive schema alone leaves unaddressed
+- [[dependency resolution through topological sort makes module composition transparent and verifiable]] — handles activation order but has no reverse protocol for deactivation cleanup order: just as topological sort resolves which modules to enable and why, a reverse traversal could determine which artifacts to clean up and in what sequence when a module is removed
+- [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]] — the adoption cost this note qualifies: the five-repetition threshold reduces but does not eliminate experimental additions that later get removed, so the adoption protocol should account for deactivation cost as part of the decision to enable
+
+Topics:
+- [[design-dimensions]]
+- [[maintenance-patterns]]