DecisionOS — Prove · the record
Value Ledger
Did the decision we made actually deliver what we said it would, and what does that say about the next one.
When you reach for it
The quarter after a decision shipped, when someone asks what the last round of AI spend returned and the honest answer is that nobody wrote it down.
How the record is built
Three moments, spread across the life of a decision rather than gathered in one sitting.
- 01
The commitment
When a Decide module produces a result you can act on, you commit it: the initiative, the benefit you expect, the person who owns it, and the date you will check. Four fields, taken at the moment you are most honest about them — before the work starts.
- 02
The review
On the review date the Ledger asks the three questions that matter: did it ship, what was the measured benefit, and what changed since you committed. A review you skip stays open rather than quietly closing itself.
- 03
The record
Committed against realised, per initiative and in total, accumulating across every module and every year you hold the subscription. One board-ready view, built from entries you wrote at the time rather than reconstructed afterwards.
The method
How the result is produced
The Ledger computes nothing you did not put into it. Committed benefit is the figure you entered when you made the commitment; realised benefit is the figure you entered at review. The difference between them is arithmetic, not a model, and both numbers carry the date and the person who entered them. Where a review is overdue the initiative is shown as overdue rather than being counted either way — an unreviewed commitment is not evidence of success or of failure.
What it connects to
Answers established elsewhere are carried in with their age shown, so a stale answer reads as stale rather than being silently reused.