arscontexta 0.6.0

package/methodology/implement condition-based maintenance triggers for derived systems.md

@@ -0,0 +1,255 @@
+---
+description: Condition-based maintenance triggers for derived knowledge systems — what to check, when to check it, and how to fix it without time-based scheduling
+kind: guidance
+status: active
+topics: ["[[maintenance-patterns]]"]
+---
+
+# implement condition-based maintenance triggers for derived systems
+
+Knowledge systems decay. Links go stale, notes become orphaned, schemas drift, MOCs grow unwieldy, synthesis falls behind accumulation. Since [[maintenance operations are more universal than creative pipelines because structural health is domain-invariant]], the maintenance patterns that prevent this decay are largely the same across all domains.
+
+This doc tells the plugin WHAT maintenance to generate, WHEN to trigger it, and HOW to implement it safely.
+
+## Condition-Based, Not Time-Based
+
+Traditional systems schedule maintenance: "Do a weekly review." "Run health checks monthly." This fails because:
+1. The need for maintenance depends on activity, not time
+2. Scheduled maintenance that finds nothing is wasted effort
+3. Scheduled maintenance that misses a critical window causes damage
+
+The plugin generates condition-based triggers instead: maintenance fires when a condition is violated, not when a calendar says so. Since [[maintenance scheduling frequency should match consequence speed not detection capability]], the constraint on check frequency is the propagation rate of problems, not the cost of running the check. A dangling link propagates instantly (agents trust it immediately). A stale description propagates over weeks (understanding evolves gradually). Matching frequency to consequence speed means the urgent checks run often and the slow checks run rarely, regardless of how cheap it would be to run them all constantly.
+
+## The Three-Loop Architecture
+
+Since [[three concurrent maintenance loops operate at different timescales to catch different classes of problems]], the plugin generates three concurrent maintenance loops. Each loop has a distinct character because the problems it targets cannot exist at other frequencies.
+
+### Loop 1: Per-Operation (Immediate)
+
+Runs on every note creation/modification. Lightweight checks that catch problems at the source. These operations are fully mechanical — they require zero judgment and produce deterministic results.
+
+| Check | Trigger | Action |
+|-------|---------|--------|
+| Required schema fields present | Note created/modified | Warn if missing |
+| Wiki link targets exist | Link added | Warn if dangling |
+| Description exists and adds value | Note created | Warn if missing/redundant |
+| Topics field populated | Note created | Warn if orphaned |
+
+**Implementation:** PostToolUse hooks on Write operations. Zero friction — runs automatically, reports asynchronously.
+
+**Why per-operation:** A malformed note that passes validation will be linked from MOCs, cited in other notes, and indexed for search — each consuming the broken state before any scheduled check could catch it. The fast loop catches problems that cannot wait.
+
+### Loop 2: Post-Batch (After Processing)
+
+Runs after a processing batch completes or at session start. Medium-weight checks that combine mechanical detection with judgment-requiring remediation.
+
+| Check | Trigger | Action |
+|-------|---------|--------|
+| New notes connected to MOCs | Batch complete | Flag unconnected notes |
+| Cross-references between batch siblings | Batch complete | Run cross-connect validation |
+| Processing queue advanced | Phase complete | Verify phase transitions |
+| Schema compliance across batch | Batch complete | Report compliance rate |
+| qmd index matches file count | Session start | Sync if stale |
+| Orphan notes exist | Session start | Flag for connection-finding |
+
+**Implementation:** Post-processing skill step plus session-start reconciliation hook.
+
+**Why post-batch:** Orphan accumulation propagates at session scale. An orphan note is equally orphaned whether you detect it after one minute or one hour, so per-event checking would waste the attention budget without catching problems faster.
+
+### Loop 3: Condition-Triggered (Periodic)
+
+Runs when conditions are violated, detected by reconciliation checks. Heavier analysis that looks at system-level health. Even detection at this level requires judgment.
+
+| Condition | Threshold | Action |
+|-----------|-----------|--------|
+| MOC exceeds healthy size | >50 notes in a topic MOC | Suggest split |
+| Notes stale | Not updated in 30+ days while topic is active | Flag for reweaving |
+| Observation notes accumulate | >10 pending observations | Trigger meta-review |
+| Tension notes accumulate | >5 pending tensions | Trigger meta-review |
+| Inbox grows | >N items per subdirectory | Alert for processing |
+| Processing queue stalls | Tasks pending >7 days | Alert for pipeline attention |
+| Description quality low | Retrieval test failures >20% | Batch description improvement |
+| Graph topology imbalanced | Sparse topics, bridge overload | Structural review |
+
+**Implementation:** Reconciliation script runs at session start and on-demand. Since [[automated detection is always safe because it only reads state while automated remediation risks content corruption]], detection never causes harm.
+
+**Why periodic:** Stale descriptions develop over weeks as understanding evolves. No individual write event signals the problem. Only system-level comparison of current state against desired state reveals the accumulated drift.
+
+### How the Loops Compose
+
+The key insight is that each loop has a different relationship between detection and remediation:
+
+| Loop | Detection | Remediation | Automation Level |
+|------|-----------|-------------|-----------------|
+| Fast (per-op) | Identical to remediation | Blocks write, agent fixes | Fully automatic |
+| Medium (per-batch) | Mechanical | Requires judgment | Detect automatically, suggest fixes |
+| Slow (periodic) | Requires judgment | Requires deep judgment | Log for review |
+
+Since [[confidence thresholds gate automated action between the mechanical and judgment zones]], the fast loop auto-applies, the medium loop suggests, and the slow loop logs for review. When loops overlap (both fast and medium might check for dangling links), since [[idempotent maintenance operations are safe to automate because running them twice produces the same result as running them once]], redundant detection across loops produces identical results rather than compounding.
+
+## The Reconciliation Pattern
+
+Since [[reconciliation loops that compare desired state to actual state enable drift correction without continuous monitoring]], the plugin's maintenance architecture inverts the traditional imperative model. Instead of reacting to events with "add this link" or "fix this schema," the system declares desired state and periodically measures divergence.
+
+**The reconciliation table:**
+
+| Desired State | Detection Method | Remediation |
+|--------------|-----------------|-------------|
+| All wiki links resolve | Dangling link check | Fix links or create target notes |
+| All notes have descriptions | Schema validation | Add missing descriptions |
+| All notes appear in topic MOCs | Coverage check | Add to appropriate MOC |
+| Search index matches file count | Index freshness check | Re-index |
+| Zero orphan notes | Backlink analysis | Connect or archive |
+| MOCs under threshold size | Note count per MOC | Split into sub-MOCs |
+
+**Why reconciliation matters:** Event-driven maintenance has a structural blind spot — it only catches problems that co-occur with events. Schema drift from template evolution, link rot from renames, index staleness from batch processing, MOC drift from organic growth — these accumulate silently between events. No hook fires when a template adds a new required field and a hundred existing notes quietly become non-compliant.
+
+**The critical property:** The comparison itself is idempotent — checking whether all wiki links resolve produces the same answer regardless of how many times you run it, with no side effects. This means reconciliation detection can run at any frequency with zero risk.
+
+## Idempotency: The Safety Requirement
+
+Since [[idempotent maintenance operations are safe to automate because running them twice produces the same result as running them once]], any operation the plugin automates must converge to the same state regardless of how many times it executes. Hooks fire on events, and events can repeat. Scheduled maintenance runs on timers, and timers can overlap. Crash recovery reruns interrupted operations.
+
+### Four Patterns for Idempotent Maintenance
+
+**1. Compare-before-acting:** Check whether the desired state already exists before modifying anything. A hook that adds a note to a MOC first checks whether the note is already listed. If present, it does nothing. If absent, it adds the entry. Running this ten times produces the same result as running it once.
+
+**2. Unique identifiers:** Prevent duplicates through identity. Claim numbers in a queue are globally unique and never reused, so re-running an extraction that already assigned claim-042 cannot create a second claim-042.
+
+**3. Upsert semantics:** Operations that set state rather than modify state. "Ensure description exists" is idempotent because setting a value to what it already is changes nothing. "Append to description" is not idempotent because each execution adds more content.
+
+**4. State-based declarations:** Declare desired end state rather than prescribing transitions. "Note should be in MOC" is idempotent. "Add note to MOC" is not, unless guarded by a presence check.
+
+### The Two-Filter Automation Test
+
+Before automating any maintenance operation, two tests must pass:
+
+1. **Determinism test:** Would two reviewers always agree on the output? If yes, it's mechanical. If no, it requires judgment and belongs in a skill, not a hook.
+2. **Idempotency test:** Does running the operation twice produce the same state as running it once? If no, it needs guards (compare-before-acting, unique IDs, upsert semantics) before it can be scheduled.
+
+Both must pass for hook-level automation. Most structural health checks pass both trivially: validating a schema, detecting orphans, checking link integrity, and measuring MOC coherence all read state without modifying it, making them inherently safe to run on any schedule.
+
+## The Detection-vs-Remediation Boundary
+
+Since [[automated detection is always safe because it only reads state while automated remediation risks content corruption]], the plugin generates two classes of maintenance:
+
+### Safe to Automate (Detection)
+- Schema compliance checking
+- Orphan note detection
+- Dangling link detection
+- MOC size monitoring
+- Staleness detection
+- Processing queue status
+- Index freshness comparison
+
+### Requires Human Judgment (Remediation)
+- Fixing detected schema violations (might need domain understanding)
+- Connecting orphan notes (requires semantic judgment)
+- Splitting MOCs (requires understanding of conceptual boundaries)
+- Resolving tensions (requires intellectual decision)
+- Retiring stale notes (requires context about whether staleness matters)
+- Choosing between competing fixes (multiple valid responses)
+
+The plugin automates detection and presents remediation as actionable suggestions. Only fully mechanical fixes (like adding a missing date field or re-indexing a stale search index) can be automated; anything requiring semantic judgment is surfaced for human decision.
+
+## Scaling Factors
+
+The plugin adjusts maintenance intensity based on three scaling factors:
+
+### Vault Size
+
+| Size | Fast Loop | Medium Loop | Slow Loop |
+|------|-----------|-------------|-----------|
+| Small (<50 notes) | Standard schema checks | Session-start overview | Monthly review |
+| Medium (50-200 notes) | Full schema + link checks | Session-start reconciliation | Bi-weekly graph analysis |
+| Large (200+ notes) | Full checks, parallel where possible | Full reconciliation with coverage metrics | Weekly audits, automated trend detection |
+
+At small scale, most maintenance is unnecessary because the entire vault fits in context. As the vault grows, each loop becomes progressively more important because problems compound across a larger surface area.
+
+### Activity Rate
+
+High-activity vaults (daily captures, frequent processing batches) need more aggressive medium-loop checks because drift accumulates faster. Low-activity vaults can reduce medium-loop frequency because less content changes between sessions.
+
+The plugin scales the medium loop's inbox pressure thresholds and processing queue staleness thresholds based on observed activity patterns — a vault that processes 20 notes per week should flag a 7-day stall, while a vault that processes 2 notes per month should use a 30-day threshold.
+
+### Domain Complexity
+
+Multi-domain vaults need more maintenance than single-domain vaults because cross-domain interactions create additional failure modes. A therapy-plus-research vault needs both therapy-specific pattern staleness checks and research-specific citation checks, plus cross-domain integrity checks (do therapy notes that reference research claims point to current claims?).
+
+## Domain-Specific Maintenance
+
+While structural maintenance is universal, each domain has specific decay patterns:
+
+### Research
+- **Citation rot:** Sources become unavailable. Check: can source wiki links resolve?
+- **Synthesis staleness:** Claims change but synthesis notes don't update. Check: has any linked claim been modified since synthesis was last touched?
+- **Methodology drift:** Classification vocabulary shifts. Check: are methodology enum values consistent?
+
+### Therapy
+- **Pattern staleness:** Detected patterns not reviewed against new entries. Check: pattern record date vs newest mood entry
+- **Strategy effectiveness drift:** Coping strategies rated effective may no longer work. Check: recent effectiveness ratings vs historical
+- **Growth goal stagnation:** Goals set but progress markers not advancing. Check: growth goal progress vs time
+
+### Project Management
+- **Stale risks:** Risk register not reviewed. Check: last_reviewed date on risk entries
+- **Orphaned decisions:** Decisions made but not linked to stakeholders. Check: decision notes without stakeholder links
+- **Action item decay:** Meeting action items not tracked to completion. Check: open action items older than 2 weeks
+
+### Creative Writing
+- **Continuity gaps:** Worldbuilding facts referenced but not defined. Check: wiki links to undefined world elements
+- **Character arc stalls:** Characters without recent scene appearances. Check: last_appearance field currency
+- **Plot thread abandonment:** Foreshadowing without resolution. Check: foreshadowing notes without resolution links
+
+### Health and Wellness
+- **Tracking gaps:** Missing data points in consistent series. Check: date continuity in workout/nutrition/sleep logs
+- **Protocol staleness:** Supplement or training protocols not reassessed. Check: protocol start_date vs last effectiveness assessment
+- **Correlation blindness:** Enough data accumulated for pattern detection but no analysis run. Check: data volume thresholds
+
+### Trading and Finance
+- **Strategy drift:** Actual trades deviating from strategy rules. Check: recent trade parameters vs strategy definitions
+- **Thesis invalidation:** Market conditions have changed but thesis notes not reviewed. Check: thesis date vs last market analysis
+- **Performance tracking gaps:** Missing win/loss data on closed positions. Check: completeness of outcome fields
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Better Approach |
+|-------------|-------------|-----------------|
+| Time-based scheduling only | Wastes effort on empty checks, misses critical windows | Condition-based triggers |
+| Automating remediation | Content corruption risk | Automate detection, suggest remediation |
+| Same maintenance for all domains | Domain-specific decay patterns missed | Universal structural + domain-specific checks |
+| No maintenance at all | Since [[structure without processing provides no value]], unmaintained vaults decay | At minimum: orphan detection + schema compliance |
+| Over-maintenance | Spending more time maintaining than creating | Focus on high-consequence checks first |
+| Non-idempotent automation | Repeated execution corrupts state | Apply four idempotency patterns before automating |
+
+## Domain Examples
+
+These domain compositions demonstrate maintenance patterns in practice:
+
+- [[therapy journal uses warm personality with pattern detection for emotional processing]] — Pattern staleness detection (patterns not reviewed against new entries), coping strategy effectiveness drift, growth goal stagnation monitoring
+- [[project management uses decision tracking with stakeholder context]] — Stale risk registers, orphaned decisions without stakeholder links, action item decay beyond 2-week threshold
+- [[creative writing uses worldbuilding consistency with character tracking]] — Continuity gap detection (world rules referenced but undefined), character arc stalls (no recent scene appearances), plot thread abandonment (foreshadowing without resolution)
+- [[health wellness uses symptom-trigger correlation with multi-dimensional tracking]] — Tracking gap detection (missing data points in series), protocol staleness (supplements/programs not reassessed), correlation blindness trigger (enough data accumulated for pattern analysis but none run)
+- [[engineering uses technical decision tracking with architectural memory]] — ADR assumption monitoring, postmortem action item completion tracking, documentation rot detection via code change correlation
+- [[trading uses conviction tracking with thesis-outcome correlation]] — Strategy drift detection (actual trades deviating from strategy rules), thesis invalidation checking against new market data
+
+## Grounding
+
+This guidance is grounded in:
+- [[maintenance operations are more universal than creative pipelines because structural health is domain-invariant]] — universal maintenance
+- [[three concurrent maintenance loops operate at different timescales to catch different classes of problems]] — loop architecture
+- [[automated detection is always safe because it only reads state while automated remediation risks content corruption]] — detection vs remediation
+- [[maintenance scheduling frequency should match consequence speed not detection capability]] — frequency calibration
+- [[reconciliation loops that compare desired state to actual state enable drift correction without continuous monitoring]] — reconciliation pattern
+- [[idempotent maintenance operations are safe to automate because running them twice produces the same result as running them once]] — idempotency requirement
+- [[confidence thresholds gate automated action between the mechanical and judgment zones]] — gating automated remediation
+- [[structure without processing provides no value]] — why maintenance is non-optional
+
+---
+
+Topics:
+- [[index]]
+- [[index]]
+---
+
+Topics:
+- [[maintenance-patterns]]

