Phase 7 Baseline: Content Structure Before Blocks
Captured 2026-03-07, before block-structured content model exists. All notes are monolithic HTML blobs.
Corpus Overview
| Metric |
Value |
| Total notes |
<strong>256</strong> |
| Total content |
<strong>1,088,274 chars (~272K tokens)</strong> |
| Average note size |
4,251 chars |
| Median note size |
2,578 chars |
| P90 note size |
9,706 chars |
| Max note size |
28,769 chars (plan-2026-02-28-woodpecker-mcp) |
| Average sections per note |
<strong>7.7 headings</strong> |
Size Distribution
| Bucket |
Count |
Avg Size |
% of Notes |
Block Impact |
| < 500 chars |
12 |
338 |
5% |
Low — too small for sections |
| 500-1K chars |
23 |
684 |
9% |
Low — 1-2 sections |
| 1K-2K chars |
61 |
1,532 |
24% |
Medium — 3-5 sections |
| 2K-5K chars |
94 |
3,144 |
<strong>37%</strong> |
<strong>High — 5-8 sections, biggest cohort</strong> |
| 5K-10K chars |
41 |
6,686 |
16% |
<strong>High — 8-15 sections</strong> |
| 10K+ chars |
25 |
16,217 |
10% |
<strong>Critical — 15-34 sections, most waste per read</strong> |
Key finding: 63% of notes (160/256) are over 2KB. These are the notes where block-level access delivers the most token savings. The 25 notes over 10KB average 16,217 chars (~4,054 tokens) — reading just one section instead of the full note would save ~90% per access.
Section Distribution
| Headings per Note |
Count |
Avg Size |
Block Benefit |
| 0 headings |
27 |
764 |
None — flat content, no sections to split |
| 1-3 headings |
15 |
915 |
Minimal — few sections |
| 4-7 headings |
108 |
2,369 |
<strong>Moderate — 4-7 addressable blocks</strong> |
| 8-15 headings |
86 |
5,401 |
<strong>High — get_block saves ~85% per read</strong> |
| 16+ headings |
20 |
16,683 |
<strong>Critical — get_block saves ~94% per read</strong> |
Key finding: 214/256 notes (84%) have 4+ headings — meaning 84% of notes would benefit from block-level access. Only 27 notes (11%) are flat content with no sections.
Content Type Distribution
| Content Type |
Count |
% of Notes |
Block Type |
| Lists (ul/ol) |
239 |
93% |
<code>list</code> |
| Tables |
118 |
46% |
<code>table</code> |
| Code blocks (pre) |
72 |
28% |
<code>code</code> |
| Mermaid diagrams |
37 |
14% |
<code>mermaid</code> |
Key finding: Rich, structured content is pervasive. 46% of notes have tables, 28% have code blocks. These are exactly the content types that benefit from typed blocks — a table block can be queried, updated, and rendered independently from surrounding text.
Size by Note Type
| Type |
Count |
Avg Size |
Max Size |
Block Impact |
| (untyped) |
85 |
3,568 |
26,688 |
High — legacy notes, many large |
| todo |
38 |
2,278 |
7,394 |
Medium |
| <strong>plan</strong> |
<strong>38</strong> |
<strong>9,441</strong> |
<strong>28,769</strong> |
<strong>Critical — largest type, most sections, most read</strong> |
| phase |
34 |
1,926 |
6,948 |
Medium |
| sop |
13 |
4,382 |
7,748 |
High — procedural, section-level reads |
| project-page |
11 |
7,612 |
17,922 |
High — large, multi-section |
| convention |
10 |
3,838 |
17,273 |
High |
| template |
9 |
2,822 |
4,752 |
Medium |
| doc |
8 |
5,121 |
7,426 |
High — concept/benchmark/decision docs |
| skill |
5 |
2,152 |
2,873 |
Medium |
| agent |
4 |
4,150 |
5,206 |
High — personality definitions |
Key finding: Plans are the largest note type (avg 9,441 chars, ~2,360 tokens) and are the most frequently read notes (4 plans loaded at every session startup). Block-level access to plans alone would save thousands of tokens per session.
Hierarchy: Current State
| Metric |
Value |
| Notes with a parent |
<strong>34</strong> (all phases) |
| Notes without a parent |
<strong>222</strong> |
| Note types that CAN have parents |
Only <code>phase</code> |
| Orphaned docs (should have parents) |
<strong>6</strong> concept/benchmark/incident/decision docs |
Orphaned Documents (logically belong under a phase)
| Slug |
Logical Parent |
| <code>concept-phase5-database-side-intelligence</code> |
<code>phase-postgres-5-fulltext-search</code> |
| <code>concept-phase5-self-hosted-rag</code> |
<code>phase-postgres-5-fulltext-search</code> |
| <code>benchmark-phase5-knowledge-baseline</code> |
<code>phase-postgres-5-fulltext-search</code> |
| <code>concept-argocd-ghost-override</code> |
<code>phase-postgres-5-fulltext-search</code> |
| <code>incident-phase5-deployment-outage-2026-03-06</code> |
<code>phase-postgres-5-fulltext-search</code> |
| <code>decision-phase6-vector-search-architecture</code> |
<code>phase-postgres-6-vector-search</code> |
Key finding: 6 docs already exist that should nest under phases but can't due to the type restriction. This will grow as more concept/benchmark/decision docs are created for Phases 6, 7, and 8. The hierarchy relaxation in Phase 7 solves this.
Token Cost Estimates: Before vs After Blocks
| Operation |
Before (monolithic HTML) |
After (block-level) |
Savings |
| Read one section of a plan |
~2,360 tokens (full note) |
~200 tokens (one block) |
<strong>~92%</strong> |
| Read TOC of a plan |
~2,360 tokens (full note) |
~50 tokens (headings only) |
<strong>~98%</strong> |
| Update one section |
~2,360 tokens (send full html_content back) |
~100 tokens (send one block) |
<strong>~96%</strong> |
| Session startup (4 plans) |
~8,750 tokens (4 × full get_note) |
~400 tokens (4 × TOC + targeted sections) |
<strong>~95%</strong> |
| Search result (find section) |
~640 tokens (note-level snippet) |
~200 tokens (block-level result) |
<strong>~69%</strong> |
Success Criteria for Phase 7
- All 256 notes decomposed into blocks (backfill migration)
- Block-level read/write API endpoints working
- TOC generation for all notes with 4+ headings (214 notes)
- 6 orphaned docs nested under their logical parent phases
- Existing MCP tools (get_note, update_note) continue working unchanged
- Benchmark re-test shows measurable token reduction vs this baseline
phase-postgres-7-block-content — the phase this benchmarksbenchmark-phase5-knowledge-baseline — Phase 5 before/after comparison (methodology reference)decision-phase6-vector-search-architecture — per-block embedding depends on blocks existing