Builder's Manual · Chapter 2

Anatomy of a Lore File

Package provenance — this chapter ships with the Ontology & Structure Engine. Provenance tag: source-ontology-project. When loaded into a new world, grep the tag to find the engine's templates and instructions.

Anatomy of a Lore File

The Lore type is the engine's backbone. The sample structure ships three files that show the whole pattern — one subject, three clusters, each small enough to embed and retrieve on its own:

FileDomainHolds
Thornhollow-placegeographyWhat the place is
Thornhollow-lorehistoryWhat happened
Thornhollow-statecultureWhat is true right now

Each links to the other two through relatedLore. Geography, history, and live state are deliberately separate files: a scene about the ferry toll needs the state file and should not have to drag the founding story along.

Field by field

  • domain (required) — the ontology axis: geography, history, culture, cosmology, magic, religion, factions, economy, technology, rules. This is the primary retrieval filter and the folder you file under.
  • summary — the recall surface. One self-contained sentence, at most 300 characters. A reader should know from the summary alone whether this is the file they want.
  • body — the chunk itself. One focused cluster of meaning; keep it short enough to embed and retrieve as a unit.
  • keyFacts — the cluster atomized into standalone facts. Each fact should survive being retrieved alone, without the file's context.
  • canonLevel — truth filter: canon, established, rumor, myth, theory, retconned. Defaults to established.
  • era — temporal anchor ("40 years before present", "Year 12 of the Sundering").
  • location / characters — typed references to Location and Character files, written as target slugs.
  • relatedLore — typed references to other Lore files; this is the ontology graph.
  • tags — recall vocabulary for retrieval (place name, concept, domain).
  • sources — provenance: book, session, author, handout.

The logic behind each field

  • summary and keyFacts exist because embedding search works best on short, atomic text. A long prose file retrieves fuzzily; a summary plus atomized facts retrieves precisely.
  • canonLevel exists so a rumor is never presented as fact. Retrieval can filter by truth level instead of the GM policing every sentence.
  • era exists so "the capital is besieged" from last war is not recalled as current truth.
  • References exist so each fact lives in exactly one file and links to many — no duplicated facts to go stale.
  • domain + tags + folder together give three increasingly fine filters: folder (coarse), tags (fine), references (graph traversal).
Manual updated Aug 19, 2026.