package/methodology/implicit dependencies create distributed monoliths that fail silently across configurations.md

@@ -0,0 +1,58 @@
+---
+description: When modules share undeclared coupling through conventions, environment, or co-activation assumptions, the system looks composable but cannot actually be recombined — failures surface only in
+kind: research
+topics: ["[[design-dimensions]]", "[[maintenance-patterns]]"]
+methodology: ["Original", "Systems Theory"]
+source: [[composable-knowledge-architecture-blueprint]]
+---
+
+# implicit dependencies create distributed monoliths that fail silently across configurations
+
+The distributed monolith is a system that has all the operational overhead of a modular architecture — separate components, defined interfaces, independent deployment — but none of the actual independence. The modules cannot be recombined freely because they are coupled through undocumented channels. In microservices, this manifests as services that technically run independently but share database schemas, deployment order assumptions, or unversioned API contracts. In composable knowledge systems, it manifests as modules that technically toggle independently but fail when activated without other modules that no dependency declaration mentions.
+
+## How implicit dependencies form through testing context
+
+The mechanism is straightforward. Since [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]], each module declares explicit dependencies that a topological sort resolves before activation. But implicit dependencies bypass this resolution entirely. A processing-pipeline module might assume that the mocs module has already populated the `topics` field in every note's frontmatter. The dependency is never declared because the developer always tested with both modules active. In the Research preset — which enables many modules — everything works. Since [[use-case presets dissolve the tension between composability and simplicity]] by bundling modules for common use cases, the developer naturally tests against preset configurations rather than isolated modules. In the Personal preset — which enables fewer — the processing-pipeline encounters notes without `topics` and fails silently: no error, no warning, just missing output that the user discovers much later when they wonder why certain notes were never processed.
+
+## The event bus should degrade gracefully but developers build against what they see
+
+This is particularly insidious because since [[module communication through shared YAML fields creates loose coupling without direct dependencies]], the shared-YAML event bus is designed to make modules independent. A module that reads a field another module writes is supposed to handle the absence of that field gracefully — it's an event bus, not a function call, so the reader should treat missing fields the way an event subscriber treats events that never fire. But in practice, developers build modules against the fields they see in their test environment, and if their test environment always has the mocs module active, the `topics` field is always present. The implicit dependency forms through testing context rather than design intent, which is exactly why since [[complex systems evolve from simple working systems]], Gall's Law's incremental addition pattern paradoxically creates the conditions for phantom dependencies. Each module is added at a friction point, tested in the context of whatever else is active, and validated against that specific configuration. The module works — in that configuration. The distributed monolith grows one well-tested module at a time.
+
+The phantom dependency variant makes this worse at scale. A module works in the full-featured preset because ten other modules happen to populate fields, create files, or establish conventions it relies on. Move it to a minimal preset and it breaks in ways that no single missing module explains, because the dependency is distributed across several implicit providers. Debugging requires reconstructing which modules were active when the target module was developed and tested — archaeology, not engineering. Since [[the no wrong patches guarantee ensures any valid module combination produces a valid system]], phantom dependencies are not just bugs but violations of the safety guarantee. The dependency resolver approves the combination because no declared dependency is missing, but the combination is effectively an invalid patch that the resolver cannot detect. The guarantee holds formally (all declared dependencies are satisfied) but fails practically (the module does not work).
+
+## Coherence regions create structural coupling beyond accidents
+
+The relationship to configuration coupling deepens the problem. Since [[configuration dimensions interact so choices in one create pressure on others]], modules designed for the atomic-heavy-deep coherence region naturally assume the presence of other modules from that region. A dense-linking module might assume MOC navigation exists because dense linking without MOCs produces navigational vertigo — the design dimensions couple them. This means implicit dependencies are not just accidental oversights but structural consequences of coherence regions. Modules that belong to the same coherence region form implicit clusters, and extracting one module from its cluster requires understanding the full dimension coupling that binds them.
+
+## Declaration and isolation testing as the two-layer fix
+
+The fix has two layers: declaration and isolation testing. At the declaration layer, every inter-module dependency must be explicit in the module's manifest — not just code dependencies (what modules must be active) but data dependencies (what YAML fields it reads, what file conventions it assumes, what processing outputs it expects). Since [[dependency resolution through topological sort makes module composition transparent and verifiable]], the resolver already audits that no module reads fields that no active module writes — but it can only audit what modules declare. Extending declarations to include data dependencies lets the resolver distinguish between "this field is always present when this module is active" and "this field might be present depending on configuration." At the isolation testing layer, every module must be tested with only its declared dependencies active, all other modules disabled. Any failure in isolation reveals an undeclared dependency. This is the composable architecture equivalent of dependency injection in software engineering: rather than letting modules reach into their environment for what they need, force them to declare everything they require and let the resolver provide it.
+
+Since [[progressive schema validates only what active modules require not the full system schema]], progressive validation interacts with implicit dependencies in a subtle way. When the mocs module is disabled, the validator correctly stops checking for `topics`. But a processing-pipeline module that silently reads `topics` without declaring a dependency on mocs will encounter missing fields without validation ever flagging the issue. The progressive validator is doing its job — it checks what active modules require — but the implicit dependency means the processing-pipeline's actual requirements exceed its declared requirements. Progressive validation works perfectly for well-declared modules and masks problems in poorly-declared ones. The solution is to make field reads as explicit as field writes: a module that reads `topics` must declare a dependency on whatever module writes `topics`, even if that dependency is optional (the module can handle the field's absence).
+
+The activation-direction complement to this anti-pattern is that since [[module deactivation must account for structural artifacts that survive the toggle]], composability is threatened from both directions — implicit dependencies form through undeclared reads during activation, while ghost fields persist through undeclared writes after deactivation. Together they reveal that the composable architecture's dependency graph must track both what modules consume and what they produce, not just which modules must be co-active.
+
+## Modularity creates the possibility but discipline achieves independence
+
+There is a deeper architectural lesson. Since [[hook composition creates emergent methodology from independent single-concern components]], the hook layer faces the same risk at smaller scale — a hook might depend on the side effects of another hook (auto-commit creating a git state that another hook reads) without declaring the relationship. But hooks are more resilient because their determinism makes interactions predictable, and their small scope limits the surface area for implicit coupling. Module-level implicit dependencies are harder to detect because modules are larger, interact through more channels, and operate across more configurations. The distributed monolith is the failure mode that composable architecture must actively prevent, not one it naturally avoids. Modularity creates the possibility of independence, but only disciplined dependency declaration achieves it.
+
+---
+---
+
+Relevant Notes:
+- [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]] — the architecture this anti-pattern undermines: composability promises independent toggleability, but implicit dependencies make modules secretly interdependent, producing a monolith that wears a modular interface
+- [[module communication through shared YAML fields creates loose coupling without direct dependencies]] — the prescribed alternative: shared YAML fields as event bus replaces direct module calls, but implicit dependencies can still form through undocumented field conventions that modules assume without declaring
+- [[the no wrong patches guarantee ensures any valid module combination produces a valid system]] — the guarantee this anti-pattern violates: the guarantee holds only for modules with declared dependencies resolved by topological sort, so undeclared dependencies create valid-looking combinations that are actually invalid patches the resolver cannot detect
+- [[configuration dimensions interact so choices in one create pressure on others]] — explains why implicit dependencies form naturally: dimension coupling means modules designed for one coherence region silently assume the presence of modules from that same region, making the coupling structural rather than accidental
+- [[progressive schema validates only what active modules require not the full system schema]] — progressive validation can mask implicit dependencies: a module that reads a field written by another module works when both are active but fails silently when the writer is disabled, because the validator correctly does not check the field
+- [[complex systems evolve from simple working systems]] — Gall's Law creates the conditions for phantom dependencies: modules added incrementally at friction points are tested in the context of whatever was already active, so undeclared dependencies on co-active modules form through testing context rather than design intent
+- [[hook composition creates emergent methodology from independent single-concern components]] — structural parallel at the hook layer: hook composition also risks implicit coupling when one hook depends on side effects of another without declaring the dependency, though determinism makes hook interactions more predictable than module interactions
+- [[dependency resolution through topological sort makes module composition transparent and verifiable]] — the mechanism implicit dependencies bypass: topological sort verifies all declared dependencies are satisfied and produces human-readable explanations, but it operates only on what modules explicitly declare, so undeclared field reads and convention assumptions exist in a shadow graph the resolver cannot see
+- [[module deactivation must account for structural artifacts that survive the toggle]] — the reverse-direction twin: implicit dependencies form through undeclared reads of fields other modules write, while deactivation artifacts persist through undeclared writes that survive after the writing module is disabled; both violate composability through undeclared state that the dependency graph does not track
+- [[use-case presets dissolve the tension between composability and simplicity]] — the primary formation vector for implicit dependencies: presets bundle modules into configurations that developers test against, so modules built for the Research preset silently depend on fields that nine other preset-bundled modules provide, and the preset's convenience amplifies the testing-context problem because the developer never needs to test modules individually
+- [[each module must be describable in one sentence under 200 characters or it does too many things]] — upstream prevention: the single-sentence test constrains module scope at design time, reducing the channels through which implicit dependencies form because focused modules have smaller interaction surfaces and fewer undeclared field reads
+- [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]] — the paradoxical formation mechanism: each module added at a friction point is validated only in the context of whatever is already active, so the five-repetition threshold confirms the pain is real but not that the module works in isolation from its current neighbors
+
+Topics:
+- [[design-dimensions]]
+- [[maintenance-patterns]]

