Chronology and Change Tracking

A living project changes through branchable continuities. The system should track planned events, actual play events, and the mutations that make one continuity diverge from another.

Event

An event is something that happens or may happen in a continuity.

Examples:

Event: Festival begins
Event: Merchant caravan arrives
Event: Spy delivers letter
Event: Bridge collapses

Planned Chronology

The planned chronology answers:

What happens if nobody interferes?

Example:

Day 1: Festival begins
Day 2: Merchant caravan arrives
Day 3: Spy delivers letter
Day 4: Bridge collapses

Continuity Chronology

A continuity chronology records what actually happened at the table. More generally, a continuity chronology records what happened in that continuity.

Example:

Session 3:
  Players repaired the bridge before the caravan arrived.

Mutations

A mutation changes continuity state.

Examples:

Character status: alive -> dead
Faction influence: 60 -> 45
Secret visibility: hidden -> discovered by party
Location status: safe -> occupied

Design Recommendation

Use an event log for important changes.

Do not only store the current state. Store the reason the state changed.

Example:

Mutation:
  target: Bridge
  field: status
  old: unsafe
  new: repaired
  caused_by: Session 3 bridge repair

This makes continuity history auditable and allows future features like undo, branching chronologies, recaps, and publication history. Base project lore should remain reusable. Divergent outcomes should be represented in continuities, chronology entries, and mutations.