arscontexta 0.6.0

package/methodology/productivity porn risk in meta-system building.md

@@ -0,0 +1,30 @@
+---
+description: Building sophisticated agent workflows becomes procrastination when output stays flat while complexity grows—building substitutes for producing
+kind: research
+topics: ["[[maintenance-patterns]]", "[[processing-workflows]]"]
+source: TFT research corpus (00_inbox/heinrich/)
+---
+
+Building meta-systems — workflows, skills, infrastructure — feels productive. It's work about work. The question: when does this investment pay off in output, and when does it become its own trap?
+
+The Collector's Fallacy (saving = learning) has a meta-level analog: building = producing. A vault with sophisticated automation but no published content has optimized for the wrong metric. Since [[throughput matters more than accumulation]], success is measured by what flows through (published content, synthesized understanding) not what accumulates (infrastructure, skills, workflows). The system exists to produce output; if it mostly produces more system, something is wrong.
+
+This creates a tension with [[complex systems evolve from simple working systems]]. Gall's Law says complexity should emerge from working simplicity — add sophistication where pain appears. But productivity porn warns that adding sophistication might itself become the procrastination. The discriminator: does complexity growth track with output growth? Healthy evolution shows both curves rising together. Productivity porn shows complexity rising while output stays flat. Since [[insight accretion differs from productivity in knowledge systems]], the test is accretion, not just productivity: building infrastructure can look productive (commits, PRs, new features) while producing zero accretion (no deeper understanding, no better synthesis, no insight that wasn't there before). The question is whether the building deepens understanding or merely reorganizes complexity.
+
+Since [[skills encode methodology so manual execution bypasses quality gates]], skills represent accumulated learning that couldn't have been designed upfront — genuine value. But the same argument could rationalize infinite infrastructure building. The risk is making this rationalization untestable. Since [[writing for audience blocks authentic creation]], a parallel diversion pattern exists: audience awareness diverts cognitive work from synthesis to presentation, just as infrastructure building diverts effort from production to meta-production. Both feel productive while producing zero output — the energy goes into framing rather than generating.
+
+This risk forms a trio with sibling failure modes: [[cognitive outsourcing risk in agent-operated systems]] tests whether delegating to agents atrophies human capability, while [[verbatim risk applies to agents too]] tests whether agent outputs contain genuine synthesis or just well-structured reorganization. Each is orthogonal — a system can fail on any one while succeeding on the others, which makes the combined risk surface wider than any individual failure mode suggests.
+---
+
+Relevant Notes:
+- [[insight accretion differs from productivity in knowledge systems]] — the test is accretion not productivity: building can look productive (commits, features) while producing zero accretion (no deeper understanding); the discriminator
+- [[throughput matters more than accumulation]] — the output metric that matters; if building doesn't increase throughput, it's not investment but procrastination
+- [[complex systems evolve from simple working systems]] — creates productive tension: Gall's Law says add complexity where pain emerges, but the discriminator is whether complexity tracks output growth
+- [[cognitive outsourcing risk in agent-operated systems]] — sibling risk from same source; tests skill atrophy from delegation while this tests procrastination disguised as productivity
+- [[verbatim risk applies to agents too]] — completes the meta-system risks trio: this tests building vs producing, cognitive outsourcing tests human capability atrophy, verbatim risk tests agent output quality
+- [[skills encode methodology so manual execution bypasses quality gates]] — exemplifies the rationalization risk: skills genuinely encode accumulated learning, but this argument could justify infinite building
+- [[writing for audience blocks authentic creation]] — parallel diversion pattern: infrastructure building diverts effort from production to meta-production; audience awareness diverts effort from synthesis to presentation; both feel productive while producing zero output
+
+Topics:
+- [[maintenance-patterns]]
+- [[processing-workflows]]

package/methodology/programmable notes could enable property-triggered workflows.md

