arscontexta 0.6.0

package/methodology/compose multi-domain systems through separate templates and shared graph.md

@@ -0,0 +1,372 @@
+---
+description: How domains compose when users have multiple use cases — shared infrastructure, separate schemas, and the graph as the integration layer
+kind: guidance
+status: active
+topics: ["[[multi-domain-composition]]"]
+---
+
+# compose multi-domain systems through separate templates and shared graph
+
+Most users don't fit a single domain. A researcher also manages projects. A therapist tracks their own health. An engineer has personal goals. Since [[multi-domain systems compose through separate templates and shared graph]], the plugin must generate vaults that serve multiple domains without conflict.
+
+This doc tells the plugin HOW to compose domains and where composition breaks down.
+
+## Why Compose Instead of Separate Vaults
+
+The temptation with multiple use cases is to create separate vaults — one for research, one for personal life, one for projects. This feels clean but destroys the primary value of a knowledge graph: cross-domain connections.
+
+Separate vaults miss connections that only exist across domain boundaries:
+
+- A research finding about cognitive load directly explains why your therapy patient struggles with a specific intervention
+- Your project management estimation patterns correlate with your personal health data during crunch periods
+- Your creative writing research into medieval trade routes connects to your personal finance mental model
+
+These connections are invisible in separate vaults because the graph edges that would connect them don't exist. The value of a composed system comes precisely from connections that separate systems would miss.
+
+The cost of composition is maintenance complexity. The benefit is connection density. Since [[cross-links between MOC territories indicate creative leaps and integration depth]], the connections justify the complexity.
+
+## The Five Composition Rules
+
+Every multi-domain system must follow these five rules. They are the invariants that prevent domain interference while enabling cross-domain value.
+
+### Rule 1: Separate Templates, Shared Graph
+
+Each domain gets its own note templates with domain-specific schemas. But all notes live in the same graph (same wiki link namespace, same connection space). Templates isolate structure; the graph unifies meaning.
+
+### Rule 2: No Field Name Conflicts
+
+When two domains use the same field name with different semantics, prefix to disambiguate. Research `status: preliminary | open | dissolved` and PM `status: not-started | in-progress | done` become `research_status` and `project_status`. Universal fields (`description`, `topics`) maintain consistent semantics.
+
+### Rule 3: Cross-Domain Reflect
+
+The reflect phase searches across ALL domains, not just the domain of the new note. A therapy insight might connect to a research claim. A project decision might link to an engineering ADR. Connection-finding that stays within domain boundaries defeats the purpose of composition.
+
+### Rule 4: Domain-Specific Processing
+
+The process step (reduce phase) adapts per domain. Research extraction differs from therapy pattern detection which differs from PM decision documentation. Since [[every knowledge domain shares a four-phase processing skeleton that diverges only in the process step]], the pipeline skeleton is shared but each domain's process step is distinct.
+
+### Rule 5: Progressive Context Loading
+
+The context file loads universal methodology first, then loads domain-specific configuration only when the user is working in that domain. A multi-domain context file that dumps all domain configurations at once wastes context window space. Progressive loading means the agent gets full depth in the active domain without noise from inactive ones.
+
+## The Composition Principle
+
+Domains compose through three layers:
+
+| Layer | Shared or Separate | Why |
+|-------|--------------------|-----|
+| **Infrastructure** | Shared | One inbox, one context file, one processing pipeline, one maintenance system |
+| **Schemas** | Separate per domain | Each domain has its own note types with domain-specific fields |
+| **Graph** | Shared | Cross-domain connections are where the real value lives |
+
+The infrastructure layer runs once. The schema layer runs per domain. The graph layer connects everything.
+
+## What's Shared
+
+### Inbox
+One capture zone for all domains. Content gets routed to the correct domain during processing (the reduce phase classifies and routes). A single inbox means: one place to dump, no decision about where to put things at capture time.
+
+### Context File
+One CLAUDE.md (or equivalent) with universal methodology + per-domain configuration sections. The agent loads one file at session start, not one per domain.
+
+### Processing Pipeline
+The four-phase skeleton (capture → process → connect → verify) runs for all domains. The process step adapts per domain, but the skeleton is shared infrastructure. Since [[every knowledge domain shares a four-phase processing skeleton that diverges only in the process step]], there's no need for separate pipelines.
+
+### Maintenance System
+Structural health checks (orphan detection, schema validation, MOC sizing) run across all domains simultaneously. Since [[maintenance operations are more universal than creative pipelines because structural health is domain-invariant]], one maintenance system covers all domains.
+
+### Universal Schema Fields
+These fields exist on every note regardless of domain:
+- `description` — retrieval filter
+- `topics` — MOC membership (domain-specific MOCs)
+
+## What's Separate
+
+### Note Templates
+Each domain has its own note types with domain-specific schemas:
+```
+templates/
+├── research-claim.md       # Research domain
+├── research-source.md
+├── therapy-reflection.md   # Therapy domain
+├── therapy-pattern.md
+├── project-decision.md     # PM domain
+├── project-risk.md
+```
+
+Templates don't conflict because note types are distinct. A `therapy-reflection` and a `research-claim` have different schemas and serve different purposes.
+
+### MOC Hierarchies
+Each domain generates its own MOC tree:
+```
+01_thinking/
+├── research/
+│   ├── index.md
+│   ├── methodology.md
+│   └── [topic MOCs]
+├── therapy/
+│   ├── patterns.md
+│   ├── growth.md
+│   └── [pattern MOCs]
+├── projects/
+│   ├── project-a.md
+│   └── project-b.md
+```
+
+### Processing Logic
+The process step (reduce phase) applies domain-specific extraction:
+- Research reduce: extract claims, classify methodology
+- Therapy reduce: detect patterns, identify triggers
+- PM reduce: document decisions, extract action items
+
+The pipeline routes to the right extraction logic based on content type.
+
+## The Cross-Domain Graph
+
+This is where composition creates unique value. Because all domains share one graph, connections can span domains:
+
+- A research finding about cognitive load connects to a therapy pattern about overwhelm
+- A PM decision links to a research claim that influenced it
+- A personal health pattern correlates with a trading performance pattern
+- An engineering ADR links to a product management PRD that motivated it
+
+Since [[concept-orientation beats source-orientation for cross-domain connections]], cross-domain connections happen naturally when notes are organized by concept rather than source domain.
+
+### Four Cross-Domain Connection Patterns
+
+Not all cross-domain connections are the same. The plugin recognizes four patterns, each with different discovery mechanisms:
+
+**1. Temporal Correlation**
+Events in different domains that co-occur in time. Sleep quality (health domain) drops on the same days that trading losses increase (trading domain). Therapy mood entries correlate with project stress periods.
+
+**Discovery mechanism:** Temporal overlap detection across domain notes. Query notes from different domains that share date ranges and compare field values.
+
+**Example:** "Your mood entries below 3 cluster on weeks where your PM domain shows sprint overruns. The correlation is 0.7 over the last 3 months."
+
+**2. Entity Sharing**
+The same person, concept, or object appears across domains. A colleague tracked in your PM domain (stakeholder) is also in your People domain (relationship). A research concept appears in both your academic and creative writing domains.
+
+**Discovery mechanism:** Wiki link and entity name matching across domain boundaries. When the same `[[person]]` or `[[concept]]` appears in notes from different domains, the connection is structural.
+
+**Example:** "[[marcus-chen]] appears in your PM domain as a stakeholder and in your People domain as a mentoring relationship. His communication preferences in one inform engagement strategy in the other."
+
+**3. Causal Chains**
+A finding or event in one domain causes or explains something in another. A research claim about attention limits explains why a PM process fails. A health protocol change produces measurable effects on creative output.
+
+**Discovery mechanism:** Semantic search across domains. The reflect phase uses `mcp__qmd__query` without domain filtering to find conceptually related notes across all domains.
+
+**Example:** "Your research claim that [[attention degrades nonlinearly after the third concurrent task]] may explain the PM pattern in [[cross-team dependencies cause more delays than technical complexity]] — the dependencies force context switching that triggers the attention degradation."
+
+**4. Goal Alignment**
+Goals or outcomes in different domains serve the same higher purpose. Research productivity goals align with personal growth goals. Engineering quality goals align with product user satisfaction goals.
+
+**Discovery mechanism:** Goal-tracing across domain MOCs. When domain MOCs reference similar outcomes or objectives, the alignment surfaces through MOC comparison.
+
+**Example:** "Your personal goal 'reduce work stress' connects to your PM goal 'improve sprint estimation accuracy' — both address the same root cause (overcommitment)."
+
+### Cross-Domain Connection Finding
+
+The reflect phase finds connections regardless of domain boundaries. Since [[elaborative encoding is the quality gate for new notes]], connection quality requires articulating WHY two cross-domain notes relate, not just that they do.
+
+The plugin generates cross-domain reflect prompts:
+- "Does this therapy pattern connect to any personal health notes?" (temporal correlation)
+- "Does this research finding have implications for any active projects?" (causal chain)
+- "Does this engineering decision relate to any product management goals?" (goal alignment)
+- "Does this person appear in any other domain context?" (entity sharing)
+
+### Cross-Domain MOC References
+
+Notes can appear in MOCs from multiple domains:
+```yaml
+topics: ["[[research-methodology]]", "[[therapy-patterns]]"]
+```
+
+A note about "cognitive load affects emotional regulation" genuinely belongs in both research and therapy MOCs. Multi-MOC membership IS the cross-domain connection.
+
+## Progressive Context Loading for Multi-Domain
+
+Rule 5 (progressive context loading) requires careful implementation. In a multi-domain vault, the context file must serve multiple domains without wasting context window space on inactive ones.
+
+### Context File Structure
+
+```
+context-file.md
+├── Universal Methodology (always loaded)
+│   ├── Note design patterns
+│   ├── Processing skeleton
+│   └── Quality standards
+├── Domain: Research (loaded when working on research)
+│   ├── Claim extraction protocol
+│   ├── Research-specific schemas
+│   └── Citation management
+├── Domain: Therapy (loaded when working on therapy)
+│   ├── Ethical constraints
+│   ├── Pattern detection protocol
+│   └── Session preparation workflow
+└── Cross-Domain (loaded when connections span domains)
+    ├── Cross-domain reflect prompts
+    ├── Shared entity resolution
+    └── Temporal correlation detection
+```
+
+### Loading Strategy
+
+The agent determines which domain section to load based on:
+1. **User's stated task** — "Let's work on my research" → load Research section
+2. **Note being processed** — a therapy entry → load Therapy section
+3. **Cross-domain detection** — a therapy note mentions a research concept → load Cross-Domain section additionally
+
+This prevents context file bloat in multi-domain systems. A 3-domain context file might be 3000 lines total, but any single session loads only the universal section (500 lines) plus one domain section (800 lines) — manageable context window usage.
+
+## Composition Patterns
+
+### Pattern 1: Primary + Secondary
+
+One domain is primary (most content, deepest structure), others are secondary (lighter use).
+
+**Example:** Researcher + Personal Assistant (see [[academic research uses structured extraction with cross-source synthesis]] + [[personal assistant uses life area management with review automation]])
+
+**Architecture:**
+- Research gets full three-tier MOC hierarchy with heavy processing
+- Personal Life gets flat-peer MOCs for life areas with light processing
+- Shared inbox with content-based routing during reduce
+- Cross-domain: research insights link to personal goals; research workload patterns connect to personal energy management
+
+**Practical composition:** Dr. Engel's vault (from the research example) adds a personal domain tracking life areas, goals, and relationships. Her research goal "publish attention allocation paper by Q3" appears in both research MOCs (as a project) and personal goals (as a life area milestone). When her research processing detects a productivity pattern, the agent can surface its connection to her personal goal of better work-life balance.
+
+### Pattern 2: Equal Peers
+
+Multiple domains receive roughly equal investment.
+
+**Example:** Creative Writing + Research (see [[creative writing uses worldbuilding consistency with character tracking]] + [[academic research uses structured extraction with cross-source synthesis]])
+
+**Architecture:**
+- Each domain gets full MOC hierarchy
+- Shared processing pipeline with domain-routing
+- Cross-domain: research findings feed worldbuilding decisions; creative exploration generates research questions
+
+**Practical composition:** A speculative fiction writer researching quantum physics for hard sci-fi. Research claims about quantum entanglement become worldbuilding constraints. The creative writing domain's consistency graph links to research claims: when a research claim is updated (new experiment contradicts the physics), the agent flags dependent world rules and scenes. Research and fiction share a vocabulary — but the fiction domain uses it metaphorically while the research domain uses it literally. The vocabulary transformation layer handles this.
+
+### Pattern 3: Professional + Personal
+
+Work and life domains compose.
+
+**Example:** Engineering + Health + People (see [[engineering uses technical decision tracking with architectural memory]] + [[health wellness uses symptom-trigger correlation with multi-dimensional tracking]] + [[people relationships uses Dunbar-layered graphs with interaction tracking]])
+
+**Architecture:**
+- Engineering gets three-tier MOCs with medium processing
+- Health gets flat-peer dimension MOCs with light processing (data accumulation)
+- People spans both contexts (colleagues + friends + family)
+- Cross-domain: health patterns correlate with work performance; people notes span professional and personal contexts
+
+**Practical composition:** An engineering manager tracks technical decisions (ADRs, architecture), personal health metrics (sleep, exercise, stress), and relationships (team members, mentors, friends). The People domain's entity sharing means `[[marcus-chen]]` exists as both a direct report (engineering context) and someone the manager mentors (people context). Health data correlates with engineering productivity: the agent can surface "Your sleep quality drops below 6 hours on weeks with 3+ architecture reviews — consider spacing them differently."
+
+## Composition Conflicts
+
+Most composition is additive (domains add note types, no conflicts). But some configurations can interfere:
+
+### Schema Field Collisions
+If two domains use the same field name with different semantics:
+- Research `status: preliminary | open | dissolved` (claim maturity)
+- PM `status: not-started | in-progress | done` (task completion)
+
+**Resolution:** Namespace domain-specific fields when collision detected: `research_status`, `project_status`. Universal fields (`description`, `topics`) use consistent semantics.
+
+### Processing Priority Conflicts
+When inbox items could belong to multiple domains:
+
+**Resolution:** The reduce phase classifies first, then routes. Classification is based on content signals, not user tagging. The plugin can ask when ambiguous.
+
+### MOC Overlap
+When a topic belongs in multiple domain hierarchies:
+
+**Resolution:** Multi-MOC membership is a feature, not a conflict. The note appears in all relevant MOCs. Since [[cross-links between MOC territories indicate creative leaps and integration depth]], this is actively valuable.
+
+### Maintenance Burden Scaling
+More domains = more note types = more maintenance checks.
+
+**Resolution:** Structural maintenance is shared (orphan detection works on all note types). Domain-specific maintenance (therapy pattern staleness, PM risk register review) scales per domain but is condition-triggered, not scheduled. The plugin warns when total domain count creates maintenance pressure.
+
+## How the Plugin Handles Multi-Domain
+
+### During /setup
+1. Ask "What domains do you work in?" (may be multiple)
+2. Identify primary domain
+3. Generate shared infrastructure once
+4. Add domain-specific layers per domain
+5. Explain cross-domain connection opportunities
+
+### During /extend
+When the user adds a new domain to an existing vault:
+1. Add new note templates (no conflict with existing)
+2. Add new MOC hierarchy (separate from existing)
+3. Update processing pipeline to recognize new content types
+4. Run cross-domain reflect to find connections between new and existing domains
+5. Update context file with new domain configuration
+
+### During /recommend
+Check for cross-domain opportunities:
+- Notes that could connect across domains but don't
+- Domains with no cross-domain links (isolated silos)
+- Common patterns across domains (same concept, different vocabulary)
+
+## Domain Composition Matrix
+
+Which domains compose well and what unique value the composition creates:
+
+| Primary | Secondary | Cross-Domain Value |
+|---------|-----------|-------------------|
+| Research | PM | Research findings inform project decisions |
+| Research | Personal | Research goals align with life goals |
+| Therapy | Health | Mood-health correlations across domains |
+| Therapy | People | Relationship patterns inform therapeutic insights |
+| PM | Engineering | Decisions trace to technical implementation |
+| PM | Product | Project execution ties to product strategy |
+| Creative | Research | Worldbuilding grounded in real research |
+| Learning | Research | Study notes become research foundations |
+| Trading | Health | Health patterns correlate with trading performance |
+| Personal | Health | Life area health includes physical health |
+| Personal | People | Relationship maintenance as life area |
+| Engineering | Product | Technical decisions linked to product requirements |
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Better Approach |
+|-------------|-------------|-----------------|
+| Separate vaults per domain | Loses cross-domain connections — the primary value of composition | Shared graph, separate schemas |
+| One schema for all domains | Since [[false universalism applies same processing logic regardless of domain]] | Domain-specific templates |
+| No cross-domain reflect | Domains become silos within the same vault | Explicit cross-domain connection finding |
+| Too many domains at once | Maintenance burden overwhelms | Start with 1-2 domains, add as needed |
+| Identical processing for all domains | Each domain's process step differs | Route to domain-specific extraction logic |
+
+## Domain Examples
+
+These domain compositions can be combined to demonstrate composition patterns:
+
+- [[therapy journal uses warm personality with pattern detection for emotional processing]] + [[health wellness uses symptom-trigger correlation with multi-dimensional tracking]] — Mood-health correlation: therapy `mood` and `trigger` fields connect to health `sleep_quality`, `exercise`, and `nutrition` fields, enabling cross-domain pattern detection
+- [[academic research uses structured extraction with cross-source synthesis]] + [[project management uses decision tracking with stakeholder context]] — Research findings inform project decisions: a claim note about methodology links to a decision note that cited the finding as rationale
+- [[engineering uses technical decision tracking with architectural memory]] + [[product management uses feedback pipelines with experiment tracking]] — Technical decisions linked to product requirements: ADRs reference PRD goals, feature MOCs link to architecture decisions
+- [[personal assistant uses life area management with review automation]] + [[people relationships uses Dunbar-layered graphs with interaction tracking]] — Relationship maintenance as life area: person MOCs cross-reference life area goals, interaction tracking feeds into personal growth patterns
+- [[trading uses conviction tracking with thesis-outcome correlation]] + [[health wellness uses symptom-trigger correlation with multi-dimensional tracking]] — Performance-health correlation: trading journal `emotions_during` fields connect to health metrics, enabling detection of physiological factors in trading performance
+
+## Grounding
+
+This guidance is grounded in:
+- [[multi-domain systems compose through separate templates and shared graph]] — the foundational composition principle (Rule 1)
+- [[every knowledge domain shares a four-phase processing skeleton that diverges only in the process step]] — shared pipeline, domain-specific process steps (Rule 4)
+- [[concept-orientation beats source-orientation for cross-domain connections]] — cross-domain links need concept organization, not domain silos
+- [[maintenance operations are more universal than creative pipelines because structural health is domain-invariant]] — shared maintenance across all domains
+- [[cross-links between MOC territories indicate creative leaps and integration depth]] — cross-domain links as the primary value signal of composition
+- [[false universalism applies same processing logic regardless of domain]] — why Rule 4 (domain-specific processing) is necessary
+- [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]] — why add-domain is incremental, not upfront
+- [[schema evolution follows observe-then-formalize not design-then-enforce]] — domain-specific fields emerge from use, not from upfront design
+
+---
+
+Topics:
+- [[index]]
+- [[index]]
+---
+
+Topics:
+- [[multi-domain-composition]]

