arscontexta 0.6.0

package/methodology/platform capability tiers determine which knowledge system features can be implemented.md

@@ -0,0 +1,48 @@
+---
+description: Three tiers (full automation, partial automation, minimal infrastructure) create a ceiling for features like pipelines, hooks, and semantic search, while core markdown conventions work universally
+kind: research
+topics: ["[[agent-cognition]]"]
+methodology: ["Original"]
+source: [[agent-platform-capabilities-research-source]]
+---
+
+# platform capability tiers determine which knowledge system features can be implemented
+
+Not all agent platforms offer the same infrastructure, and this asymmetry directly constrains which knowledge system features can function on each platform. The useful framing organizes platforms into three capability tiers, each creating a different ceiling for what a knowledge system built on that platform can actually do.
+
+The first tier provides full automation infrastructure: context files with read-write access, lifecycle hooks at multiple event boundaries, skills with context forking and model selection, subagent spawning with independent context windows, and MCP integration for external tools. Claude Code exemplifies this tier. A knowledge system built here can implement automated session orientation, processing pipelines with fresh context per phase, validation on every file write, and semantic search. The full Ars Contexta methodology -- skill-encoded quality gates, progressive disclosure via hooks, recursive self-extension -- operates at this tier because since [[context files function as agent operating systems through self-referential self-extension]], self-extension specifically requires the platform to grant write access to the context file that governs agent behavior.
+
+The second tier provides partial automation: context files and some skill support but limited hooks, no native subagent spawning, and basic MCP integration. Cursor, Gemini CLI, and Codex fit here with varying feature profiles. A knowledge system on this tier can implement note templates, wiki links, MOCs, and YAML schemas, plus some skill-driven workflows, but loses the processing pipeline's isolation guarantee. Since [[fresh context per task preserves quality better than chaining phases]], the inability to spawn subagents means later pipeline phases run on degraded attention -- a quality loss that cannot be papered over with instruction-level workarounds.
+
+The third tier provides minimal infrastructure: the agent can read instructions and execute file operations but lacks hooks, skills, and subagents. Any LLM with filesystem access fits here. The knowledge system reduces to core markdown conventions -- note templates, wiki links, MOCs, YAML frontmatter -- because since [[local-first file formats are inherently agent-native]], these features are just files and text that any agent reads without infrastructure.
+
+The critical design insight is that these tiers create a composability requirement, not a binary adoption decision. Core features (yaml-schema, wiki-links, atomic-notes, mocs) work at every tier because they are markdown conventions requiring no platform capabilities. Advanced features (processing-pipeline, hooks, validation, semantic-search) require specific platform infrastructure. A knowledge system generator must detect the platform tier and offer only features the platform can actually support, rather than degrading gracefully from a full-feature assumption. The tier framework becomes more precise when crossed with since [[four abstraction layers separate platform-agnostic from platform-dependent knowledge system features]]: tiers describe what platforms CAN do, layers describe what features NEED, and the intersection produces a capability matrix that maps exactly which features work where. The sharpest boundary in this matrix is the convention-to-automation layer transition, because since [[hook enforcement guarantees quality while instruction enforcement merely suggests it]], the jump from instruction compliance to hook enforcement is a categorical change in what the system can guarantee.
+
+This means since [[knowledge system architecture is parameterized by platform capabilities not fixed by methodology]], the generator's job is not replicating a fixed design but parameterized production. Because [[eight configuration dimensions parameterize the space of possible knowledge systems]], the tiers directly constrain at least two dimensions — automation level (which IS the tier distinction) and processing intensity (which requires subagent infrastructure for heavy processing). The same methodology manifests differently at each tier because the infrastructure determines which positions along these dimensions are viable. But parameterization must be combined with restraint: since [[complex systems evolve from simple working systems]], the generator should target the minimum viable configuration for each tier rather than the maximum features the tier could theoretically support. A tier-one platform that could run twelve skills, five hooks, and three-phase parallel processing should still start simple and let friction determine what to add.
+
+Even at tier one, capability is not unlimited. Since [[skill context budgets constrain knowledge system complexity on agent platforms]], the skill description budget (2% of context or 16,000 characters) caps active modules at roughly fifteen to twenty, meaning a tier-one platform cannot simply encode all methodology as skills -- the budget forces prioritization among workflows, and methodology that exceeds the budget falls back to instruction-level encoding with its weaker enforcement guarantees. The budget is a first-tier constraint: a problem you encounter precisely because you have the skill infrastructure, not despite it.
+
+Even within a single tier, platforms differ in ways that matter. Since [[platform adapter translation is semantic not mechanical because hook event meanings differ]], translating automation-layer features between platforms at the same nominal tier requires decomposing quality guarantees into constituent properties rather than mechanically mapping event names. This maps to since [[data exit velocity measures how quickly content escapes vendor lock-in]]: tier-universal features align with high exit velocity (plain text, portable conventions), while tier-specific features introduce platform dependencies that lower exit velocity. The tension is productive: advanced features are genuinely valuable -- since [[skills encode methodology so manual execution bypasses quality gates]], losing skill infrastructure means losing the methodology itself, not just convenience. And since [[schema enforcement via validation agents enables soft consistency]], features like automated schema validation require tier-one hooks to guarantee enforcement -- at lower tiers, the same validation degrades to instruction-based compliance that provably drifts as context fills. But designing for universality means the core knowledge graph (notes, links, structure) survives platform transitions even when the automation layer does not. The self-improvement loop adds another dimension: since [[bootstrapping principle enables self-improving systems]], only tier-one platforms where the agent has write access to its own context file and infrastructure can close the recursive improvement loop. Lower tiers can operate knowledge systems but cannot evolve them -- the system stays as it was configured rather than adapting to discovered friction.
+
+---
+---
+
+Relevant Notes:
+- [[context files function as agent operating systems through self-referential self-extension]] — identifies the read-write vs read-only distinction that creates the sharpest tier boundary: self-extension requires write access to context files
+- [[local-first file formats are inherently agent-native]] — explains why core features work at every tier: plain text with embedded metadata needs no platform infrastructure
+- [[skills encode methodology so manual execution bypasses quality gates]] — illustrates what gets lost at lower tiers: not just automation convenience but the encoded quality gates that skills carry
+- [[data exit velocity measures how quickly content escapes vendor lock-in]] — the portability metric that favors tier-universal features: high exit velocity maps to tier-independent functionality
+- [[fresh context per task preserves quality better than chaining phases]] — a first-tier feature that cannot degrade gracefully: without subagent spawning, the processing pipeline loses its quality preservation mechanism
+- [[four abstraction layers separate platform-agnostic from platform-dependent knowledge system features]] — the complementary decomposition: tiers describe what platforms CAN do, layers describe what features NEED; crossing them produces a capability matrix for mapping what works where
+- [[hook enforcement guarantees quality while instruction enforcement merely suggests it]] — the hook-instruction gap defines the sharpest boundary between tiers one and two: the jump from suggested to guaranteed enforcement
+- [[knowledge system architecture is parameterized by platform capabilities not fixed by methodology]] — the design consequence: tiers create the parameterization requirement because the same methodology manifests differently at each tier
+- [[complex systems evolve from simple working systems]] — constrains how to start at each tier: Gall's Law says target the minimum viable configuration, not the maximum features the platform could theoretically support
+- [[schema enforcement via validation agents enables soft consistency]] — a concrete automation-layer feature that requires tier-one hooks to guarantee enforcement; at lower tiers it degrades to instruction-based compliance that provably drifts
+- [[platform fragmentation means identical conceptual operations require different implementations across agent environments]] — the implementation cost: even platforms at the same nominal tier implement capabilities differently enough that code sharing is minimal
+- [[bootstrapping principle enables self-improving systems]] — the self-improvement loop only closes at tier one where the agent has write access to its own context file and can create infrastructure; lower tiers cannot bootstrap
+- [[platform adapter translation is semantic not mechanical because hook event meanings differ]] — reveals that even within a tier, event semantics differ enough that translating automation-layer features between platforms requires decomposing quality guarantees rather than mechanical event-name mapping
+- [[eight configuration dimensions parameterize the space of possible knowledge systems]] — the tiers directly constrain at least two of the eight dimensions: automation level IS the tier distinction, and processing intensity requires subagent infrastructure that only tier-one platforms provide
+- [[skill context budgets constrain knowledge system complexity on agent platforms]] — first-tier constraint: the description budget caps active skills at 15-20, so even tier-one platforms cannot encode unlimited methodology as skills, creating a resource allocation problem within the most capable tier
+
+Topics:
+- [[agent-cognition]]