@@ -0,0 +1,64 @@
+---
+description: When notes have queryable metadata, the vault can shift from passive storage to active participant — notes surfacing themselves based on due dates, staleness thresholds, or status transitions
+kind: research
+topics: ["[[maintenance-patterns]]"]
+methodology: ["Original"]
+source: [[2-4-metadata-properties]]
+---
+
+# programmable notes could enable property-triggered workflows
+
+The standard model treats notes as passive objects. You write them, file them, maybe search for them later. The note sits until you retrieve it. But when notes have structured metadata, a different architecture becomes possible: notes that act based on their properties. A note with `status: seedling` and `created: 30 days ago` surfaces itself for review. A note with `due: today` appears in the morning's task list. A note whose `last-reviewed` date exceeds some threshold enters a maintenance queue.
+
+This is the shift from repository to agent that the source material describes: "systems where notes can trigger actions based on their properties" transform "the PKM system from a passive repository into an active agent in the user's cognitive workflow."
+
+The vault already implements primitive versions of this pattern. Since [[live index via periodic regeneration keeps discovery current]], hooks that fire on note changes demonstrate property-triggered behavior — the note's modification triggers index regeneration. Since [[schema enforcement via validation agents enables soft consistency]], validation hooks that fire on Write demonstrate notes triggering quality checks. But these are system-level triggers (file events), not semantic triggers (property changes).
+
+The fuller vision involves semantic triggers:
+
+| Property Condition | Triggered Action |
+|-------------------|------------------|
+| `status: seedling` AND age > 14 days | Add to review queue |
+| `last-reviewed` older than interval | Surface for spaced repetition |
+| `type: tension` AND `status: open` | Include in synthesis prompts |
+| Incoming link count < 2 AND age > 30 days | Flag as potential orphan |
+| `source` note modified after this note created | Trigger reweave check |
+
+Since [[type field enables structured queries without folder hierarchies]], the `type:` field already provides one property dimension for triggers — tension notes wanting synthesis, methodology notes wanting implementation review. The table above extends this to compound conditions (type AND status, property AND age).
+
+The implementation challenge is the event model. File-based hooks fire on Write/Read events — they don't know about property semantics. Since [[maintenance scheduling frequency should match consequence speed not detection capability]], the choice between event-driven and periodic detection is not about cost but about how fast the problem develops — schema violations need per-event triggers because they propagate instantly, while staleness conditions need periodic scans because they develop over weeks. And since [[three concurrent maintenance loops operate at different timescales to catch different classes of problems]], each property trigger in the table above maps naturally onto a specific loop: schema-violation triggers belong in the fast loop (per-event hooks), orphan detection and staleness surfacing belong in the medium loop (per-session checks), and source-change reweave triggers belong in the slow loop (periodic review). The three-loop architecture provides the scheduling container that determines which trigger gets which infrastructure investment. A property-aware trigger system would need either:
+
+1. **Property diff on every write** — compare YAML before/after, fire triggers when specific fields change. Since [[metadata reduces entropy enabling precision over recall]], YAML frontmatter is already structured for parsing; diffing it is tractable. And since [[intermediate representation pattern enables reliable vault operations beyond regex]], an IR layer where notes are already parsed into typed objects would make property diffs a comparison of structured dictionaries rather than regex extraction that breaks on multiline values or edge-case YAML formatting.
+
+2. **Periodic property scans** — a maintenance agent queries properties vault-wide and surfaces notes meeting conditions. This is less reactive but simpler. It is essentially what `/review` does for link validity, extended to arbitrary property queries. Since [[reconciliation loops that compare desired state to actual state enable drift correction without continuous monitoring]], periodic property scans are reconciliation loops where each property condition in the table above defines a desired state and the scan detects divergence. The reconciliation pattern explains why periodic scans may be the pragmatic first step: reconciliation's core insight is that the comparison is always safe and idempotent, meaning scheduled property scans carry zero risk and catch the accumulated drift that event-driven triggers miss.
+
+3. **Hybrid approach** — file events trigger property parsing; property changes enqueue notes for condition evaluation; a scheduler processes the queue.
+
+The connection to spaced repetition is direct. Since [[spaced repetition scheduling could optimize vault maintenance]] proposes interval-based attention allocation, programmable notes are the implementation mechanism. The note's `last-reviewed` property determines its next review date; a scheduler queries notes due for review and surfaces them. The note participates in determining when it gets attention. Similarly, since [[maturity field enables agent context prioritization]] proposes seedling/developing/evergreen status, that status becomes a trigger dimension: seedlings surface more frequently for development, evergreens surface rarely for confirmation.
+
+There's a deeper principle here about the nature of notes in agent-operated systems. Traditional notes are inert — the agent acts on them. Programmable notes are reactive — they influence when and how the agent acts. This shifts the architecture from pull (agent searches for relevant content) to push (content declares its relevance). The shift is especially important because since [[prospective memory requires externalization]], every "remember to check this note later" intention is a guaranteed failure across agent sessions. Property-triggered workflows eliminate the prospective memory demand entirely — the note surfaces itself when conditions are met, rather than depending on any agent to remember that attention is due. Since [[dangling links reveal which notes want to exist]], the vault already has notes that "want" things — this pattern extends that: notes that want attention, want review, want connection. This connects to [[bootstrapping principle enables self-improving systems]]: property-triggered workflows let the vault participate in its own maintenance by declaring what needs attention. The system improves itself through the notes it contains.
+
+The risk is complexity. Every property trigger is a rule; rules interact; interactions create surprises. A note might trigger multiple workflows simultaneously. Cascades might emerge where one note's action triggers another's. Since [[complex systems evolve from simple working systems]], the safe approach starts minimal: one or two trigger types (staleness, due date), implemented as periodic queries rather than event-driven hooks, extended only when the simple version proves valuable.
+
+The question worth investigating: what property triggers would actually improve vault operation vs adding complexity without benefit? Staleness-based surfacing seems high-value (prevents write-only memory). Due-date surfacing seems high-value (explicit scheduling). Status-transition triggers seem medium-value (could automate parts of the processing pipeline). Arbitrary programmability seems low-value (complexity exceeds benefit for most workflows). The consequence speed framework helps here: triggers earn their complexity when the problem they detect propagates faster than the next scheduled check would catch it. A schema violation that propagates instantly justifies per-event complexity. A staleness condition that develops over weeks does not need event-driven infrastructure — a periodic scan suffices. The research direction is identifying which triggers earn their complexity, and consequence speed provides the evaluation criterion. And since [[confidence thresholds gate automated action between the mechanical and judgment zones]], the response to each trigger need not be binary (fire or do not fire) -- a three-tier response pattern where high-confidence triggers auto-execute, medium-confidence triggers suggest, and low-confidence triggers merely log provides a graduated approach that reduces the risk of cascade interactions while still capturing the value of property-triggered surfacing.
+---
+
+Relevant Notes:
+- [[live index via periodic regeneration keeps discovery current]] — primitive form: file events already trigger index updates; property triggers extend this to semantic events
+- [[schema enforcement via validation agents enables soft consistency]] — sibling pattern: validation hooks fire on writes; property triggers fire on semantic conditions
+- [[spaced repetition scheduling could optimize vault maintenance]] — direct application: property-triggered surfacing is how spaced repetition would be implemented
+- [[metadata reduces entropy enabling precision over recall]] — prerequisite: property triggers require queryable metadata; this note explains why that metadata exists
+- [[dangling links reveal which notes want to exist]] — the notes that want framing: dangling links want resolution; this extends to notes wanting attention, review, connection
+- [[complex systems evolve from simple working systems]] — constraint: start with minimal triggers, extend when value is proven
+- [[bootstrapping principle enables self-improving systems]] — the deeper architecture: property triggers let notes participate in vault maintenance, making the system self-improving through its own content
+- [[maturity field enables agent context prioritization]] — trigger dimension: seedling/developing/evergreen status determines review frequency and surfacing priority
+- [[type field enables structured queries without folder hierarchies]] — existing trigger dimension: `type:` field enables category-based triggers (tensions for synthesis, methodology for implementation review)
+- [[intermediate representation pattern enables reliable vault operations beyond regex]] — infrastructure prerequisite: property diff on writes and compound condition checking both depend on reliable YAML extraction; an IR layer makes property access typed lookups rather than regex parsing that breaks on multiline values
+- [[reconciliation loops that compare desired state to actual state enable drift correction without continuous monitoring]] — complementary architecture: periodic property scans are reconciliation loops where each condition defines a desired state; reconciliation catches the accumulated drift that event-driven property triggers miss
+- [[confidence thresholds gate automated action between the mechanical and judgment zones]] -- response calibration for triggered actions: property triggers range from safe read-only operations (adding to review queue) to risky write operations (auto-modifying content), and confidence scoring determines which response tier the trigger activates; a staleness detection with high certainty can auto-queue while a reweave check with medium certainty should only suggest, applying the three-tier pattern to property-triggered workflow design
+- [[maintenance scheduling frequency should match consequence speed not detection capability]] — scheduling framework for trigger frequency: consequence speed provides the principled answer to whether a property condition needs event-driven detection or periodic scanning — schema violations propagate instantly (per-event trigger), staleness develops over weeks (periodic scan), and the five-tier spectrum maps each property condition to its appropriate detection cadence
+- [[three concurrent maintenance loops operate at different timescales to catch different classes of problems]] — scheduling container for property triggers: each trigger maps onto a specific loop (fast for schema, medium for orphan/staleness, slow for reweave), and the three-loop architecture determines which triggers earn event-driven infrastructure versus periodic scanning
+- [[prospective memory requires externalization]] — the cognitive problem property triggers solve: agents cannot remember to check conditions across sessions, so notes that surface themselves when conditions are met eliminate the prospective memory demand entirely
+
+Topics:
+- [[maintenance-patterns]]