package/methodology/concept-orientation beats source-orientation for cross-domain connections.md

@@ -0,0 +1,51 @@
+---
+description: Notes organized by source bundle ideas by origin not meaning, preventing the same concept from different authors from meeting — extract concepts into independent nodes instead
+kind: research
+topics: ["[[graph-structure]]"]
+methodology: ["Evergreen"]
+---
+
+# concept-orientation beats source-orientation for cross-domain connections
+
+When you create "notes on Book X," you bundle ideas by where they came from rather than what they mean. The author becomes the organizing principle. A concept that appears in three different books exists in three separate places, isolated from itself. Since [[topological organization beats temporal for knowledge work]] argues for organizing by concept rather than chronology, concept-orientation applies that same principle to source material: organize by meaning, not by origin.
+
+Concept-oriented notes flip this. Instead of a container labeled "Matuschak's ideas," you extract each idea into its own note: "associative ontologies beat hierarchical taxonomies," "concept handles compress thought," "spaced repetition builds durable memory." Now these claims can link to claims from other sources that address the same territory. Because [[note titles should function as APIs enabling sentence transclusion]], each extracted concept becomes a callable unit that can be invoked in arguments across the entire graph — something a source-bundled document can never do. When Luhmann's zettelkasten principles overlap with Matuschak's evergreen notes, the overlap becomes visible because both feed into the same concept nodes.
+
+The mechanism is simple: source-orientation creates documents that don't interact. Concept-orientation creates nodes that can form edges across any domain boundary. The retrieval consequence compounds with scale: since [[flat files break at retrieval scale]], source-bundled notes are functionally flat files organized by origin, hitting the same retrieval wall where finding a concept requires remembering which source mentioned it. Since [[each new note compounds value by creating traversal paths]], the architecture choice determines whether cross-domain connections are even possible. Source-bundled documents can only compound within their bundle. Concept nodes compound across the entire graph.
+
+This has practical implications for capture and processing. Source material should go to archive — the full article, book notes, interview transcript preserved for reference. But the artifacts that enter the knowledge graph should be concept extractions: independent claims that can participate in cross-domain synthesis. The extraction pass is not optional decoration; it's the step that transforms documents into graph nodes. Since [[structure without processing provides no value]], merely filing source documents — even with good folder structure — produces no knowledge graph benefits. The extraction IS the processing that creates value.
+
+For agents, this matters because agents traverse graphs. An agent exploring "what do different thinkers say about note-taking friction?" can only find convergent answers if those answers exist as concept nodes rather than source-bundled documents. The query requires cross-domain traversal, which requires cross-domain edges, which requires concept-orientation at the extraction stage. Since [[wiki links implement GraphRAG without the infrastructure]], the explicit curated edges between concept nodes enable the multi-hop reasoning that makes cross-domain synthesis possible. Source-bundled documents can't participate in this graph traversal — they're isolated containers that don't form edges.
+
+Concept extraction also enables the hub formation that makes graphs navigable. Since [[small-world topology requires hubs and dense local links]], efficient traversal requires power-law distribution: a few high-connectivity hubs creating shortcuts, many focused nodes forming local clusters. Source-bundled notes can't become hubs — they're isolated by their origin. Extracted concept nodes can accumulate links from multiple sources, multiple contexts, multiple MOCs. A concept like "retrieval utility" that appears across Zettelkasten, Cornell, and evergreen notes traditions becomes a hub through convergent citation — impossible if those traditions stayed bundled in their source containers.
+
+Since [[storage versus thinking distinction determines which tool patterns apply]], concept extraction is the diagnostic moment — the operation that commits a system to being a thinking system rather than a storage system. Source-bundled notes that stay organized by origin are performing a storage operation regardless of what the user intended. The extraction step is where the system declares its type.
+
+The cost is extraction effort — and something subtler. Source-bundled notes are fast to create — just annotate while reading. Concept extraction requires the additional step of asking "what is this claim, independent of who said it?" But since [[the generation effect requires active transformation not just storage]], this additional effort is precisely the processing that generates value. Source-bundled notes feel like work but produce inventory. Concept extraction feels harder but produces network nodes. Since [[ThreadMode to DocumentMode transformation is the core value creation step]], this extraction step is where ThreadMode dies and DocumentMode begins — source-bundled notes are ThreadMode organized by origin, while extracted concept notes are DocumentMode organized by meaning. But because [[decontextualization risk means atomicity may strip meaning that cannot be recovered]], the extraction that enables cross-domain edges also strips the argumentative scaffolding that gave claims their original force. The architectural bet is that cross-domain connections are worth more than preserved source context — but the bet may not hold equally for all claim types, particularly contextual heuristics and trade-off judgments whose meaning depends on knowing when they apply.
+
+At the system architecture level, concept-orientation is what makes [[multi-domain systems compose through separate templates and shared graph]] tractable. When a personal vault tracks research, health, and projects simultaneously, cross-domain connections — a stress pattern correlating with decision quality, a sleep insight relating to cognitive performance — can only form if both domains produced independent concept nodes. Source-bundled notes trapped in their domain of origin cannot participate in the cross-domain reflect phase that multi-domain composition depends on.
+
+Concept-orientation also turns out to be a prerequisite for multi-agent collaboration patterns. Since [[federated wiki pattern enables multi-agent divergence as feature not bug]], when multiple agents process the same territory and develop different interpretations, they need independent concept nodes to offer alternative perspectives ON. "Notes on Book X" cannot federate because there is no single concept to reinterpret. But "spaced repetition builds durable memory" can support alternative perspectives — one agent emphasizing the cognitive mechanism, another emphasizing the implementation pattern. Concept-orientation creates the units that federation operates on, making cross-domain connections and multi-perspective coexistence both architecturally possible from the same extraction step.
+---
+
+Relevant Notes:
+- [[each new note compounds value by creating traversal paths]] — explains why architecture choice matters: concept nodes can compound across domains, source bundles cannot
+- [[source attribution enables tracing claims to foundations]] — concept-orientation doesn't abandon provenance; Source footers preserve the link back while freeing concepts to participate independently
+- [[the generation effect requires active transformation not just storage]] — concept extraction is the transformation; source bundling is storage that mimics processing
+- [[topological organization beats temporal for knowledge work]] — the foundational design principle this note extends: organize by meaning (concept/topic) rather than origin (source/date)
+- [[note titles should function as APIs enabling sentence transclusion]] — extracted concepts with sentence titles become callable APIs; source-bundled documents cannot be invoked this way
+- [[wiki links implement GraphRAG without the infrastructure]] — concept nodes enable multi-hop graph traversal; source-bundled documents can't participate in the link graph
+- [[structure without processing provides no value]] — extraction is the processing that creates value; filing sources without extraction is the Lazy Cornell anti-pattern
+- [[incremental reading enables cross-source connection finding]] — complementary approach: concept-orientation makes cross-source connections architecturally possible; incremental reading surfaces them during processing
+- [[small-world topology requires hubs and dense local links]] — concept extraction enables hub formation: high-connectivity concept nodes that aggregate links from multiple sources can become the hubs that create shortcuts across the network
+- [[federated wiki pattern enables multi-agent divergence as feature not bug]] — downstream consequence: concept-orientation is a prerequisite for federation because only concept nodes can support multiple legitimate interpretations; source-bundled notes have nothing to federate
+- [[faceted classification treats notes as multi-dimensional objects rather than folder contents]] — explains WHY concept extraction matters for classification: extracted concepts have multiple independent properties (topic, methodology, type) that faceted access can slice from multiple angles, while source-bundled documents have only one meaningful facet (origin)
+- [[narrow folksonomy optimizes for single-operator retrieval unlike broad consensus tagging]] — explains why concept extraction works in single-operator vaults: the vocabulary used to title extracted concepts doesn't need to generalize beyond the operator who will search it, so personal retrieval keys can be maximally specific to the operator's conceptual landscape
+- [[ThreadMode to DocumentMode transformation is the core value creation step]] — names this extraction step precisely: source-bundled notes are ThreadMode organized by origin, concept notes are DocumentMode organized by meaning; concept extraction IS the ThreadMode-to-DocumentMode transformation applied to source material
+- [[storage versus thinking distinction determines which tool patterns apply]] — diagnostic: concept extraction is the operation that commits a system to being a thinking system rather than a storage system; source-bundled notes that stay organized by origin are performing a storage operation regardless of intent
+- [[multi-domain systems compose through separate templates and shared graph]] — architectural consequence: concept extraction is the prerequisite for cross-domain composition because only independent concept nodes can form edges across domain boundaries during cross-domain reflect
+- [[decontextualization risk means atomicity may strip meaning that cannot be recovered]] — names the cost that concept extraction creates: cross-domain edges require stripping source context, but contextual heuristics and trade-off judgments may lose essential meaning in the process
+- [[flat files break at retrieval scale]] — the scale consequence: source-bundled notes are functionally flat files organized by origin, and they hit the same retrieval wall — past ~200 sources, finding a concept buried inside a source bundle requires remembering which source mentioned it
+
+Topics:
+- [[graph-structure]]

