In the intricate world of financial documentation, clarity and consistency are paramount. The FinanceCompendium vault, a treasure trove of financial knowledge, relies on meticulous formatting to ensure its information is not only accurate but also easily digestible and navigable. This article delves deep into the comprehensive subagent instructions designed for manual formatting remediation within this vault. It's a high-touch, fully manual endeavor, emphasizing precision over speed, and strictly prohibiting any form of scripting or automation. We'll break down the workflow, from initial assessment to final verification, ensuring every markdown document within the FinanceCompendium adheres to the highest standards of formatting.

⛔️ The Cardinal Rules: What NOT To Do

Before we embark on the detailed remediation process, it's crucial to understand the absolute prohibitions. These aren't mere suggestions; they are strict mandates to preserve the integrity and manual nature of the task. First and foremost, no scripts are allowed. This means no Python, no Bash, and absolutely no automation scripts whatsoever. The goal is a human touch, ensuring nuanced understanding and correction. Consequently, bulk operations are also forbidden. Tools like sed, awk, or regex find-replace on files are off-limits. Each correction must be deliberate and targeted. If you encounter an ambiguous fix – something that isn't crystal clear – do not guess. Skip it and meticulously log it in the bead issue. This ensures that only certain and correct changes are made. Furthermore, wholesale rewrites are prohibited. You should use targeted Edit tool calls, not Write commands that replace entire files, preserving the original structure as much as possible. Finally, and this is a critical point, do not touch image links. Under absolutely no circumstance should you modify any image link, whether it's in the ![[...]] format or the ![...](...) format. Leave them exactly as they are. These rules are the bedrock of the remediation process, ensuring that the task remains a manual, detailed, and accurate undertaking.

📋 Understanding the Task at Hand

Your assignment involves tackling specific "bead issues" (identified by FIN-xxxxx codes) that point to markdown documents within the FinanceCompendium vault needing formatting remediation. This isn't a quick job; it requires a systematic approach. The process begins with reading the document iteratively in chunks, typically between 300 and 500 lines. For each chunk, you'll need to identify and fix formatting issues using the designated Edit tool. This manual correction is key. Following the fixes, you'll be responsible for generating relevant multi-word tag phrases that accurately reflect the content. After each chunk is processed, you must update the bead issue with detailed correction logs, providing a clear audit trail of your work. The final step for each chunk is to verify that the document renders correctly with your changes. This iterative cycle of read, fix, tag, log, and verify forms the core of the remediation workflow, ensuring a high degree of accuracy and thoroughness throughout the process.

🔄 The Remediation Workflow in Phases

This comprehensive guide breaks down the formatting remediation into distinct, manageable phases, ensuring a structured and systematic approach to cleaning up the FinanceCompendium's markdown documents. Each phase builds upon the last, moving from broad assessment to granular correction and finally to strategic tagging and verification. Adhering to these phases will not only streamline the process but also guarantee that all necessary checks and balances are in place, resulting in a perfectly formatted and easily navigable vault.

Phase 1: Initial Assessment – Getting the Lay of the Land

The very first step in any remediation task is to understand what you're dealing with. This begins with reading the bead issue itself. Don't just glance at it; absorb all the information, especially the file path and any specific notes or context provided by the issue tracker. This initial intel can save you a lot of time and prevent misunderstandings later on. Once you have the file path, the next action is to read the first 500 lines of the document using the Read tool. This initial read isn't about fixing things yet; it's about getting a feel for the document's structure and identifying any glaring issues. Pay close attention to the document structure. How many level 1 headers (# Header) are there? This gives you a clue about the overall organization. Try to estimate the total document length – is it a short note or an extensive treatise? Note any obvious major problems that jump out, such as missing YAML frontmatter (the metadata block at the beginning), broken LaTeX equations, or unusual formatting that immediately seems out of place. This phase is all about reconnaissance. Think of yourself as a detective examining a crime scene – you're gathering initial clues and forming a preliminary hypothesis about the extent and nature of the 'damage' before you start collecting evidence or making arrests (corrections). A solid initial assessment ensures that your subsequent steps are well-informed and efficient, setting the stage for a successful remediation.

Phase 2: Chunk Planning – Dividing and Conquering

