Relational Linkage and Retrieval Discipline

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.

The graph

Lore links in three directions: location (one Location file), characters (Character files), and relatedLore (other Lore files). Write references as readable target slugs (thornhollow-state); the platform hydrates them to ids. When a field accepts several file types, qualify the slug as type/slug so it resolves unambiguously.

Prefer references over prose everywhere. If two lore files both need the founding date, one file owns it and the other references it — a duplicated fact is a future contradiction.

Retrieval discipline

The engine's whole reason to exist is to recall only directly relevant knowledge. The rules:

1. Recall the one chunk that owns the fact in question — not every file that mentions the subject.
2. Follow a reference one hop when the scene actually needs the linked chunk; do not pull the whole neighborhood.
3. Filter by domain and tags before recalling, and by canonLevel when truth matters: canon and established are fact; rumor and myth are hearsay and legend, recalled only as such.
4. Filter by era when time matters: current truth lives in -state files, historical truth in history files.

Retrieving through the index

The whole knowledge base is navigated through its index, never by enumerating files into a prompt or context. This section is the durable, clone-safe form of the index navigation discipline (the Knowledge Index Retrieval assistant instruction may not survive a clone; this chapter does):

1. Read the index first. Consult /Ontology-Engine/OE-Index/OE-Knowledge-Index.index.md — or grep it with the query's key terms. It lists every folder and file in the base — file mentions, titles, content tags, canon levels, eras, and reference links.
2. Score relevancy. Map the query onto the index's vocabulary: folder domains first (e.g. "who burned the barge" → /Conflicts/, /Events/, /Quests/, /Lore/Culture/), then per-file tag overlap, then subject proper nouns, then canon/era fit (prefer canon/established over rumor/myth unless the question is about belief).
3. Read only the top candidates. Batch-read the top 2–5 files in one read call (use select to stay lean). Stop when tag overlap drops below the query's core terms.
4. Never dump the base into context. The index is the map; files load on demand. If the index has no folder, type, or tag for a concept, the concept is likely absent — say so instead of a fruitless presence.

Keep the index current: when a file is added, renamed, or retagged, update its entry (or regenerate the index) the same session. An index that drifts from the file tree silently poisons every lookup built on it (single-writer rules in Migration and Lifecycle Conventions).

Changing truth

When play changes the world, update the -state file's keyFacts the same session. When an old claim is overturned, do not silently delete it — set it to retconned and replace it. The knowledge base is a record of belief, not just of current fact; future recall should be able to see what was once believed true and why it changed.

How to extend

New types and files follow the same conventions: chunk, name, link, tag, anchor. If a new type is needed, fold it into the Ontology Map and Startup Checklist together.