The ledger

Every change to an element in Fabled goes through the ledger. The ledger is a list of small events ('Lirien took 7 damage', 'Cast Cure Wounds, recover 1d8+3 HP', 'Levelled up to 4'), and the current state of the element is what falls out when you replay those events through the element's framework.

Most of the time you do not think about the ledger. You roll a die, you click a button on a sheet, and the right number changes. The ledger is what makes that work without anyone copy-pasting state around.

Why a ledger instead of just storing values

Three things become easy when state is event-driven instead of snapshot-driven:

• Undo and history. Roll back the last entry and the state before that entry comes back. Scroll the timeline and you can see exactly what happened during a session, in order, with timestamps.
• Rule-driven recompute. When the framework changes, replaying the same events through the new rules gives a fresh, correct state. There is no stale snapshot to migrate.
• Audit trail. Players occasionally want to know how a number on their sheet got there. The ledger answers that without anyone keeping notes.

What lives on the ledger

Every meaningful interaction with an element produces a ledger entry. The common ones, in roughly increasing complexity:

• Dice rolls. Every roll is recorded with its expression, the result, and what it was for (attack, save, ability check). Rolls are the most common ledger entry by far.
• Direct edits. Setting current HP, ticking a box, changing a value. The framework decides whether the change is allowed (a class limit, a tier gate, a permission check) before the entry is written.
• Action functions. The framework's pre-defined buttons: 'Take damage', 'Cast spell', 'Short rest'. An action function bundles several smaller writes into one labelled entry, so the timeline reads as a story instead of as raw arithmetic.
• Levelling up and other structural changes. Pickling new class features, swapping spells, changing equipment. These are still single ledger entries, even if they touch many derived values.

What does NOT live on the ledger

The framework's own rules are not ledger entries. If a class feature reads 'AC = 10 + Dex + shield', that rule belongs in the framework. The ledger never writes 'AC is 17'; it writes 'Dex went up by 2' and the framework recomputes AC from there. This separation is exactly the rule-vs-instance split from the frameworks, elements, and frames concept.

Notes, journals, descriptions, and anything that is just text live on the element directly, not on the ledger. Editing a backstory is not an event the system needs to replay; it is just a value.

Reading the timeline

Every element has a timeline view that walks through its ledger in order. New entries land at the bottom; the most recent few sit pinned in the sidebar during a session so the table can see what happened. Each entry is a small panel with a label, a timestamp, the actor (player vs. GM), and an expand control for the underlying detail.

When something looks wrong

If a value on a sheet is off, the ledger is the place to start. Open the timeline, find the entry that produced the surprising value, and look at how the framework computed it. Most surprises trace to either an unexpected ledger entry (someone clicked the wrong button) or a framework bug (the rules say something different than the GM thought).

GMs can delete any ledger entry; players can delete their own entries on their own characters. Deleting an entry replays the remaining entries through the framework, so a deleted dice roll's HP loss disappears, downstream calculations recompute, and the timeline closes the gap. The deleted entry is gone from the timeline; if you need it back, the only path is to write a fresh entry that restores the same effect.

Where to go from here

• If you have not read the Frameworks, elements, and frames page yet, read that one first. The ledger only really makes sense once the rule-vs-instance split is clear.
• If you are building a custom framework and want your buttons to write nice ledger entries, the framework node reference's Action functions category is the relevant section.