When Wikilinks Stop Scaling: An Organizational Audit of an 18,000-Note Vault

That Beautiful Graph

If you've ever watched an Obsidian promo video or browsed a community showcase, you've almost certainly seen it — a galaxy-like graph view, hundreds of nodes glimmering against a dark background, colored edges weaving in from every direction. It looks like a neural network, like synaptic connections in a brain, like something alive and organic.

It is Obsidian's most powerful piece of marketing.

Wikilinks — the simple syntax of wrapping double brackets [[]] around a note name to connect it to another — are the engine behind this visual spectacle. An entire philosophy has grown around it: Zettelkasten, atomic notes, emergent knowledge structures. The core narrative is compelling: don't constrain your thinking with rigid folders; let ideas connect freely, and knowledge will organize itself.

I bought in. I did exactly that. Then my vault swelled to 18,000 notes, 59 million words of effective body text, and 130,000 files.

At that scale, I started noticing things that didn't quite add up.

A Read-Only Audit

To answer the question — "which organizational method actually holds up at scale?" — I had an AI agent perform a full read-only statistical scan of my entire Obsidian vault. No modifications, pure measurement and analysis.

The scan covered 18,221 Markdown notes and 2,280 folder nodes. The counting methodology was deliberately designed for a bilingual vault — mine is roughly 56% Chinese and 44% English — where a naive English word count would severely undercount Chinese content. So I used a hybrid metric: Chinese characters counted individually, English words counted normally, yielding approximately 59 million units of effective body text. Markdown syntax, code blocks, and URLs were stripped to get as close as possible to "the prose you actually wrote and read."

This wasn't a casual glance. The scan produced over a dozen interactive visualizations, multiple data tables, and a stack of static analysis charts. Every conclusion that follows is grounded in this data.

The Tree in Full

Before diving into specifics, here's what this vault looks like from above.

Main folder subtree sunburst graph

source: Vault Structure Audit

This chart shows the effective body text carried by each folder subtree. The longest bar is Investment — a single subtree housing 16,238 notes and over 51 million words of effective text, accounting for 86% of the vault's total. Drill down and Investment/TKamchk/Global Equity dominates most of that, branching further into 4.Sector (company research organized by GICS industry), 2.Themes (cross-cutting topics like AI, Payments), 3.Industry (supply chain research), and more.

This is not a symmetrical tree. It's more like a tree with a very thick trunk — the trunk carries overwhelming content density, while branches like Publish, Script, Dayflow, and VisionRecall each serve distinct functions at comparatively lighter volumes.

Worth noting: this vault isn't just a text repository. Total file count reaches 131,933, of which 107,894 are images (82%), while Markdown files account for only 18,220 (14%). In other words, it's simultaneously a multimedia asset system managing six figures' worth of images and screenshots. Tags and wikilinks struggle to provide stable organizational anchoring for non-text assets — they're naturally better at expressing semantic relationships than handling the physical routing of large file volumes.

With that panorama established, let's look at how the three organizational methods actually perform.

Three Numbers, One Fact

After the scan completed, three numbers jumped out first and told the story with blunt clarity:

• Folder objects: 2,278
• Unique tags: 89,520
• Unique wikilink edges: 92,165

Comparison of the three organizational object counts

source: Vault Structure Audit

One glance at this chart says enough. The blue bar — folders — barely rises above the x-axis. The orange and purple bars — tags and wikilinks — shoot skyward.

If you think of "organizational objects" as complexity containers that you need to maintain, folders are roughly 1/39th the scale of tags, and 1/40th of wikilink edges. Managing 18,000 notes with 2,278 objects means each folder carries about 8 notes on average; managing the same notes with 89,520 tags means each tag covers 0.2 notes on average.

That's already a strong signal. Folders compress complexity. Tags and wikilinks release it.

The Tag Long-Tail Problem

Let's start with tags.

