Almost 3,000 tests keep our calculation core frozen

We keep that suite for one property that sells badly in a brochure and shows up every day in the work: identical inputs must produce identical outputs in every version of the tool. Close enough is not a category here.

Why media math has no "roughly right" mode

A media calculation lives a long time and changes hands along the way: tender, then contract, then post-buy. Each handover turns the number into an obligation to somebody else — the client, the sales house, finance. An analytics dashboard carries a different risk profile, where a wrong figure gets spotted and corrected at the next review.

When a coefficient shifts quietly between two versions, the damage is never one cell. The contracted sum stops reconciling with the rationale it was approved on, and the argument opens with the worst possible question: which version was calculating correctly? If the logic was never pinned down, nobody in the room can answer.

Two layers where the math breaks most often

Sales house discounts are the clearest case. They multiply, they do not add:

So 20% and 10% give 28%, not 30%. Two points look trivial until you multiply them by a campaign budget. The formula wants to collapse into addition, and that is usually where it collapses — in a copy of the file somebody else edited, or in the rush before sending. A test pins the rule: adding the percentages fails the build instead of surfacing at the negotiating table.

The second layer is subtler, and you can barely check it by hand. The budget → discount tier → budget cycle converges by iteration: budget sets the tier, tier moves the budget, repeat until the pair stabilizes. Sometimes the value oscillates between two adjacent tiers and settles on neither. Then the core takes the larger budget — the conservative call for a buyer, since reserving margin beats discovering a shortfall during execution. None of this is visible in the interface, and standard cases never touch it. A harmless-looking refactor breaks it, and somebody notices a quarter later, with nothing left to compare against.

Does "frozen" mean the product stops evolving?

No. Frozen means every change to a result is deliberate, explainable, and visible the same day, instead of surfacing months later as a surprise. We ship continuously. What we block is a numeric difference seeping in as a side effect of somebody's unrelated edit; each one passes through an explicit decision.

Our anchor is the core itself: identical inputs produce identical outputs in every build. On implementation we also reconcile, cell by cell, against the model an agency arrives with, so a migration does not break history a client already signed off — that gate holds below 0.01%, held on every build, not signed off once at the start of an implementation. If the divergence grows, the build does not pass. Nielsen's numbers we reproduce at the values we receive them in; the calculation layer has no business reshaping input figures to suit itself.

Tests as a protocol, not as QA

In practice these tests work as a protocol. They hold the agreements about the math in executable form — out of the head of whoever wrote the formula, out of a cell comment that survives one file handover at best. Reproducibility separates a tool from a spreadsheet far more decisively than the interface does; we break that comparison down in Alternatives to Enterprise Media Planning Platforms

One boundary, stated plainly: CPP inside TV Budgeting is a planning proxy, not a contracted price. A frozen core guarantees the arithmetic is stable and repeatable. It does not turn a proxy into proof of real cost, savings, or ROI.

None of this is glamorous. Trust in a media planning tool is built on predictability, not on feature count: the same inputs must return the same result in any version. Everything else sits on top of that property, and without it nothing on top holds.