# DR-56 — A location carries a unit reference, and verification is about the building

**Raised:** 4 September 2026, while reviewing prompt 1R4R.
**Status:** decided — Sky, 4 September 2026.
**Touches:** M2 · `cl_locations`. Extends DR-55 rather than revising it.

## The question

DR-55 verifies an address against Google Places. A site inside a mall, market hall or arcade has
two addresses: the **building**, which Google knows, and the **unit**, which only the landlord and
the customer know — `G-2-1`, `Unit 3, The Arches`, `Kiosk 12`. DR-55 gave the second nowhere to
live.

## Why it needed answering

Without somewhere to put the unit, a rep recording such a site types the unit into the address,
Google disagrees, and the only way to save is **Override with a reason**. The seeded fixture says it
out loud: *"Unit is inside a market hall that Google lists under the hall name."*

So for a whole class of sites — plausibly the most common class in a hospitality and retail customer
base — the normal state becomes "unverified, with a reason". **A flag that is normally set carries no
information**, and reps stop reading override notes that every third record has. That is the exact
failure DR-55 was written to prevent, arrived at from the other direction.

## Decision

**A location carries `unit_reference`, and address verification is a claim about the building only.**

- `unit_reference` is free text on `cl_locations`. ConnectIQ's own data; Google has no opinion on it.
- It **never participates in verification**. Editing it does not mismatch an address; it may be
  present on a verified row and an overridden one alike.
- The four Google-owned fields — address, city, postal code, country — keep DR-55's behaviour
  unchanged. Override still means Google is wrong about the building.
- It displays with the address rather than apart from it: "G-2-1, 44 Oldham Street" reads like an
  address; two fields on opposite sides of a panel do not.
- **Locations only.** A company is a legal entity with a postal address and does not need it.

## Beat

**A second override reason meaning "this is a mall".** That is a note explaining a limitation of the
data model rather than a fact about the customer, and it would still leave the flag meaningless.

**Letting the unit live inside the address line.** Cheapest, and it is what happens today by
accident. It makes every mall site unverifiable, cannot be reported on, and cannot be corrected
without re-verifying the building.

## Consequences

**The Places type filter goes.** Prompt 1R4 restricted suggestions to `street_address`, `premise`,
`subpremise` and `route`. With the unit held separately, the rep is searching for a *building*, and
buildings are as often named venues as street addresses — a rep typing "Royal Festival Hall" must
find it. No `includedPrimaryTypes`.

**A street-level invariant replaces the filter.** Without an allow list, "London" becomes selectable,
and a record whose verified address is a city is worse than an honest unverified one, because the
database now vouches for it. So: **a selection only counts as verified if the resolved place has a
street-level component.** Otherwise it takes the Override path. This is ours, testable without a
network call, and it holds however Google's type taxonomy shifts.

**Duplicate detection does not know units exist.** Two sites in the same building with different
units are not duplicates. `near-match.ts` has no notion of `unit_reference` today. Not blocking in
M2 — flagged for M8, where a single mall may import as six units at one address.

**Naming.** `cl_locations` already carries `external_reference` — the site code, `SITE-0001`. These
are different things and easy to conflate: one identifies the site in a system, the other locates the
door within a building. Both the column comment and the form label must say so.

## Where it lands

- Migration `20260904120000_m2_cl_location_unit_reference_dr56.sql` — one column, plus the
  `cl_locations_visible` drop-and-recreate that any added column on that table requires.
- Prompt `M2-prompt-1R4R2` — the form field, the display, and the rule that editing it never
  mismatches.