Maintenance and Review

A calculator can come back under review for many reasons. A new rule or dataset may be published, a scheduled check may come due, a user may report an issue, a test may fail, or we may identify a better way to handle or explain something.

The type and frequency of review depend on the calculator. A calculator built on stable mathematical relationships does not need the same maintenance as one that relies on annual tax limits or other changing data. We set review expectations based on those differences and document completed checks so each calculator receives the attention its underlying logic and data require.

Once we understand a change, we identify what it affects and how much review it requires. That may include the calculator’s formula, assumptions, reference data, tests, examples, documentation, or user experience. For changes to reference data, we also confirm the source, the applicable dates or years, and when the new values should take effect.

We then run the checks that match the scope and risk of the change. A small documentation update may need only focused review, while a change to a formula or governed data may require calculation tests, interface checks, and a broader review of the calculator. Automation helps us verify the behavior, while people make the decisions about expected results, assumptions, and how the change should be presented.

Before we release a material change, we review it in a controlled environment where we can examine the calculator and the full user experience together. We keep a record of the decision, the testing completed, and the review evidence that supports the release.

If an important check fails or a problem appears after release, we can pause or reverse the affected change while we investigate. Restoring the prior behavior helps protect users, but it does not end the review. We still determine what went wrong, whether anyone may have been affected, and what correction or documentation is needed.