package/methodology/progressive disclosure means reading right not reading less.md

@@ -0,0 +1,69 @@
+---
+description: The efficiency framing misses the point — tokens are free, quality requires depth, so the goal is a dense relevant context window not a sparse one
+kind: research
+topics: ["[[discovery-retrieval]]"]
+---
+
+# progressive disclosure means reading right not reading less
+
+The common interpretation of progressive disclosure is efficiency: read less, save tokens, minimize context. This is the wrong framing. The system philosophy inverts it: fill the context window, but fill it with what matters.
+
+## Why the Efficiency Framing Fails
+
+Tokens are free. Context window capacity is not the scarce resource it once was. What remains scarce is relevance. A context window stuffed with whatever loaded first performs worse than a smaller context loaded with exactly what the task needs.
+
+The failure mode isn't "too much reading." It's "undiscerning reading." Loading all descriptions with `rg "^description:" thinking/*.md` dumps everything regardless of relevance. At scale this fills context with noise. The problem isn't the token count — it's that most of those tokens don't help.
+
+## Curation Over Reduction
+
+Progressive disclosure provides the mechanism for curation, not reduction. Since [[spreading activation models how agents should traverse]], the discovery layers implement decay-based context loading — high decay stops at descriptions, low decay reads full files. The layers — file tree, descriptions, MOCs, outlines, semantic search — let you find what's relevant before you load it fully. Since [[dual-coding with visual elements could enhance agent traversal]], visual representations (Mermaid diagrams, relationship graphs) might constitute an additional layer type — one that encodes structural relationships in a format where patterns are visible rather than described. This remains a research direction: the current layers are all text-based, and visual layers would require verifying that multimodal processing provides genuine filtering benefit. The MOC path provides curated navigation that demonstrably works; semantic search remains useful for candidate generation but not as the primary discovery mechanism. The pattern is:
+
+```
+find relevant content (MOC or vsearch) → load it fully → follow links that matter
+```
+
+This isn't about reading less. It's about reading right. Once you've identified relevant notes, read them completely. Don't skim when depth matters. Quality comes from understanding, and understanding requires enough context to grasp the full picture.
+
+The MOC-first pattern works because of network structure: since [[small-world topology requires hubs and dense local links]], MOCs serve as hub nodes that create shortcuts across the knowledge graph. Starting from a hub node means most relevant content is 1-2 hops away, not buried in a linear search. This is why curated navigation (following MOC links) outperforms semantic search for initial orientation — you're traversing a graph optimized for short paths. And since [[complete navigation requires four complementary types that no single mechanism provides]], the disclosure layers succeed precisely because they exercise all four navigation types in sequence: file tree scanning provides global orientation (where am I?), MOC reading provides local orientation (what's nearby?), following wiki links provides contextual depth (what's related to this?), and searching provides supplemental discovery (how else can I find things?). The progressive disclosure stack is not an arbitrary ordering but a traversal of complementary navigation types, which is why skipping a layer creates a predictable blind spot.
+
+## Progressive Summarization as Implementation
+
+Tiago Forte's Progressive Summarization provides a concrete methodology for this philosophy. The technique creates compression layers: Notes → Bold → Highlights → Summary. Each layer is progressively more compressed, letting readers choose their depth based on need.
+
+For agent-operated vaults, this translates to a layered content strategy. Source materials live in archive at full fidelity. Reference notes compress key insights. Wiki-linkable claims distill the core argument. Agents navigate at the appropriate abstraction level — summaries for broad scanning when building context across many notes, full content for deep analysis when a single note is central to the task.
+
+The key insight: these aren't mutually exclusive depths but simultaneous layers. The archive doesn't disappear when you create the summary. Both exist, and the agent chooses which to load based on what the task requires. This is why the system keeps raw sources in archive alongside the extracted claims — the compression layers coexist rather than replacing each other.
+
+## The Dense Context Window
+
+The goal is a context window dense with relevant material. Not sparse. Not efficient. Dense with what matters for this task. Since [[descriptions are retrieval filters not summaries]], each discovery layer serves the curation function: helping you decide what deserves the full-depth treatment.
+
+The question at each step isn't "can I stop here?" but "does this warrant going deeper?" Sometimes the answer is yes — follow the link, read the full note, load the related content. Sometimes no — the description told you enough to know this isn't relevant. Progressive disclosure gives you the information to make that call, not permission to skip depth.
+
+But the filtering layer only works when compression preserves enough distinctiveness for correct decisions. Since [[sense-making vs storage does compression lose essential nuance]], some ideas may be systematically invisible at the filter layer — not because the description is poorly written, but because the idea's distinctive features ARE the nuance that compression discards. For these ideas, the disclosure layer fails not through quality defects but through format incompatibility. The agent never reaches the full content because the filter never identified relevance in the first place.
+
+Since [[testing effect could enable agent knowledge verification]], this assumption becomes testable. If descriptions truly enable accurate filtering decisions, an agent should be able to predict note content from title and description alone. The recite skill applies the testing effect: read only metadata, predict content, score against actual content. Notes where prediction fails are exactly notes where the disclosure layer has broken — the filtering information doesn't match what's being filtered. Since [[retrieval verification loop tests description quality at scale]], this verification extends to the entire vault: systematic scoring across all notes reveals patterns (which types of notes fail, common failure modes, whether quality correlates with age) and turns disclosure layer quality from assumption to measured property. This is the verification mechanism for progressive disclosure's core assumption.
+
+But the deeper risk is that structural completeness creates false confidence: since [[metacognitive confidence can diverge from retrieval capability]], the system may feel navigable through surface metrics (descriptions exist, MOCs are organized) while actual retrieval systematically fails. The disclosure layers exist to enable curation — but only if they actually predict what they're filtering. The verification loop closes this gap by testing empirically, not assuming structurally.
+
+## The Design Decision
+
+This is a CLOSED claim — a foundational choice about how the system works. We could have designed for efficiency: minimal context, just-enough reading, token conservation. We chose the opposite: fill the context window with quality content, use disclosure layers to curate what "quality" means for each task.
+
+The phrase "reading right not reading less" captures the philosophy. There is no virtue in reading less. The virtue is in reading what matters.
+---
+
+Relevant Notes:
+- [[descriptions are retrieval filters not summaries]] — describes the progressive disclosure layers and how descriptions enable filtering without full loading
+- [[spreading activation models how agents should traverse]] — provides the cognitive science foundation: progressive disclosure IS decay-based context loading
+- [[small-world topology requires hubs and dense local links]] — explains WHY MOC-first navigation works: hub nodes create shortcuts that keep relevant content 1-2 hops away
+- [[intermediate packets enable assembly over creation]] — Progressive Summarization creates intermediate packets at multiple compression levels
+- [[testing effect could enable agent knowledge verification]] — tests whether the disclosure layer actually works: if descriptions don't predict content, filtering fails
+- [[retrieval verification loop tests description quality at scale]] — operationalizes the test at vault-wide scale: systematic scoring reveals patterns and turns disclosure layer quality from assumption to measured property
+- [[metacognitive confidence can diverge from retrieval capability]] — tests the failure mode where disclosure assumptions break: structural completeness produces false navigability confidence while actual retrieval fails
+- [[dual-coding with visual elements could enhance agent traversal]] — proposes visual representations as an additional layer type alongside the current text-based disclosure layers
+- [[sense-making vs storage does compression lose essential nuance]] — the tension: some ideas may be invisible at the filter layer because their distinctive features are the nuance that compression discards
+- [[complete navigation requires four complementary types that no single mechanism provides]] — explains WHY the disclosure layers are ordered as they are: each layer exercises a different navigation type (global, local, contextual, supplemental), so the progressive sequence is a traversal of complementary types, not an arbitrary ordering
+
+Topics:
+- [[discovery-retrieval]]

package/methodology/progressive schema validates only what active modules require not the full system schema.md

@@ -0,0 +1,49 @@
+---
+description: Each module declares its required YAML fields and validation checks only active modules — otherwise disabling modules does not reduce schema demands, creating an all-or-nothing trap
+kind: research
+topics: ["[[design-dimensions]]", "[[note-design]]"]
+methodology: ["Original", "Systems Theory"]
+source: [[composable-knowledge-architecture-blueprint]]
+---
+
+# progressive schema validates only what active modules require not the full system schema
+
+A composable knowledge system fails its own premise if validation enforces the full schema regardless of which modules are active. Since [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]], each module is a capability that can be enabled or disabled independently. But if the validation module checks every field that any module might need — topics for MOCs, methodology for processing pipeline, semantic neighbors for search — then disabling those modules does not actually reduce the system's demands on the user. The schema becomes a monolith wearing a composable costume: the modules are theoretically independent, but in practice you must satisfy all their requirements because the validator does not know which modules are running.
+
+The fix is straightforward in principle: each module declares the YAML fields it requires, and the validator checks only the fields belonging to active modules. A user with only yaml-schema and wiki-links enabled should never see errors about missing `topics` or `methodology` fields, because those fields belong to the mocs module and processing-pipeline module respectively, neither of which is active. This is the knowledge system equivalent of optional types in programming — a field like `topics` is required IF the mocs module is active, optional otherwise. The schema definition needs conditional requirements: `topics: required_when(mocs)`. The generated context file includes the topics field documentation only when mocs is enabled, and the validation module checks for topics only when mocs is active.
+
+This matters because the alternative — validating everything regardless of activation state — creates what the modular synthesis tradition would recognize as a broken patch routing. Since [[the no wrong patches guarantee ensures any valid module combination produces a valid system]], a foundation-only configuration that triggers validation errors from convention-layer fields is arguably a "wrong patch" — the module combination is valid but the validation layer rejects notes that satisfy all active requirements. Progressive schema is what extends the no wrong patches guarantee from structural integrity (no data corruption) to operational integrity (no spurious warnings). Since [[four abstraction layers separate platform-agnostic from platform-dependent knowledge system features]], the module dependency graph follows the layer hierarchy: foundation modules (yaml-schema, wiki-links) have no dependencies, convention modules (atomic-notes, mocs) build on foundation, automation modules (validation, processing-pipeline) build on convention. Progressive schema respects this hierarchy by checking only the fields from the user's current active layer and below. A user at the convention layer sees convention-level requirements. A user at the foundation layer sees only the universal base: a description field and whatever their note contains. The validator does not look upward into layers the user has not reached.
+
+The connection to enforcement style deepens the design. Since [[schema enforcement via validation agents enables soft consistency]], the vault already uses soft enforcement — warnings rather than blocks. Progressive schema adds a second axis of flexibility: not only does validation warn instead of block, it also scopes which warnings fire. Without progressive scoping, soft enforcement merely makes the pain gentler (a warning instead of an error about missing methodology), but the pain still occurs for fields the user has no reason to populate. With progressive scoping, the warning never fires in the first place because the validator knows that methodology belongs to an inactive module. The combination of soft enforcement and progressive scope creates the loosely coupled validation that composability requires.
+
+The practical consequence is that progressive schema prevents a specific failure mode at the intersection of two sibling anti-patterns. Since [[premature complexity is the most common derivation failure mode]], deploying too much system at once overwhelms users before they develop working habits. Since [[configuration paralysis emerges when derivation surfaces too many decisions]], exposing too many choices prevents setup from completing. Non-progressive schema creates a third failure mode that operates during daily use rather than at setup or deployment: the user has successfully configured a minimal system, has started creating notes with just descriptions and wiki links, and then encounters validation warnings about topics, methodology, and relevant_notes — fields belonging to modules they deliberately chose not to enable. The response is predictable: either enable everything to silence the warnings (defeating the purpose of composable adoption), add placeholder values to satisfy the validator (the schema-stuffing anti-pattern that [[schema evolution follows observe-then-formalize not design-then-enforce]] identifies as false compliance), or abandon the system. All three responses are failures of the architecture, not the user.
+
+The implementation pattern maps cleanly to the existing module dependency graph. Each module's declaration includes not only its code dependencies (what other modules must be active) but also its schema contributions (what YAML fields it adds to the note format). Since [[module communication through shared YAML fields creates loose coupling without direct dependencies]], the schema assembly inherits the same event-bus architecture: each module publishes its field requirements to a shared declaration surface, and the validator subscribes by collecting those declarations into a runtime schema. The validator reads the active module list, collects their schema contributions, and validates only those fields. Foundation modules contribute `description`. The wiki-links module contributes nothing additional to the schema — it operates through inline link syntax, not YAML fields. The mocs module contributes `topics`. The processing-pipeline contributes `methodology` and `relevant_notes`. The validation module itself contributes nothing — it reads what others declare. This means the schema is assembled dynamically from the active module set, and since [[schema validation hooks externalize inhibitory control that degrades under cognitive load]], the assembled schema is what the hooks enforce. The hooks fire reliably regardless of the agent's cognitive state, but what they check is scoped to what matters.
+
+Progressive schema also interacts with implicit dependencies in a way that makes both harder to detect. Since [[implicit dependencies create distributed monoliths that fail silently across configurations]], a module that reads a field written by another module works when both are active but fails silently when the writer is disabled. The progressive validator is doing its job — it checks only what active modules require — but the implicit dependency means the reader's actual requirements exceed its declared requirements. Progressive validation works perfectly for modules with honest declarations and masks problems in modules with incomplete 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.
+
+There is a shadow side. Progressive schema creates the risk of silent under-validation. A user who should have enabled mocs but did not will never see warnings about missing topics, which means their notes will lack the navigation metadata that mocs would have organized. The system works perfectly within its configured scope — and the user may not realize that scope is too narrow until they have hundreds of notes with no topic assignments and decide to enable mocs retroactively. The mitigation is twofold: the module recommendation engine should surface "you have 50 notes and no topics — consider enabling mocs" as proactive guidance, and the module activation process should include a backfill step that scans existing notes and flags which ones need updates for the newly activated module's schema requirements. This is incremental adoption working as designed — since [[schema evolution follows observe-then-formalize not design-then-enforce]], the evidence of 50 topic-less notes IS the observation that justifies adding the mocs module, and the backfill is the formalization step.
+
+The deeper principle is that validation scope should match activation scope. In a monolithic system, the full schema applies everywhere because everything is always active. In a composable system, what is active varies by configuration, and validation that does not respect that variation undermines the composability it serves. Progressive schema is not a feature of validation — it is a requirement of composability. Without it, the modules are toggleable but the quality gates are not, and the quality gates are what the user actually encounters during daily work. The composability promise — start simple, add what you need, never encounter demands from features you have not adopted — requires that validation, the most frequent point of system-user interaction, honor the same principle of independent activation that the module architecture was designed around.
+
+---
+---
+
+Relevant Notes:
+- [[composable knowledge architecture builds systems from independent toggleable modules not monolithic templates]] — provides the architectural context: modules are independently toggleable, so their schema requirements must be independently activatable; progressive schema is what makes module independence extend to the validation layer
+- [[schema enforcement via validation agents enables soft consistency]] — the enforcement mechanism that progressive schema operates through: soft validation already warns rather than blocks, and progressive schema further scopes WHICH warnings fire based on module activation state
+- [[schema evolution follows observe-then-formalize not design-then-enforce]] — complementary temporal axis: evolution governs which fields exist and when they get formalized, progressive schema governs which of those fields are checked at any given moment based on active modules; evolution is change over time, progressive schema is scope at a point in time
+- [[four abstraction layers separate platform-agnostic from platform-dependent knowledge system features]] — the layer hierarchy that module dependencies follow: foundation modules have no schema requirements beyond description, convention modules add topics and linking fields, automation modules add processing metadata; progressive schema checks only the fields from active layers
+- [[premature complexity is the most common derivation failure mode]] — progressive schema prevents the validation equivalent of premature complexity: without it, enabling basic features forces compliance with advanced schemas, creating the same overwhelming first-encounter that premature complexity creates at the system level
+- [[configuration paralysis emerges when derivation surfaces too many decisions]] — related failure mode at a different layer: configuration paralysis overwhelms during setup choices, while non-progressive schema overwhelms during daily use by demanding fields the user has not yet decided to care about
+- [[schema validation hooks externalize inhibitory control that degrades under cognitive load]] — the enforcement infrastructure: hooks fire regardless of cognitive state, but progressive schema determines what those hooks check; without progressive scoping, hooks would enforce requirements from modules the user never activated
+- [[the no wrong patches guarantee ensures any valid module combination produces a valid system]] — extends the guarantee from structural to operational: without progressive schema, valid module combinations can produce spurious validation warnings, which is arguably a wrong-patch failure at the quality-gate layer even if data integrity holds
+- [[module communication through shared YAML fields creates loose coupling without direct dependencies]] — the communication substrate: progressive schema assembles its runtime validation set from the same shared-field declarations that modules use for inter-module coordination; field ownership discipline maps directly to schema contribution declarations
+- [[derived systems follow a seed-evolve-reseed lifecycle]] — progressive schema enables the seed phase to start clean: minimal module activation means minimal validation requirements, so the user builds working habits before encountering convention-layer or automation-layer schema demands; each evolution step that enables a new module progressively expands validation scope
+- [[multi-domain systems compose through separate templates and shared graph]] — progressive schema becomes especially important in multi-domain systems where different domains contribute different schema fields: a therapy domain's trigger and pattern_type fields should not create validation noise for research notes, and progressive scoping by domain-module activation prevents cross-domain schema interference
+- [[implicit dependencies create distributed monoliths that fail silently across configurations]] — the masking interaction: progressive validation correctly stops checking fields from disabled modules, but this makes undeclared field reads invisible; a module that reads topics without declaring a dependency on the mocs module works when mocs is active and fails silently when it is disabled, and the validator never flags the gap because it is checking the right things for the wrong reasons
+- [[friction-driven module adoption prevents configuration debt by adding complexity only at pain points]] — ensures friction-driven adoption extends to daily experience: a user who has only added yaml-schema and wiki-links never encounters validation demands from modules they have not yet adopted, so the enforcement surface matches the adoption state
+
+Topics:
+- [[design-dimensions]]
+- [[note-design]]