Per-project world projections

A world morphs across a series. The same character is a godking in book three and deposed in book four. The same city stands tall in book one and is rubble in book five. Per-project projections let a world carry that history without the writer having to fork the world.

What a projection overrides

The base world entry stays the canonical identity (name, domain). The projection sits in a sibling table keyed on (entry_id, project_id) and overrides:

  • objective_description, the fact set the AI grounds on.
  • rules, hard constraints + tendencies. Useful when a world's magic system breaks halfway through.
  • tags, concept tags that drive AI context retrieval.
  • parent_id, re-parent the entry within the world's hierarchy for this project.
  • notes, author-facing notes scoped to this project.

Resolution rule

App-layer, not enforced in SQL: if a projection exists for (entry, project), the AI sees the projected form; otherwise it sees the base.The resolver works field-by-field, a projection that overrides only the description still inherits the base's rules.

Where to manage them

Open any world entry in the World Builder. Expand the “Per-project projections” section. The pane shows every existing projection with a label (“Book 4, The Hollow Year”), an override summary, and Edit / Delete affordances. Click New to attach a fresh projection to a project that doesn't have one yet (the project picker filters out projects already projected so you can't silently overwrite).

Why this exists

Without projections, a writer has to either fork the world (lose canonical identity) or accept that the AI doesn't know the character's status by book five (drift). With projections, the world carries one canonical truth plus a per-book ledger of how it's changed, same shape as a time-traveling identity that knows its own history.