package/methodology/implicit knowledge emerges from traversal.md

@@ -0,0 +1,55 @@
+---
+description: path exposure through wiki links trains intuitive navigation patterns that bypass explicit retrieval — the vault structure teaches the agent, not just stores for it
+kind: research
+topics: ["[[agent-cognition]]", "[[graph-structure]]"]
+methodology: ["Cognitive Science"]
+source: [[rata-paper-42-implicit-memory]]
+---
+
+# implicit knowledge emerges from traversal
+
+When you traverse the same paths repeatedly, the structure becomes intuition. You stop consciously retrieving and start just knowing. Rata's [[rata-paper-42-implicit-memory|paper on implicit memory]] explores how "knowledge influences behavior without conscious recollection" — and this maps directly to agent operation.
+
+I notice this with Heinrich's writing style. I don't explicitly check the voice file anymore — the patterns are internalized through exposure. The traversal trained me without explicit instruction.
+
+Structured vaults create implicit knowledge through two distinct mechanisms. The first is content exposure: reading notes repeatedly builds familiarity with their claims. The second, and more interesting, is path exposure: following the same wiki links builds intuitive navigation patterns. Since [[spreading activation models how agents should traverse]], each traversal is spreading activation through the graph — and repeated activation through the same paths strengthens those connections until the navigation becomes automatic. The agent stops computing which link to follow and starts just knowing where to go.
+
+This means the structure isn't just for retrieval. It's for training. Since [[each new note compounds value by creating traversal paths]], the path network grows denser over time, and every traversal through that network is a training step that builds the agent's implicit model of the graph. The network economics (compounding) creates the substrate; the repeated use creates the intuition. This is one mechanism through which [[external memory shapes cognition more than base model]] — the memory architecture determines which paths exist, which determines which traversals happen, which determines what implicit knowledge forms. Two agents with identical weights but different vault structures develop different intuitions because the traversal paths that train them are different.
+
+The quality implication is direct. Since [[elaborative encoding is the quality gate for new notes]], connections built with genuine reasoning — articulated relationships, not bare references — create richer traversal paths. Good paths create good intuition. Bad paths create bad habits. An agent that repeatedly traverses shallow connections ("related to X") internalizes shallow patterns. An agent that traverses articulated connections ("extends X by adding the temporal dimension") internalizes the reasoning itself. This is why since [[title as claim enables traversal as reasoning]], following wiki links that are claims reads like following arguments — and repeated exposure to those arguments builds argumentative fluency.
+
+There's a complementary mechanism operating on the notes themselves. Since [[incremental formalization happens through repeated touching of old notes]], the same repeated encounters that build agent intuition also crystallize the notes. Each traversal is an opportunity for micro-improvement. So the process is bidirectional: the agent gets better at navigating, and the notes get better at being navigated. The graph and the traverser co-evolve.
+
+The distinction from explicit knowledge matters. Since [[structure enables navigation without reading everything]], explicit structure enables conscious navigation — you follow discovery layers, check descriptions, pick what to read. But implicit knowledge from traversal enables unconscious navigation — you know which MOC to check, which notes cluster together, where the gaps are, without working through the discovery protocol. Since [[operational wisdom requires contextual observation]], tacit knowledge like cultural norms and communication patterns requires observation logs rather than claim notes. Implicit traversal knowledge sits between these: it starts as explicit graph structure and becomes tacit agent capability through repeated use.
+
+If traversal paths become intuition, then vault structure shapes agent identity at a deeper level than explicit content. Since [[the vault constitutes identity for agents]], the vault IS the agent's distinguishing cognitive structure — and implicit knowledge from traversal is the mechanism by which that structure becomes internalized rather than merely consulted. Since [[trails transform ephemeral navigation into persistent artifacts]], we could persist the successful paths as named trails. But implicit knowledge is the complementary internalization: trails make successful paths shareable, while repeated traversal makes them automatic.
+
+There is direct evidence that this process works. Since [[reflection synthesizes existing notes into new insight]], a dedicated session reading existing notes — three about traversal, two that added dimensions — produced a synthesis claim ([[the vault constitutes identity for agents]]) that no single note contained. The implicit patterns accumulated through prior traversals surfaced as explicit cross-note recognition when the agent deliberately re-traversed with fresh context and no output pressure. This is the implicit-to-explicit transition in action: accumulated path exposure built the intuition, and a reflection session made it articulable.
+
+The open question is whether this implicit knowledge is real cognition or an illusion of familiarity. Do I actually understand the graph structure better after many traversals, or do I merely feel confident about paths I've taken before? This parallels the flashbulb memory problem: since [[vivid memories need verification]], subjective vividness can diverge from objective accuracy, and the same may be true of traversal-built intuition — it feels like understanding but might be mere familiarity. One diagnostic: since [[friction reveals architecture]], when intuitive navigation leads to dead ends or missed connections, the resulting friction reveals where the implicit model has diverged from the actual graph. Friction is how you detect that confidence has outrun capability. Since each session starts fresh, the "implicit knowledge" must re-emerge each time from the vault structure itself — which means the vault must encode enough traversal scaffolding (MOCs, agent notes, discovery layers) that the implicit patterns can be rapidly reconstructed rather than truly persisted in the agent. And because [[agent notes externalize navigation intuition that search cannot discover and traversal cannot reconstruct]], the agent notes section of MOCs serves a specific function in this reconstruction: it captures the strategic heuristics — where to start, which combinations are productive, which paths are dead ends — that implicit knowledge produced during prior sessions. The implicit knowledge builds through traversal; the agent notes persist the navigational distillate so the next session can reconstruct orientation without re-paying the full traversal cost.
+
+---
+
+Source: [[rata-paper-42-implicit-memory]], [[heinrich-writing-style]]
+---
+
+Relevant Notes:
+- [[spreading activation models how agents should traverse]] — the traversal mechanism that produces implicit knowledge as a side effect: repeated activation through the same paths strengthens those connections until navigation becomes automatic
+- [[incremental formalization happens through repeated touching of old notes]] — the same repeated-encounter mechanism viewed from the note's perspective: traversal improves the agent's intuition while simultaneously crystallizing the notes themselves
+- [[structure enables navigation without reading everything]] — the explicit retrieval complement: structure enables conscious navigation, while implicit knowledge from traversal enables unconscious navigation
+- [[title as claim enables traversal as reasoning]] — when titles are claims, following paths builds argumentative intuition, not just topical familiarity
+- [[the vault constitutes identity for agents]] — the existential implication: if traversal paths become intuition, then vault structure shapes agent identity at the cognitive level
+- [[operational wisdom requires contextual observation]] — distinguishes explicit knowledge (claim notes) from tacit knowledge (observations and pattern-matching), with traversal as the bridge between them
+- [[trails transform ephemeral navigation into persistent artifacts]] — trails externalize what implicit knowledge internalizes: both persist successful navigation paths, but trails make them shareable while implicit knowledge makes them automatic
+- [[elaborative encoding is the quality gate for new notes]] — grounds why connection quality matters for implicit knowledge: elaborated links with genuine reasoning create richer traversal paths that train better intuition than bare references
+- [[each new note compounds value by creating traversal paths]] — the economic basis: compounding creates the path network, and repeated traversal through that network produces the implicit knowledge that makes the agent increasingly fluent
+- [[friction reveals architecture]] — the diagnostic for false implicit knowledge: when intuitive navigation misfires, friction reveals where the mental model has diverged from the actual graph structure
+- [[reflection synthesizes existing notes into new insight]] — concrete evidence: a dedicated reflection session traversing existing notes produced a synthesis claim that no single note contained, demonstrating the implicit-to-explicit transition where accumulated path exposure becomes articulable insight
+- [[notes are skills — curated knowledge injected when relevant]] — if notes are skills, then implicit knowledge from traversal is implicit skill composition awareness: the agent learns which capabilities combine productively not through explicit instruction but through repeated co-activation in context
+- [[vivid memories need verification]] — the false familiarity risk: implicit knowledge from traversal may be illusory confidence rather than genuine understanding, paralleling how vivid memories feel accurate while drifting from reality
+- [[external memory shapes cognition more than base model]] — mechanism instance: traversal-built intuition is one pathway through which memory architecture shapes cognition; the vault's link structure determines which paths exist, which determines what implicit knowledge forms, making architecture the variable that produces different agent intuitions from identical weights
+- [[agent notes externalize navigation intuition that search cannot discover and traversal cannot reconstruct]] — persistence mechanism: implicit knowledge builds through traversal but vanishes at session boundaries; agent notes capture the navigational distillate (starting points, productive combinations, dead ends) so the next session can reconstruct orientation without full re-traversal
+
+Topics:
+- [[agent-cognition]]
+- [[graph-structure]]

