Correct by Coincidence

Two numbers agreed perfectly. Neither of them knew the other existed.

That is not a bug you can see. It is a bug you can only read.

Two Paths to the Same Figure

The discount engine does two things with one value.

It stores the discount amount. That calculation reads the VAT rate from configuration — a custom metadata record with a taxRate__c field, editable precisely so a rate change is an admin task rather than a deployment.

Then it decides whether the discount needs a manager. That calculation uses PCT_MARKUP = 20, a constant in the code, with zero references to the tax-setup service anywhere in the class.

Same tax. Two authorities. One of them is editable by an admin on a Tuesday afternoon.

Why Nothing Looked Wrong

The configured rate is 20. The constant is 20.

So the stored amount and the approval threshold produce identical figures on every input, in every environment, in every demo. No discrepancy to notice, no test that fails. I could not have found this by executing a test case, because there is no execution in which it misbehaves today.

The system is not correct. It is correct by coincidence.

The Shape of the Future Failure

Picture the day the configured rate changes. Not a dramatic day — someone tidying a metadata record.

The stored amounts move. The approval threshold does not.

From that moment, discounts are stored against one rate and governed against another. Both figures still look plausible. A discount that should have gone to a manager auto-approves, or one that should auto-approve gets routed. Either way the number on the screen looks like a number, not like an error.

The trigger is an admin action in a different part of the org, weeks or months earlier, and nobody will connect the two. That is what makes this class of fault expensive: dormant, plausible when it fires, and its cause already scrolled off everyone's memory.

The Same Class, Found the Same Afternoon

A few days earlier, a different reading produced the same kind of finding.

I put a technical design next to the actual org schema and compared the custom field API names on vlocity_cmt__OrderDiscount__c. Six of the seven differed from the document. RejectionComments__c is really Comments__c. ApprovedBy__c is Approved_By__c. And DiscountReason__c — which the design puts a validation rule on, and displays to the approver — does not exist at all.

That would be a documentation problem, except for one detail: the checkout gate that blocks unapproved discounts is a DataRaptor, and a DataRaptor queries those fields by name.

A field-name mismatch does not throw. It returns nothing. HasUnapprovedDiscount evaluates to false, the SetErrors block never renders, and the order submits with an unapproved discount attached to it.

Every functional test around it stays green. The discount applies. The approver receives their request. The approval flow behaves exactly as designed. The only thing that fails is the gate, and the gate fails by staying quiet.

What Neither of These Was

Neither was a calculation error. Both calculations are individually correct. And neither was a missing test case in the ordinary sense — you could add cases for years and never touch either one, because both are invisible to anything you can execute.

What they share is structural: a fact that lives in two places, or a name that lives in two places, with nothing in the system reconciling them. Agreement is maintained by luck and by nobody having edited either copy yet.

The Test That Would Have Caught It

For the VAT constant, the valuable test is not "does 20% work." It works. Everyone has already proved that.

The valuable test is: change the configured rate, then prove the stored amount and the governance check still agree. One config edit, one discount, two numbers compared. If they diverge, you have found a second source of truth. If they hold, the wiring is real.

For the field names, the check is thirty seconds of reading. Whenever automation resolves fields by name — a DataRaptor, an Integration Procedure, a Flow formula, anything driven by a string rather than a compiler — "do these fields exist under exactly these names?" is a core check, not an assumption. The compiler is not covering you. Nothing is.

What to Hunt For

What I took away is a search, not a test.

Look for the same fact expressed twice. A rate held in config and repeated as a constant. A field name written in a document and separately typed into a mapping. A threshold in metadata and a duplicate in a formula. Every one of those pairs is fine on the day it is written, and every one is a divergence waiting for an unrelated edit.

Then ask the question that turns the pair into a test: what would have to change for these two to disagree, and would anything tell us?

Which number in your system is being calculated twice — and is one of the copies hardcoded?