EA Connected Vault Setup
Create a light navigation layer, not a new taxonomy or a content rewrite. Preserve every note's text, existing properties, filenames, folders, templates, query blocks, and links unless the requested linking requires a small additive edit.
Scope and safety
- Work only on the user-designated corpus. Exclude configuration, templates, attachments, generated/cache folders, daily logs, and existing database/query files unless the user includes them.
- Search filenames, aliases, frontmatter keys, links, and existing root/MOC notes before creating anything. Reuse a clearly matching root rather than duplicating it.
- Use the exact, capitalized property names
Parents and Related. Both are YAML/Markdown lists of wikilinks, even when they initially contain one item. Do not replace populated values; merge without changing their existing representation or casing.
- In this initial setup, give each child exactly one
Parents entry: its cluster root. Do not introduce multiple root assignments.
- Do not infer a topical relationship from name similarity alone. Leave uncertain notes in a deliberately named holding root (for example,
Unsorted concepts) and flag them.
- This operation changes many files. First produce an inventory and proposed clustering; obtain confirmation before writing. After approval, apply only additive, minimal diffs and report every created/changed file.
1. Inventory and cluster proposal
- Read each in-scope Markdown note's title, aliases, frontmatter, headings, outbound links, and enough body text to establish its subject. Read linked context when it resolves ambiguity.
- Exclude the future root notes from the child count. Identify existing hubs, broad concepts, and duplicate/near-duplicate titles.
- Propose topic clusters that are semantically coherent and navigable:
- Target 5–10 roots for a substantial collection.
- Target roughly 8–15 child notes per root. Use fewer roots for a small corpus; split an oversized coherent cluster only when it has a meaningful internal division.
- Give each root a specific, durable, plural-friendly name (for example,
Plant functional traits, not Miscellaneous).
- Assign every in-scope note exactly one proposed root, with a one-line reason for ambiguous assignments.
- Present the proposal as a compact table: root name, intended scope, child count, and any uncertain notes. Do not write yet.
2. Create roots and the child Base
After approval:
Create the shared Base at __Support/Bases/Children by Parents.base unless the user specifies another support location. Copy the bundled [assets/Children by Parents.base](assets/Children by Parents.base) verbatim.
Create a Roots/ folder at the vault root if it does not already exist. Create every new root note in Roots/, using that vault's root/topic template when one exists. If there is no template, use this minimal structure:
---
---
# Root name
> [!note] AI-generated
> Created by EA Connected Vault Setup as a navigation root. Review the cluster boundary before treating it as a settled taxonomy.
![[__Support/Bases/Children by Parents.base]]
Keep the embed directly below the title/provenance. The Base resolves this to the root that embeds it, so the same file lists the correct children in every root. Its table displays the child Note first, followed by its Related list.
If a reused root already exists outside Roots/, leave it in place; do not rename or move it. Add the Base embed only if it has no equivalent child listing, and do not overwrite or rearrange its content.
The Base contents are:
filters: 'Parents.contains(this.file)'
properties:
file.name:
displayName: Note
Parents:
displayName: Parents
Related:
displayName: Related
views:
- type: table
name: Children
order:
- file.name
- Related
3. Assign each child
For every approved in-scope, non-root note:
Add this list to the existing YAML frontmatter. Preserve ordering and formatting otherwise:
Parents:
- "[[Root name]]"
If the note lacks YAML frontmatter, add a minimal block containing this Parents list.
Do not change an existing non-empty Parents list without flagging it in the review report. If it clearly points to an obsolete equivalent, ask before replacing it.
Verify every Parents target resolves to a root note and every root Base has at least one expected child.
4. Make each note alive with discourse-advancing body links
Make a separate pass after parent assignment. A frontmatter list is only a navigation aid: it must not be the sole connection between notes. Review every substantive paragraph rather than aiming for a quota.
For each candidate target, read the target note and score the prospective link. Add it only when its overall case is strong; the purpose is to deepen the note's line of thought, not to make its graph denser.
| Criterion |
0 points |
1 point |
2 points |
| 1. Available target |
No suitable existing note. |
A broadly adjacent note exists. |
A specific existing note directly covers the concept, mechanism, method, evidence, or implication. |
| 2. Contribution to discourse |
Merely interesting, decorative, or navigational. |
Helpful context. |
Advances the paragraph's reasoning: it defines a premise, supplies a mechanism, qualifies a claim, provides evidence, or opens a necessary next question. |
| 3. Existing treatment |
The target is already linked nearby and another link adds no value. |
Mentioned/linked elsewhere in the note, but this paragraph needs a local entry point. |
Not already linked in the relevant context, or a deliberate repeated link materially improves navigation. |
| 4. Minimal integration |
Requires new claims or rewriting. |
Requires a short contextual line below the paragraph. |
Can be integrated by linking an existing phrase or making only a word-level edit. |
| 5. Semantic precision |
The relationship is ambiguous or misleading. |
Plausible but indirect. |
The link label and target accurately express the exact relationship implied by the paragraph. |
| 6. Reader utility |
The reader gains little by opening it. |
Useful background. |
Opening the target is likely to resolve a real conceptual, methodological, or evidential need created by this paragraph. |
Add inline links for candidates scoring 9–12, and normally reject candidates scoring 0–6. Treat 7–8 as editorial judgment: retain only when the link clearly improves the reader's path through the argument.
Prefer direct inline links. Convert a natural, unlinked mention to [[Canonical note title|visible phrase]]. Make only the smallest word-level edit necessary for a grammatical, precise anchor; never alter a source claim or manufacture a sentence.
When a candidate clears the threshold but lacks a natural anchor, add a compact contextual line immediately below the relevant existing paragraph, for example:
*Related: [[Concept A]] and [[Concept B]].*
This line must qualify or extend that paragraph without adding an unverified claim. Do not append detached link dumps or use these lines to satisfy a quota.
Add or merge the strongest body-level connections into a capitalized Related list in frontmatter. There is no fixed length: include only the compact set of links that remains useful as navigation. Related supplements body links rather than replacing them:
Related:
- "[[Concept A]]"
- "[[Concept B]]"
Preserve existing links and Related values. A second contextual link to the same note is valid only when it gives a later paragraph its own needed entry point. If no candidate clears the threshold, add none and list the note for human review.
5. Validate and report
- Confirm that each child has exactly one resolving
Parents entry.
- Confirm that every Base file is valid YAML and its filter is exactly
Parents.contains(this.file).
- Check that every substantive paragraph was considered against the link score, that each added link meets the discourse/precision threshold, and that
Related only supports rather than substitutes for those links.
- Check for broken wikilinks introduced by this setup and for accidental links to the Base/template itself.
- Report:
Roots/ folder created/reused, roots created/reused, Base location, number of children assigned, number of inline/contextual links and Related lists added, uncertain notes, and anything intentionally untouched.
- Clearly label the root notes as AI-created; do not add AI-generated prose to existing notes beyond the requested structural properties and links.
1---2name: ea-connected-vault-setup3description: Organize a sparse, mostly unconnected Markdown/Obsidian vault into a light topic hierarchy. Use when a user wants 5–10 topic root notes, a capitalized `Parents` list assigning notes to topic roots, an embedded Obsidian Base that lists each root's children, and meaningful body-level/`Related` wikilinks that make concept notes navigable without substantive rewriting.4---56# EA Connected Vault Setup78Create a **light navigation layer**, not a new taxonomy or a content rewrite. Preserve every note's text, existing properties, filenames, folders, templates, query blocks, and links unless the requested linking requires a small additive edit.910## Scope and safety1112- Work only on the user-designated corpus. Exclude configuration, templates, attachments, generated/cache folders, daily logs, and existing database/query files unless the user includes them.13- Search filenames, aliases, frontmatter keys, links, and existing root/MOC notes before creating anything. Reuse a clearly matching root rather than duplicating it.14- Use the exact, capitalized property names `Parents` and `Related`. Both are YAML/Markdown lists of wikilinks, even when they initially contain one item. Do not replace populated values; merge without changing their existing representation or casing.15- In this initial setup, give each child exactly one `Parents` entry: its cluster root. Do not introduce multiple root assignments.16- Do not infer a topical relationship from name similarity alone. Leave uncertain notes in a deliberately named holding root (for example, `Unsorted concepts`) and flag them.17- This operation changes many files. First produce an inventory and proposed clustering; obtain confirmation before writing. After approval, apply only additive, minimal diffs and report every created/changed file.1819## 1. Inventory and cluster proposal20211. Read each in-scope Markdown note's title, aliases, frontmatter, headings, outbound links, and enough body text to establish its subject. Read linked context when it resolves ambiguity.222. Exclude the future root notes from the child count. Identify existing hubs, broad concepts, and duplicate/near-duplicate titles.233. Propose topic clusters that are semantically coherent and navigable:24 - Target **5–10** roots for a substantial collection.25 - Target roughly **8–15 child notes per root**. Use fewer roots for a small corpus; split an oversized coherent cluster only when it has a meaningful internal division.26 - Give each root a specific, durable, plural-friendly name (for example, `Plant functional traits`, not `Miscellaneous`).27 - Assign every in-scope note exactly one proposed root, with a one-line reason for ambiguous assignments.284. Present the proposal as a compact table: root name, intended scope, child count, and any uncertain notes. Do not write yet.2930## 2. Create roots and the child Base3132After approval:33341. Create the shared Base at `__Support/Bases/Children by Parents.base` unless the user specifies another support location. Copy the bundled [`assets/Children by Parents.base`](assets/Children by Parents.base) verbatim.352. Create a `Roots/` folder at the vault root if it does not already exist. Create every new root note in `Roots/`, using that vault's root/topic template when one exists. If there is no template, use this minimal structure:3637 ```md38 ---39 ---4041 # Root name4243 > [!note] AI-generated44 > Created by EA Connected Vault Setup as a navigation root. Review the cluster boundary before treating it as a settled taxonomy.4546 ![[__Support/Bases/Children by Parents.base]]47 ```4849 Keep the embed directly below the title/provenance. The Base resolves `this` to the root that embeds it, so the same file lists the correct children in every root. Its table displays the child **Note** first, followed by its **Related** list.503. If a reused root already exists outside `Roots/`, leave it in place; do not rename or move it. Add the Base embed only if it has no equivalent child listing, and do not overwrite or rearrange its content.5152The Base contents are:5354```yaml55filters: 'Parents.contains(this.file)'56properties:57 file.name:58 displayName: Note59 Parents:60 displayName: Parents61 Related:62 displayName: Related63views:64 - type: table65 name: Children66 order:67 - file.name68 - Related69```7071## 3. Assign each child7273For every approved in-scope, non-root note:74751. Add this list to the existing YAML frontmatter. Preserve ordering and formatting otherwise:7677 ```yaml78 Parents:79 - "[[Root name]]"80 ```81822. If the note lacks YAML frontmatter, add a minimal block containing this `Parents` list.833. Do not change an existing non-empty `Parents` list without flagging it in the review report. If it clearly points to an obsolete equivalent, ask before replacing it.844. Verify every `Parents` target resolves to a root note and every root Base has at least one expected child.8586## 4. Make each note alive with discourse-advancing body links8788Make a separate pass after parent assignment. A frontmatter list is only a navigation aid: it must not be the sole connection between notes. Review **every substantive paragraph** rather than aiming for a quota.8990For each candidate target, read the target note and score the prospective link. Add it only when its overall case is strong; the purpose is to deepen the note's line of thought, not to make its graph denser.9192| Criterion | 0 points | 1 point | 2 points |93| --- | --- | --- | --- |94| **1. Available target** | No suitable existing note. | A broadly adjacent note exists. | A specific existing note directly covers the concept, mechanism, method, evidence, or implication. |95| **2. Contribution to discourse** | Merely interesting, decorative, or navigational. | Helpful context. | Advances the paragraph's reasoning: it defines a premise, supplies a mechanism, qualifies a claim, provides evidence, or opens a necessary next question. |96| **3. Existing treatment** | The target is already linked nearby and another link adds no value. | Mentioned/linked elsewhere in the note, but this paragraph needs a local entry point. | Not already linked in the relevant context, or a deliberate repeated link materially improves navigation. |97| **4. Minimal integration** | Requires new claims or rewriting. | Requires a short contextual line below the paragraph. | Can be integrated by linking an existing phrase or making only a word-level edit. |98| **5. Semantic precision** | The relationship is ambiguous or misleading. | Plausible but indirect. | The link label and target accurately express the exact relationship implied by the paragraph. |99| **6. Reader utility** | The reader gains little by opening it. | Useful background. | Opening the target is likely to resolve a real conceptual, methodological, or evidential need created by this paragraph. |100101- Add inline links for candidates scoring **9–12**, and normally reject candidates scoring **0–6**. Treat **7–8** as editorial judgment: retain only when the link clearly improves the reader's path through the argument.102- Prefer direct inline links. Convert a natural, unlinked mention to `[[Canonical note title|visible phrase]]`. Make only the smallest word-level edit necessary for a grammatical, precise anchor; never alter a source claim or manufacture a sentence.103- When a candidate clears the threshold but lacks a natural anchor, add a compact contextual line immediately below the relevant existing paragraph, for example:104105 ```md106 *Related: [[Concept A]] and [[Concept B]].*107 ```108109 This line must qualify or extend that paragraph without adding an unverified claim. Do not append detached link dumps or use these lines to satisfy a quota.110- Add or merge the strongest body-level connections into a capitalized `Related` list in frontmatter. There is **no fixed length**: include only the compact set of links that remains useful as navigation. `Related` supplements body links rather than replacing them:111112 ```yaml113 Related:114 - "[[Concept A]]"115 - "[[Concept B]]"116 ```117118- Preserve existing links and `Related` values. A second contextual link to the same note is valid only when it gives a later paragraph its own needed entry point. If no candidate clears the threshold, add none and list the note for human review.119120## 5. Validate and report121122- Confirm that each child has exactly one resolving `Parents` entry.123- Confirm that every Base file is valid YAML and its filter is exactly `Parents.contains(this.file)`.124- Check that every substantive paragraph was considered against the link score, that each added link meets the discourse/precision threshold, and that `Related` only supports rather than substitutes for those links.125- Check for broken wikilinks introduced by this setup and for accidental links to the Base/template itself.126- Report: `Roots/` folder created/reused, roots created/reused, Base location, number of children assigned, number of inline/contextual links and `Related` lists added, uncertain notes, and anything intentionally untouched.127- Clearly label the root notes as AI-created; do not add AI-generated prose to existing notes beyond the requested structural properties and links.
lnilya