package/methodology/platform fragmentation means identical conceptual operations require different implementations across agent environments.md

@@ -0,0 +1,44 @@
+---
+description: The same operation -- validate schema on write, orient at session start, enforce processing pipelines -- needs different code for Claude Code, OpenClaw, Codex, Gemini CLI, and every other platform,
+kind: research
+topics: ["[[agent-cognition]]"]
+methodology: ["Original"]
+source: [[agent-platform-capabilities-research-source]]
+---
+
+# platform fragmentation means identical conceptual operations require different implementations across agent environments
+
+The agent platform landscape in early 2026 presents a straightforward problem that resists straightforward solutions. Claude Code, OpenClaw, Codex, Cursor, Gemini CLI, Cline, Windsurf, Aider -- these platforms all enable similar conceptual operations but implement them through incompatible interfaces, file formats, naming conventions, and event models. The result is that building a knowledge system that works across platforms is not a matter of writing the logic once and deploying everywhere. Every piece of automation touches platform-specific infrastructure that must be reimplemented per environment.
+
+Consider a concrete operation: "validate note schema after every file write." Since [[schema enforcement via validation agents enables soft consistency]], the validation logic itself is universal -- parse YAML frontmatter, check required fields against a template schema, report violations. That logic is maybe fifty lines of code that works identically everywhere. But the trigger mechanism is entirely platform-specific. On Claude Code, a PostToolUse hook fires after every tool invocation and surfaces warnings back to the agent in the same conversation turn. On OpenClaw, there is no per-operation hook -- `command:new` fires at session start, so the same guarantee requires a fundamentally different enforcement strategy. On Gemini CLI, hooks exist but with different event boundaries and response formats. On platforms without hooks at all, the validation must fall back to instruction-based reminders in the context file, which since [[hook enforcement guarantees quality while instruction enforcement merely suggests it]] degrades the guarantee from enforcement to suggestion.
+
+This is not a packaging problem. Since [[platform adapter translation is semantic not mechanical because hook event meanings differ]], you cannot write a mechanical translation layer that maps event names across platforms. PostToolUse on Claude Code fires per-operation, returns results to the same conversation turn, and runs outside the context window. No other platform provides exactly these three properties simultaneously. Translating the operation means decomposing the guarantee into its constituent properties and reconstructing each one through whatever mechanisms the target platform offers -- even if the reconstruction looks nothing like the original.
+
+The fragmentation has an uneven topology. Since [[four abstraction layers separate platform-agnostic from platform-dependent knowledge system features]], the foundation layer (files, wiki links, YAML schemas) and convention layer (naming patterns, quality standards in context files) are largely immune to fragmentation because since [[local-first file formats are inherently agent-native]], they are just text that any LLM with filesystem access can implement. But the automation layer (hooks, skills, MCP) and orchestration layer (pipelines, subagent coordination, team processing) are where fragmentation creates real cost. Each platform implements these layers differently enough that code sharing is minimal.
+
+Emerging standards partially address this. The AgentSkills standard defines a common SKILL.md format -- YAML frontmatter with name, description, and optional metadata followed by markdown instructions -- that works across twenty-plus platforms. The AGENTS.md standard provides a universal context file format. But both standards deliberately scope to the common denominator. AgentSkills omits Claude Code's `context:fork` for subagent execution, Cursor's Background Agents for async processing, and OpenClaw's hook-based skill discovery. The standard captures what any agent can read while leaving platform-differentiating capabilities outside its scope. This is a reasonable design choice -- universality requires leaving out what is not universal -- but it means the standards reduce fragmentation at the convention layer while leaving the automation and orchestration layers fragmented.
+
+The practical consequence for knowledge system generation is an implementation multiplier. Since [[knowledge system architecture is parameterized by platform capabilities not fixed by methodology]], a generator must produce platform-specific output for every automation feature. The methodology stays constant (process through isolated phases, validate on every write, orient at session start) but the implementation differs per platform. This is not an argument against cross-platform generation -- it is an argument for understanding the cost structure. The foundation and convention layers are write-once. The automation and orchestration layers are write-per-platform. A generator that underestimates this cost produces systems that look complete but lack the enforcement layer that actually guarantees quality.
+
+The N-platforms times M-operations multiplier has a structural parallel worth noting. Since [[intermediate representation pattern enables reliable vault operations beyond regex]], Pandoc solves the N-formats times M-formats conversion problem with N+M implementations by routing everything through a canonical AST. The fragmentation problem is the same shape: N platforms times M automation operations currently demands N*M adapters. An intermediate operations language -- a canonical representation of what a hook should achieve, decomposed into guarantee properties like timing, scope, and enforcement level -- could let a generator compile from that representation to platform-specific implementations. This would not eliminate the platform-specific code, but it would reduce the design problem from reimagining each operation per platform to writing one compiler per platform. Whether this abstraction is achievable in practice depends on whether the guarantee properties decompose cleanly, which since [[platform adapter translation is semantic not mechanical because hook event meanings differ]] is genuinely uncertain -- but the architectural direction is sound.
+
+The fragmentation topology also explains why since [[data exit velocity measures how quickly content escapes vendor lock-in]], exit velocity drops sharply at the automation boundary. Foundation and convention features have high exit velocity -- they are portable text. But since [[operational memory and knowledge memory serve different functions in agent architecture]], operational coordination (queues, hooks, pipelines) inherits the fragmentation of the automation layer, making operational memory platform-locked while knowledge memory remains portable. A knowledge system that migrates platforms preserves its claims and connections but loses its processing infrastructure, which must be rebuilt from scratch on the new platform.
+
+---
+---
+
+Relevant Notes:
+- [[four abstraction layers separate platform-agnostic from platform-dependent knowledge system features]] -- provides the analytical framework for WHERE fragmentation bites: foundation and convention layers escape it, automation and orchestration layers suffer it
+- [[platform adapter translation is semantic not mechanical because hook event meanings differ]] -- explains WHY fragmentation resists simple solutions: the same event name on two platforms carries different timing, scope, and enforcement semantics
+- [[platform capability tiers determine which knowledge system features can be implemented]] -- the complementary analysis: tiers describe what platforms CAN do, fragmentation describes how differently they DO it even at the same tier
+- [[knowledge system architecture is parameterized by platform capabilities not fixed by methodology]] -- the design consequence: fragmentation forces parameterized generation rather than fixed replication
+- [[the AgentSkills standard embodies progressive disclosure at the skill level]] -- partial solution: standards like AgentSkills reduce fragmentation at the skill metadata level but deliberately omit platform-specific capabilities
+- [[intermediate representation pattern enables reliable vault operations beyond regex]] -- structural parallel: the IR note describes how Pandoc solves N*M format conversions with N+M implementations via a canonical AST; fragmentation is the same N*M problem applied to platform adapters, suggesting an intermediate operations language could reduce the implementation multiplier
+- [[local-first file formats are inherently agent-native]] -- foundation: explains WHY foundation-layer features escape fragmentation entirely; plain text with embedded metadata requires no platform infrastructure, which is why the fragmentation topology is uneven rather than uniform
+- [[schema enforcement via validation agents enables soft consistency]] -- concrete instance: the running example (validate schema on every write) IS the operation this note describes; the fragmentation note shows how this universal validation logic fragments across platform trigger mechanisms
+- [[data exit velocity measures how quickly content escapes vendor lock-in]] -- measurement: the write-once vs write-per-platform distinction maps directly to exit velocity gradients; automation-layer features have low exit velocity precisely because they fragment across platforms
+- [[operational memory and knowledge memory serve different functions in agent architecture]] -- memory topology: knowledge memory lives at foundation/convention layers and is portable across platforms, while operational memory requires automation/orchestration layers and inherits their fragmentation
+- [[blueprints that teach construction outperform downloads that provide pre-built code for platform-dependent modules]] — a distribution-format response to fragmentation: instead of pre-built per-platform code, blueprints ship semantic quality guarantees that each agent compiles into native implementations, reducing the N*M multiplier to N+M (one blueprint per operation, one compiler per platform)
+
+Topics:
+- [[agent-cognition]]

