Checking at the destination

In one of the group's subscription businesses, we connected the management system to a layer that reads payments to notice when a customer is about to leave. The integration went live, the logs were clean, no alert fired, and for a few days everything seemed to work. The revenue arriving on the other side was zero.

The connector sent an invoice-created event. The destination only accepted invoice-paid. One word apart, and neither side had a reason to complain: the sender got confirmation that the message had been accepted, and the receiver simply had nothing to count.

This kind of defect slips past ordinary integration tests, because those tests usually check what left the source. A 200 status means someone answered. It does not mean the data was stored, or that any rule read what was stored.

Since then, we treat three things as part of delivery, not as operational detail.

Check at the destination, not at the source. When an integration is called done, someone opens the receiving system and looks for the record that should have arrived, with the right value, in the right field. If nobody can point to where the data landed, the integration is not done.

Name the zero. A metric can show zero for three very different reasons: it was measured and came out zero, it was not measured, or the measurement broke on the way. On screen they look the same. In our dashboards every number says which of the three it is, and "not measured" is written out instead of becoming a confident zero.

Test the safeguard by breaking it on purpose. A check that has never failed anything proves nothing. Before trusting a safeguard, we deliberately break the thing it should catch and confirm it catches it.

With AI and automated rules reading that data, a silent failure costs more. A dashboard showing zero may still catch someone's eye; a decision layer that receives zero acts on it. That is why, in SYNQi³, every number carries its source and the window that was measured, and the absence of a measurement has its own rule.

None of this is sophisticated. It costs a little more time at delivery and spares a company the worst conversation there is, finding out weeks later that a number everyone used to decide was empty.

Four questions to ask whoever runs your integrations:

1. 01When this integration was called done, did anyone check the record in the destination system?
2. 02Does this metric distinguish "came out zero" from "not measured"?
3. 03When did an automated check last actually fail something?
4. 04If an event stops arriving tomorrow, how long until someone notices?