89,520 unique tags sounds like a lot. But the truly unsettling part is their distribution: 63,475 of them — 71% of the total — appear exactly once. Tags appearing five times or fewer account for 93%. The top 10 most-used tags combined cover only 5.5% of all tag occurrences.

Tag frequency rank-frequency distribution (log-log scale)

source: Vault Structure Audit

This near-straight line on a log-log plot is a classic power-law distribution — Zipf's Law. A small fraction of tags see heavy use, while the vast majority are essentially one-time semantic traces.

Why does this happen? The reason is actually intuitive.

Adding a new folder is a constrained act — you don't casually create a new top-level domain; new content more often lands in an existing branch. Tags have no such built-in constraint. Every new note can introduce a new tag, and synonyms, near-synonyms, capitalization differences, and varying levels of semantic granularity all spawn new objects. When your vault covers topics ranging from AI semiconductors to global macro to consumer goods to cryptography, tag vocabulary is almost guaranteed to inflate rapidly.

Top tags frequency distribution

source: Vault Structure Audit

A look at the top tags in my vault makes this problem tangible. The most frequent tags simultaneously include entirely different types of things: AI (topic tag), Nvidia (entity tag), positive / negative / neutral (sentiment judgment tags), already_processed (workflow status tag). The most-used labels in a single system serve content classification, sentiment annotation, and workflow management all at once — they're carrying too many different roles. Tags are genuinely useful, but they're too well-suited to "supplementing semantics" and ill-suited for serving as the main skeleton.

When 71% of a classification system appears only once, it looks more like scattered local annotations — not a stable, reusable organizational framework that keeps working as scale grows.

Wikilinks: Relationship Web or Organizational Backbone?

Now the star of the show: wikilinks.

My vault contains 414,268 resolved wikilinks, corresponding to 92,165 unique link edges. That's roughly 23 outgoing links per note on average. These numbers suggest wikilinks are being used extensively.

But shift the angle: 11.3% of notes are completely isolated, with zero links. Nodes with a total degree of 1 or less account for 38%. Five or less: 49%. Meanwhile, the top 10 hub nodes absorb 16.6% of all link degree.

This is a textbook "many sparse nodes + a few super-hubs" network structure. It doesn't resemble a uniform mesh. It looks more like a galaxy — a few massive stars capturing most of the gravitational pull while vast numbers of small bodies drift at the periphery.

Top wikilink hub nodes

source: Vault Structure Audit

What are those hubs? The highest-ranked is AI.md, followed closely by Apple.md, Nvidia.md, Visa.md, Mastercard.md, OpenAI.md — they're essentially concept pages, company homepages, topic indices. To keep the wikilink network navigable, these hub nodes grew organically.

Here's an observation worth pausing on: what these hub nodes are doing is, in essence, reinventing the directory. Their function is to consolidate complexity, provide hierarchical navigation, and give downstream nodes a sense of belonging — which is precisely what a folder tree does natively. A purely peer-to-peer graph, once it grows large enough, spontaneously develops tree-like structures. Much like a city built without zoning will eventually see main roads emerge wherever traffic volume is highest.

A Line and a Curve

So far we've been looking at a static snapshot — the state of each organizational method at the 18,000-note cross-section. But the more compelling question is: how does each one behave as note count grows?

Organizational burden per note

source: Vault Structure Audit

This chart turns the question into something viscerally intuitive.

The blue dashed line stays flat at 1. Forever. Because a note needs exactly one "home" — one folder destination. Whether your vault has 100 notes or 100,000, the folder placement cost per note is constant at 1.

The orange and purple lines keep climbing. As the vault grows, the average number of tags per note creeps from an initial 5–8 up to around 16; wikilink outgoing edges climb from 3–4 to over 22. Not because the user became more diligent — but because as the knowledge network densifies and topic coverage widens, the relationships and attributes each note needs to express objectively multiply.

This is the fundamental difference between folder placement and point-to-point connection. The former is a belonging judgment — where does this note live? The answer is singular; the cost is fixed. The latter is a relationship judgment — what is it related to? The answers are plural, and they expand with scale.