package/methodology/confidence thresholds gate automated action between the mechanical and judgment zones.md

@@ -0,0 +1,50 @@
+---
+description: A three-tier response pattern (auto-apply, suggest, log-only) based on confidence scoring fills the gap between deterministic hooks and semantic skills, as ClueBot NG's 0.9 revert threshold
+kind: research
+topics: ["[[agent-cognition]]", "[[maintenance-patterns]]"]
+methodology: ["Original", "Systems Theory"]
+source: [[automated-knowledge-maintenance-research-source]]
+---
+
+# confidence thresholds gate automated action between the mechanical and judgment zones
+
+Since [[the determinism boundary separates hook methodology from skill methodology]], the vault treats automation as binary: deterministic operations go to hooks, judgment operations go to skills. But this binary obscures a third zone that sits between them — operations where automation can act if its confidence is high enough, and should defer when it is not. The determinism boundary asks "is this operation deterministic?" The confidence threshold asks the complementary question: "when the operation is NOT fully deterministic, can we still automate it above a confidence threshold?"
+
+Wikipedia's ClueBot NG demonstrates the pattern concretely. It scores every edit on a 0-1 scale using a neural network trained on vandalism examples. Above 0.9, it auto-reverts — the confidence is high enough that the cost of occasional false positives is lower than the cost of delayed vandalism response. Between 0.5 and 0.9, it flags the edit for human review — the confidence is meaningful but not sufficient for autonomous action. Below 0.5, it logs the edit without flagging — the signal is too weak to warrant attention. This three-tier response pattern (auto-apply, suggest, log-only) is not specific to vandalism detection. It generalizes wherever an automated system can score its own confidence.
+
+The vault already implements implicit confidence tiers through its search architecture. Since qmd provides three search modes — keyword (`search`), vector (`vsearch`), and hybrid with LLM reranking (`query`) — each mode represents a different confidence level in its results. LLM-reranked results from `query` mode are higher confidence than raw vector matches, which are higher confidence than keyword matches. The three-tier search architecture is itself a confidence-gated system, even though the thresholds are implicit in the tool choice rather than explicit in a numerical score. An agent choosing `query` over `search` for connection finding is implicitly choosing higher-confidence results at the cost of slower execution — the same trade-off ClueBot NG makes when setting its threshold at 0.9 rather than 0.5.
+
+The design principle underlying confidence thresholds is conservative asymmetry: the cost of incorrect automated action exceeds the cost of missed automation opportunity. Since [[automated detection is always safe because it only reads state while automated remediation risks content corruption]], the read/write asymmetry reveals why confidence thresholds apply selectively — detection needs no confidence gating because false alerts are cheap and correctable, while remediation needs gating proportional to the irreversibility of the change. This is also the asymmetry that since [[over-automation corrupts quality when hooks encode judgment rather than verification]] makes over-automation dangerous — a wrong automated action corrupts silently while a missed opportunity is merely a missed opportunity. Confidence thresholds operationalize this asymmetry by requiring high confidence before granting automated authority. The threshold itself encodes the system's risk tolerance: a 0.9 threshold says "we accept one false positive in ten automated actions," while a 0.95 threshold says "we accept one in twenty." The correct threshold depends on how expensive each false positive is relative to how expensive each missed true positive is.
+
+This extends the existing determinism boundary from a line to a spectrum with three zones. At one end, fully mechanical operations — schema field presence, file existence, format compliance — need no confidence scoring because their correctness is deterministic. Since [[hook enforcement guarantees quality while instruction enforcement merely suggests it]], these belong in hooks that fire on every operation. At the other end, fully semantic operations — connection quality evaluation, claim specificity judgment, synthesis across domains — need full agent reasoning regardless of any confidence score. Between these poles sits the confidence-gated zone: duplicate detection where high-similarity pairs can be flagged automatically but ambiguous pairs need evaluation, tag suggestions where strong keyword matches can be auto-applied but weaker matches need review, stale note detection where notes unchanged for months in active topic areas are confidently stale but notes in stable domains require judgment.
+
+Since [[nudge theory explains graduated hook enforcement as choice architecture for agents]], the confidence threshold pattern parallels nudge theory's enforcement graduation but along a different axis. Nudge theory graduates the severity of response to a detected violation — warn versus block. Confidence thresholds graduate whether an automated system should act at all based on how certain it is about its assessment. A system could combine both: high confidence plus structural violation triggers auto-fix (block-level severity with high confidence), medium confidence plus qualitative issue triggers a suggestion (nudge-level severity with medium confidence), low confidence triggers only logging. The two graduation axes — enforcement severity and confidence level — create a two-dimensional design space for automation decisions.
+
+The practical implication for knowledge vault automation is that many operations currently treated as either fully-automated or fully-manual could benefit from confidence-gated intermediate states. Since [[schema enforcement via validation agents enables soft consistency]], soft enforcement already implements one form of this: warning rather than blocking when confidence that the violation matters is medium. But the pattern extends beyond schema validation. Duplicate detection could auto-flag pairs with cosine similarity above 0.95, suggest pairs between 0.8 and 0.95, and ignore pairs below 0.8. Orphan detection could auto-escalate notes orphaned for over 30 days in active topic areas, suggest attention for notes orphaned 7-30 days, and suppress alerts for notes orphaned less than 7 days (the expected window between create and reflect). Connection suggestion could surface high-confidence semantic matches as ready-to-add links, medium-confidence matches as "consider connecting," and suppress low-confidence noise entirely. The risk tolerance at each tier also interacts with the operation's reversibility: since [[idempotent maintenance operations are safe to automate because running them twice produces the same result as running them once]], idempotent operations can tolerate lower confidence thresholds because a wrong action that can be safely re-run or undone is less costly than a wrong action that compounds on retry.
+
+The shadow side of confidence thresholds is that they create a false sense of precision. A threshold of 0.9 sounds objective, but the underlying model's calibration determines whether a 0.9 score actually means 90% probability of correctness. Since [[metacognitive confidence can diverge from retrieval capability]], the same divergence between self-assessment and actual capability applies here at the system level: poorly calibrated models produce confidence scores that do not correspond to actual accuracy — a 0.9 score might reflect 70% actual accuracy if the model is systematically overconfident. This is the metacognitive version of the Goodhart problem: the confidence score becomes a target, and if the scoring model is wrong, the threshold gates on the wrong thing. The practical defense is empirical validation: track the false positive rate at each threshold level, and adjust thresholds based on observed accuracy rather than theoretical calibration.
+
+There is also a temporal dimension to threshold design. Early in a system's life, when the automation has limited training data and the knowledge graph is sparse, thresholds should be conservative — higher confidence required before automated action. As the system accumulates more data and the automation's accuracy can be validated empirically, thresholds can relax. This parallels the broader pattern that since [[methodology development should follow the trajectory from documentation to skill to hook as understanding hardens]], each encoding level requires operational experience at the previous level before promotion. Confidence thresholds follow an analogous trajectory: start with high thresholds (conservative, suggest-only), lower thresholds as empirical evidence accumulates (graduated action), and eventually some operations may prove reliable enough to move entirely into the mechanical zone. The confidence zone is not a permanent category — it is a staging area where operations mature toward either full automation or permanent human oversight. But since [[hooks cannot replace genuine cognitive engagement yet more automation is always tempting]], this maturation trajectory itself carries the expansion temptation: as thresholds lower and more operations graduate to full automation, the agent's judgment scope narrows progressively — the same erosion dynamic that confidence gating was partly designed to moderate.
+
+---
+---
+
+Relevant Notes:
+- [[the determinism boundary separates hook methodology from skill methodology]] -- foundation: establishes the binary hook/skill divide that this note extends into a spectrum by identifying the confidence-gated zone between the two poles
+- [[over-automation corrupts quality when hooks encode judgment rather than verification]] -- develops the failure mode that confidence thresholds are designed to prevent: acting on low-confidence judgments produces the same invisible corruption as encoding judgment in hooks
+- [[nudge theory explains graduated hook enforcement as choice architecture for agents]] -- parallel graduation: nudge theory graduates enforcement severity (warn vs block), this note graduates automation scope (auto-apply vs suggest vs log) based on confidence rather than severity
+- [[hook enforcement guarantees quality while instruction enforcement merely suggests it]] -- the detection guarantee that makes confidence scoring possible: hooks ensure every operation is evaluated, and confidence thresholds determine what happens after evaluation
+- [[schema enforcement via validation agents enables soft consistency]] -- soft enforcement is a specific instance of confidence-gated action: warn-without-blocking is the response when confidence that the violation matters is medium rather than high
+- [[reconciliation loops that compare desired state to actual state enable drift correction without continuous monitoring]] -- reconciliation is the scheduling pattern whose remediation side benefits from confidence gating: detection is always safe (read-only), but remediation actions range from mechanical to judgment-requiring, and confidence thresholds determine which remediation actions can execute autonomously
+- [[maintenance scheduling frequency should match consequence speed not detection capability]] — consequence speed determines WHEN to check, confidence thresholds determine HOW AGGRESSIVELY to respond: together they parameterize the full automation scheduling decision across temporal and response dimensions
+- [[automated detection is always safe because it only reads state while automated remediation risks content corruption]] -- deeper principle: the read/write asymmetry explains why confidence thresholds apply selectively to remediation but not detection; detection failure is a cheap false alert while remediation failure is content corruption proportional to irreversibility
+- [[methodology development should follow the trajectory from documentation to skill to hook as understanding hardens]] -- temporal parallel: the methodology trajectory (instruction to skill to hook) mirrors the confidence trajectory (high threshold to lower threshold to full automation) as evidence accumulates through operational experience
+- [[metacognitive confidence can diverge from retrieval capability]] -- calibration risk: poorly calibrated confidence scores produce the same divergence between self-assessment and actual capability that metacognitive confidence describes for retrieval; the system believes its 0.9 threshold means 90% accuracy when it may not
+- [[hooks cannot replace genuine cognitive engagement yet more automation is always tempting]] -- expansion pressure: the temporal maturation of thresholds (lowering as evidence accumulates) IS the automation expansion dynamic this tension warns about; confidence gating moderates expansion but the trajectory still narrows agent judgment scope over time
+- [[idempotent maintenance operations are safe to automate because running them twice produces the same result as running them once]] -- risk modulation: idempotent operations can tolerate lower confidence thresholds because errors are reversible and repetition is harmless, adding a third safety filter that interacts with both determinism and confidence
+- [[three concurrent maintenance loops operate at different timescales to catch different classes of problems]] — maps the confidence spectrum onto operational architecture: the fast loop operates in the mechanical zone (deterministic, auto-apply), the medium loop straddles the boundary (mechanical detection, judgment-requiring remediation), and the slow loop operates primarily in the judgment zone, making the three loops a concrete instantiation of the confidence gradient
+- [[the fix-versus-report decision depends on determinism reversibility and accumulated trust]] — temporal complement: confidence thresholds gate individual actions at a point in time, while the fix-versus-report framework adds the temporal dimension of accumulated trust that determines when confidence gating can relax; together they parameterize both the instantaneous and historical dimensions of automation authority
+
+Topics:
+- [[agent-cognition]]
+- [[maintenance-patterns]]

