# DR-58 · The stored address is Google's formatted address

**Decided and delivered 11 September 2026**, during the DR-55 walkthrough. Narrows DR-55; does not
reopen it. No schema change — the columns are DR-55's.

## What changed

**1. `address` is Google's `formattedAddress`, whole.** Previously the module composed a street
line from `streetNumber` + `route` and fell back to the full string only when no route component
was found. Now `place.formattedAddress` is stored verbatim, e.g.
`"123 Sukhumvit Soi 1, Khlong Toei, Bangkok 10110, Thailand"`.

**Why.** A recomposed street line is our taxonomy imposed on Google's, and it loses whatever
Google knows about how an address is written in that country. Google's own formatted string is
the one value guaranteed to be present, correctly ordered, and locally conventional.

**2. `city`, `postalCode` and `country` are analytics fields.** Still extracted from
`addressComponents`, still stored, still shown — but they are no longer the source of truth for
what the address *is*, and they are not guaranteed present.

**3. The city fallback chain, extended.** No component type means "city" in every country.
Thailand has no city at all outside Bangkok — province → district (amphoe) → sub-district
(tambon) — and Bangkok's own districts are tagged `sublocality_level_1`, not
`administrative_area_level_2` as a province's are. The chain is now:

```
postal_town → locality → administrative_area_level_2 → sublocality_level_1 → administrative_area_level_1
```

**This is a fallback to the coarsest available label, not a claim that any of these is the city.**
For a Thai address the last link yields the province. That is wrong as a semantic and better than
an empty field, which is the whole of the argument. A correct answer needs per-country address
semantics and is not worth it at this scale.

**4. `streetNumber` and `street` removed.** They existed only to build the old street-only
address. `route` stays: `hasStreetLevel` depends on it, and that is a separate question — whether
a place resolves to a real street — from what gets stored as the address string.

**5. Location suggestions are biased toward Southeast Asia.** `locationBias` with a bounding box
of roughly north 29, south −11, east 141, west 92. **A soft re-ranking, not a restriction** —
addresses outside the region still resolve. It exists because an unbiased global search ranks
poorly for the region the customer base is concentrated in.

**6. The place's own name is offered as a suggestion for the record's Name field** — e.g.
"CentralWorld". Offered, never applied, and deliberately **not** part of `AddressFields`: Name
lives outside the address block, so it cannot trigger or clear a verification mismatch.

## What did not change

The DR-55 contract holds: suggestions are shown and never applied automatically; nothing
autosaves; the override flow requires a note; the database CHECK still refuses a verified address
carrying an override note; the no-key path still degrades to a plain text input that saves
unverified.

## Two consequences worth knowing

**`city`, `postalCode` and `country` are still compared by `sameFields`.** All four fields remain
in the mismatch test, so editing the city still invalidates verification even though the city is
described above as an analytics field. That is defensible — any edit to a displayed address field
should invalidate a verification the user is visibly departing from — but the comment and the
comparison are saying slightly different things. **If a rep ever needs to correct a city without
losing verification, this is the line to revisit**, not a bug to fix pre-emptively.

**The address string now repeats the analytics fields.** `formattedAddress` already contains the
city, the postcode and the country, so those values appear twice on the form. Deliberate: the
separate fields are what makes the data queryable, and the string is what makes it correct.
Whether the form should present them as subordinate to the address rather than beside it is a
presentation question for UX-1, not an address question.