A tree only asks you to answer "where does this note belong?" once. Tags and wikilinks keep asking you to add "what else is it related to?"

Zoom out from individual notes to the system level, and the divergence becomes even starker.

Cumulative organizational burden as note count grows

source: Vault Structure Audit

The blue line (folders touched) barely lifts off the x-axis — because the majority of new notes simply enter existing paths without requiring new folder creation. Tag occurrences and wikilink occurrences, by contrast, climb relentlessly, since every new note adds organizational actions.

Trees mainly reuse structure. Tags and wikilinks mainly create structure.

If we push this logic further to its theoretical implications:

Complexity divergence between tree placement and point-to-point possibilities (log scale)

source: Vault Structure Audit

The blue line grows linearly — one placement decision per new note. The red line grows quadratically — each new note expands the potential connection space with every existing note in the vault. Of course, you don't actually link every note to every other note. But the decision space itself expands quadratically — who could this new note link to? Which links should it have? Which relationships are worth maintaining explicitly? The complexity of these questions increases relentlessly with scale.

This isn't to say wikilinks lack value. It's to say that if you rely on point-to-point connections to organize a large-scale knowledge base, you're facing a structurally harder scaling problem.

Trees Aren't Rigid Filing Cabinets

A reasonable objection at this point: aren't folders just the old-fashioned directory system? Those deeply nested paths — isn't that exactly what we were trying to escape by using Obsidian?

The objection holds — if you're talking about three shallow layers plus a handful of "Unsorted" folders.

That's not what's happening in my vault.

Note distribution by path depth

source: Vault Structure Audit

Effective body text by path depth

source: Vault Structure Audit

Maximum path depth reaches 12 levels. Notes concentrate most heavily at levels 6 and 7 (upper chart), and effective body text is similarly densest at those mid-deep levels — levels 6 and 7 together carry over 30 million words of effective text. This depth isn't arbitrary — it maps to a clear layering logic:

Investment → TKamchk → Global Equity → 4.Sector → Information Technology → Nvidia → ...

First by domain, then by sub-domain, then by company or topic, and finally introducing a time dimension where appropriate. Each additional layer adds a constraint, narrowing the search space. This is closer to a multi-level taxonomy than a traditional filing cabinet.

The Investment subtree alone houses 16,238 notes and 51 million words of effective text — 89% of all vault notes, 86% of total text volume. Internally, it continues to branch through Themes, Industry, Sector, Non-holdings, Periodic materials, and more.

And these branches don't flatten everything to the same granularity. Some terminate at level 4 (e.g., Script/202506 — finished output archived by month), while others extend to level 10 or deeper (e.g., the AI semiconductor research chain with company-level and material-level subdivisions). Different knowledge domains receive different organizational depths based on their inherent complexity — a living, fractal structure.

On the time dimension, one design choice deserves special mention: time is not the top-level organizational axis. I don't sort all content under 2024/, 2025/, 2026/ as the first layer. Time appears beneath the appropriate semantic branch — e.g., Global Equity/Periodic materials/2025 or Dayflow/2026. Domain path determines semantic belonging first; time handles chronological sedimentation second.

Many knowledge bases, once they reach a certain size, unconsciously slide toward "chronological piling" — because time is the easiest dimension to define. But time alone provides no semantic compression. A 2025 folder organized by year can mix AI research, Payments analysis, macro notes, and company earnings indiscriminately — you know when something was created, but not which intellectual thread it belongs to.

Not a Three-Way Choice

If the article ended here, you might take away "folders good, wikilinks bad, tags worse."

That's not what the data says.

Look again at my Investment subtree — it's not only the deepest and most expansive part of the tree structure, it's also the area with the highest tag density (17 tags per note on average) and the most wikilink outgoing edges (24 per note on average). The more core, complex, and long-term a domain is, the more heavily all three organizational methods stack on top of each other.

