Which way does a postcode point?
The last postcode post concluded that the "which country is this" signal has to come from the trained model reading the whole string, because the postcode by itself settles the question less than half the time. That is the expensive version of the feature. In this post we built the country signal into the model. It improved German addresses in native word order by a large margin and did not help the same addresses in a different word order.
We took the postcode's gazetteer membership (the [us, de, fr] answer from last time) and injected it into the model at the postcode token instead of passing it to a regex. The injection is a small additive vector on the hidden state at the position of the five digits, encoding which countries the code could belong to. On German addresses in German word order, it added thirty-five points of locality accuracy and beat Pelias.
The international-order numbers were much worse. With the same model, the same anchor, and the same German cities written house-number-first with the postcode after the city (the way our test feed renders them), the model scored slightly above 50%. On those rows the anchor did slightly worse than no anchor.
The rest of this post addresses three questions:
- When a parser "collapses" on a test, is the parser wrong, or is the test?
- Can you train one model to read an address in any order, or does each order cost you the other?
- What does a learned anchor learn: the meaning you intended, or the position where it appeared in training? This one took three retrains to answer.
The collapse that was a rendering bug
Before fixing a collapse, confirm that it is real. Most of ours was not. German international-order addresses parsed around 45% while native-order ones scored in the eighties, and that gap measured our test harness as much as our model.
Our German evaluation set is rendered from OpenAddresses in the layout our US-trained tooling defaults to: 27 Straußstraße, Berlin, Berlin 12623. That layout puts the house number first, the postcode after the city, and the region at the end. German addresses are written Straußstraße 27, 12623 Berlin, with the street before the number and the postcode before the city. The model had trained on the German order, we graded it on the American order, and we read the low score as a model failure.
We re-rendered the same cities in native order and measured again. The model scored 83.8%, above Pelias's 78.7. Most of the collapse came from rendering the test in the wrong order. When a model fails on exactly one stratum of your data, check the stratum before you check the model. Evaluation order has caused this mistake for us twice, and both times the fix required no new work.
After we corrected the rendering, a residual gap remained that order artifacts did not explain. With the anchor on, international-order German still scored a few points below the same model with the anchor off. The anchor that added +35 on native addresses subtracted on international ones. A rendering fix could not explain that. The anchor was making the harder order worse, and the rest of this post investigates why.
Three swings at the residual
We first addressed training coverage. If the model had seen German only in native order, it would struggle with the international order, so we rebuilt the training extract to render both orders, roughly sixty/forty. The model with the anchor off improved: international-order parsing rose from 35.9% to 48.4%. The model can learn both layouts when it sees both.
The model with the anchor on did not improve. International stayed around 44%, still below the anchor-off number. This showed that the corpus was not the limit. That result was useful, but it did not fix the problem.
For the second attempt, we noticed that the international synthesizer dropped the region from the end of the address while the eval included it. The model was segmenting a City, Region Postcode ending it had never trained on. We rendered the region back into the ending and retrained. International region accuracy rose from zero to about forty percent, and locality accuracy did not change. The address ending was not the limit either.
The third attempt was architectural, and we expected it to work. The anchor sits on the postcode, and in international order the postcode comes after the city. We added a second injection of the anchor at the first token, where every locality can attend back to it regardless of the postcode's position. The change adds no parameters. When the anchor has zero confidence, the injection leaves the input exactly unchanged. We retrained.
It had no effect. International held at 43.7%, still below the anchor-off number.
| retrain | native, anchor on | international, anchor on |
|---|---|---|
| both-order corpus | 82.1 | 44.5 |
| region in the tail | 83.6 | 44.7 |
| second anchor at token 0 | 83.5 | 43.7 |
Three retrains left the international number unchanged. A result that stays flat across three different fixes is a finding in its own right.
What the anchor learned
The useful question was what the anchor does inside the model. We had been describing the anchor as if it encoded a meaning ("this postcode could be German"), and a meaning has no direction. What we add at that position is a vector, and during training the model learns what to do with it. What it learned has a direction.
Consider where the city sits relative to the postcode in each training distribution. In native German, the postcode comes before the city: 12623 Berlin. Every time the anchor fired during training, the locality it was supposed to help was to its right. The model learned an anchor that looks rightward. On native addresses it looks right and finds Berlin. That produces the +35 points. In an international-order address, the postcode comes after the city. The anchor still looks right, finds the region or the end of the string, and misses the city behind it. The added signal slightly disrupts the city prediction.
The US locale confirms this. American addresses put the postcode after the city (Seattle WA 98101), and the US anchor never hurt accuracy. US held at 96 to 97%. US training data is consistently postcode-after-city, so the US anchor learned to look left, toward the city, and the layout never varies. The architecture and injection point are the same, but the learned direction is opposite, because the two countries write addresses in opposite orders and each anchor learned the order it was trained on.
This asymmetry is structural, and tuning will not remove it. A single added vector can encode "look toward the city." It cannot encode "look toward the city, sometimes to the left and sometimes to the right." When both orders are mixed into one extract, the vector settles on an average that serves the dominant order. That average matches the flat international number across retrains. To rule out a name-matching artifact, we ran a containment metric that checks whether the resolved point lands inside the correct city's polygon. The gap remained: 96% on native German and 57% on the international order. The misses are geographic errors, and the scoring method did not cause them.
The measured asymmetry is acceptable
We had changed the corpus, the address ending, and the architecture without moving the number, so we stopped treating it as a bug. We brought the full sequence to our second-opinion model, the same one that argued against the flag removal last time, and it recommended the option we had been considering: accept the asymmetry and ship the result.
The evidence supports that choice. The improvement is large, stable across every retrain, and does not hurt other locales: US and French held throughout. The international penalty is small and stable. An international-order German address can skip the anchor, because the model reads both orders on its own once it has trained on both. That layout loses no measurable points when production turns the anchor off. Production therefore turns the anchor on where the postcode comes before the city and off where it comes after. That setting keeps the +35 points where they were measured.
The asymmetry also leaves the larger plan intact. One vector can only learn one direction, so a single shared anchor was never going to work for both orders. The next design is an anchor per locale, so that each learns its own country's direction: the German anchor looks right, and the American one looks left. That is about a week of work for later, and the measurement now justifies it. That is the same conclusion the last postcode post reached.
The lesson is older than this anchor
A learned signal does not encode the meaning of its name. It encodes the structure of its training data. We called it a "country anchor" and reasoned as if it knew a fact about a postcode, but it had learned where cities tend to sit relative to the postcode. The name described our intent, and the learned direction is what shipped.
When a helper signal works well on the distribution you trained it on, check what it learned before trusting it on a different distribution, such as another locale. Ours failed that check. Three retrains showed the limitation, and within its narrow scope the anchor still adds thirty-five points.