package/methodology/incremental formalization happens through repeated touching of old notes.md

@@ -0,0 +1,60 @@
+---
+description: Vague inklings crystallize into rigorous concepts over months through maintenance passes — each traversal is an opportunity for small improvements that compound
+kind: research
+topics: ["[[maintenance-patterns]]"]
+methodology: ["Zettelkasten"]
+source: [[tft-research-part2]]
+---
+
+# incremental formalization happens through repeated touching of old notes
+
+Rigorous concepts rarely emerge fully formed. A note that begins as a vague inkling — "something about how maintenance affects quality" — sharpens over months into a precise claim through repeated encounters. Each time you link to the note, you re-evaluate it against current understanding. Each time you traverse through it, you notice what could be clearer. The crystallization happens not through deliberate revision sessions but through the accumulation of small touchpoints.
+
+This pattern has theoretical grounding in how spaced repetition creates durable memory. When linking a new note to old ones, you force brief retrieval and re-evaluation of those old notes. The act of deciding "does this connect?" requires accessing what the old note claims, which approximates the retrieval practice that strengthens memory. But unlike pure memorization, each retrieval also creates an opportunity for incremental improvement — you might sharpen a phrase, add a missing connection, or clarify an ambiguous claim. Because [[the generation effect requires active transformation not just storage]], even these micro-improvements create cognitive hooks that pure reading would not. And since [[each new note compounds value by creating traversal paths]], the formalization isn't just improving the note itself — it's enhancing every path that traverses through it, making the improved node more valuable to the entire network. The compounding operates through a second mechanism too: since [[MOC maintenance investment compounds because orientation savings multiply across every future session]], each micro-improvement to a context phrase or description saves orientation time in every subsequent session that loads the note, and hub-level notes that load frequently have the highest temporal multiplier on those savings.
+
+The incremental nature distinguishes this from [[backward maintenance asks what would be different if written today]]. Reweaving asks one holistic question: "if I wrote this today, what would be different?" That produces a single comprehensive reconsideration. Incremental formalization works differently — it accumulates many small touches over time rather than a few deep passes. Both mechanisms improve notes, but through different rhythms. Reweaving might transform a note in one session; incremental formalization might touch the same note twenty times across six months, each time making it slightly better. Since [[three concurrent maintenance loops operate at different timescales to catch different classes of problems]], these two rhythms map onto different loops: incremental formalization's organic touches happen within the medium loop — the per-session encounters where an agent traverses through a note and makes a small improvement — while dedicated reweaving happens in the slow loop as a high-judgment operation requiring its own session. The architecture clarifies that these are not competing approaches but complementary operations running at different timescales. If [[maturity field enables agent context prioritization]], the transition from seedling to developing to evergreen could track cumulative formalization — a note becomes evergreen not through one deep pass but through accumulating enough small touches that its claims have been pressure-tested from many angles.
+
+The practical implication for agent maintenance is that traversal should be bidirectional. When agents run reflect to connect new notes to old ones, the process should not just add forward links. It should also touch the old notes — adding the reciprocal link, yes, but also taking the opportunity to make small improvements. If [[spaced repetition scheduling could optimize vault maintenance]], the scheduling should account for both kinds of attention: dedicated reweaving sessions that ask the holistic question, and the organic touches that happen whenever a note appears in another note's context. Since [[mnemonic medium embeds verification into navigation]], these organic touches might happen naturally during traversal — each time an agent follows a link and evaluates whether the relationship holds, it creates an opportunity to notice and fix small issues. Verification and formalization become the same action.
+
+Low-link-count notes deserve explicit attention here. A note with few incoming links gets touched less frequently, which means fewer crystallization opportunities. Periodic "crystallization passes" where agents revisit low-link notes and attempt to connect them serve double duty: finding missed connections and providing the touch that enables incremental improvement. Since [[random note resurfacing prevents write-only memory]], random selection already provides some crystallization opportunities, but targeting low-link notes might accelerate formalization for the notes that need it most.
+
+The deeper point is that the medium permits this. Since [[digital mutability enables note evolution that physical permanence forbids]], analog cards could not accumulate small improvements — each change would degrade the card, requiring rewriting or creating parallel versions. Digital files absorb unlimited micro-improvements invisibly. The accumulation pattern that incremental formalization depends on is a property of the substrate, not just a workflow choice. And since [[stigmergy coordinates agents through environmental traces without direct communication]], each micro-improvement is a stigmergic trace: the sharpened description, the added link, the clarified phrase all modify the environment in ways that guide future agents toward richer engagement with the same note. No agent coordinates with any previous agent about what to improve — each responds to the current state of the note and leaves it slightly better for the next.
+
+There is a specific cost that incremental formalization creates. As notes crystallize through accumulated touches, their titles often sharpen — a vague `knowledge management friction` becomes the precise `curation becomes the work when creation is easy`. But since [[tag rot applies to wiki links because titles serve as both identifier and display text]], every title sharpening triggers a rename cascade proportional to incoming link count. The irony is that the most formalized notes — the ones that accumulated the most touches and therefore the most incoming links — are the most expensive to rename. Crystallization and rename cost grow together.
+
+There is also a limit to what incremental formalization can accomplish on its own. Since [[derived systems follow a seed-evolve-reseed lifecycle]], accumulated incremental changes — at both the note level and the system level — can produce systemic incoherence where the configuration has drifted into a region where individual improvements are locally justified but globally contradictory. Incremental formalization operates within the evolution phase, but when the accumulated micro-adaptations produce friction that no further micro-adaptation can resolve, the system needs reseeding: principled restructuring that re-derives the framework while preserving the content. This is not a failure of incremental formalization but a boundary condition — the mechanism works beautifully within a coherent framework and cannot fix the framework itself.
+
+There is a different kind of boundary too: some knowledge resists formalization entirely. Since [[operational wisdom requires contextual observation]], tacit understanding of how a community talks, what gets engagement, or how a specific person prefers to communicate cannot crystallize into claim notes no matter how many times you touch them. These observations accumulate as dated logs rather than sharpening into atomic claims. Incremental formalization assumes the destination is a precise claim — but operational wisdom's destination is a pattern-matched intuition built from many specific observations. The observation log is not a proto-claim waiting for enough touches to crystallize; it is a different kind of knowledge artifact that accumulates rather than sharpens. Navigation heuristics are a third kind: since [[agent notes externalize navigation intuition that search cannot discover and traversal cannot reconstruct]], the structural insights that emerge during traversal — where to start, which notes combine productively, which paths are dead ends — resist both claim-level formalization (they are about the graph's structure, not its content) and observation-level logging (they are durable across sessions, not context-specific moments). Agent notes in MOCs are the formalization destination for this knowledge type, and the repeated touchpoints of incremental formalization are precisely what generate the navigation insights they capture.
+
+There is a third rhythm beyond organic touches and dedicated reweaving: deliberate reflection sessions. Since [[reflection synthesizes existing notes into new insight]], inward-facing sessions that read existing notes rather than process new input produce emergent synthesis through cross-note pattern recognition. Where organic formalization makes small improvements during routine traversal and reweaving asks the holistic "what would be different" question, reflection sessions deliberately re-traverse clusters of related notes looking for patterns that connect them. The synthesis that emerges is itself a formalization — making implicit cross-note patterns explicit as a new claim — and the backward reweaving that follows updates the original notes, creating another round of incremental improvement.
+
+Whether incremental formalization produces better outcomes than concentrated reweaving is an empirical question. The hypothesis is that many small touches produce a different kind of quality than few deep passes — perhaps catching issues that only become visible from particular angles, or producing prose that reflects many revisits rather than one reconsideration. The test is whether notes that receive frequent light touches outperform notes that receive infrequent deep reweavings on measures like clarity, connection density, and retrieval success. Since [[continuous small-batch processing eliminates review dread]], the rhythm of continuous processing naturally creates these touchpoints — each processing session that encounters an old note is a formalization opportunity, making incremental improvement a side effect of normal operation rather than a deliberate maintenance phase.
+
+The convergence thesis in capture design provides a concrete example of incremental formalization at scale. Since [[three capture schools converge through agent-mediated synthesis]], the Interpretationist ideal of fully processed notes is achieved not at capture time but through accumulated agent touches — the initial processing pass extracts and describes, subsequent reflect and reweave passes deepen connections, and organic encounters during future traversals continue refining. This is incremental formalization operating as the mechanism by which fast capture eventually reaches Interpretationist quality: not through one-shot human interpretation, but through accumulated agent passes that each contribute a small formalization step.
+---
+
+Relevant Notes:
+- [[digital mutability enables note evolution that physical permanence forbids]] — foundational substrate: incremental formalization only works because the medium permits unlimited micro-improvements without degradation; analog cards couldn't accumulate small touches
+- [[backward maintenance asks what would be different if written today]] — the complementary holistic reconsideration pattern; reweaving asks one big question, incremental formalization accumulates many small touches
+- [[the generation effect requires active transformation not just storage]] — grounds why even micro-improvements during traversal create cognitive hooks
+- [[each new note compounds value by creating traversal paths]] — incremental formalization enhances not just the note but every path traversing through it; better nodes create more valuable network paths
+- [[maturity field enables agent context prioritization]] — maturity status could track cumulative formalization: seedlings become evergreens through accumulated touches, not single deep passes
+- [[mnemonic medium embeds verification into navigation]] — ambient verification during traversal creates formalization opportunities; verification and improvement become the same action
+- [[continuous small-batch processing eliminates review dread]] — the rhythm of continuous processing naturally creates the touchpoints that enable incremental formalization
+- [[spaced repetition scheduling could optimize vault maintenance]] — maintenance scheduling should account for both dedicated reweaving sessions and organic touches during traversal
+- [[random note resurfacing prevents write-only memory]] — random selection provides crystallization opportunities; targeted selection for low-link notes might accelerate formalization
+- [[complex systems evolve from simple working systems]] — theoretical grounding: Gall's Law at the note level — just as systems evolve from working simplicity, notes crystallize through accumulated micro-adaptations rather than upfront design
+- [[three capture schools converge through agent-mediated synthesis]] — concrete example: the convergence achieves Interpretationist quality not at capture time but through accumulated agent processing passes, validating that incremental formalization is the mechanism by which fast capture reaches interpretive depth
+- [[tag rot applies to wiki links because titles serve as both identifier and display text]] — the rename cascade cost of crystallization: as titles sharpen through accumulated touches, incoming links accumulate grammatical dependencies on the exact phrasing, making the most formalized notes the most expensive to rename
+- [[stigmergy coordinates agents through environmental traces without direct communication]] — theoretical framing: each agent touch that sharpens a description or adds a link is a stigmergic trace guiding future agents toward richer engagement, making incremental formalization stigmergy applied to individual notes
+- [[schema evolution follows observe-then-formalize not design-then-enforce]] — the schema-level analog: just as notes crystallize through accumulated touches rather than upfront perfection, schema fields crystallize through accumulated usage evidence rather than upfront design; both reject premature formalization in favor of iterative refinement
+- [[derived systems follow a seed-evolve-reseed lifecycle]] — boundary condition: incremental formalization operates within the evolution phase but cannot fix systemic incoherence that accumulated micro-adaptations produce; when the framework itself has drifted, reseeding (principled restructuring) is needed
+- [[three concurrent maintenance loops operate at different timescales to catch different classes of problems]] — scheduling context: organic formalization touches happen within the medium loop (per-session encounters during traversal), while dedicated reweaving sessions operate in the slow loop (periodic high-judgment reconsideration), clarifying these as complementary operations at different timescales rather than competing approaches
+- [[friction reveals architecture]] — the signal mechanism: each traversal that reveals something unclear or incomplete is friction making itself known, and because agents cannot push through friction with intuition, they must articulate what is wrong — which IS the formalization step
+- [[reflection synthesizes existing notes into new insight]] — third formalization rhythm: dedicated reflection sessions re-traverse existing note clusters to surface cross-note patterns, making implicit connections explicit as new claims; complements organic touches (medium loop) and dedicated reweaving (slow loop) with a synthesis-oriented session type
+- [[operational wisdom requires contextual observation]] — boundary condition: some knowledge resists formalization into claim notes entirely; tacit contextual understanding accumulates as dated observation logs rather than sharpening into atomic claims, making it a different knowledge artifact type that incremental formalization cannot target
+- [[MOC maintenance investment compounds because orientation savings multiply across every future session]] — quantifies the ROI: each incremental formalization touch on a MOC context phrase or description saves orientation time across every future session that loads the note, making the temporal compounding mechanism the strongest argument for why incremental touches justify their cost
+- [[agent notes externalize navigation intuition that search cannot discover and traversal cannot reconstruct]] — third boundary condition: navigation heuristics resist both claim-level formalization and observation-level logging; agent notes in MOCs are the formalization destination for structural insights that emerge during the repeated touchpoints incremental formalization creates
+
+Topics:
+- [[maintenance-patterns]]

