Blog
A result-note template for calculators you might revisit later
Record assumptions, inputs, and the reason for the estimate so a calculator result is not separated from its context.
Published: 2026-08-18 · Updated: 2026-09-16
Key points
- Write the assumption beside the result
- Store the input values
- Mark what would change the decision
A number without its inputs is a rumour. Three weeks after you worked something out, the figure is still in the message you sent but everything that produced it is gone, so the only options are trusting it blindly or doing the whole thing again. A short standing template fixes that, and the value is not tidiness. It is that future you can tell whether the old answer still applies to the new situation.
The six fields, and why each one is there
Date, question, inputs, result, dependency, and revisit trigger. The date matters because rates, prices, and rules move, and an undated estimate cannot be aged. The question is written as a sentence ending in a question mark, because that is what forces you to notice when you calculated something adjacent to what you actually wanted to know. The inputs are recorded exactly as entered, including units and the option settings you did not choose deliberately.
The result is written with the precision you will really use, not the precision the tool displayed. Rounding at the point of recording prevents the false confidence that arrives with four decimal places on an estimate built from a guess. The dependency is the one input that most affects the outcome, and the revisit trigger is the event that would make you redo the calculation, such as a rate changing or a headcount changing.
What a filled-in note looks like in practice
For a money question the shape is: the date, the question of what the monthly cost is under a particular arrangement, the inputs including the amount, the term, the rate as entered and whether fees were included, then the result rounded to something usable, then the note that the term is what dominates, then the trigger of the quoted rate changing. Anyone reading that later, including you, can tell in fifteen seconds whether it is still valid.
For a date question the fields are the same but the dependency is almost always a convention rather than a number: whether both endpoints counted, whether weekends were excluded, and which holiday set applied. Write that convention down in words, because it is the part that varies between tools and it is the part that produces two different answers to what looks like the same question. For a unit conversion, record which definition of the unit you used, since several common units have more than one.
Store it where the decision lives
The note belongs next to whatever the calculation was for: in the same document as the proposal, attached to the same task, in the same thread. A separate notes file organised by topic sounds better and works worse, because it requires you to remember that the note exists at the moment you are reconsidering the decision, and you will not. Redundant copies are fine; orphaned ones are the problem.
When you share the result, share the note rather than the number. A colleague or a family member handed a bare figure will treat it as settled and build on it, while a figure accompanied by its two assumptions invites the correction you actually wanted. This is also the fastest way to catch your own errors, because the person who spots the wrong input is usually the one who had to read what the inputs were.
Age the notes and retire them on purpose
Once every month or two, look at the notes attached to live decisions and check the dates against the revisit triggers you wrote. Anything whose trigger has occurred gets recalculated or deleted. Anything whose trigger has not occurred can be trusted without reopening it, which is the payoff for having written the trigger down in the first place.
Do not keep superseded notes alongside current ones without marking them. The characteristic failure is two notes with different results for the same question, both undated in any obvious way, and nobody able to say which one the decision was based on. Mark the old one as replaced and point it at the new one, and the record stays readable instead of becoming an argument.
Before you commit
- Write the assumption beside the result
- Store the input values
- Mark what would change the decision
Six fields, written at the same time as the calculation, stored beside the decision, shared with the number rather than behind it, and aged deliberately. That is a minute of writing against the alternative, which is redoing the work while no longer remembering what you assumed the first time.