Going Stellar

Home/Research

Address repair

Two signals, or a person

Every plausible rule for automatically repairing a broken delivery address, measured against real orders — and why most of them were rejected.

Published

The rule we kept

Cleaning up broken delivery addresses in bulk looks like an obvious win. The rule we ended up with is narrower than any of the ones we tried: a broken address field is repaired only when two independent signals agree. One signal, or any ambiguity, and the order goes to a person.

Independent carries most of the weight in that sentence. A postcode recovered from a broken field and an official locality nomenclature are independent: one comes from what the customer typed, the other from a published register, and they fail for different reasons. Re-reading the same typed field is not an independent signal, however different the parsers look.

The rule is also late by design. It runs only on an address the courier has already rejected, never preventively across the whole order book. Every part of that sentence turned out to matter, and the measurements below are the reason.

What the rule did, order by order

Once the broken postcode field was cleaned, the digits left formed a code, and the official locality nomenclature listed that same locality at that same code. Two signals agreed. Repaired, label issued.

A postcode prefix resolved to exactly one city, and the city field held a truncated version of that city's name. Two signals again, but only about the city. The city was written; the postcode was left invalid, because nothing confirmed the remaining digits. We correct the field we can confirm and no more.

A postcode prefix resolved to six possible localities. One signal, ambiguous. Sent to a person.

A postcode field containing a place name with no digits at all, and a city field containing the generic word for a rural settlement. Nothing to work with. Sent to a person. What is worth noticing here is that a cleanup pass which "does its best" would have produced a confident answer for the escalated orders as well.

The trap that nearly shipped

We were wrong about what a postcode file contains. In one country's official postcode source, the string 00-000 is not a postcode. It is the "not filled in" marker.

It appears in 13,222 of 341,720 rows. Because it is so frequent, it comes out first when you count the most common postcode per locality — for 557 localities, including three of the country's largest cities, where it appears 2,220, 1,346 and 1,282 times respectively.

The existing repair rule would therefore have written 00-000 onto an order from a major city. The parcel would have gone nowhere. It was caught by a regression test before it ever ran on a real order.

Four neighbouring countries have no such marker: zero rows. That is the part we got wrong, stated precisely. The assumption that failed was not this file is clean but a file that is clean in the neighbouring countries is clean here too. A sentinel value defeats the mode specifically, and the mode was the statistic we had chosen to trust.

Two rules that sounded obviously right

The rules below were proposed, measured against real orders, and rejected. Each sounded obviously right. Each would have touched far more working orders than broken ones.

"City field contains the county name, so take the city from the postcode": touches 8,166 orders, of which 18 were actually blocked. One in 453.

"The house number is in the second address line, so move it to the first": touches 2,652 orders, of which 4 were blocked. One in 663.

The denominator is the whole argument. A rule with numbers like those is not an address repair; it is a mass edit of addresses that were already delivering, justified by the fact that they looked wrong to us. Blast radius is cheaper to measure than precision, and it should be measured first.

Why the repair runs last

A blind cleanup invents a destination. Confirmation from an independent source is what turns a guess into a correction, and without it a repair is indistinguishable from a plausible fabrication written into a shipping label.

Restricting the repair to addresses the courier has already rejected changes what the rule can touch. It uses the rejection itself as evidence that something is wrong, and it keeps every rule away from the orders that were delivering fine — exactly the orders the two rejected rules would have modified.

The costs are asymmetric, which settles the ambiguous cases. An escalation costs a person's handling time on one order. A wrong repair produces a parcel that goes nowhere, a customer who is not told, and a courier record that now looks correct. So ambiguity always resolves towards the person.

Running the same check

Measure before you repair. Run each proposed rule's predicate as a pure filter over a window of real orders and count how many orders it touches, then how many of those the courier actually rejected. The ratio between them decides whether the rule exists at all, and it takes a query rather than a design discussion.

For nomenclature files, count the frequency of every postcode value before trusting any aggregate computed from them. A value that appears far more than the rest, and appears across unrelated localities, is a sentinel marker rather than real data. Then run the same count on the neighbouring countries' files: a marker present in one country and absent in the others shows up immediately as a difference in row counts.

Keep a regression test per rule, with the pathological rows written into it. Ours caught the sentinel.

Limitations

This is one courier ecosystem, a handful of countries, and nomenclature files whose quality differs by country. A marker that exists in one country's register and not in its neighbours' is exactly the kind of thing that will differ again in a country we have not touched.

The ratios above come from one measurement window. Treat them as evidence that the method finds bad rules, not as constants to carry into another dataset. The same two rules measured elsewhere could easily produce different numbers; what should transfer is the habit of counting the orders a rule touches and comparing them against the blocked ones before shipping anything.

The two-signal rule is only as strong as the sources behind the second signal. Where the register itself is wrong, two signals can agree and still be wrong together — the sentinel case was precisely that, caught by a test rather than by the rule. And we measured the rules we thought of. Rules nobody proposed remain unmeasured, which is not the same as safe.

Questions and answers

When is it safe to automatically fix a customer's delivery address?

Automatically fixing a delivery address is safe only when two independent signals agree, for example a postcode recovered from the broken field and an official locality nomenclature listing that locality at that code. With one signal or any ambiguity, the order goes to a person. The repair should also run only on addresses the courier has already rejected, never preventively across all orders.

What counts as an independent signal for address validation?

An independent signal for address validation is one that comes from a different source and fails for different reasons. A postcode taken from what the customer typed and a published official locality register are independent. Re-reading the same typed field with another parser is not an independent signal, however different the parsers look, because both readings share the same underlying error.

How do I test an address-cleanup rule before using it on real orders?

An address-cleanup rule is tested by running its predicate as a pure filter over a window of real orders. Count how many orders the rule touches, then how many of those the courier actually rejected. The ratio decides whether the rule should exist at all. A rule that mostly touches orders that were already delivering is a mass edit, not a repair.

Why can the most common postcode in an official file be wrong?

The most common postcode in an official file can be wrong because some registers use a sentinel value for missing data. In one country's official postcode source, 00-000 is the not-filled-in marker, and it wins the count for many localities, including large cities. Counting the frequency of every postcode value, and comparing with neighbouring countries' files, exposes such a marker quickly.

Why should ambiguous address repairs go to a person?

Ambiguous address repairs should go to a person because the costs are asymmetric. An escalation costs a person's handling time on one order. A wrong repair produces a parcel that goes nowhere, a customer who is not told, and a courier record that now looks correct. Without confirmation from an independent source, a repair is indistinguishable from a plausible fabrication on a shipping label.

How to cite this

Going Stellar (2026). Two signals, or a person. GOING STELLAR S.R.L..
https://goingstellar.ro/research/two-signals-or-a-person/

Read as Markdown

All research

Contact

Tell us what is not working

Write in English or Romanian. A person reads it — usually the same person who would do the work — and answers within one business day.