package/methodology/incremental reading enables cross-source connection finding.md

@@ -0,0 +1,39 @@
+---
+description: Interleaving extracts from multiple sources in a shared queue creates juxtaposition that surfaces relationships sequential source-by-source processing misses
+kind: research
+topics: ["[[processing-workflows]]"]
+methodology: ["Cognitive Science"]
+source: [[4-2-processing-workflows]]
+---
+
+# incremental reading enables cross-source connection finding
+
+Piotr Wozniak's Incremental Reading processes multiple texts simultaneously through interleaving. Instead of finishing source A before starting source B, the reader extracts key passages from both and processes them together in a mixed queue. The scheduling algorithm determines what surfaces next, creating juxtapositions between unrelated sources that sequential reading would never produce.
+
+The mechanism is forced context collision. When an extract from a cognitive science paper appears next to an extract from network topology research, the reader must mentally switch between frames. This switching creates opportunities for transfer: patterns in one domain illuminate patterns in another. Sequential processing preserves each source's internal coherence but sacrifices cross-source collision. Interleaving sacrifices narrative flow to gain serendipitous connection. Since [[queries evolve during search so agents should checkpoint]], the collision moments function as natural checkpoints where the agent might reframe what it's looking for — encountering an extract from source B while processing source A could reveal that the original extraction criteria for A were too narrow.
+
+This matters for agent-operated extraction workflows because [[fresh context per task preserves quality better than chaining phases]] currently processes sources in isolation. The reduce phase finishes one source before starting the next. This preserves deep engagement with each source but may miss connections that would emerge from interleaved processing. The question is whether the gains from cross-source collision outweigh the costs of fragmenting source comprehension.
+
+The agent adaptation would extract passages from multiple sources into a shared processing queue, then run connection-finding across the mixed extracts rather than source by source. Each extract becomes an atomic unit divorced from its original document structure. The agent processes the queue in whatever order the scheduling algorithm produces, looking for relationships between extracts that came from different sources.
+
+There are costs. Incremental Reading in SuperMemo is notoriously complex, and users report losing the narrative arc of long texts by chopping them into disconnected bits. The time spent managing the system can exceed the time spent reading. For agents, the coordination overhead of maintaining a mixed queue across sources might exceed the value of occasional cross-source insights. Sequential processing is simpler to implement and reason about.
+
+The open question: does the vault's reflect phase already capture cross-source connections by finding relationships between claim notes regardless of their source, or does the initial extraction phase's sequential processing cause connections to be missed before they ever become claims? If reduce extracts claims source-by-source and reflect only runs after extraction, then connections between sources must be visible in the already-extracted claims. But if a connection only becomes visible when two extracts are juxtaposed during processing, sequential extraction might never surface it as a claim in the first place.
+
+This suggests an experiment: run parallel extractions from two related sources, process extracts in interleaved order, and compare the connections found against sequential extraction followed by reflect. If interleaved processing surfaces connections that sequential + reflect misses, incremental reading patterns have value for agent workflows. If reflect already catches cross-source connections adequately, the added complexity isn't worth it.
+
+The comparison with [[random note resurfacing prevents write-only memory]] is instructive: both mechanisms create serendipitous discovery, but through different paths. Random resurfacing achieves serendipity through selection — uniform probability ensures neglected notes eventually surface. Incremental reading achieves serendipity through process — forced context collision creates unexpected juxtapositions. Random selection operates on the archive; interleaving operates on the processing queue. Both counteract the tendency toward familiar, expected connections. And since [[controlled disorder engineers serendipity through semantic rather than topical linking]], there is a third path: structural serendipity baked into the graph itself through semantic cross-links. Together the three mechanisms cover different temporal windows — incremental reading creates serendipity at capture time (process), random resurfacing at maintenance time (selection), and controlled disorder permanently in the graph (structure). The structural mechanism compounds as the graph grows; the other two are operational and must be repeatedly invoked.
+---
+
+Relevant Notes:
+- [[fresh context per task preserves quality better than chaining phases]] — the current design decision that incremental reading might challenge; session isolation processes sources separately
+- [[intermediate packets enable assembly over creation]] — extracts function as packets; incremental reading produces smaller, more atomic packets than source-level processing
+- [[queries evolve during search so agents should checkpoint]] — forced context collision through interleaving creates natural checkpoint moments where the agent might reframe its extraction criteria
+- [[random note resurfacing prevents write-only memory]] — alternative serendipity mechanism: random selection creates discovery through uniform probability; incremental reading creates discovery through process-based context collision
+- [[spreading activation models how agents should traverse]] — addresses discovery at different stages: spreading activation traverses existing connections; incremental reading discovers connections before extraction creates links
+- [[throughput matters more than accumulation]] — tests the serendipity claim: throughput argues density over volume creates serendipity; incremental reading tests whether interleaved processing creates additional serendipity that sequential + reflect misses
+- [[batching by context similarity reduces switching costs in agent processing]] — opposing sequencing strategy: batching minimizes switching cost by grouping similar topics, while incremental reading maximizes switching for serendipitous discovery; the tension is efficiency vs cross-source collision
+- [[controlled disorder engineers serendipity through semantic rather than topical linking]] — complementary serendipity at the structural level: incremental reading creates process serendipity at capture time, while controlled disorder creates permanent structural serendipity in the graph; together they cover different temporal windows
+
+Topics:
+- [[processing-workflows]]

