The Update Ledger 2.2.3-2

Purpose

The update ledger is the team's institutional memory of what it learned from disagreement. Where the error-friendly retro (2.2.3-1) surfaces disagreement and converts it into action, the update ledger records the result: what was changed, why, on what evidence, and what happened next.

Without the ledger, the team's learning is ephemeral. Decisions change, but no one remembers why they changed — or, more importantly, what the team learned from the process. The ledger converts episodic correction into cumulative learning.

Format

Each entry contains five fields:

Date — When the update was decided.

Prior position — What the team believed or practiced before the update. State it concretely: not "we had a communication problem" but "we assumed the client would review deliverables within 48 hours."

Triggering evidence — What prompted the revision. Name the specific evidence: a failed outcome, a dissenter's argument that survived steelmanning, a retro finding, an external signal. If multiple sources contributed, name them all.

Updated position — What the team now believes or practices. Same concreteness standard as the prior position.

Review date — When the team will check whether the update is working. This mirrors the individual weekly review's commitment to a next-check date and prevents updates from becoming permanent without evaluation.

How to Use It

The ledger is reviewed at two cadences.

Short-cycle: At each error-friendly retro, check open items from previous retros and record completed updates in the ledger. This keeps the ledger current and ensures that retro outputs are tracked to completion.

Long-cycle: Quarterly or at project close, review the full ledger for patterns. Questions to ask: What kinds of assumptions does this team consistently get wrong? What types of evidence does the team respond to most effectively? Are there domains where the team revises frequently and others where it never revises? The patterns in the ledger reveal the team's epistemic profile — its characteristic strengths and blind spots.

The Epistemic Health Signal

Over time, the ledger becomes evidence of the team's epistemic health. A team with a growing ledger is a team that learns. A team with an empty ledger is a team that either makes no errors — which fallibilism regards as improbable — or has no mechanism for converting errors into learning. The ledger does not guarantee good judgment. It guarantees that the team's judgment is auditable — that the reasoning behind changes is recorded and reviewable.