In areas like Script (a container for audio transcripts), tag usage approaches zero and outgoing links are sparse — because it functions more as finished-product storage, requiring little relational expression.

The right mental framework isn't "pick the best one." It's understanding what each one does:

Folder hierarchy solves belonging. Where does a note live? The answer is singular, stable, and the path itself carries multi-layered semantic information. It's the backbone.

Tags provide annotation. What are this note's attributes? Is it AI-related? Positive sentiment? Already processed? Tags stick to notes like Post-it notes, enabling multi-perspective slicing. They're the label layer.

Wikilinks express relationships. What other notes is this one connected to? What's the link between this Nvidia earnings report and that TSMC capacity analysis? Wikilinks weave a semantic relationship web. They're the relational overlay.

The three operate at different organizational levels. They're not competing alternatives on the same plane.

File over App: Why Folder Structure Is AI's Natural Memory System

Up to this point, the first half of this article answered a purely knowledge-management question: which organizational method scales better. But I want to push the discussion one step further — because in 2026, how a knowledge base is organized is no longer just a human concern.

Obsidian's core philosophy is "File over App" — your data lives as plain-text Markdown files stored on your local filesystem, not locked inside any app's proprietary database. I discussed the basic implications of this idea in a previous article. But at that time, I hadn't yet realized that the true value of the File over App choice only fully reveals itself in the age of AI agents.

The reason is simple: an AI agent's native language is the filesystem.

When Claudian — the Obsidian-embedded AI agent I use — works inside my vault, every operation it performs — reading files, writing files, searching paths, executing Bash commands — acts directly on the filesystem. The vault's working directory is the agent's working directory. It doesn't need to query some database via API to understand how content is organized. The file path itself is the semantic cue.

Investment/TKamchk/Global Equity/4.Sector/Information Technology/Nvidia/ — this path, without any additional metadata, tells the agent: this is a research note about Nvidia, filed under IT sector analysis, part of a global equity investment research system. The path is the context.

In the article on the JARVIS architecture, I described the system's three-layer pipeline: ingestion, processing, output. But there's a more fundamental point I never fully unpacked: the reason this pipeline can operate efficiently is that the filesystem underneath is itself a well-structured memory system.

When my vault-deep-research Skill runs, it dispatches multiple sub-agents to search different informational dimensions in parallel, writing results to temporary files for the main agent to synthesize. The efficiency of this workflow depends directly on the quality of the filesystem's organization. A clear hierarchical tree lets the agent use Glob patterns to quickly locate the right directory branch, then Grep within a bounded scope for keywords. If all notes were dumped flat in a single folder and differentiated only by tags, the agent's search space and signal-to-noise ratio would deteriorate dramatically.

Put differently, this folder tree isn't just my knowledge management backbone — it's simultaneously the AI's context system. A well-designed hierarchical directory serves as taxonomy for a human and as memory architecture for an AI agent.

The Gravity of Structure Itself

With that layer understood, a deeper question naturally surfaces: how did this vault grow to 18,000 notes and 130,000 files? Doesn't maintaining a knowledge base at this scale demand enormous organizational effort?

The answer lies in the tree structure itself.

A well-designed hierarchical tree possesses what I'd call "gravity." Once you've built the path Investment/TKamchk/Global Equity/4.Sector/Information Technology/Nvidia/, every subsequent Nvidia-related note — whether it's a quarterly earnings analysis, a supply chain update, or an analyst day writeup — has a destination that requires almost zero thought to determine. You don't need to redesign the organizational system, agonize over which tags to apply, or deliberate about which notes to link. The path is already there. New content gets pulled in by the structure itself.

This is why the marginal cost of folder hierarchy approaches zero — the upfront design cost isn't trivial, but once the tree is established, the filing cost of each new note is negligible. By contrast, if you rely on wikilinks as your primary organizational method, the organizational cost per note is nonzero and increasing: you need to judge which existing nodes it should link to, and the pool of potential link targets keeps growing.

