An Intended Absence Needs An Owner

If a system is supposed to produce nothing for a particular case, that nothing is a requirement, and it needs the same care as anything the system does produce. Write it down, give it a test, and name who confirmed it. Otherwise it looks exactly like a bug, and the people working hardest to make the system complete are the ones most likely to break it.

I was reminded of this during acceptance testing of a billing export. Several things were genuinely wrong at once. Some expected lines were missing, some records had never been marked as processed, and a few descriptions had not come through. Everyone in the room was in "find the gaps" mode, which is a sensible mode to be in. Somewhere in the middle of it sat one record that produced no billing line at all, and it was supposed to. A whole category of patient is deliberately excluded from that export. The correct output for that case is nothing.

Why absence is so easy to lose

Testing is built around evidence of presence. We look for the row, the line, the message, the total. A passing check usually means something showed up that we could point at. A deliberate absence offers nothing to point at, so it never gets on anyone's list. It lives in somebody's head, or in a conversation from three weeks ago, or in the memory of the one person who asked the question when the rule was first agreed.

Then the work shifts into repair. Once a team is chasing missing output, an unexplained empty result reads as one more symptom. The instinct is reasonable: if five records are missing lines and a sixth is also missing a line, the sixth probably has the same cause. Someone finds a plausible fix, the fix is general enough to cover all six, and the excluded case starts producing a line. In a billing context, that is a charge raised where the business decided none should exist. In a healthcare context, it might also be a charge raised against someone, or against a public system, that never should have seen one.

Nothing in that sequence involves carelessness. Everyone did the sensible thing with the information in front of them. The information just did not include the one fact that mattered, which is that this particular emptiness was chosen on purpose.

What I do about it now

The practical habit is small. When a rule says "this case produces nothing," I want it recorded as a positive statement with a reason, in the place the team already looks for expected behaviour. Not a footnote under the happy path, but its own line: this input, this output is empty, confirmed by this person, for this reason. The reason matters more than it looks, because a rule with a reason can be challenged sensibly later, and a rule without one can only be obeyed or ignored.

Then I want a test that asserts the emptiness. This is the part that tends to feel odd, because asserting that nothing happened seems like a weak check. It is actually a strong one. A test that feeds in the excluded case and demands zero output fails the moment a well-meaning fix starts producing a line. It turns "someone remembers" into "the build remembers." It also forces a useful precision: nothing is not one thing. The record might be skipped before any processing, processed and filtered at the end, or processed and emitted as an explicit zero. Those are different behaviours with different consequences for anything downstream, and a test makes you choose.

That last point connects to something I have written about before, which is that a quiet exit can be mistaken for a failure. The same logic applies in reverse here. If an excluded case leaves no trace at all, nobody can tell whether it was excluded correctly or simply lost. A log entry or a counter saying "excluded by rule" costs almost nothing and makes the difference between a deliberate absence and a mysterious one. When reconciliation time arrives and the totals are a few records short, you want to be able to say exactly which few and why.

The commercial side

It is tempting to treat this as testing hygiene, but there is a business argument too. Rules that exclude things are often the ones that carry the most commercial and regulatory weight. They exist because someone decided, for good reason, that a certain category is handled differently: a different payer, a different contract, a different legal obligation. They are also the rules least likely to be visible in a demo, because a demo shows things happening. Nobody walks a stakeholder through the screen where nothing appears.

So the risk is lopsided. Missing a line that should exist is noticed quickly, because someone is waiting for it. Creating a line that should not exist can sit unnoticed until an invoice goes out or an audit asks why. The cheaper failure is the loud one, and the expensive failure is the silent one, and we usually spend our attention in the opposite proportion.

Giving the absence an owner

The title of this piece is the honest summary. Every intended absence needs someone who can say "yes, that is correct, and here is why." In practice that is usually whoever on the business side made the decision, not whoever wrote the code. When that person has confirmed it once and the confirmation is written down, the team can stop relitigating it every time a similar-looking gap appears.

I have come to think of it as the difference between a system that is complete and a system that is correct. Complete means everything that could be produced is produced. Correct means exactly the right things are produced, and some of the right answers are blank. The first is easy to measure and the second takes a bit of deliberate memory. If you are in the middle of fixing missing data, it is worth pausing to ask which of the gaps in front of you somebody chose. The answer is usually fewer than you fear, but it is rarely zero.