package/methodology/configuration dimensions interact so choices in one create pressure on others.md

@@ -0,0 +1,58 @@
+---
+description: Atomic granularity forces explicit linking, deep navigation, and heavy processing — the valid space is far smaller than the combinatorial product because each choice constrains its neighbors
+kind: research
+topics: ["[[design-dimensions]]"]
+methodology: ["Original"]
+source: [[knowledge-system-derivation-blueprint]]
+---
+
+# configuration dimensions interact so choices in one create pressure on others
+
+Knowledge system design involves at least eight dimensions — since [[eight configuration dimensions parameterize the space of possible knowledge systems]], the list includes granularity, organization, linking philosophy, processing intensity, navigation depth, maintenance cadence, schema density, and automation level. The tempting assumption is that these are independent knobs: pick your preferred setting on each, combine them, and deploy. But the dimensions are coupled. A choice at one end of one spectrum creates pressure toward specific regions of other spectra, and ignoring that pressure produces systems that are internally incoherent.
+
+The clearest example is granularity cascading through everything else. Choosing atomic notes (one claim per file) means each note has minimal internal context, so connections between notes must be explicit — you cannot rely on "it's in the same document" proximity. This forces explicit linking. But thousands of atomic notes with dense explicit links require deep navigation structures to remain traversable, because since [[navigational vertigo emerges in pure association systems without local hierarchy]], a flat sea of equally-small nodes becomes disorienting without MOC hierarchy to provide landmarks. And maintaining all those links and navigation structures demands heavy processing — extraction pipelines, reflection passes, reweaving cycles. The granularity choice didn't just set one parameter. It created pressure across linking, navigation, and processing simultaneously. And since [[every knowledge domain shares a four-phase processing skeleton that diverges only in the process step]], the processing intensity cascade is particularly consequential — the process step is the only phase that varies by domain, so dimension interactions concentrate at that single variable point while capture, connect, and verify absorb pressure as structural constants.
+
+The reverse cascade is equally constraining. Coarse granularity (one note per source, or topic-level documents) means each note carries enough internal context that lightweight linking suffices — a few cross-references rather than dense typed connections. Navigation can be shallow because fewer nodes need organizing. Processing can be lighter because each note is more self-contained. The entire configuration coheres at the coarse pole just as it coheres at the atomic pole, but mixing atomic granularity with shallow navigation produces an incoherent system where notes are too small to be self-contained and too numerous to find.
+
+Automation level creates a parallel cascade. Full automation (hooks, skills, pipelines) enables dense schemas because validation catches errors that humans would miss. It enables heavy processing because pipelines handle volume that manual invocation cannot sustain. But manual operation — where every action requires explicit invocation — pressures toward minimal schemas (less to remember, less to validate by hand) and lighter processing (each step is expensive in attention). Deploying dense schemas in a manual system creates a maintenance burden that collapses under its own weight. Deploying minimal schemas in a fully automated system wastes the infrastructure's enforcement capacity. The cascade operates even within automation — since [[skill context budgets constrain knowledge system complexity on agent platforms]], limited skill slots force methodology back into instruction encoding, which degrades enforcement strength, which pressures toward simpler schemas. Since [[methodology development should follow the trajectory from documentation to skill to hook as understanding hardens]], the automation dimension itself has internal structure where different encoding levels create different pressure profiles.
+
+Volume introduces a third pressure axis. Since [[small-world topology requires hubs and dense local links]], a 500-note vault needs deep navigation, semantic search, and automated maintenance to remain traversable. A 50-note vault works with shallow navigation and grep because the agent can hold the entire structure in context. The volume dimension doesn't just affect search modality — it pressures navigation depth and maintenance cadence simultaneously, because what works at small scale (manual, shallow, grep-based) becomes unnavigable at large scale.
+
+The implication for derivation is that the valid configuration space is much smaller than the combinatorial product. Eight dimensions with even three positions each produces 6,561 theoretical combinations. But most are incoherent — atomic granularity with shallow navigation, manual operation with dense schemas, high volume with no automated maintenance. Since [[derivation generates knowledge systems from composable research claims not template customization]], a derivation engine that treats dimensions as independent will produce specifications that look reasonable in isolation but fail in practice because the pressures conflict. But the coupling structure cuts both ways: since [[configuration paralysis emerges when derivation surfaces too many decisions]], the same interaction constraints that make independent dimension selection incoherent also make inference tractable — resolving a few primary choices propagates through the coupling to determine secondary ones, so the derivation engine can reduce the decision surface from the full combinatorial product to the genuine choice points where user constraints leave multiple viable paths. Since [[knowledge system architecture is parameterized by platform capabilities not fixed by methodology]], the generator must understand not just which parameters to set but which parameter combinations form coherent operating points.
+
+This reframes methodology traditions as discovered coherence points rather than arbitrary preferences — a framing that [[methodology traditions are named points in a shared configuration space not competing paradigms]] develops extensively. Zettelkasten coheres at the atomic-explicit-deep-heavy end. PARA coheres at the coarse-lightweight-shallow-manual end. Each tradition represents a region of the configuration space where the dimension interactions have been resolved through practice. The value of understanding interactions is that it enables generating NEW coherent configurations for novel use cases — combinations that no existing methodology has discovered but that respect the coupling constraints.
+
+An upstream constraint narrows the space further: since [[storage versus thinking distinction determines which tool patterns apply]], the storage/thinking classification determines which coherence regions are even viable before dimension tuning begins. A storage system cannot coherently adopt atomic granularity with heavy processing because its purpose does not generate the synthesis demand that justifies the processing cost. A thinking system cannot coherently adopt coarse granularity with minimal linking because it sacrifices the composability that synthesis requires. The classification constrains which cascade patterns produce functional systems. And since [[complex systems evolve from simple working systems]], even within a coherent region, Gall's Law adds a temporal constraint: start at the simple end and let friction drive elaboration rather than deploying the full coherent configuration from day one.
+
+Multi-domain composition introduces a further pressure axis that operates across domain boundaries. Since [[multi-domain systems compose through separate templates and shared graph]], when multiple domains coexist in one graph, dimension settings in one domain can conflict with settings in another. A domain with high processing intensity and dense schemas shares graph space with a domain using light processing and minimal schemas, and the shared navigation structure must serve both. The cross-domain surface area grows quadratically with each new domain, making dimension interaction analysis not just intra-system but inter-domain. Whether the shared graph mechanics — wiki links, MOCs, progressive disclosure — can bridge domains with different structural densities is an open question that tests how hard the coupling constraints really are.
+
+Dimension coupling also explains why evolution eventually requires reseeding. Since [[derived systems follow a seed-evolve-reseed lifecycle]], small adaptations in one dimension accumulate pressure on others — adding a schema field creates query expectations, adding a MOC shifts navigation patterns. Each adaptation is locally justified but the accumulated pressure drifts the configuration into an incoherent region. This is dimension interaction operating over time: the coupling constraints that make initial derivation a constraint-satisfaction problem also make evolution a drift-detection problem, because each incremental change shifts the system's position in configuration space without checking whether the new position still satisfies the coupling constraints.
+
+There is a shadow side. If dimension interactions are strong enough, they may reduce the space of viable configurations to essentially the known methodology traditions, making "novel derivation" more theoretical than practical. The test is whether the interaction constraints are hard (violating them produces failure) or soft (violating them produces friction that can be overcome with compensating mechanisms). Since [[four abstraction layers separate platform-agnostic from platform-dependent knowledge system features]], automation can compensate for some mismatches — automated linking can sustain atomic granularity with less navigation depth than the pure interaction would demand. The real question is how much automation can compensate versus how much the coupling is fundamental. The novel domain case tests this directly — since [[novel domains derive by mapping knowledge type to closest reference domain then adapting]], adapting a reference domain means adjusting specific dimensions, and each adjustment must respect the coupling constraints or produce an incoherent system. Whether adaptation can safely deviate from the reference coherence point measures exactly how hard the interaction constraints are.
+
+---
+---
+
+Relevant Notes:
+- [[knowledge system architecture is parameterized by platform capabilities not fixed by methodology]] — establishes that dimensions are parameterized, this note adds that parameters are coupled rather than independent
+- [[eight configuration dimensions parameterize the space of possible knowledge systems]] — defines the dimensions this note shows are coupled; that note treats them as largely independent in definition, this note develops their practical entanglement
+- [[methodology traditions are named points in a shared configuration space not competing paradigms]] — interaction pressure explains WHY traditions cohere where they do: each tradition resolved the coupling through practice, which this note formalizes as constraint satisfaction
+- [[derivation generates knowledge systems from composable research claims not template customization]] — derivation must satisfy these interaction constraints or produce incoherent systems; justification chains are the mechanism for verifying coherence
+- [[four abstraction layers separate platform-agnostic from platform-dependent knowledge system features]] — layer dependencies are one mechanism of dimension interaction: automation-level choices cascade through processing intensity and schema density
+- [[enforcing atomicity can create paralysis when ideas resist decomposition]] — documents the creation-time cost at the atomic pole, which this note predicts: fine granularity creates pressure toward heavy processing, and when that processing burden exceeds capacity the system collapses
+- [[decontextualization risk means atomicity may strip meaning that cannot be recovered]] — documents the retrieval-time cost at the atomic pole: fine granularity strips argumentative context during extraction, and the coupling means the heavy processing that atomicity demands may not compensate for what extraction loses
+- [[small-world topology requires hubs and dense local links]] — the topological consequence of granularity choice: atomic notes require dense local linking to maintain navigability, which is exactly the pressure this note describes
+- [[navigational vertigo emerges in pure association systems without local hierarchy]] — the failure mode when granularity-navigation coupling is violated: atomic notes without the deep navigation they demand become unnavigable
+- [[complex systems evolve from simple working systems]] — complementary constraint: even at a coherent configuration point, Gall's Law says start simple and evolve; interaction pressures are evolutionary pressures that drive correction or collapse
+- [[skill context budgets constrain knowledge system complexity on agent platforms]] — concrete instance of the automation cascade: skill budgets constrain methodology encoding which cascades through schema density and processing intensity
+- [[methodology development should follow the trajectory from documentation to skill to hook as understanding hardens]] — the trajectory IS an automation-level progression; this note explains why different automation levels create different pressures on schema density and processing intensity
+- [[storage versus thinking distinction determines which tool patterns apply]] — upstream classification that determines which coherence region is viable; storage and thinking systems occupy different interaction-resolved regions of the configuration space
+- [[every knowledge domain shares a four-phase processing skeleton that diverges only in the process step]] — explains why the processing intensity cascade is particularly consequential: since only one of four pipeline phases varies by domain, dimension interactions concentrate at that single variable point
+- [[novel domains derive by mapping knowledge type to closest reference domain then adapting]] — concrete application of dimension coupling during derivation: adapting a reference domain for a novel use case must respect interaction constraints because changing one dimension (e.g., temporal dynamics) cascades through maintenance cadence, navigation depth, and schema density
+- [[multi-domain systems compose through separate templates and shared graph]] — cross-domain pressure: adding a second domain does not simply double the configuration space because dimension interactions propagate across domain boundaries, and the shared graph must accommodate domains with different structural densities
+- [[derived systems follow a seed-evolve-reseed lifecycle]] — temporal consequence of coupling: accumulated incremental adaptations in coupled dimensions drift configuration into incoherent regions, explaining why evolution alone is insufficient and principled restructuring (reseeding) is periodically required
+- [[configuration paralysis emerges when derivation surfaces too many decisions]] — the UX consequence of coupling: dimension interactions are precisely what makes inference tractable, because resolving a few primary choices propagates through the coupling structure to determine secondary ones, reducing the decision surface from the full combinatorial product to genuine choice points
+- [[premature complexity is the most common derivation failure mode]] — dimension coupling is the amplification mechanism: each choice beyond minimum viable cascades through neighbors, so small increases in initial complexity produce disproportionate system-level complexity, making the complexity budget more critical than a linear count would suggest
+
+Topics:
+- [[design-dimensions]]