Skip to main content

Ledger

Remember what worked, what didn't, and why.

Write down what you expect before the evidence arrives, then settle it once the evidence lands. Over time you can see which calls worked, which didn't, and how often your team turns out to be right.

The pieces Ledger gives you.

Ledger — Write down what you expect before you make a call
01

Write down what you expect before you make a call

02

See whether a decision moved the number it was meant to

Ledger — Mark what actually happened when the results come in
03

Mark what actually happened when the results come in

Ledger — See how often your team's expectations turn out right
04

See how often your team's expectations turn out right

Ledger — Keep your numbers current without entering them by hand
05

Keep your numbers current without entering them by hand

Nobody writes down what they expected to happen, so a year later nobody can say which of the decisions were any good.

Entries, metrics, the chart, and settling up.

Write the prediction into the entry, bind it to a metric, watch both on one chart, and settle it when the evidence is in.

01

The entry

A decision, with what you expected written down before the evidence arrived. Everything else here exists to keep that ordering intact.

Six fields
Where it applies, what you did, why, what you expect, what happened, and what you now believe. The last one is written only at settlement.
Several claims per expectation
A decision commits to every number it names. A claim either reaches a value or holds one, and a claim you want on the record without letting it decide the verdict is marked as watched.
Guardrails with a real baseline
State a tolerance against the weeks before the change, anchored on the entry's creation date — which isn't editable, so the window can't be chosen after the outcome.
Open entries stay editable
A prediction nobody has settled is still a draft. Once settled it's supersede-only: a correction is a new entry pointing at the old one.
02

Metrics

The numbers expectations bind to. Readings arrive on a cadence and land as evidence on the expectations that named them.

Ledger — Metrics
A starting catalog
Around ninety-five presets across every part of the business, each with a unit, cadence, and direction, browsable by business area or by cross-cutting tag. Adopt one twice and you still have one series.
Feeds
A standing instruction for how a number arrives: one connected system, one tool, frozen arguments, one path to the value, a cadence. No model in the path, so the instrument can't drift between runs.
Backfill that's safe to repeat
Re-run the same instruction over a wider window; readings deduplicate per time bucket, so a series can start before the change you're measuring.
Staleness
A metric whose readings stop arriving is visibly stale, rather than a chart that quietly flatlines.
03

Reading the chart

Where a decision and the number it claimed to move sit on the same timeline, which is the comparison every retrospective is trying to make from memory.

Ledger — Reading the chart
Decision markers
The decisions that claimed a metric appear on its chart at the date they were made. Every decision in the window is available behind a toggle, drawn differently.
Small multiples
Compare metrics and each keeps its own y-scale over one shared x-axis, so a marker runs down the grid at a single date. Never a second y-axis.
Trend line
Opt-in least squares, not drawn below four points, because a trend through three readings is decoration.
Expect a change from the chart
Click where you want the number to be, and the target, comparator, and deadline carry into a decision — so all that's left to fill in is what you're changing and why.
04

Settlement and calibration

The part that turns a pile of entries into something a team learns from: honest verdicts, and an aggregate answer to how often you're right.

Ledger — Settlement and calibration
Three verdicts
Met, not met, and mixed — because a change that hit its target and slipped a guardrail is a trade, and forcing it into a binary throws away the part worth remembering.
Lapsed claims surface on the metric
A claim past its deadline appears on the metric page with its computed verdict and a settle action, rather than firing a notification and waiting to be found.
Evidence lands where it belongs
Readings and Caliper eval runs land on the expectations that named them, so the evidence for a conclusion sits with it.
Workspace calibration
How often settled expectations turned out right, as a workspace aggregate. Never sliced per person — that boundary is permanent.

Decide. Expect. Settle. Know.

Ledger is one loop: record the decision with its expectation, let the evidence arrive, settle it into a lesson. After every pass you have more to draw on for the next decision.

  1. A decision happens

    In a tool, in a meeting, in a hallway. Most companies let it evaporate. Here it becomes an entry: what you did, why, and what you expect to happen.

  2. The expectation is written first

    A number and a date, written down before the evidence exists — so nobody gets to adjust the prediction once the results are in.

  3. Let zv1 draft it

    Say the decision out loud and you get a drafted entry back, written from the conversation that produced it. Approve it instead of filling in a form.

  4. Evidence settles it

    Caliper runs, observations, outcomes. Once you can answer the expectation, settle the entry and write the lesson while it's fresh. Recorded once, and kept.

  5. Beliefs compound

    Settled lessons collect into what the workspace knows, each belief citing the entries behind it. A new teammate can read it to get up to speed.

What does your operation actually know?

A record of what the company decided, what it expected, and what turned out to be true. Part of every ZeroWidth workspace.