package/methodology/premature complexity is the most common derivation failure mode.md

@@ -0,0 +1,45 @@
+---
+description: Derivation can produce systems with 12 hooks and 8 processing phases because the claim graph justifies them, but users abandon within weeks — a complexity budget constrains initial output to minimum
+kind: research
+topics: ["[[design-dimensions]]"]
+methodology: ["Systems Theory", "Original"]
+source: [[knowledge-system-derivation-blueprint]]
+---
+
+# premature complexity is the most common derivation failure mode
+
+When a derivation engine traverses a well-developed claim graph, it can justify remarkable sophistication. Since [[eight configuration dimensions parameterize the space of possible knowledge systems]], the research says atomic notes enable composability, so the engine specifies atomic granularity. Composability requires explicit linking, so it adds typed wiki links. Explicit links demand deep navigation, so it generates a three-tier MOC hierarchy. Deep navigation needs maintenance, so it adds reweaving cycles and schema validation hooks. Each step follows logically from the last, and since [[configuration dimensions interact so choices in one create pressure on others]], the cascade is genuinely justified — atomic granularity really does pressure toward heavy processing and deep navigation. The problem is that a system justified at every step can still be unjustified as a whole, because the user receiving it cannot absorb twelve interacting design decisions simultaneously.
+
+This is the derivation-specific application of Gall's Law. Since [[complex systems evolve from simple working systems]], even a perfectly justified complex configuration will collapse if deployed all at once, because the micro-adaptations that make each component actually work — the habits of filing, the muscle memory of linking, the recognition of when a MOC needs splitting — can only develop through use. Because [[navigation infrastructure passes through distinct scaling regimes that require qualitative strategy shifts]], premature complexity has a concrete diagnostic beyond Gall's Law: it is deploying a higher regime's infrastructure into a lower regime's system. Automated community detection (Regime 3) in a 30-note vault (Regime 1) is not just premature in the abstract — it is premature in the precise sense that the mechanism only justifies itself at the scale it serves, and the operational experience that would make it valuable does not yet exist. A derivation engine that outputs the theoretically optimal system is like an architect who designs the perfect house but hands over blueprints that require living in the finished building to understand. The user needs to inhabit a simpler version first.
+
+The failure signature is distinctive. Unlike organic over-engineering, which builds up gradually through [[PKM failure follows a predictable cycle]] (Stage 4), derivation-induced complexity arrives all at once. The user opens their new system and encounters a context file with 200 lines of methodology, five note types with different schemas, hooks that fire on every save, and a processing pipeline they don't understand. The abandonment timeline accelerates because there is no period of working simplicity to build investment. The user never develops the attachment that comes from a system that started simple and grew with them.
+
+The concrete constraint is a complexity budget. Since [[ten universal primitives form the kernel of every viable agent knowledge system]], the budget has a floor — the kernel that every viable system needs regardless of domain — and the question is how far above that floor initial derivation should go. Initial derivation should be limited to the minimum viable configuration for the use case: two to three note types, two to four MOCs, four or fewer processing phases, and hooks only for the highest-value automation. This is not a suggestion to be overridden when the claim graph has more to say — it is a hard ceiling that reflects the reality that since [[derived systems follow a seed-evolve-reseed lifecycle]], the right time to add complexity is the evolution phase, where friction signals tell you exactly which elaboration is justified. The derivation engine's role at seed time is to produce a working kernel and embed enough context for the system to grow intelligently, not to front-load every insight the research graph contains. Since [[use-case presets dissolve the tension between composability and simplicity]], presets operationalize the complexity budget as curated module selections: a Research Vault preset activates thirteen modules (far fewer than the full catalog) because those thirteen are what the use case justifies. The preset author has already applied the complexity budget, and the user who selects the preset inherits that constraint without needing to understand or enforce it themselves.
+
+What makes this the most common failure mode rather than just one risk among many is the structural incentive. Since [[derivation generates knowledge systems from composable research claims not template customization]], the derivation process rewards thoroughness — a richer claim graph produces more justified choices, and each justified choice adds apparent value. The agent performing derivation is optimizing for completeness and coherence, which are genuine virtues in research but liabilities in system deployment. There is no natural brake on complexity in the derivation process itself, which is why the complexity budget must be an external constraint rather than an emergent property.
+
+The complexity budget also interacts with the dimension coupling that makes derivation non-trivial. Because dimension choices cascade — atomic granularity forces explicit linking forces deep navigation forces heavy maintenance — each choice beyond the minimum viable set amplifies across multiple dimensions. A system with three initial choices might involve six total dimension settings after cascading. A system with eight initial choices might involve twenty or more when interaction pressures are satisfied. The amplification means that small increases in initial complexity produce disproportionate increases in system-level complexity, making the budget more important than a linear count would suggest.
+
+The shadow side is that the complexity budget risks under-derivation. A system so minimal that it provides no structural guidance fails in the opposite way — the user has to discover everything through friction rather than benefiting from what the research already knows. The concrete antidote to premature complexity is [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]], which provides measurable thresholds — add after five manual repetitions, split above 500-character descriptions, remove after three unused sessions, cap at fifteen to twenty active modules — that prevent the justified-at-every-step-but-overwhelming-as-a-whole failure by requiring demonstrated need before each addition. The resolution is that the budget constrains the deployed system, not the derivation agent's knowledge. The context file should contain evolution guidelines — "when you notice X friction, add Y structure" — that encode the claim graph's insights as conditional advice rather than upfront deployment. Since [[justification chains enable forward backward and evolution reasoning about configuration decisions]], the user can trace from experienced friction back through the chain to the specific claims that justify adding the deferred complexity, making the budget a postponement rather than a loss. The system starts simple but carries the intelligence to grow precisely where it needs to.
+
+This note forms a trio of derivation anti-patterns with two siblings. Since [[configuration paralysis emerges when derivation surfaces too many decisions]], exposing too much of the claim graph during setup overwhelms the user before deployment even begins — a failure of decision presentation rather than system output. And since [[false universalism applies same processing logic regardless of domain]], reducing initial features to stay within the complexity budget can backfire if the remaining features default to one domain's processing patterns. The three anti-patterns constrain derivation from different directions: premature complexity means too much, false universalism means the wrong kind, and configuration paralysis means too many choices.
+---
+
+Relevant Notes:
+- [[complex systems evolve from simple working systems]] — provides the theoretical foundation via Gall's Law, but this note adds the concrete derivation-time constraint: a complexity budget with specific limits rather than a general principle about evolutionary design
+- [[PKM failure follows a predictable cycle]] — premature complexity maps to Stage 4 (Over-engineering) of the failure cascade, but applied at derivation time rather than during use; the derivation engine can inject Stage 4 conditions before the user even begins
+- [[derivation generates knowledge systems from composable research claims not template customization]] — derivation's composability is both its strength and its risk: because the claim graph justifies each choice individually, the composed system can be locally justified but globally unsustainable
+- [[derived systems follow a seed-evolve-reseed lifecycle]] — the complexity budget is the seeding constraint: minimum viable configuration at seed time, with evolution guidelines encoding when to add complexity rather than front-loading it
+- [[configuration dimensions interact so choices in one create pressure on others]] — dimension coupling amplifies premature complexity because each added dimension choice cascades through others, so an initial system with many choices accumulates more interaction pressure than one with few
+- [[the derivation engine improves recursively as deployed systems generate observations]] — the mechanism that calibrates the complexity budget over time: deployment observations teach the engine which elaborations users absorb and which overwhelm, so the budget becomes empirically grounded rather than theoretically estimated
+- [[configuration paralysis emerges when derivation surfaces too many decisions]] — sibling anti-pattern at a different point in the derivation timeline: premature complexity deploys too much justified complexity all at once while configuration paralysis overwhelms users with too many choices during setup; both are failure modes of exposing too much of the claim graph
+- [[false universalism applies same processing logic regardless of domain]] — complementary anti-pattern: premature complexity deploys too much of the right logic while false universalism deploys the wrong logic; avoiding one can trigger the other when reducing initial features defaults the remainder to one domain's processing patterns
+- [[justification chains enable forward backward and evolution reasoning about configuration decisions]] — the mechanism that makes the complexity budget's shadow side manageable: evolution guidelines encode claim-graph insights as conditional advice, and justification chains enable users to trace from friction back to the specific claims that justify adding deferred complexity
+- [[ten universal primitives form the kernel of every viable agent knowledge system]] — the kernel defines the floor of the complexity budget: minimum viable configuration cannot go below these ten primitives, and the budget constrains initial deployment to somewhere between the kernel and the fully justified but unsustainable maximum
+- [[progressive schema validates only what active modules require not the full system schema]] — prevents the validation equivalent of premature complexity: without progressive scoping, enabling basic modules forces compliance with advanced schemas, creating daily-use friction from features the user never adopted
+- [[use-case presets dissolve the tension between composability and simplicity]] — operationalizes the complexity budget: preset authors apply the budget once as curated module selections for each use case, so users inherit the constraint without needing to evaluate every module individually
+- [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]] — the concrete antidote: measurable thresholds (5-repetition addition, 500-char split, 3-session removal, 15-20 module cap) prevent premature complexity by requiring demonstrated need before each module addition, operationalizing the complexity budget as calibrated checkpoints rather than a single constraint
+- [[navigation infrastructure passes through distinct scaling regimes that require qualitative strategy shifts]] — regime-specific diagnostic: gives premature complexity a concrete frame beyond Gall's Law — deploying Regime 3 infrastructure (automated community detection, four-tier MOC hierarchy) into a Regime 1 system violates the complexity budget because the mechanisms only justify themselves at the scale they serve
+
+Topics:
+- [[design-dimensions]]

