Entity Context Pattern

The smallest unit of useful knowledge is rarely a sentence. It is a fact about an entity — a person, a company, a project, a concept, a source. A KMS that only stores sentences (notes, posts, snippets) misses the structural backbone that makes knowledge queryable.

The principle

Every persistent thing in the world that the system reasons about is an entity with:

• a stable slug
• a typed page (person, company, project, concept, source, decision)
• a small set of structured fields (role, status, relationships)
• a free-form notes section
• explicit links to other entities

Notes attach to entities, not the other way around. "Met with Sam" is a note on the entity sam, not a standalone log.

Why it matters

Flat notes can't be queried. "What do I know about Sam?" returns a search result; "what do we know about this customer's renewal?" returns a search result. A search result is not knowledge — it's a list of places where a string occurs.

Entity-typed knowledge can be composed. "What do I know about Sam?" returns a single page that gathers facts, recent meeting notes, related entities, and unresolved questions — assembled from many sources but presented as one. That is the difference between finding information and reading what the system knows.

How it works

Three things have to be true:

1. Type schemas are explicit. Each entity type has a fixed set of optional fields. A person has role, org, relationship, last-contact. A company has industry, stage, engagement-status. The agent fills these from natural language; the user never types into a field.
2. Wikilinks are first-class. Every mention of an entity in any note becomes a [[wikilink]]. Backlinks are computed and shown on the entity page.
3. The entity page is a view, not a file. The page renders the structured fields, the latest notes, the backlinks, and any derived facts (e.g. "last touched 14 days ago"). Edits go to the underlying note that mentioned the entity, not to the page itself.

In Claude primitives

• Skills like find-or-create-entity, add-note-to-entity, update-entity-field enforce the pattern.
• CLAUDE.md carries the entity-type schema — "person has these fields; never invent new types without an ADR."
• Long-context Sonnet/Opus can read the whole entity page (notes + backlinks) into the working window when an entity is referenced.

Where I've seen it

A BD-focused app-scoped KMS I work with uses this pattern explicitly for deal entities. My personal KMS uses it for people, projects, concepts. A team-scale KMS we've built uses it with role-based permissions layered on top. The contrast is illuminating: every system that drifted away from entity-context drifted toward flat note collections, and every flat note collection became unusable past ~500 notes.

The contrarian read

It feels like database thinking applied to a notebook. It is. That is the point — most knowledge work is database work in disguise, and pretending otherwise makes the system worse.