Stack your advantage.From the team at Stackmatix
The Growth Library

Check every number in a worked-example guide

Verify inputs, units, denominators, rounding, and boundary cases before publishing an explanatory calculation.

A worked example teaches a reader how to reason. If its arithmetic is wrong or its units are unclear, the reader can reproduce the mistake with real decisions. Review the calculation independently from the prose that describes it.

Start with the inputs and assumptions. Label invented numbers as hypothetical and distinguish them from measured values. A realistic-looking example should not be mistaken for a client result, industry benchmark, or actual commercial price.

The checklist below uses simple invented publishing scenarios. It is an editorial verification method rather than a specialized financial model.

Write the inputs before the formula

For a hypothetical article review, suppose ten guides need two review hours each at USD 80 per hour. The review cost is 10 × 2 × 80 = USD 1,600. Keep articles, hours per article, and dollars per hour visible so the units resolve correctly.

If a paragraph later changes the number of guides to twelve, every dependent table and conclusion needs review. A copied total of USD 1,600 would then be stale even though the formula in the original example was correct.

CheckQuestion
InputsAre values measured, proposed, or hypothetical?
UnitsDo quantities and rates combine meaningfully?
FormulaDoes it represent the stated relationship?
DenominatorWhich observations are included?
RoundingIs it applied consistently at presentation?
BoundaryWhat happens with zero, missing, or invalid inputs?

Recalculate from the original inputs

Use a separate calculation path rather than copying the displayed result into a test. For simple arithmetic, a calculator or short script can verify the expression. For a workbook, change representative inputs and inspect the dependent outputs.

Check totals against their components. If three categories contain 10, 20, and 30 observations, the total denominator is 60. Do not average category percentages without considering their different sizes unless the method intentionally gives categories equal weight and says so.

Keep the verification record close to the article source. It should identify the example, inputs, expected result, and any limits, not become a large test suite that merely repeats the prose.

Test a meaningful boundary

A percentage with no eligible observations should not quietly display zero. Zero would imply a measured absence of the event; an empty denominator means the rate is unavailable. State that distinction in the example or tool.

Similarly, missing input is not automatically zero input. An unknown cost should remain unknown or be represented as an explicit assumption. A calculator that silently fills blanks can make an incomplete plan look complete.

Check negative values and impossible dates where they can occur. Decide whether the model should reject them or explain their interpretation. The answer depends on the actual calculation, not a universal rule that every negative number is invalid.

Review the sentence that interprets the number

A correct calculation can still support an exaggerated conclusion. Five wins from twenty observed opportunities is 25% in that set. It does not establish that every future opportunity has a 25% chance of closing or that a particular article caused the wins.

Keep arithmetic, observation, and inference separate. Use the template review to inspect how readers will reuse the example. Publish when the inputs, formula, displayed result, and explanation all agree about what the number means.

Matt Pru

Co-founder and CEO of Stackmatix. Writing about growth, customer acquisition, and the decisions behind useful marketing. Connect on LinkedIn.

Developed with AI assistance under Matt's editorial direction. Read our editorial approach.