Once you have a good grasp of the document's overall structure from the initial assessment, it's time to break it down into manageable pieces. The strategy here is to split the document by level 1 markdown headers (# Header). This hierarchical approach ensures that you're working within logical sections of the document. The goal is to group these sections into chunks that are approximately 300-500 lines long. A buffer of ±100 lines is acceptable, allowing for flexibility based on content flow. When creating these chunks, always try to start each chunk at a # Header. This provides a clean entry point for processing. If you find that a single H1 section is excessively long and exceeds the 500-line limit, you should split it at the next logical break, such as a level 2 (##) or level 3 (###) header. This maintains semantic coherence within your chunks. Crucially, you must track your chunk boundaries meticulously. This means noting down the line ranges for each chunk, such as lines 1-450, lines 451-890, and so on. Keep a detailed chunk log in your working notes. This log is essential for organizing your work, ensuring no lines are missed, and accurately reporting progress. This phase transforms a potentially overwhelming document into a series of bite-sized tasks, making the remediation process far less daunting and much more systematic.

Phase 3: YAML Frontmatter Processing – The Document's Metadata Heart

The YAML frontmatter, located at the very beginning of a markdown file, is the document's metadata heart. It provides essential information like the title and tags, which are crucial for organization and discoverability within the FinanceCompendium vault. Your task here is to ensure this section is not only present but also correctly structured and populated. The required YAML structure looks like this:

---
title: Document Title in Title Case
primary_tags:
  - most important concept
  - core methodology
  - central theme
secondary_tags:
  - supporting concept one
  - related methodology
  - additional topic
  - peripheral theme
cssclasses: academia
---

Adhering to the specific YAML rules is vital. The title must be plain text, presented in Title Case, and contain absolutely no markdown formatting. The primary_tags field should list between 1 and 10 of the most important key phrases that define the document's core concepts, methodology, or theme. secondary_tags can include up to 25 next-most-relevant key phrases, offering supporting context. The cssclasses field must always be set to academia. Pay close attention to fields that need removal: REMOVE the tags field if it exists, as it's being replaced by primary_tags and secondary_tags. Similarly, REMOVE the key_concepts field as it's redundant. Also, REMOVE any linter-generated fields like linter-yaml-title-alias or source. Ensure there is exactly one blank line after the closing --- before the document content begins. If the frontmatter is missing entirely, you'll need to create it from scratch, deriving the title from the document's H1 header and inferring tags from the content you've already reviewed. This meticulous processing of the YAML frontmatter is critical for the vault's organization and searchability.

Phase 4: Chunk-by-Chunk Processing – The Granular Fixes

This is where the detailed, hands-on work happens. For each chunk of the document (remember, 300-500 lines), you'll systematically perform a series of checks and fixes in a specific order. This structured approach ensures that you address all potential issues methodically.

A. Structure & Headings: Building a Solid Foundation

Correct headings are the backbone of a well-structured document. Your first checks within each chunk involve ensuring heading integrity. You need to watch out for multiple H1 headers (# Title). If you find more than one, demote all subsequent H1s to ## Header to maintain a single document title. Pay attention to decimal headings like 3.1.1 Abstract; these should not be plain text but should be converted to #### 3.1.1 Abstract for proper hierarchy. Look for instances where there's a missing space after the # symbol in headings (e.g., ##Section); always add a space to make it ## Section. Similarly, ensure there's a blank line before a heading; text should not immediately precede a ## Header. Finally, problematic headers like ### Problem 2.1 should be converted to a bold paragraph (**Problem 2.1**) rather than a formal heading, as they often represent specific examples rather than structural divisions.

B. Text & Paragraphs: Ensuring Readability

Readability is key to comprehension. You'll be looking for common text formatting errors. Mid-sentence line breaks are a frequent issue, especially in documents generated from different sources. If a line ends without a sentence-ending punctuation mark (.?!:;) and the next line starts with a lowercase letter, join them into one continuous line. However, be cautious! There are specific STOP Conditions for joining lines. Do NOT join if the second line begins with a pipe (| for tables), a hyphen (-) or asterisk (* for lists), a greater-than sign (> for blockquotes), $ (for math blocks), ``` (for code blocks), or a number followed by a period (indicating a numbered list). You also need to collapse multiple blank lines down to a single blank line to avoid visual clutter. Finally, watch out for broken words, often resulting from Optical Character Recognition (OCR) errors, like di erent or e ect. Simply join these into their correct forms: different, effect, hypothesis.

C. Lists: Order and Clarity

Lists, whether ordered or unordered, need consistent formatting. Standardize bullet markers: replace *, +, •, ○ with the standard hyphen (-). Ensure there are no blank lines between list items; these should be removed to keep the list contiguous. If a list immediately follows a paragraph, make sure there's a blank line before the list starts for proper separation. For numbered lists, check that they follow the 1. Item format, adding the missing dot if you find errors like 1 Item.

D. Mathematics & LaTeX: Precision in Equations

Mathematical expressions require rigorous formatting. For inline math ($...$), ensure there are no spaces between the dollar sign and the content (e.g., $x + y$ is correct, $ x + y $ is not). If you encounter currency symbols that might interfere with math rendering, escape them as \$50 if $50 causes issues. For block math ($...$), the delimiters must be on their own lines, like this:

$
E = mc^2
$

There should also be one blank line before the opening $ and after the closing $. Be vigilant about OCR Artifact Fixes: correct spaced decimals (0 . 0 5 to 0.05), excessive spacing around operators (x + y = z), spaced text commands in LaTeX (\text {w h e r e} to \text{where}), spaced subscripts (\beta_ {I} to \beta_{I}), incorrect log notation (Log or ln when \log is intended), the multiplication symbol (* in math mode should often be \cdot or implicit), unescaped percent signs in math (50% to 50\%), and currency symbol artifacts (\mathbb{S} to \$). Crucially, always use \text{word} for words inside equations (e.g., \text{Rate} = \frac{\text{Distance}}{\text{Time}}) to prevent them from being rendered as italic variables.

E. Tables: Structure and Legibility

Markdown tables provide a structured way to present data. The standard format is:

| Header 1 | Header 2 |
| :------- | :------- |
| Cell 1   | Cell 2   |

Your primary focus here is on fixing obvious typos or broken pipes (|) within these markdown tables. However, a critical rule applies: if you encounter <table> HTML or \begin{tabular} LaTeX structures, LEAVE THEM ALONE. Do not attempt to convert them to markdown; preserve them exactly as they are.

F. Images & Media: The Hands-Off Rule

This rule cannot be stressed enough: DO NOT TOUCH IMAGE LINKS. Absolutely leave all image syntax exactly as it appears in the document. This includes formats like ![[filename.png]] and ![alt](path/to/image.png). Do not change the syntax format, do not fix paths that look broken, do not rename or reorganize anything related to images, and do not add or remove alt text. They must remain completely untouched. This strict adherence ensures that all media references remain functional and preserves the original author's intent regarding image inclusion.

G. Table of Contents / Outlines: Streamlining Navigation

If a document begins with a Table of Contents (TOC) that includes dotted leaders and page numbers (e.g., 2.1 Section Name … … … … … … . . 17), your task is to clean these up. You should remove the dotted leaders and page numbers. The best approach is often to convert this into a clean markdown list or, if the TOC is redundant with the document's natural structure, remove it entirely. The goal is to simplify navigation and remove outdated or cluttered elements.

H. Content Exclusion: Pruning the Unnecessary

Finally, identify and remove practice or exercise sections that are typically found at the end of documents. Look for headers that match patterns like # Practice Questions, # Problems, # Exercises, # Further Questions, or # Questions and Problems. Once identified, delete both the header and all the content that follows it. This step helps to keep the core documentation clean and focused on the primary subject matter.

🏷️ Crafting Meaningful Tags: The Two-Tier System

Tagging is a critical aspect of organizing and linking information within the FinanceCompendium vault. The vault employs a two-tier tag system: primary_tags and secondary_tags. primary_tags should encompass the 1-10 MOST important key phrases. These are the core concepts, central themes, and main methodologies that fundamentally define the document. Think about what someone searching for this document would most likely use as keywords. secondary_tags, on the other hand, can include up to 25 supporting key phrases. These cover related concepts, peripheral topics, and additional context that enriches the document's discoverability. Both types of tags must be multi-word key phrases, ideally between 2 and 4 words, that are specific enough to be meaningful but general enough to potentially appear in multiple documents across the vault. This specificity allows for effective vault-wide internal linking using wikilinks. The goal is to create tags that accurately capture the essence of the content, enabling users to navigate and connect information seamlessly. Remember, tags should be lowercase, use natural spaces (no snake_case or hyphens), and avoid single words unless absolutely necessary. Good examples include term structure models or risk neutral valuation, while term_structure or derivatives would be considered poor tags due to their format or vagueness.

Strategic Tag Distribution

Determining the right number of tags involves considering the document's size and complexity. While document sizes can range significantly, from short notes to extensive treatises, we have guidelines based on both word count and the number of processing chunks. For word count, smaller documents (< 5,000 words) might have 1-2 primary and 3-5 secondary tags, scaling up to larger documents (> 150,000 words) which could have 9-10 primary and up to 25 secondary tags. However, a more practical approach during processing is the chunk-based method. This formula suggests Primary Tags = min(10, max(1, ceil(chunks / 2))) and Secondary Tags = min(25, chunks × 2). For instance, if you process 1-2 chunks, you'd aim for 1 primary tag and 2-4 secondary tags. If you handle 5-6 chunks, that translates to 3 primary tags and 10-12 secondary tags. Use whichever method is easier to calculate as you work, but the chunk-based approach is often preferred since you're already tracking your progress through the document in chunks.

The Art of Tag Extraction

Tag extraction is a two-step process. Step 1: Per-Chunk Extraction. As you process each chunk, actively identify 2-4 key phrases that best represent the core concepts within that specific section. Record these in your working notes, assigning a relevance score: 3 for core concepts (strong primary tag candidates), 2 for important supporting concepts (secondary tag candidates), and 1 for peripheral or contextual terms (secondary tag candidates if space permits). For example, in a finance document chunk, you might note "term structure models" (3), "yield curve dynamics" (3), and "spot rate derivation" (2). After processing all chunks, move to Step 2: Consolidation & Ranking. Gather all extracted phrases from your notes. Group similar or overlapping phrases, always keeping the best phrasing. Sort them first by relevance score (3s, then 2s, then 1s) and within each tier, prioritize phrases that appeared in multiple chunks. Ensure your selection provides balanced coverage across the entire document, not just concentrated in the initial sections. From this ranked list, select your primary_tags and secondary_tags based on the distribution guidelines, ensuring they are descriptive, lowercase, and multi-word.

📝 Updating the Bead Issue: Your Progress Report

After processing EACH chunk, it is imperative that you update the associated bead issue. This detailed logging serves as a crucial audit trail and keeps stakeholders informed. Your update should follow a strict format, clearly outlining the work done for that specific chunk.

The Standard Update Format

Begin with a clear header indicating the chunk number and line range, such as ## Chunk [N] Processing Complete (lines X-Y). Following this, create a ### Corrections Made: section. Under this, list each correction precisely: specify the [Issue Type], the line [Z] where it occurred, the [exact original text/code], and the [exact corrected text/code]. If you encountered any ambiguous issues that you had to skip, document them under ### Issues Skipped (Ambiguous):, providing the line number and a brief description. Finally, conclude with ### Chunk Status: ✓ Complete. This structured reporting ensures clarity and consistency in tracking progress and issues.

An Example of a Detailed Update

Here’s how a typical update might look after processing the second chunk:

## Chunk 2 Processing Complete (lines 451-890)

### Corrections Made:
1. **Mid-sentence line break** at line 467:
   - Original: `the forward rate can be\ncomputed using`
   - Corrected: `the forward rate can be computed using`

2. **OCR spaced decimal** at line 512:
   - Original: `$r = 0 . 0 5


	
    
    
    
    
	
	
	
	
	
	
	
    
    
    
    
    
    
    
    
    
    


    

        
    
    

        

            

                

                    
Mastering Obsidian Vault Formatting For Finance Compendium
                    

                        Dec 22, 2025
                        by Alex Johnson
                        
                            59 views
                        
                    
                
            
            

                

    

            
            

                

                    

                        
   - Corrected: `$r = 0.05


	
    
    
    
    
	
	
	
	
	
	
	
    
    
    
    
    
    
    
    
    
    


    

        
    
    

        

            

                

                    
Mastering Obsidian Vault Formatting For Finance Compendium
                    

                        Dec 22, 2025
                        by Alex Johnson
                        
                            59 views
                        
                    
                
            
            

                

    

            
            

                

                    

                        

3. **Block math formatting** at lines 534-536:
   - Original: `$ E[X] = \mu $` (single line)
   - Corrected: `$\nE[X] = \mu\n$` (delimiters on own lines)

4. **Bullet marker** at line 601:
   - Original: `• First item`
   - Corrected: `- First item`

### Key Phrases Extracted (with relevance scores):
- "forward rate agreements" (3) - primary candidate
- "interest rate parity" (2) - secondary candidate
- "covered interest arbitrage" (2) - secondary candidate

### Issues Skipped (Ambiguous):
- Line 678: Unmatched `


	
    
    
    
    
	
	
	
	
	
	
	
    
    
    
    
    
    
    
    
    
    


    

        
    
    

        

            

                

                    
Mastering Obsidian Vault Formatting For Finance Compendium
                    

                        Dec 22, 2025
                        by Alex Johnson
                        
                            59 views
                        
                    
                
            
            

                

    

            
            

                

                    

                         delimiter - unclear if currency or math

### Chunk Status: ✓ Complete