When the error is in the specification, not the code

The system works correctly. Why is the result wrong?

Imagine a product that implements every mechanism in its specification: accruals, limits, payments and rewards. Tests pass, calculations are reproducible, and no critical code defects have been found. Yet the financial model fails to meet its targets.

This is not necessarily a developer error. The software may be faithfully executing contradictory requirements.

For fintech products and projects with an internal economy, this distinction matters. An implementation audit asks, “Does the system work correctly?” A requirements audit asks a different question: “Can a system with these rules achieve its stated goal?”

How contradictions arise

Product requirements are often developed in separate parts. Bonus rules, monetisation, guaranteed payouts, infrastructure costs and growth targets are specified independently. Each section may look reasonable, while nobody has checked their combined effect.

For example, a business may want to guarantee minimum payouts, retain extensive free features and become self-sustaining with a limited proportion of paying users. These rules can be implemented technically. Establishing their financial compatibility is a separate task.

Hidden assumptions are another common problem. A specification includes revenue without explaining the evidence behind conversion rates. It lists recurring costs without distinguishing operating expenses from development costs. It defines constraints without explaining what to do when they conflict.

Three levels of verification

In my work, I distinguish three independent levels.

A positive result at one level does not settle the others.

Why quietly adjusting parameters does not “fix” the economy

When a calculation produces an unwelcome result, it is tempting to choose more convenient coefficients: reduce payouts, increase expected conversion or change constraints. The report may then become positive, but it is evaluating a different system.

Every proposed change should therefore answer these questions: which original requirement does it affect, who can approve it, which acceptance criteria no longer apply, and which checks must be repeated?

If a change violates a fundamental client condition, it cannot be presented as optimisation within the original specification.

How to document a contradiction

A useful record includes the original requirements and their versions, the observed conflict, a reproducible example, the assumptions used, the consequences and possible solutions. It separately records what calculations confirm and what remains a hypothesis.

The decision status also matters: identified, submitted for approval, accepted, rejected or awaiting more data. This prevents the same contradiction from resurfacing over multiple development iterations.

When to stop optimising

Optimisation remains useful while there is a testable hypothesis that could improve the result without violating mandatory requirements. If a series of investigations reveals no suitable alternatives, continuing to search nearly identical parameter combinations may add no new information.

At that point, it is more useful to document the negative result, define the limits of the investigation and propose a review of the underlying design. This changes the level of decision-making: from tuning a mechanism to revisiting requirements.

What the client receives

A useful audit produces more than a list of observations. It provides a decision map: which requirements are compatible, which conflict, which metrics depend on unconfirmed assumptions, and which changes require approval.

When working with economic models, it is especially important to distinguish technical success from business success. A functioning simulator can correctly show that a proposed design fails its stated criteria.

Frequently asked questions

How does a requirements audit differ from a code review?

A code review checks whether the rules are implemented correctly. A requirements audit checks whether the rules themselves are complete and compatible with the product goals.

Can parameters be changed to obtain a positive result?

New parameters can be investigated, but the affected requirements, assumptions and acceptance criteria must be explicitly recorded and agreed.

What should you do when requirements conflict?

Document the conflict and a reproducible example, explain the consequences and possible solutions, and submit the change to the product owner for approval.