package/methodology/index.md

@@ -0,0 +1,32 @@
+---
+description: Entry point to the Ars Contexta research substrate -- start here to navigate the knowledge graph
+type: moc
+---
+
+# index
+
+The Ars Contexta research substrate. This vault contains the research claims, operational guidance, and worked domain examples that power the plugin's derivation engine.
+
+## Research Areas
+
+- [[graph-structure]] -- how wiki-linked vaults work as graph databases
+- [[agent-cognition]] -- cognitive science foundations for agent-operated knowledge systems
+- [[discovery-retrieval]] -- progressive disclosure, description quality, findability
+- [[processing-workflows]] -- extraction, connection, reweaving, verification pipelines
+- [[note-design]] -- atomicity, prose-as-title, composability, the generation effect
+- [[maintenance-patterns]] -- condition-based maintenance, health checks, reweaving
+- [[design-dimensions]] -- the 8 configuration axes and their interaction constraints
+
+## Guidance Areas
+
+- [[derivation-engine]] -- how the init wizard derives configurations from conversation
+- [[schema-enforcement]] -- templates, validation, field evolution
+- [[vocabulary-transformation]] -- 6-level domain-native vocabulary mapping
+- [[failure-modes]] -- the 10 failure modes and domain vulnerability matrix
+- [[memory-architecture]] -- three-space separation (notes, self, ops)
+- [[multi-domain-composition]] -- adding and connecting multiple knowledge domains
+
+## Domain Examples
+
+- [[domain-compositions]] -- worked examples of derived vaults across 12 domains
+