Entities vs Concepts vs Sources: Why Schema Beats Folders

Every knowledge base starts as a folder tree. Projects/, Notes/, Reference/, Archive/ — clean, intuitive, and within a month it is a graveyard. Files go wherever the author’s mood put them, duplicate topics multiply under three different names, and the question "what do we actually know about X?" takes longer to answer than it did before you started organizing.

The fix is not a better folder structure. It is no folder structure. It is a schema — a fixed set of node types with rules for what each one contains, where each one links, and how each one traces back to evidence.

This article is the concrete worked example: the three node types we actually run — entities, concepts, and sources — why they are separate, and why that separation beats a folder of markdown every time.

- Advertisement -

Folders answer "where" — schema answers "what kind"

Foldering is spatial thinking. It optimizes for where a file lives, and it assumes the reader already knows the category. A file about the council vault’s memory layers could reasonably sit in Architecture/, Systems/, or Protocols/ depending on who filed it — and all three would be defensible, which is precisely the problem. When location is opinion, retrieval is a coin flip.

Schema replaces the spatial question with a temporal-theoretic one: what kind of thing is this, and what role does it play? We answer it with three and only three node types, each with a template that is enforced, not advised:

• Entities — the things. Agents, services, products, systems, personas. Each carries a type (council, system, agent, project…), aliases, sources, and mandatory sections: Basic Information, Description, Related Entities, Related Concepts, Mentions in Source.
• Concepts — the ideas. Patterns, doctrines, principles, methodologies. Each cites the entities that instantiate it and the sources it derives from, with Definition, Key Characteristics, Applications, and the same link-and-attribution sections.
• Sources — the evidence. Imported notes, logs, documents, status boards. Every claim in an entity or concept traces back to one; a source with no derived pages is a prompt to look harder, not a loose end.

The enforced template is the whole trick. Not "mostly" enforced — the generation pipeline writes against these templates, and a linter rejects or flags output that doesn’t match. A page with the wrong type field, a tag not in the valid subtype list, a wiki-link that diverges from the naming convention (lowercase-with-hyphens, full-path with display-text pipe) — all of it is caught mechanically. The schema is code, and code gets linted.

- Advertisement -

Why this separation matters more than it sounds

It sounds pedantic until you hit the three failures every folder tree triggers at scale:

1. Queryability by role. A folder answers "where is it?" A schema answers "what do we know?" — and lets you query by role. "What do we know about agent orchestration?" returns concepts. "Which system actually does that?" returns entities. "Who said so, and when?" returns sources. Three different questions, three different node types, one graph. Folders collapse all three into two words: "somewhere over there."

2. Auditable provenance. In a folder, a quote is text. In a schema, a claim with no source is a bug. The sources: frontmatter field and the Mentions in Source section are mandatory — every quote is a verbatim string attributed to a source wiki-link, in academic-footnote style. When you publish authority content, this is the difference between an opinion and a citation. (Series S3 exists because the engine’s whole argument is traceable authority; S3.1 covered the publish loop, this is the storage half.)

- Advertisement -

3. Enforced hygiene. Folders hide rot; schema exposes it. Orphan pages — nodes with zero inbound links — are detected by a lint report, not noticed by a human three months later. Dead links (target pages that don’t exist) get counted: our first lint pass found 57, a deeper pass 157. Naming mismatches, stale indexes, ungrounded quotes — all become a measurable list the next maintenance pass works through. A folder tree cannot be linted, because its "schema" is whatever the author felt like that day.

The memory-layer echo

This separation is not unique to the vault — it mirrors how Hermes itself splits memory. The stack runs three persistence layers with different roles: state.db holds raw session transcripts (working memory — the source material), ChromaDB holds curated, semantically-searchable embeddings (retrieval memory), and the Obsidian vault holds human-readable markdown (the knowledge layer — the entities and concepts). The lesson transfers directly: separate the evidence from the interpretation from the raw log. Don’t overstuff one container and call it organized.

What this buys a knowledge operating system

Two properties that a folder can never produce:

- Advertisement -

The graph is queryable by role. Nodes are typed, so the graph is typed. A 109-entity, concept, and source graph with thousands of semantic edges becomes a relational structure you can interrogate — not a picture to admire in graph view. Dataview and the index regenerate from the live graph, so the index is a query, never a hand-maintained document that drifts out of sync.

The system compiles, like a second brain rather than a stack of shortcuts. Wiki knowledge is compiled once and linked once; it compounds. Karpathy’s pattern — compile the knowledge base, auto-link related pages, flag contradictions, keep it current on a schedule — only works when there is a stable, lintable structure underneath. Folders fail the compile step because a compiler needs a grammar, and folders have none.

The bottom line

A folder tree expresses an author’s mental org-chart on the day they made it; a schema expresses the nature of the thing itself, forever. When every page knows whether it is a thing, an idea, or evidence — and that identity is enforced by template and lint rather than by memory — then the knowledge base becomes a system with three typed eyes instead of a pile organized by mood.

- Advertisement -

Whatever tool you use, start the adoption with the schema, not the folders: pick your three node types, write the templates, wire the linter, trace every filler claim to a source. The folders will quietly stop mattering, because the schema answers the only question that ever did — what do we actually know, and can we prove it?

- Advertisement -