package/methodology/prevent domain-specific failure modes through the vulnerability matrix.md

@@ -0,0 +1,336 @@
+---
+description: Domain-specific failure modes and prevention strategies — what breaks in knowledge systems across domains, why it breaks, and how the plugin prevents it
+kind: guidance
+status: active
+topics: ["[[failure-modes]]"]
+---
+
+# prevent domain-specific failure modes through the vulnerability matrix
+
+Knowledge systems fail in predictable ways. Since [[PKM failure follows a predictable cycle]], the plugin can anticipate and prevent most failures before they occur. This doc catalogs failure modes across domains and specifies prevention strategies the plugin implements.
+
+This doc tells the plugin WHAT to watch for, per domain, and HOW to prevent it.
+
+## The 7-Stage Failure Cascade
+
+Knowledge system failure is not sudden. It follows a predictable cascade where each stage creates the conditions for the next. Early intervention prevents the later stages from materializing.
+
+| Stage | Name | What Happens | Typical Onset |
+|-------|------|-------------|---------------|
+| 1 | **Collector's Fallacy** | Content enters faster than it's processed. Saving feels productive. Inbox grows. | Days to weeks after setup |
+| 2 | **Structure Mirage** | User organizes the backlog into folders and tags. Feels like progress but produces no understanding. | Weeks after Stage 1 |
+| 3 | **Orphan Drift** | New notes are created quickly without connection-finding. The graph fragments into temporal layers that don't reference each other. | Weeks to months |
+| 4 | **Schema Erosion** | Without enforcement, notes gradually deviate from schema. Fields go missing, descriptions go stale, enum values drift. | Concurrent with Stage 3 |
+| 5 | **Navigation Breakdown** | MOCs become stale. Since [[stale navigation actively misleads because agents trust curated maps completely]], agents follow outdated maps and miss recent notes. | Months after Stage 3 |
+| 6 | **Retrieval Failure** | Users search for knowledge they know exists and cannot find it. Trust in the system drops. The vault feels unreliable. | Follows Stage 5 |
+| 7 | **Abandonment** | The maintenance burden exceeds perceived value. The system is abandoned. Since [[premature complexity is the most common derivation failure mode]], this stage is almost always traceable to excessive complexity at Stage 0 (/setup). | Follows Stage 6 |
+
+**The cascade is not inevitable.** Each stage has specific interventions. The critical insight: Stages 1-3 are low-cost to fix. Stages 5-7 require structural restructuring (/reseed). The plugin's job is to detect and intervene at Stages 1-3 before the cascade progresses.
+
+### Early-Stage Interventions
+
+| Stage | Detection Signal | Intervention | Plugin Mechanism |
+|-------|-----------------|-------------|------------------|
+| 1 (Collector's) | Inbox count > 2x weekly processing capacity | Inbox pressure alert + processing pipeline activation | /health checks inbox depth |
+| 2 (Structure Mirage) | Notes with tags/folders but zero wiki link connections | Flag "organized but unprocessed" notes | Orphan detection counts notes with topics but zero incoming links |
+| 3 (Orphan Drift) | Orphan accumulation rate > 15% of new notes | Batch connection-finding pass | /recommend suggests reflect passes on unconnected notes |
+| 4 (Schema Erosion) | Schema compliance < 80% on critical fields | Validation report with specific fix suggestions | /health runs schema compliance checks |
+| 5 (Navigation Breakdown) | MOC links point to moved/deleted notes; MOCs not updated in 30+ days | MOC health audit with stale link detection | /architect proposes MOC restructuring |
+
+**The principle:** prevention at Stage 0 (/setup) matters most. Since [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]], a minimal starting system prevents the premature complexity that makes the entire cascade more likely.
+
+### Domain-Specific Cascade Manifestations
+
+The same cascade looks different in each domain:
+
+| Domain | Stage 1 (Collector's) Looks Like | Stage 5 (Navigation) Looks Like |
+|--------|----------------------------------|----------------------------------|
+| Research | Papers saved but unread, bibliography grows, highlights unextracted | Literature review cites sources whose underlying claims have changed |
+| Therapy | Journal entries written but never reviewed for patterns | Pattern MOC lists triggers from 3 months ago, current triggers unlisted |
+| PM | Meeting notes captured but decisions unextracted | Project MOC shows "active" decisions that were superseded |
+| Creative | Worldbuilding ideas captured but never canonicalized | Character sheets contradict scenes written after the last canon update |
+| Personal | Goals set but never reviewed, areas neglected | Life area MOC shows "active" status on goals abandoned months ago |
+| Trading | Trade entries logged but thesis not tracked | Strategy MOC references market conditions that have changed |
+
+## Agent-Specific Failure Modes
+
+These failure modes are unique to agent-operated knowledge systems. They have no direct analogue in human PKM because they arise from the agent's relationship to the vault:
+
+### Stale MOC Navigation
+
+**The pattern:** MOCs are curated once then neglected. New notes are created but MOCs are not updated to include them. The agent trusts MOC-based navigation and treats unlisted notes as non-existent.
+
+**Why it happens:** Since [[stale navigation actively misleads because agents trust curated maps completely]], agents navigate by MOC and never "stumble on" unfiled items the way humans browse folders.
+
+**Prevention:**
+- Pipeline enforcement: /reflect phase MUST update MOCs as part of note creation
+- MOC health check: compare notes with matching `topics` against notes actually listed in the MOC's content
+- Orphan detection distinguishes "no topics field" (schema failure) from "topics present but MOC doesn't list note" (stale navigation)
+
+**Monitoring signal:** Count of notes with `topics: [[some-moc]]` that are NOT linked from that MOC's content.
+
+### Cognitive Outsourcing
+
+**The pattern:** The agent processes vault content, keeps the vault healthy, surfaces insights — but the human stops engaging with the knowledge. The human outsources understanding to the agent. The vault stays healthy but the human's comprehension atrophies.
+
+**Why it happens:** Agent processing makes knowledge work feel effortless. The human asks "what should I think about X?" instead of thinking about X. The processing pipeline produces insights, but the human never internalizes them.
+
+**Prevention:**
+- Processing pipeline requires human judgment gates — the agent proposes, the human decides
+- Since [[the architect does not auto-implement]], evolution recommendations go to the human for approval
+- Periodic prompts requiring human interpretation: "I detected this pattern — what does it mean to you?"
+- In therapy domains (see [[therapy journal uses warm personality with pattern detection for emotional processing]] ethical constraints), the agent surfaces patterns but explicitly withholds interpretation
+
+**Monitoring signal:** Ratio of agent-initiated changes to human-initiated changes. If consistently > 10:1, the human may be outsourcing cognitive work.
+
+### Context Degradation Across Sessions
+
+**The pattern:** Each agent session starts with partial context. Important information from previous sessions is lost because the context file doesn't capture it, session logs aren't consulted, or the agent skips orientation.
+
+**Why it happens:** Since [[LLM attention degrades as context fills]], agents work within context windows. Cross-session continuity depends on orientation artifact quality (context files, session logs, MOCs). Poor artifacts create agents that repeat work, miss connections, and contradict previous sessions.
+
+**Prevention:**
+- Context file generated with domain-specific orientation protocol
+- Session logging captures decisions and discoveries, not just actions
+- Start-of-session orientation reads context file + recent session log + relevant MOC
+- Pipeline handoff files carry state between phases explicitly
+
+**Monitoring signal:** Frequency of duplicate note creation or contradictory notes across sessions.
+
+### Processing Bias Accumulation
+
+**The pattern:** The agent's extraction and connection-finding develops systematic biases over time. It favors certain connection types, over-extracts from familiar claim patterns, and misses novel insights that don't match established patterns.
+
+**Why it happens:** Skills encode specific extraction patterns. Over many processing cycles, these patterns become self-reinforcing: the agent finds what the skill tells it to look for, and what it finds confirms the skill's approach.
+
+**Prevention:**
+- Periodic /rethink passes that challenge processing assumptions
+- Domain example diversity — multiple reference domains prevent single-pattern fixation
+- Human review of extraction results to catch systematic blind spots
+- Since [[derived systems follow a seed-evolve-reseed lifecycle]], reseed provides a principled reset when processing bias becomes systemic
+
+**Monitoring signal:** Declining novelty in extracted claims — new sources produce claims that increasingly resemble existing ones.
+
+## Monitoring Signal Summary
+
+The plugin should track these signals across all domains. When signals cross thresholds, /recommend surfaces them as actionable recommendations.
+
+| Signal | What It Measures | Healthy | Warning | Critical |
+|--------|-----------------|---------|---------|----------|
+| Inbox depth | Accumulation vs processing rate | < 10 items | 10-25 items | > 25 items |
+| Orphan accumulation rate | Connection-finding pipeline health | < 10% of new notes | 10-20% | > 20% |
+| Schema compliance | Metadata integrity | > 90% critical fields | 80-90% | < 80% |
+| MOC staleness | Navigation currency | Updated within 14 days | 14-30 days | > 30 days |
+| Description quality | Retrieval effectiveness | > 80% pass recite test | 60-80% | < 60% |
+| Agent/human ratio | Cognitive outsourcing risk | < 5:1 | 5-10:1 | > 10:1 |
+| Cross-session duplicates | Context degradation | 0 per month | 1-2 per month | > 2 per month |
+| Claim novelty | Processing bias | Novel claims > 50% | 30-50% | < 30% |
+
+## Universal Failure Modes
+
+These affect every domain regardless of content type:
+
+### 1. Accumulation Without Processing
+
+**The pattern:** Content enters the system faster than it's processed. Inbox grows. Unprocessed items create guilt. The system becomes a dumping ground.
+
+**Why it happens:** Since [[throughput matters more than accumulation]], capture is easy and getting easier (voice transcription, AI-assisted recording). Processing requires effort and judgment.
+
+**Prevention:**
+- Inbox pressure alerts when unprocessed items exceed threshold
+- Processing pipeline that reduces effort per item
+- WIP limits on inbox size — since [[WIP limits force processing over accumulation]]
+- Visual indicators of processing debt
+
+### 2. Structure Without Processing
+
+**The pattern:** Notes are filed into folders, tagged, and organized — but never synthesized. The system looks organized but contains no original thinking.
+
+**Why it happens:** Since [[structure without processing provides no value]], organizing feels like progress but produces no new understanding.
+
+**Prevention:**
+- Processing pipeline requires transformation, not just filing
+- Since [[generation effect gate blocks processing without transformation]], the reduce phase demands active transformation
+- Health metrics that measure synthesis (new connections created) not just accumulation (new notes filed)
+
+### 3. Orphan Note Accumulation
+
+**The pattern:** Notes exist but aren't connected to anything. No incoming links, no MOC membership. Effectively invisible.
+
+**Why it happens:** Notes created without running the connect phase. Quick captures that never get integrated.
+
+**Important reframe:** Orphan notes are seeds, not failures. A note without connections is potential awaiting integration, not garbage requiring deletion. The metric that matters is the orphan accumulation RATE, not the absolute count. A steady-state of 5-10% orphans is healthy (recent captures awaiting processing). A growing orphan rate signals pipeline breakdown.
+
+**Prevention:**
+- Topics field required on every note (orphan prevention)
+- Orphan detection in maintenance loop
+- Reflect phase mandatory after note creation
+- MOC update required as part of the note creation cycle
+
+### 4. Schema Drift
+
+**The pattern:** Notes gradually deviate from schema requirements. Fields go missing, enum values diverge, descriptions become stale.
+
+**Why it happens:** Without enforcement, entropy wins. Each note cut corners slightly.
+
+**Prevention:**
+- Schema enforcement (see [[schema-enforcement]] guidance doc)
+- Periodic validation passes
+- Progressive schema — only enforce what's actually used
+
+### 5. System Abandonment
+
+**The pattern:** Elaborate system set up, used enthusiastically for 2-3 weeks, then gradually abandoned.
+
+**Why it happens:** Since [[premature complexity is the most common derivation failure mode]], the system's maintenance burden exceeds its perceived value.
+
+**Prevention:**
+- Start minimal — since [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]]
+- Early value delivery — show insights from the first captured content
+- Low-friction capture — since [[temporal separation of capture and processing preserves context freshness]]
+- Condition-based maintenance, not scheduled reviews
+
+## Domain-Specific Failure Modes
+
+### Research & Academic
+
+| Failure Mode | Symptom | Prevention |
+|-------------|---------|------------|
+| Source-oriented thinking | Notes organized by paper, not by concept | Since [[concept-orientation beats source-orientation for cross-domain connections]], enforce concept-based note titles |
+| Citation rot | Sources become unavailable | Periodic link checking on source notes |
+| Confirmation bias | Only citing supporting evidence | Track "contradicts" relationships; flag topics with only confirming evidence |
+| Synthesis stagnation | Many claims, no synthesis notes | Monitor claim-to-synthesis ratio; suggest synthesis when claims cluster |
+
+### Therapy & Reflective
+
+| Failure Mode | Symptom | Prevention |
+|-------------|---------|------------|
+| Write-only journaling | Entries never reviewed for patterns | Automatic pattern detection across entries |
+| Emotional avoidance | Consistently avoiding difficult topics | Detect topic avoidance patterns (topics mentioned then dropped) |
+| Over-intellectualization | Analysis replaces feeling | Track emotional vocabulary density in entries |
+| Strategy-trigger disconnect | Coping strategies exist but aren't linked to triggers | Enforce strategy-trigger relationships in schema |
+
+### Project Management
+
+| Failure Mode | Symptom | Prevention |
+|-------------|---------|------------|
+| Decision amnesia | "Why did we decide this?" | Decision notes required with rationale field |
+| Meeting action decay | Action items captured, never completed | Action item tracking with staleness alerts |
+| Risk register staleness | Risks assessed once, never updated | Condition-based review triggers on risk notes |
+| Retrospective theater | Same issues across retros | Cross-retrospective pattern detection |
+
+### Creative Writing
+
+| Failure Mode | Symptom | Prevention |
+|-------------|---------|------------|
+| Continuity errors | Contradictions across chapters | Consistency graph with contradiction detection |
+| Voice drift | Character speech patterns change | Character voice baseline tracking |
+| Worldbuilding rabbit hole | Building worlds nobody reads about | Track worldbuilding notes vs scenes they appear in |
+| Plot thread abandonment | Foreshadowing without payoff | Thread tracking with resolution status |
+
+### Student & Learning
+
+| Failure Mode | Symptom | Prevention |
+|-------------|---------|------------|
+| Passive accumulation | Notes taken but never actively recalled | Spaced repetition integration |
+| Prerequisite blindness | Advanced material attempted without foundations | Prerequisite graph validation |
+| Course silo-ing | Concepts isolated within single courses | Cross-course concept connection detection |
+| Illusion of competence | Since [[metacognitive confidence can diverge from retrieval capability]] | Active retrieval testing via recite patterns |
+
+### Personal Life Management
+
+| Failure Mode | Symptom | Prevention |
+|-------------|---------|------------|
+| Review fatigue | Weekly reviews abandoned | Condition-based reviews, not scheduled |
+| Area neglect | Some life areas get no attention | Area health dashboard with neglect detection |
+| Goal drift | Goals set but never updated | Quarterly goal review triggers |
+| Productivity porn | Since [[productivity porn risk in meta-system building]] | Track time spent on system vs time spent doing work |
+
+### Trading & Finance
+
+| Failure Mode | Symptom | Prevention |
+|-------------|---------|------------|
+| Strategy drift | Actual trades deviate from strategy rules | Strategy compliance checking per trade |
+| Confirmation bias | Only seeking thesis-supporting evidence | Track counter-evidence for each thesis |
+| Emotional trading | Decisions driven by fear/greed | Sentiment analysis on journal entries |
+| Review avoidance | Trade journal not analyzed for patterns | Automatic pattern detection across trades |
+
+### Health & Wellness
+
+| Failure Mode | Symptom | Prevention |
+|-------------|---------|------------|
+| Tracking without analysis | Data collected but no patterns detected | Automatic correlation analysis at data thresholds |
+| Protocol inertia | Supplements/programs continued without reassessment | Protocol effectiveness review triggers |
+| Symptom isolation | Symptoms tracked in isolation from lifestyle factors | Multi-dimensional correlation (sleep + nutrition + exercise + symptoms) |
+| Plateau blindness | Progress stalled without detection | Trend analysis with plateau detection |
+
+### Engineering Team
+
+| Failure Mode | Symptom | Prevention |
+|-------------|---------|------------|
+| Tribal knowledge | Critical info in people's heads only | Knowledge gap detection via undocumented system alerts |
+| ADR decay | Decisions documented but never updated | ADR assumption monitoring |
+| Postmortem theater | Incidents analyzed, action items ignored | Action item tracking with completion rates |
+| Documentation rot | Docs diverge from implementation | Staleness detection via code change correlation |
+
+### Product Management
+
+| Failure Mode | Symptom | Prevention |
+|-------------|---------|------------|
+| Feedback fragmentation | Customer voice scattered across tools | Feedback aggregation with theme detection |
+| Experiment amnesia | A/B tests run, learnings not captured | Experiment log with mandatory learnings field |
+| Roadmap-strategy disconnect | Features not traced to OKRs | Dependency tracking from features to strategic goals |
+| Research staleness | User research cited years later | Research freshness tracking |
+
+### Legal & Case Management
+
+| Failure Mode | Symptom | Prevention |
+|-------------|---------|------------|
+| Precedent rot | Relying on overruled case law | Precedent chain monitoring for updates |
+| Jurisdictional blindness | Compliance missed across jurisdictions | Multi-jurisdiction regulatory tracking |
+| Clause inconsistency | Standard terms drift across contracts | Cross-contract clause comparison |
+| Deadline miscalculation | Complex filing deadlines missed | Automated deadline tracking with jurisdictional rules |
+
+## How the Plugin Uses This Doc
+
+| Meta-Skill | How It Uses Failure Modes |
+|------------|--------------------------|
+| /setup | Configures prevention mechanisms based on selected domains |
+| /recommend | Checks for active failure mode symptoms and suggests fixes |
+| /architect | Ensures new extensions don't introduce known failure modes |
+| /ask | References domain-specific failure modes when answering "what could go wrong?" |
+
+## Domain Examples
+
+Every domain composition includes agent-native prevention strategies for its specific failure modes:
+
+- [[academic research uses structured extraction with cross-source synthesis]] — Concept-orientation enforcement prevents source-oriented thinking; citation graph monitoring detects citation rot
+- [[therapy journal uses warm personality with pattern detection for emotional processing]] — Automatic pattern detection prevents write-only journaling; emotional vocabulary density tracking catches over-intellectualization
+- [[project management uses decision tracking with stakeholder context]] — Decision notes with mandatory `rationale` field prevent decision amnesia; action item staleness alerts prevent meeting action decay
+- [[creative writing uses worldbuilding consistency with character tracking]] — Consistency graph with contradiction detection prevents continuity errors; thread tracking with resolution status prevents plot thread abandonment
+- [[student learning uses prerequisite graphs with spaced retrieval]] — Active retrieval testing via recite patterns prevents illusion of competence; prerequisite graph validation prevents prerequisite blindness
+- [[health wellness uses symptom-trigger correlation with multi-dimensional tracking]] — Automatic correlation analysis at data thresholds prevents tracking without analysis; protocol effectiveness review triggers prevent protocol inertia
+- [[engineering uses technical decision tracking with architectural memory]] — Knowledge gap detection via undocumented system alerts prevents tribal knowledge; ADR assumption monitoring prevents ADR decay
+- [[legal case management uses precedent chains with regulatory change propagation]] — Precedent chain monitoring for updates prevents precedent rot; multi-jurisdiction regulatory tracking prevents jurisdictional blindness
+
+## Grounding
+
+This guidance is grounded in:
+- [[PKM failure follows a predictable cycle]] — the 7-stage cascade follows predictable patterns
+- [[premature complexity is the most common derivation failure mode]] — the leading cause of abandonment (Stage 7 traces to Stage 0)
+- [[structure without processing provides no value]] — Stage 2 (Structure Mirage) accumulates organization without synthesis
+- [[throughput matters more than accumulation]] — processing velocity prevents Stage 1 (Collector's Fallacy)
+- [[false universalism applies same processing logic regardless of domain]] — domain-specific failures need domain-specific prevention
+- [[stale navigation actively misleads because agents trust curated maps completely]] — agent-specific failure mode: stale MOCs
+- [[derived systems follow a seed-evolve-reseed lifecycle]] — reseed as escape valve when cascade reaches late stages
+- [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]] — minimal starting systems prevent cascade onset
+
+---
+
+Topics:
+- [[index]]
+- [[index]]
+---
+
+Topics:
+- [[failure-modes]]