This "gravity" effect is even more critical for AI workflows. I add roughly 40 new notes per day on average — a large portion of which are automatically ingested and structured by AI agents. If every note's filing required manual judgment about "what is it related to," the pipeline would bottleneck at the ingestion stage. Under a tree structure, the agent only needs to make a relatively simple classification judgment — which domain branch does this content belong to? — and it naturally falls into the existing path.

Trees create gravity. Gravity lowers ingestion cost. Low ingestion cost makes large-scale accumulation possible. And large-scale accumulation, in turn, makes the tree an increasingly valuable context source for AI. That's a positive flywheel.

Cross-reference heatmap of wikilinks between top-level areas

source: Vault Structure Audit

This heatmap shows the density of wikilink cross-references between different top-level areas. The deepest square — Investment pointing to itself — reveals that the vast majority of link relationships occur within the same main trunk. This is no accident: a sufficiently deep hierarchical tree naturally generates heavy intra-domain cross-referencing demand, and the tree structure ensures these references can be located within a bounded search scope.

An analogy: if the wikilink network is the web of streets crisscrossing a city, then the folder hierarchy is the city's zoning and addressing system. You can navigate without an address system — if you know every street by heart — but once the city expands past a certain scale, no zoning means no navigability. And once zoning exists, the street network (wikilinks) actually functions more efficiently within that framework.

An Uncomfortable Corollary

There's one implication I can't sidestep.

In the article on the efficiency illusion, I cited a finding: the "cognitive friction" inherent in completing a task by hand may be precisely the mechanism through which competence is built. The same logic applies to knowledge organization.

Manually placing a note into the correct folder path is itself an act of judgment — what domain does this content belong to? Where does it sit in my knowledge system? What existing material is it most closely related to? These questions force you to think, and the thinking itself builds intuition about the structure of a domain.

If you rely entirely on automated linking — whether wikilinks or AI-powered auto-tagging — you gain coverage but may skip the step where you're forced to think "what is this, really?" This doesn't mean automation has no value — in the article introducing the Virtual Linker plugin, I described how I use automated linking to expand wikilink coverage in my own vault. But auto-generated links and manually curated directory structures carry different cognitive value.

The former is coverage. The latter is understanding.

That Beautiful Graph, One More Look

Back to the beginning.

Obsidian's graph view is genuinely beautiful. It displays a panorama of every explicit connection in your knowledge base — a galaxy-like relationship map. As an exploration tool for "what associations exist among my notes," it has real value.

But if you treat it as the organizational method itself, you'll run into a fundamental scaling problem. As note count grows, the potential connection space expands quadratically, the cognitive burden of maintaining those connections rises continuously, and the network structure naturally drifts toward an uneven "few hubs + many sparse nodes" distribution — until you find yourself building MOC pages, index pages, and topic hubs, essentially reinventing the tree on top of the graph.

The data yields a rather plain answer: the folder tree is the organizational backbone that remains stable at the scale of 18,000 notes. Tags and wikilinks are supplementary layers stacked on top of that backbone, each with its own strengths.

In the age of AI agents, this conclusion carries even more weight. File over App isn't merely a philosophical stance about data sovereignty — it's the precondition for turning your knowledge base into AI's memory system. A well-structured folder tree serves as a navigation system for humans and as context architecture for AI. Trees create gravity, gravity enables large-scale accumulation, and accumulation in turn provides ever-richer context for both human and machine.

This isn't a particularly glamorous conclusion. No visually dazzling graph to show off, no "one feature changes everything" narrative — just an engineering fact validated repeatedly by data at sufficient scale: hierarchical decomposition is one of the oldest and most enduring methods of complexity management known to humanity. From biological taxonomy to library systems to filesystems to the internet's DNS — every information system that needs to remain navigable at massive scale ultimately relies on some form of tree.

Knowledge management is no exception. Wikilinks are beautiful, but the tree is the bone. And at a moment when your knowledge base is about to become AI's operating space, the bone matters more than ever.