package/methodology/processing effort should follow retrieval demand.md

@@ -0,0 +1,57 @@
+---
+description: Just-in-time processing on retrieval beats just-in-case front-loading because most captured notes are never revisited
+kind: research
+topics: ["[[processing-workflows]]"]
+---
+
+# processing effort should follow retrieval demand
+
+Tiago Forte's research reveals a striking fact: most captured notes are never revisited. This means heavy upfront processing at capture time wastes effort on content that will never be used.
+
+The alternative is JIT (just-in-time) processing: minimal work at capture, investment only on retrieval. When something actually gets retrieved, that's when you process it deeply. This creates a demand-driven queue where attention follows demonstrated value. The cognitive grounding: since [[LLM attention degrades as context fills]], front-loading fills context with low-probability content, degrading attention for the content that actually matters.
+
+The temporal caveat: since [[temporal separation of capture and processing preserves context freshness]], JIT processing has limits for inbox content. Ebbinghaus decay means the human context that made something worth capturing fades within 24 hours. Pure demand-driven processing risks waiting so long that even when retrieval finally signals value, the original understanding is unrecoverable. The reconciliation: JIT still applies, but inbox items have a time-sensitive urgency that other content doesn't. Old inbox items need processing regardless of retrieval signal.
+
+The implication for vault operations is clear: capture quickly and move on. Let retrieval patterns identify what deserves deeper processing. Track retrieval counts to identify high-value content that earns additional synthesis work. And since [[intermediate packets enable assembly over creation]], the deep processing triggered by retrieval naturally produces composable packets — the session's output becomes a building block that future retrieval can assemble from. JIT processing and packet production reinforce each other: retrieval triggers processing, processing produces packets, packets enable future assembly.
+
+But JIT processing requires efficient filtering. Since [[progressive disclosure means reading right not reading less]], the goal isn't minimal loading but curated loading — finding what deserves deep attention before committing full context. The discovery layers provide this filtering mechanism: [[descriptions are retrieval filters not summaries]] enables agents to identify which notes are relevant without loading everything. Scanning 50 descriptions costs fewer tokens than reading 5 full notes to find the relevant one. Aggregated descriptions become a pre-computed low-entropy representation that enables demand-driven retrieval to be efficient.
+
+This inverts the traditional knowledge management instinct to "process properly" at capture time. That instinct optimizes for the wrong thing. Since [[throughput matters more than accumulation]], the constraint isn't capture quality but capture volume — and volume demands selective investment based on actual use, not predicted importance.
+
+## Demand signals in practice
+
+How do you actually measure retrieval demand? Since [[dangling links reveal which notes want to exist]], one concrete signal emerges from wiki link patterns. When multiple notes independently reference the same concept, that accumulated demand justifies creation of the note. The frequency of dangling links IS demand measurement — the graph is voting with its references.
+
+This connects to traversal patterns too. Since [[spreading activation models how agents should traverse]], frequently traversed nodes accumulate more activation and show up in more search results. The spreading activation mechanism creates its own demand signal: nodes that get visited often during retrieval are demonstrably high-value.
+
+Together, these provide objective demand metrics:
+- **Dangling link frequency** — how often does the graph reference this concept?
+- **Traversal frequency** — how often do agents visit this node during retrieval?
+- **Backlink count** — how many notes invoke this one?
+
+Processing investment should flow to nodes that score high on these metrics. Let demand emerge from use, not from predictions about importance.
+
+## The blind spot
+
+Demand-driven processing has a structural limitation: notes that SHOULD receive attention but don't generate retrieval signals fall outside the demand loop. If maintenance attention follows the same power-law distribution as link density, the bottom 80% of notes may receive minimal attention regardless of need. [[random note resurfacing prevents write-only memory]] tests whether random selection — explicitly anti-JIT — addresses this blind spot by giving every note equal probability of maintenance attention independent of demand signals. A complementary approach emerges from [[spaced repetition scheduling could optimize vault maintenance]], which tests whether interval-based scheduling (frequent early review, sparse later) adds a proactive dimension to the demand-following principle — some maintenance effort anticipates need based on note age rather than responding to retrieval signals or random selection.
+
+For experiments specifically, since [[maintenance targeting should prioritize mechanism and theory notes]], demand signals should be semantic rather than observed. The question "what mechanism does this test?" predicts higher-value reweave targets than retrieval frequency or topic proximity. Experiments need their theory notes, not their MOC neighbors.
+---
+
+Relevant Notes:
+- [[topological organization beats temporal for knowledge work]] — JIT retrieval is only efficient when the system is organized for semantic access; date-based organization would force chronological scanning regardless of retrieval demand
+- [[progressive disclosure means reading right not reading less]] — the philosophy underlying efficient filtering: curated loading over minimal loading
+- [[queries evolve during search so agents should checkpoint]] — both patterns recognize that processing should respond to runtime information, not front-loaded predictions
+- [[dangling links reveal which notes want to exist]] — provides the demand measurement mechanism: dangling link frequency signals where processing investment pays off
+- [[spreading activation models how agents should traverse]] — traversal patterns create demand signals: frequently visited nodes demonstrate high retrieval value
+- [[descriptions are retrieval filters not summaries]] — provides the filtering mechanism that makes JIT retrieval efficient: scan descriptions to identify what deserves full loading
+- [[throughput matters more than accumulation]] — provides the success metric that demand-driven processing serves: velocity from capture to synthesis, not archive size
+- [[LLM attention degrades as context fills]] — cognitive grounding for JIT: front-loading degrades attention for the content that actually matters
+- [[temporal separation of capture and processing preserves context freshness]] — temporal constraint on JIT: inbox content has time-sensitive urgency because human context decays
+- [[random note resurfacing prevents write-only memory]] — tests whether anti-JIT random selection addresses the blind spot where notes lacking demand signals accumulate neglect
+- [[spaced repetition scheduling could optimize vault maintenance]] — tests interval-based scheduling as a third allocation strategy alongside demand-driven (JIT) and random selection; proactive rather than reactive
+- [[maintenance targeting should prioritize mechanism and theory notes]] — refines demand-following for experiments: semantic demand (what mechanism is being tested) predicts value better than observed demand (retrieval frequency)
+- [[intermediate packets enable assembly over creation]] — connects processing outputs to composability: JIT processing triggered by retrieval naturally produces packets that future work can assemble from
+
+Topics:
+- [[processing-workflows]]