# Hospitality & Commercial Context — methodology gate

**This document is populated for Gate A — Unit & Identity, Gate B — Activity
Taxonomy, Gate C — Status Semantics, Gate D — Temporal Comparability, Gate E —
Geographic Reconciliation and Gate F — Denominator Construction & Indicator
Admissibility.** (Gate B renumbers the later gates' evidence questions onto C–F;
issue #33's original letters are preserved.)

Nothing here builds a UI, a map layer, an indicator, a score, a ranking or a
denominator, and nothing here changes HATI, Destination Context, Area Profile,
population, VUT or any existing production dataset. It is research.

The reproducible evidence lives in
[`research/hospitality_commercial_gate/`](../research/hospitality_commercial_gate/).
Every count below is produced by
[`audit_identity.py`](../research/hospitality_commercial_gate/audit_identity.py)
and stored in
[`results/gate_a_identity_summary.json`](../research/hospitality_commercial_gate/results/gate_a_identity_summary.json).
None were typed by hand.

---

## Gate A — Unit & Identity

### The single question

> Can the same local/premises and its associated activities be tracked between
> consecutive monthly snapshots using a stable, source-native identifier — without
> relying on names, addresses, coordinates or fuzzy matching?

### A.0 · Retrieval date/time

Audited on **2026-09-30** (UTC timestamps recorded per resource in the results
file). Fetched directly from `datos.madrid.es`. The Gate C0 network block of
2026-09-30 was an environment-specific egress policy; this audit ran from an
environment where `datos.madrid.es` was reachable, and records a SHA-256 for every
file so the exact upstream state is verifiable.

### A.1 · Source files examined

Dataset: **Censo de locales, sus actividades y terrazas de hostelería y
restauración — histórico**, `datos.madrid.es`
`209548-0-censo-locales-historico`, licence **CC BY 4.0**, catalogue state
`2026-09-28T15:40:59` at audit time.

The dataset publishes four monthly resource families (Actividades, Locales,
Locales con información de licencia, Terrazas). Gate A examines **Locales** and
**Actividades** only. Licencias and Terrazas were **not** fetched.

Structure document read in full:
[`estructura_ds_ficherocla.pdf`](https://datos.madrid.es/dataset/209548-0-censo-locales-historico/resource/209548-403-censo-locales-historico/download/estructura_ds_ficherocla.pdf)
— *"Datos abiertos: Censo de Locales y Actividades", versión mar/2022*. One
document governs **both** the Locales and Actividades files.

### A.2 · Exact resource months

Resolved deterministically by exact `description` match (the only field carrying
family + month; unique per resource). Opaque numeric ids are recorded, not used to
select.

| Family | Month | Resource id | Bytes | SHA-256 (head) | HTTP Last-Modified |
|---|---|---|---:|---|---|
| Locales | Sep 2026 | 209548-851 | 89,266,582 | `2475e8bcff7d` | Thu 03 Sep 2026 06:18 |
| Locales | Aug 2026 | 209548-839 | 89,296,127 | `906a02b2a5a2` | Mon 28 Sep 2026 15:43 |
| Locales | Sep 2025 | 209548-726 | 89,900,542 | `a9b5571a86eb` | Mon 16 Feb 2026 00:52 |
| Actividades | Sep 2026 | 209548-857 | 124,927,121 | `47185269efe6` | Thu 03 Sep 2026 06:45 |
| Actividades | Aug 2026 | 209548-845 | 125,004,408 | `ca31fbef1c06` | Mon 28 Sep 2026 15:28 |
| Actividades | Sep 2025 | 209548-35 | 126,043,844 | `cd7f232695700` | Sun 15 Feb 2026 23:53 |

> **A published-cut caveat that must travel with these two months.** The file
> *labelled* "Agosto 2026" carries a **later** HTTP `Last-Modified` (28 Sep 2026)
> than the one labelled "Septiembre 2026" (03 Sep 2026). The month label is the
> reference period; the timestamp is when the file was last served. They do not
> contradict the identity findings, but they mean the *direction* of the Aug→Sep
> churn in A.4 reflects this particular pair's cut timing, not a clean calendar
> delta. The Sep 2025 → Sep 2026 control is the cleaner longitudinal picture.

### A.3 · Row / unit semantics

The structure document is explicit, and the data confirm it exactly.

- **Locales — one row is one premises (`local`).** *"Fichero de locales en el que
  cada registro corresponde a un local."* Confirmed: in every snapshot the row
  count equals the distinct `id_local` count with zero duplicates and zero blanks
  (Sep 2026: 203,610 rows / 203,610 distinct).
- **Actividades — one row is one premises × one activity epigraph.** *"Cada
  registro corresponde a un local más un código de actividad… si un local tiene
  asociado más de un epígrafe de actividad, dicho local aparecerá repetido tantas
  veces como epígrafes tenga."* Confirmed: Sep 2026 has 225,556 rows, of which
  187,484 locals carry one activity and 16,126 carry more than one (max 14).

The two files share the same premises block and the same premises universe: in
Sep 2026, **0** Actividades rows reference an `id_local` absent from the Locales
file (referential integrity holds).

`one local ≠ one activity row` — as the gate anticipated. Premises identity and
activity identity therefore need **different keys**, established next.

### A.4 · Candidate identifiers and uniqueness

| Candidate | File | Semantics | Uniqueness (Sep 2026) | Verdict |
|---|---|---|---|---|
| **`id_local`** | Locales | documented premises code | 203,610 / 203,610 distinct, 0 blank, 0 dup | **premises key** |
| **`(id_local, id_epigrafe)`** | Actividades | premises × epigraph | 225,556 / 225,556 distinct, 0 dup pairs; but 53,242 rows have a **blank** epigraph | **classified-activity key** — valid only where `id_epigrafe` is populated (172,314 rows); blank rows are **not** an activity identity (A.9, A.10) |
| `id_local` alone | Actividades | — | repeats by design (1 per epigraph) | not a row key here |
| `id_ndp_edificio` (address) | Locales | building address code | 40,588 addresses hold >1 local; max 264 | rejected (A.6) |
| coordinates | Locales | approx. entrance UTM | one pair `(0.0,0.0)` shared by 50,808 | rejected (A.6) |
| `rotulo` (name) | Locales | commercial sign | 53,244 blank; `"S/R"` on 11,454 | rejected (A.6) |

`id_local` is documented as *"Código numérico que identifica cada local"*, derived
from `id_ndp_edificio` + `secuencial_local_PC` (puerta de calle) or from
agrupación + planta + local (agrupado) — an address-anchored construction, which
is consistent with the empirical stability below.

### A.5 · Cross-month persistence

**Premises (`id_local`), Locales, Aug → Sep 2026:**

- Aug 203,680 → Sep 203,610; intersection **203,610**; persistence **99.966%**.
- 70 disappeared, 0 appeared (see the published-cut caveat, A.2).
- Of 203,610 persistent premises, only **688 changed any tracked attribute while
  `id_local` stayed identical**: rótulo 623, situación 123 (e.g. 80 Cerrado→Abierto,
  28 Abierto→Cerrado), coordinates 11, building/number 5. This is the crux: the key
  is stable *while* descriptive attributes move. Identity is not a description.

**Premises (`id_local`), Locales, Sep 2025 → Sep 2026 control:**

- Sep 2025 202,346 → Sep 2026 203,610; intersection **202,343**; persistence
  **99.999%** — only **3** premises from a year earlier are absent, 1,267 new.
- This holds **across a format change**: the 2025 file is unquoted, the 2026 file
  quotes every field (A.7). The source-native key survives it intact; a
  line/string identity would have matched nothing.

**Activity (`id_local, id_epigrafe`), Actividades, Aug → Sep 2026:**

- 225,689 → 225,556 pairs; intersection **224,983**; pair persistence **99.687%**.
- 706 pairs left, 573 appeared — activities churn on premises that themselves
  persist (the premises `id_local` persistence is the same 99.966%). New activities
  attach to existing locals; this is coherent, expected behaviour, not instability.
- This persistence is a property of the *pair*; it does not resolve the 53,242
  blank-epigraph rows, whose pair is `(id_local, "")` and whose meaning is a Gate B
  question (A.9, A.10).

> **Direction caveat (both files, Aug → Sep 2026).** The pair is valid for identity
> *persistence* testing, but the appeared/disappeared *direction* must not be read as
> clean calendar-month churn: the published resource timing is inverted (A.2), so
> September is a near-subset of August. The Sep 2025 → Sep 2026 control is the
> representative directional delta.

### A.6 · Negative controls — why weaker identities are rejected

Each was tested on the real Sep 2026 Locales file, not merely asserted.

- **Name (`rotulo`).** 53,244 of 203,610 rows blank; the single value `"S/R"`
  covers 11,454 premises, `"ROTULO NO INFORMADO"` 4,848, `"VIVIENDAS TURISTICAS"`
  2,878 — and the accented/unaccented pair `"RÓTULO NO INFORMADO"` (1,679) vs the
  unaccented form shows the same concept spelled two ways. Unusable as identity.
- **Full address (`id_ndp_edificio`).** 40,588 addresses legitimately hold more
  than one local; one building address holds 264. A building is not a premises.
- **Coordinates.** "No coordinate" is encoded as the sentinel `(0.0, 0.0)`, shared
  by 50,808 locals; agrupados share their agrupación's single coordinate. Only
  137,245 distinct pairs for 203,610 locals. Unusable.
- **Concatenated descriptive fields / fuzzy matching.** Since name, address and
  coordinates each fail individually, and 688 persistent premises change one or
  more of exactly these fields month-to-month (A.5), any string concatenation of
  them is *both* non-unique *and* non-stable. No fuzzy matching is used anywhere;
  the source-native key makes it unnecessary.

### A.7 · Schema / format drift observed (documented, not normalised away)

The mar/2022 structure document and the 2025–2026 files disagree on form, though
not on the identity fields:

- **Delimiter.** Document says `|`; the 2025–2026 files use `;`.
- **Quoting.** 2026 files quote every field and carry a UTF-8 BOM; the Sep 2025
  file is unquoted (still BOM-prefixed). The audit detects dialect per file.
- **Field name.** Document writes `ide_epigrafe`; the files use `id_epigrafe`.
- **Coordinates.** Document lists a single `coordenadas x-y_local`; the files split
  it into `coordenada_x_local` and `coordenada_y_local`.
- **Undocumented columns.** `cod_postal`, `hora_apertura1/2`, `hora_cierre1/2` and
  a per-row load date `fx_carga` appear in the files but not the mar/2022 document.
- **Undocumented access type.** `id_tipo_acceso_local = 3` ("Interior", 51,455 rows
  in Sep 2026) is not among the document's 0/1/12 codes.
- **Column count is stable across all six files** (Locales 46, Actividades 47), so
  no column-level break exists across the audited window.

None of this alters `id_local` or `(id_local, id_epigrafe)`; it is recorded so a
later gate does not mistake a format change for a real change.

### A.8 · Geography observation (not the geography gate)

Recorded only to answer whether source-native geography exists for later testing.
It does: Locales carries `id_distrito_local`, `id_barrio_local` (which *includes*
the district code), `cod_barrio_local`, `id_seccion_censal_local` and coordinates.
In Sep 2026 the file contains **exactly 131 distinct `id_barrio_local`** and **21
distinct `id_distrito_local`**, with **1** row missing a barrio. The count matches
Lens's canonical 131 barrios and 21 districts — **promising, and to be *tested*,
not assumed, in Gate E.** No reconciliation is built here.

### A.9 · Known uncertainties

1. **Published-cut timing (A.2).** The Aug/Sep 2026 labels do not correspond to a
   clean sequential cut; the "August" file was served later. Aug→Sep new/disappeared
   counts are pair-specific. The 2025→2026 control is the more representative delta.
2. **Blank epigraph — activity semantics UNRESOLVED.** 53,242 Actividades rows in
   Sep 2026 have a blank `id_epigrafe`; for those rows the pair collapses to
   `(id_local, "")`. Row-level uniqueness still holds, but `(id_local, "")` is **not**
   a known activity identity and is not treated as one. This gate does not reinterpret
   the blank, does not assign a placeholder activity category, and does not discard the
   rows. Their meaning is deferred to Gate B. Classified activity identity is asserted
   only for the 172,314 rows whose epigraph is populated.
3. **Situación is a "variable de mantenimiento complicado"** (source's own words):
   there is no procedure that records when an activity ceases and a local closes
   without a new activity appearing. Any use of situación is Gate C; it is out of
   scope for identity.
4. **Records not to be counted as premises.** The source states situación Baja (8,
   12,427) and Baja R (9, 4,114) and access type "PC Asociado" (12, 2,877) *"no
   deben tenerse en cuenta a la hora de extraer datos del número total de locales."*
   Identity is unaffected; any future *count* must apply these exclusions. That is
   a counting rule for a later gate, deliberately not applied here.
5. **Full history untested.** Only three months were examined. The claim is about
   Aug/Sep 2026 with a Sep 2025 control, not about 2014→2026 homogeneity (Gate D).

### A.10 · Gate A ruling — **GO to Gate B, with one explicit scope limitation**

The ruling is deliberately split, because one part of the activity file is not yet
resolvable at Gate A:

| Question | Ruling |
|---|---|
| **Premises identity** — `id_local` | **GO** |
| **Classified activity identity** — `(id_local, id_epigrafe)` *where `id_epigrafe` is populated* | **GO** |
| **Blank-epigraph activity semantics** — the 53,242 Sep 2026 rows with a blank `id_epigrafe` | **UNRESOLVED — deferred to Gate B** |
| **Overall Gate A** | **GO to Gate B**, subject to the limitation above |

- **Premises key: `id_local`** — unique within every snapshot (0 duplicate, 0
  blank), 99.966% persistent Aug→Sep 2026 and 99.999% across a full year, stable
  under both descriptive-attribute drift and a CSV formatting change.
- **Classified activity key: `(id_local, id_epigrafe)` where the epigraph is
  populated** — the pair is unique within every snapshot (0 duplicate pairs);
  172,314 of the 225,556 Sep 2026 rows carry a populated epigraph, and 99.687% of
  the Aug→Sep pairs persist, with activity churn correctly localised onto persistent
  premises.
- **Blank-epigraph rows are NOT a known activity identity.** For the 53,242 Sep 2026
  rows with a blank `id_epigrafe`, the pair collapses to `(id_local, "")`. This gate
  does **not** call that an activity identity, does **not** reinterpret the blank,
  does **not** invent a placeholder activity category, and does **not** discard the
  rows. What they represent is a taxonomy/semantics question that belongs to Gate B.
- **Row unit — Locales:** one premises. **Actividades:** one premises × activity
  epigraph. Documented and confirmed.
- Every weaker identity (name, address, coordinates, concatenation, fuzzy) is shown
  to be non-unique, non-stable, or both.

The same local/premises **can** be followed reproducibly between monthly snapshots
using its source-native identifier, and so can each of its *classified* activities.
Gate A is satisfied for identity; the blank-epigraph rows are the one carve-out
handed forward to Gate B.

**What GO does not authorise.** No indicator, count, taxonomy, denominator, map or
status interpretation is admitted by this ruling. A premises census record remains
administrative evidence — not economic vitality, not commercial success, not visitor
demand, not tourism pressure, and not evidence that a documented premises is trading
today. GO means only that identity is solved well enough for the next gate to begin.

### Recommendation for Gate B (taxonomy)

Gate B should read the official three-level epigraph classification (Sección 21 /
División / Epígrafe) and define a reproducible hostelería/restauración and
commercial subset. Two facts from this audit bound that work: the files carry **453
distinct epigraphs and 86 divisions** in Sep 2026 (the mar/2022 document says 448
and 87 — the taxonomy has drifted and must be read live, not from the PDF), and
**53,242 activity rows carry a blank epigraph** and must be handled explicitly
rather than silently dropped or bucketed.

---

## Gate B — Activity Taxonomy

The reproducible evidence for this section is produced by
[`audit_taxonomy.py`](../research/hospitality_commercial_gate/audit_taxonomy.py)
and stored in
[`results/gate_b_taxonomy.json`](../research/hospitality_commercial_gate/results/gate_b_taxonomy.json)
(full per-epigraph mapping) and
[`results/gate_b_taxonomy_summary.json`](../research/hospitality_commercial_gate/results/gate_b_taxonomy_summary.json).
Every count below is produced by that script from the live source and stored in
those files; none were typed by hand. The audit reuses the Gate A source contract
(catalogue resolution by exact `description`, streamed fingerprinting, per-file
dialect detection) by importing the Gate A helpers, so both gates provably read the
same upstream the same way.

### B.0 · Scope

Gate B resolves **one** question: *which official activity epigraphs can support a
defensible Hospitality & Commercial Context classification, and which cannot?* It
builds a classification **layer** only. It does **not** build an indicator, count,
ranking, score, denominator, map, or any "pressure", "overtourism", "saturation" or
"commercial vitality" claim. An activity record remains administrative evidence — it
is not revenue, turnover, employment, footfall, demand, popularity, commercial
health, economic success, tourist use, tourist expenditure, visitor pressure, legal
compliance, or proof that a premises is trading today. Central location is not read
as tourist orientation, and hospitality presence is not read as tourist demand.

The taxonomy is read **live** from the primary snapshot **Actividades. Septiembre
2026** (resource `209548-857`, SHA-256 head `47185269efe6`), with **Actividades.
Septiembre 2025** (resource `209548-35`, SHA-256 head `cd7f23269570`) as a
drift/control snapshot. Only these two Actividades files are fetched; no years of
history are downloaded, and no raw CSV is committed.

### B.1 · Observed taxonomy

The primary snapshot carries a clean three-level hierarchy. Read live:

| Quantity | Sep 2026 (live) |
|---|---:|
| Distinct sections (`id_seccion`) | **21** |
| Distinct divisions (`id_division`) | **86** |
| Distinct populated epigraphs (`id_epigrafe`) | **453** |
| Rows total | 225,556 |
| Rows with a populated epigraph | **172,314** |
| Rows with a blank epigraph | **53,242** |

For every populated epigraph the report records its `id_seccion`, `desc_seccion`,
`id_division`, `desc_division`, `desc_epigrafe`, activity-row count and distinct
`id_local` count.

**One epigraph maps to exactly one parent.** `epigraph_multi_parent_count` is **0**:
no `id_epigrafe` appears under more than one `(id_seccion, id_division)` pair. This is
the fact that makes a hierarchy-based classification safe (Stop condition 2 does not
fire). **One epigraph carries a within-snapshot description inconsistency:** code
`561008` appears as both `ESTABLECIMIENTO DE RESTAURACION MOVIL` and `VENDEDOR
AMBULANTE DE ALIMENTOS PREPARADOS PARA SU CONSUMO INMEDIATO`. Both are food service
under division 56, so the *class* is unaffected; the inconsistency is recorded on the
epigraph record rather than normalised away.

### B.2 · Source hierarchy semantics

The structure document (`estructura_ds_ficherocla.pdf`, versión mar/2022), section
IV, is explicit, and the live data confirms it:

- **Epígrafe is an administrative code, not an operational label.** Activities are
  coded by *"una clasificación propia del Ayuntamiento que parte de los antiguos
  epígrafes de Impuesto de Actividades Económicas (I.A.E.)"*, and the epigraph
  information is provided *"sólo a efectos estadísticos"*. It is derived from a tax
  register lineage; it is not a statement that a business trades, earns or is used.
- **Sección and División are CNAE-09.** The document states the two upper levels
  *"coinciden con los utilizados por la CNAE-09 del INE"* and that *"todos los
  epígrafes de una misma división empiezan por los dos dígitos de división."* So the
  section (a letter) and division (two digits) are **source-stable, INE-aligned
  administrative categories**, and the epigraph code itself begins with its division.
  Classification in Gate B is therefore made on the **official section/division the
  file carries**, never by keyword-matching the free-text description.
- **The PDF counts are stale; the live counts govern.** The mar/2022 document reports
  **21 sections / 87 divisions / 448 epigraphs**; the live Sep 2026 data has **21 /
  86 / 453**. The PDF is not exhaustive and is not used as the taxonomy of record.
- **Mixed sections exist.** Section I (Hostelería) itself contains two very different
  divisions — 55 (alojamiento) and 56 (comidas y bebidas) — and section R mixes
  culture, sport, entertainment and gambling. This is why the classification resolves
  section I and section N at the division level rather than the section level.

### B.3 · Classification framework

Six analytical classes (issue #33's letters A–F), assigned on the CNAE
section/division, plus a separate label for the blank rows. No class is a binary
"tourism / not tourism" variable.

| Class | Meaning | Source-native rule |
|---|---|---|
| **A · Core hospitality / restoration** | Food and beverage service | Division **56** |
| **B · Accommodation** | Lodging (kept separate from A, and from VUT / Madrid Destino) | Division **55** |
| **C · Tourism-adjacent commercial context** | Not inherently a tourist business but defensibly destination-relevant | Division **79** |
| **D · Generic commercial context** | Documented commerce, background composition only | Section **G** (div 45/46/47) |
| **E · Excluded** | Outside a Hospitality & Commercial Context reading | All other sections + Z (SIN ACTIVIDAD) |
| **F · Ambiguous / manual review** | Semantics do not permit a confident class | Section **R** (div 90/91/92/93) |
| *(separate)* **UNCLASSIFIED_SOURCE_ACTIVITY** | Blank epigraph — a premises with no activity classification recorded | blank `id_epigrafe` |

The assignment is a rule on the official code (`DIVISION_OVERRIDE` for 55/56/79, else
`SECTION_DEFAULT`), so every one of the 453 epigraphs is auditable to its CNAE parent.
Programmatic grouping assists review; it is not a black-box authority, and there is no
keyword-only production rule. The six classes **partition** the populated universe
exactly: 21 + 9 + 1 + 158 + 241 + 23 = **453** epigraphs and 22,762 + 8,092 + 837 +
53,575 + 82,768 + 4,280 = **172,314** rows.

Per-class rollup (Sep 2026). *Distinct-premises counts are a union within each class
and deliberately do **not** sum across classes — a premises may host activities in
more than one class:*

| Class | Epigraphs | Source rows | Distinct premises |
|---|---:|---:|---:|
| CORE_HOSPITALITY (56) | 21 | 22,762 | 21,552 |
| ACCOMMODATION (55) | 9 | 8,092 | 8,007 |
| TOURISM_ADJACENT (79) | 1 | 837 | 837 |
| GENERIC_COMMERCIAL (G) | 158 | 53,575 | 44,433 |
| EXCLUDED | 241 | 82,768 | 77,652 |
| AMBIGUOUS (R) | 23 | 4,280 | 3,997 |

### B.4 · Core hospitality / restoration

**Division 56 — Servicios de comidas y bebidas.** 21 epigraphs, 22,762 activity
rows, 21,552 distinct premises. This is the food-and-beverage core: restaurants,
fast food, cafés/bars, catering and mobile food service all sit under one CNAE
division whose code prefix is unambiguous (`56xxxx`). The defensible management
question this supports is bounded: *"how much administratively documented
food-and-beverage activity is recorded in a barrio?"* — not how much it earns, how
busy it is, or whether it serves tourists. **GO.**

### B.5 · Accommodation

**Division 55 — Servicios de alojamiento.** 9 epigraphs, 8,092 activity rows, 8,007
distinct premises. Lodging is a **separate** class from food/beverage: CNAE places
hotels, hostels and other lodging in division 55, distinct from 56. Examples include
`HOTELES Y MOTELES CON/SIN RESTAURANTE`.

This class is census-**activity** evidence and is a **different evidence universe**
from the project's licensed-VUT numerator and from the Madrid Destino accommodation
catalogue. It must **not** be merged with them; any later reconciliation is a separate
decision-module task with explicit compatibility logic. As a class, it is defensible
and cleanly source-native. **GO** (as a distinct class, with the no-merge condition).

### B.6 · Tourism-adjacent commercial context

**Division 79 — Agencias de viajes, operadores turísticos y servicios de reservas.**
1 epigraph, 837 rows, 837 premises. This is the one category that is both
destination-facing and cleanly isolable by a source-native code. It is admitted
because a real management question justifies it (documented travel-trade presence),
not because it contains the word "turístico".

No other category is admitted to C. Section R (culture, entertainment, sport,
gambling) is a *candidate* — museums, shows and sports venues are plausibly
destination-relevant — but the section is heterogeneous and no source-native sub-code
isolates the tourism-facing part, so it is held in F, not forced into C. **GO for
division 79 only; MODIFY** if C is to be broadened, which would require an explicit
management question and, ideally, a source-native way to isolate the relevant subset.

### B.7 · Generic commercial context

**Section G — Comercio al por mayor y al por menor; reparación de vehículos.** 158
epigraphs, 53,575 rows, 44,433 premises (divisions 45 vehicle sales/repair, 46
wholesale, 47 retail). This is the barrio's documented commercial composition, with no
tourism-specific interpretation. It supports the question *"what is the documented
commercial composition of the barrio?"* — background only. **GO.**

The boundary between D and E is, beyond section G, a **scope decision, not a taxonomy
fact.** Several excluded sections are consumer-facing and could be folded into a
broader "commercial composition" if a management question warranted it — finance and
insurance branches (K, div 64/65/66), real-estate agencies (L, div 68), and repair and
other personal services (S, div 95/96). The report flags these divisions as
`broader_composition_candidate` rather than silently discarding them. They are not
included in the confirmed commercial class here.

### B.8 · Blank epigraph analysis

**53,242 rows carry a blank `id_epigrafe` — the single most important finding of Gate
B.** What was learned:

1. **The whole taxonomy is blank, not just the epigraph.** In all 53,242 rows,
   `id_seccion`, `id_division` and all three descriptions are empty as well. There is
   **no higher hierarchy level to fall back to** — a blank epigraph cannot be rescued
   to a section or division.
2. **It is one row per premises, and never co-occurs with a classified activity.**
   53,242 distinct `id_local`; `locals_blank_only_no_populated = 53,242`;
   `locals_blank_and_also_populated = 0`. A premises either carries classified
   activities **or** appears once with an entirely blank taxonomy — never both.
3. **It is not merely "closed".** Situación skews to Cerrado (24,046), Baja (9,069),
   Uso vivienda (7,396) and Baja R (1,704) — but **11,027 are "Abierto"** (open,
   with declared economic activity per the source) yet carry no activity code. So the
   blank is genuinely an *absent classification*, not a synonym for a closed premises.
4. **It is spread across the whole city** — present in all 131 barrios — so it is not
   a localised artefact.
5. **The source documentation does not define it.** The structure PDF describes every
   field but never says what an empty epigraph means. The characterisation above is
   therefore **empirical only**.
6. **A higher-level classification is not supported** (point 1), and the rows must not
   be invented into an epigraph, assigned "unknown hospitality", bucketed, discarded,
   or treated as the activity identity `(id_local, "")`.

**Ruling for the blank set — split: handling RESOLVED, source semantics UNRESOLVED.**
The *empirical handling* is **RESOLVED**: the set is fully characterised (points 1–4
above) and carried under the project label **`UNCLASSIFIED_SOURCE_ACTIVITY`** — a
premises-level "no activity classification recorded" set, explicitly outside classes
A–F and **not an activity**, distinct from section **Z "SIN ACTIVIDAD"** (4,402 rows
under code `000000`), which is an explicit **populated** "no activity" code classified
as Excluded. The *source semantics* are **UNRESOLVED**: the official documentation
never defines an empty epigraph (point 5), so **why** these records carry no taxonomy
is not stated by the source and is not asserted here. `UNCLASSIFIED_SOURCE_ACTIVITY`
is therefore a **project handling label, not an official source meaning**. The blank
set must be carried explicitly through any later premises-level counting and **never
silently dropped** from a denominator.

### B.9 · Taxonomy drift

Sep 2025 → Sep 2026, taxonomy stability only (not a trend claim; full comparability
is a later gate):

| Check | Result |
|---|---|
| Epigraphs present in both | **453** |
| New epigraph codes in 2026 | **0** |
| Disappeared epigraph codes | **0** |
| Same code, changed description | **0** |
| Same code, changed division/section | **0** |
| Distinct sections | 21 → 21 |
| Distinct divisions | 86 → 86 |
| Blank-epigraph share | 24.08% → 23.60% |

The taxonomy is **stable across this one-year pair**: identical code set, identical
descriptions, identical parents, identical section/division counts, and a
near-constant blank share (~24%). The only drift observed anywhere is the **PDF vs
live** discrepancy (87→86 divisions, 448→453 epigraphs) noted in B.2, which is a
documentation-lag artefact, not a change between the two live snapshots. No claim is
made about the 2014→2025 history, which is not examined here.

### B.10 · Interpretation limits

- The classification is a **layer**, not a verdict. It labels what kind of activity a
  code represents; it does not measure how much, how busy, how profitable, or how
  touristic.
- **Counts are not yet admitted.** The per-class row and premises counts in B.3 are
  observations that describe the taxonomy's shape; they are not a barrio indicator and
  carry no denominator. The source's own counting rules (situación Baja 8/9 and access
  type 12 *"no deben tenerse en cuenta a la hora de extraer datos del número total de
  locales"*) are a Gate C/F concern and are **not** applied here.
- **Accommodation (B) must not be merged** with licensed-VUT or Madrid Destino
  evidence; they are different universes.
- The **blank set** must remain visible in any later premises-level denominator.
- Central location, hospitality density and status are **not** admitted as evidence of
  tourist demand, pressure or economic strength.

### B.11 · Gate B ruling — **GO to Gate C, with scoped sub-rulings**

| Question | Ruling |
|---|---|
| **Core hospitality / restoration** — division 56 | **GO** |
| **Accommodation** — division 55 | **GO** (distinct class; no merge with VUT / Madrid Destino) |
| **Tourism-adjacent commercial context** — division 79 | **GO** (division 79 only); **MODIFY** to broaden (needs a management question) |
| **Generic commercial context** — section G | **GO** |
| **Blank-epigraph** — handling | **RESOLVED** — characterised and labelled `UNCLASSIFIED_SOURCE_ACTIVITY` (a project handling label) |
| **Blank-epigraph** — source semantics | **UNRESOLVED** — the official documentation does not define why these records carry no taxonomy |
| **Overall Gate B** | **GO to Gate C**, subject to the scope limitation below |

A defensible hospitality/restoration subset (56), a defensible and *separate*
accommodation subset (55), a clean tourism-adjacent code (79) and a defensible generic
commercial subset (section G) all exist as source-native CNAE categories; the
ambiguous entertainment/culture section (R) is held explicitly for manual review
rather than forced into a tourism class; and the blank rows' *handling* is resolved as
an explicit unclassified set while their *source semantics* remain undefined by the
documentation. No result is hidden under a blanket GO.

**What GO does not authorise.** No indicator, count, ranking, score, denominator, map
or status interpretation is admitted by this ruling. A classification layer is not a
policy verdict.

### Product name (B evaluation)

**Recommendation: keep "Hospitality & Commercial Context."** The taxonomy supports it:
*Hospitality* maps cleanly to CNAE section I (division 56 food/beverage + division 55
accommodation) and *Commercial Context* maps cleanly to CNAE section G (comercio). Both
pillars have defensible source-native definitions. This is recorded as a
recommendation only; production is not renamed here, and the name is valid solely for
the classification layer — never as a tourism-pressure or vitality claim.

### Recommendation for Gate C (status semantics)

Gate C should establish exactly what `id_situacion_local` (Abierto/Cerrado/Uso
vivienda/Obras/Baja/Baja R) can and cannot mean, given the source's own warning that
situación is a *"variable de mantenimiento complicado"* with no procedure to record
when an activity ceases without a replacement. Two Gate B facts bound that work: the
53,242 `UNCLASSIFIED_SOURCE_ACTIVITY` rows carry a situación even with no activity code
(including 11,027 "Abierto"), and the source's exclusion rules for situación 8/9 and
access type 12 are a counting decision that Gate C/F must confront before any premises
count is admitted. Gate C must not translate abierto/cerrado into operating
performance, demand, turnover or commercial success.

---

## Gate C — Status Semantics

The reproducible evidence for this section is produced by
[`audit_status.py`](../research/hospitality_commercial_gate/audit_status.py) and
stored in
[`results/gate_c_status.json`](../research/hospitality_commercial_gate/results/gate_c_status.json)
(full report) and
[`results/gate_c_status_summary.json`](../research/hospitality_commercial_gate/results/gate_c_status_summary.json)
(compact digest). Every count below is produced by that script from the live source
and stored in those files; none were typed by hand. The audit imports the Gate A
helpers (catalogue resolution by exact `description`, streamed fingerprinting,
per-file dialect detection) and the Gate B classification (`classify`, the CNAE
section/division class map), so all three gates provably read the same upstream and
classify activities the same way.

### C.0 · Scope

Gate C resolves **one** question: *what can the administrative status fields
(`id_situacion_local`, `id_tipo_acceso_local`) legitimately tell us about whether a
premises belongs in a future administrative count — and what must they never be read
as?* It establishes a **semantics layer** only. It builds **no** indicator, count
for production, ranking, score, denominator, map, or any "operating business",
"business failure", "economic", "vitality", "saturation" or "tourism-pressure"
claim. A status field is administrative evidence, nothing more.

Three evidence levels are kept in **separate fields** throughout the machine-readable
report and never merged: **(1) source semantics** — what the structure document
actually says; **(2) empirical observation** — what the live data shows; **(3)
project handling / interpretation ceiling** — our analytical decision. A
project-handling label is **not** official source metadata.

Status lives on **Locales** (one row = one premises); taxonomy lives on
**Actividades** (one row = one premises × epigraph). Gate C reads the primary
snapshot **Locales. Septiembre 2026** and **Actividades. Septiembre 2026**, with
**Locales. Septiembre 2025** as a status-mutability control. It does **not** download
the full history — that is Gate D.

> **⚠ `nominal_snapshot_revision` — the "Septiembre 2026" resource was re-published.**
> This is a formal provenance finding, not an incidental note. The resource *labelled*
> "Septiembre 2026" that Gate C read is a **later published revision** of the one Gate
> A/B read: the Sep 2026 Locales fingerprint changed from SHA-256 `2475e8bcff7d…`
> (HTTP `Last-Modified` 03 Sep 2026, 203,610 premises) at the Gate A/B run to
> `4ca33fed004b…` (HTTP `Last-Modified` 01 Oct 2026, **203,688** premises) at the Gate
> C run. Therefore:
>
> 1. Gate C uses a **later published revision** of the resource labelled "Septiembre
>    2026" than Gate A/B did.
> 2. Gate C counts **must not** be numerically compared against the earlier Gate A/B
>    Sep-2026 counts **without using their respective SHA-256 fingerprints**.
> 3. This does **not** invalidate Gate A/B conclusions; those remain valid observations
>    tied to their own recorded SHA-256 upstream states.
> 4. The mutable/revised nature of nominal monthly snapshots is a formal **Gate D**
>    temporal-comparability question.
> 5. **Never treat the month label alone as sufficient version identity** — identity is
>    the (month label + SHA-256 fingerprint) pair.
>
> Counts throughout Gate C are observations of one run against the fingerprinted
> resources recorded in the results file, not repository invariants. The Sep 2025
> control file is byte-for-byte the one Gate A saw (SHA `a9b5571a86eb`). The machine-
> readable form of this finding is `nominal_snapshot_revision` in
> [`gate_c_status.json`](../research/hospitality_commercial_gate/results/gate_c_status.json)
> and its summary.

### C.1 · Status universe

**`id_situacion_local` — complete observed universe (Sep 2026 Locales, 203,688
premises; one row per premises, so rows = distinct `id_local`):**

| Code | Official description | Premises | Share | Source counting instruction |
|---|---|---:|---:|---|
| 1 | Abierto | 139,797 | 68.63% | none |
| 4 | Cerrado | 38,888 | 19.09% | none |
| 5 | Uso vivienda | 8,460 | 4.15% | none |
| 8 | Baja | 12,423 | 6.10% | **exclude from total count** |
| 9 | Baja Reunificación | 4,120 | 2.02% | **exclude from total count** |

**`id_tipo_acceso_local` — complete observed universe:**

| Code | Official description | Premises | Share | Note |
|---|---|---:|---:|---|
| 1 | Puerta Calle | 134,643 | 66.10% | documented |
| 3 | Interior | 51,501 | 25.28% | **UNDOCUMENTED** (see C.10) |
| 0 | Agrupado | 14,663 | 7.20% | documented |
| 12 | PC Asociado | 2,881 | 1.41% | **exclude from total count** |

**Discrepancies vs the structure documentation (recorded, not normalised away):**

- **Code 7 "Obras" is documented but absent** — the structure PDF lists situación 7
  (Local en obras), but the live Sep 2026 snapshot has **0** such rows. Documented ≠
  present; it is reported, not invented.
- **Access code 3 "Interior" is undocumented** — it is 25% of all premises yet the
  mar/2022 structure document's Tipo-acceso table lists only 0/1/12, and the
  document's own extraction note says only Agrupado / Puerta de Calle / PC Asociado
  premises were selected. Its source meaning is **UNRESOLVED**; it is surfaced
  prominently and given no invented meaning.

### C.2 · Official source semantics

Verified **again** against `estructura_ds_ficherocla.pdf` (versión mar/2022),
apartados II and III — not inherited from earlier gates.

| Code | Official description | Documented meaning (verbatim sense) | Counting instruction | Analytical interpretation allowed |
|---|---|---|---|---|
| sit 1 Abierto | Local activo | *"Local activo en el que se desarrolla algún tipo de actividad económica"* | none | administrative **last-recorded** "active"; not verified trading |
| sit 4 Cerrado | Local cerrado (sin actividad) | *"Local en el que en ese momento no se realiza ningún tipo de actividad"* | none | not independently verified current closure, not permanent cessation, not failure/decline; no date |
| sit 5 Uso vivienda | Local destinado a vivienda | *"…transformado en vivienda y se utilizan, exclusivamente, como vivienda familiar"* | none | recorded conversion to housing; no economic-cessation date |
| sit 7 Obras | Local en obras | *"Locales en los que se está realizando una reforma"* | none | undergoing works; **absent from this snapshot** |
| sit 8 Baja | Local que ha desaparecido | *"Locales desaparecidos"* | **exclude** | administrative "disappeared"; not a measured business failure |
| sit 9 Baja R | …desaparecido uniéndose a otro | *"Baja o baja por reunificación: Locales desaparecidos"* | **exclude** | administrative merge/reorganisation; not a failure |
| acc 12 PC Asociado | PC asociado | *"No se trata de un local físico… permite diferenciar actividades…"* | **exclude** | non-physical sub-access / double-representation |

Two caveats from the source govern **every** situación value:

- **"Variable de mantenimiento complicado."** Apartado III: *"…no se dispone de
  ninguno [procedimiento] que informe de cuándo una actividad cesa y el local se
  cierra sin aparecer una nueva actividad."* There is no procedure that detects a
  closure without a replacement activity, so any value — Abierto included — can be
  stale.
- **Extraction shows the last status.** *"…mostrándose la última situación del
  local."* Situación is the last recorded state, not a verified real-time status.

### C.3 · Status vs activity taxonomy

Cross-tab of premises status × per-premises taxonomy-record state (classified /
section-Z *SIN ACTIVIDAD* / blank `UNCLASSIFIED_SOURCE_ACTIVITY`), joined on
`id_local`, each premises counted once:

| Situación | CLASSIFIED | SIN_ACTIVIDAD | BLANK | CLASSIFIED+SIN_ACT |
|---|---:|---:|---:|---:|
| 1 Abierto | 126,710 | 2,009 | 11,015 | 63 |
| 4 Cerrado | 13,032 | 1,810 | 24,017 | 29 |
| 5 Uso vivienda | 728 | 342 | 7,390 | 0 |
| 8 Baja | 3,167 | 189 | 9,065 | 2 |
| 9 Baja R | 2,352 | 63 | 1,704 | 1 |

Answers (all from the join, not assumption):

1. **Can `Abierto` coexist with blank taxonomy?** **Yes** — 11,015 Abierto premises
   carry only an `UNCLASSIFIED_SOURCE_ACTIVITY` (blank) taxonomy.
2. **Can `Cerrado` retain populated activity codes?** **Yes** — 13,032 do.
3. **Can `Baja` retain activity codes?** **Yes** — 3,167 (Baja) + 2,352 (Baja R) do.
4. **Can section Z (SIN ACTIVIDAD) coexist with different statuses?** **Yes** — it
   appears under every situación value.
5. **Does administrative status determine taxonomy state?** **No** — every status
   co-occurs with multiple taxonomy states.

**Therefore status and activity classification are separate dimensions and must not
be collapsed.**

### C.4 · Status by Gate B class

Per Gate B class, over its **distinct** premises (a premises may belong to several
classes; it is counted once *within* a class and these do **not** sum across
classes). The purpose is **not** to rank sectors — it is to test whether any class
has a materially different status composition that would make a naive premises count
misleading.

| Gate B class | Distinct premises | Abierto | Cerrado | Uso viv. | Baja | Baja R | Source-excluded (8∪9∪acc12) |
|---|---:|---:|---:|---:|---:|---:|---:|
| CORE_HOSPITALITY (56) | 21,565 | 19,227 | 1,777 | 49 | 163 | 349 | 2,033 |
| ACCOMMODATION (55) | 8,050 | 7,503 | 362 | 70 | 63 | 52 | 131 |
| TOURISM_ADJACENT (79) | 834 | 751 | 50 | 2 | 22 | 9 | 37 |
| GENERIC_COMMERCIAL (G) | 44,411 | 37,588 | 4,696 | 165 | 673 | 1,289 | 2,350 |
| AMBIGUOUS (R) | 4,016 | 3,545 | 338 | 9 | 31 | 93 | 203 |
| EXCLUDED | 77,769 | 65,766 | 8,100 | 780 | 2,426 | 697 | 3,893 |

The composition differs modestly between classes (e.g. generic commerce carries
proportionally more Baja R than accommodation). The finding is only that a naive
total-premises count per class would fold in differing shares of source-excluded
records; it is **not** a vitality, health or ranking statement.

### C.5 · Official counting exclusions

The structure document instructs **exactly three** codes out of a total-premises
count, verified verbatim:

- situación **8 (Baja)** and **9 (Baja R)**: *"Los locales en situación 8 y 9, no
  deben tenerse en cuenta a la hora de extraer datos de número total de locales."*
- access **12 (PC Asociado)**: *"No deben tenerse en cuenta a la hora de extraer
  datos del número total de locales"* because *"No se trata de un local físico."*

The rule applies to **Locales** rows (premises; it speaks of "número total de
locales"), is **unconditional**, and covers **only** these codes — Cerrado, Uso
vivienda and Obras carry no exclusion instruction.

**Sep 2026 impact (audit calculation):**

| Quantity | Premises |
|---|---:|
| Raw premises universe | 203,688 |
| Excluded — situación 8 (Baja) | 12,423 |
| Excluded — situación 9 (Baja R) | 4,120 |
| Excluded — access 12 (PC Asociado) | 2,881 |
| Naïve sum (with double-counting) | 19,424 |
| Overlap: PC Asociado ∩ Baja | 1 |
| Overlap: PC Asociado ∩ Baja R | 14 |
| Overlap: Baja ∩ Baja R | 0 (mutually exclusive) |
| Double-subtraction avoided | 15 |
| **Union excluded** | **19,409** |
| **Remaining after official exclusions** | **184,279** |

> **This is an audit calculation only.** It does **not** authorise a production
> denominator or indicator. Gate F remains the denominator gate. Excluded records
> remain valid historical evidence; exclusion is from a current total-count universe,
> not from the research record.

### C.6 · `Abierto`

Official definition: *"Local activo en el que se desarrolla algún tipo de actividad
económica."* Sep 2026: **139,797** premises (68.6%). Of these, **126,773** carry a
populated classified activity, **11,015** carry a blank-only taxonomy, and **2,072**
carry a section-Z *SIN ACTIVIDAD* row. Abierto premises appear across **every** Gate
B class, including 65,766 in EXCLUDED.

**Does `Abierto` support "currently operating business"? — NO, only as an
administrative status.** The source *does* say Abierto means a premises with economic
activity, but (a) it explicitly warns situación is a *variable de mantenimiento
complicado* with no procedure to detect cessation without a replacement activity, (b)
extraction shows the *última situación* (last recorded, not verified-today), and (c)
11,000+ Abierto premises carry no activity classification at all. Abierto is at most
`ADMINISTRATIVELY_OPEN` (last-recorded active); it is never a verified current-
operation count, and never revenue, demand, footfall or commercial success.

### C.7 · `Cerrado`

**Source semantics (verbatim, apartado III):** *"Local en el que en ese momento no se
realiza ningún tipo de actividad."* This exact wording is the source meaning and is
preserved as such — it is **not** paraphrased into a project phrase. Sep 2026:
**38,888** premises; **13,061** still carry a populated classified activity. No
closure dates are published, and Cerrado is explicitly distinct from Baja
(desaparecido).

**Project interpretation ceiling (separate from the source meaning).** Because
`situación` is a difficult-to-maintain, last-recorded administrative variable and the
source lacks a complete cessation-update procedure, Gate C does **not** treat
`Cerrado` as: independently verified current closure; permanent cessation; business
failure; or economic decline. Activity codes can remain attached and no date exists.

**Can `Cerrado` be read as business cessation or economic failure? — NO (bounded).**
The ruling is NO-GO for all four interpretations above; the verbatim source meaning
stands on its own and is not stretched to cover them.

### C.8 · `Baja` and `Baja R`

Treated separately. **Baja (8):** *"Local que ha desaparecido"*, 12,423 premises,
3,169 still carrying activity codes. **Baja R (9):** *"Local que ha desaparecido
uniéndose a otro"*, 4,120 premises, 2,353 still carrying activity codes. The
distinction **is** documented (9 = disappeared by merging into another); apartado III
groups both as *"Baja o baja por reunificación: Locales desaparecidos."* Both are
**unconditionally excluded** from total-premises counts.

"Desaparecido" is an administrative register event, **not** a measured business
failure or bankruptcy; Baja R in particular is a reorganisation (merge). The records
**remain** in the research artifacts — exclusion from a count is not deletion from the
evidence.

### C.9 · Other statuses

- **Uso vivienda (5):** 8,460 premises. *"Transformado en vivienda… exclusivamente
  como vivienda familiar."* No source exclusion; inclusion as an administrative record
  is defensible, but it is explicitly a premises converted to housing, so folding it
  into a "commercial premises" reading would need its own justification.
- **Obras (7):** documented in the PDF, **0 rows** in this snapshot — reported as
  documented-but-absent, not invented.

### C.10 · Access-type semantics

- **PC Asociado (12):** 2,881 premises (1.4%). *"No se trata de un local físico"* — a
  subordinate access that separates activities of different owners inside one physical
  premises (a double-representation). Excluded from total-premises counts because it
  is **not a premises**, not because of any status or economic signal. Its overlap
  with the status exclusions (1 also Baja, 14 also Baja R) is handled so it is never
  double-subtracted (C.5).
- **Interior (3):** 51,501 premises (25.3%), **undocumented** (C.1). It is not named
  in any exclusion rule, so the explicit rules leave it in the counted universe, but
  any future count **must** flag it. Gate C invents no meaning for it; its source
  semantics are UNRESOLVED.
- **Agrupado (0)** and **Puerta Calle (1):** carry no special counting instruction.

### C.11 · Temporal transition control

Sep 2025 → Sep 2026, persistent premises (stable `id_local`): **202,343**; situación
unchanged for **200,693**. Observed transitions include Abierto→Cerrado **867**,
Cerrado→Abierto **489**, Abierto→Baja R **77**, **Baja→Abierto 60**, Baja
R→Abierto **5**, Abierto→Baja **4**, Uso vivienda→other **22**.

Statuses behave like **mutable administrative attributes**: the same persistent
premises carries different situación values across snapshots in both directions —
including "disappeared" premises (Baja/Baja R) reverting to Abierto, which a literal
"disappeared" reading could not produce. Transitions are **not** read as real
business openings or closures. Two snapshots only; full historical comparability
(field/code/format homogeneity across the whole series) remains **Gate D**.

### C.12 · Permissible counting language

Project handling labels — each explicitly distinguished from source terminology, none
asserting that a premises trades today:

| Project label | Rule | Source basis | Interpretation ceiling | Usable later? |
|---|---|---|---|---|
| `SOURCE_INCLUDED_PREMISES` | all − (sit∈{8,9} ∪ acc=12) | explicit source instruction | administrative records the source does not exclude; not a trading count | **yes** |
| `SOURCE_EXCLUDED_PREMISES` | sit∈{8,9} ∪ acc=12 | explicit source instruction | disappeared premises + non-physical sub-accesses; kept in the record | **yes** |
| `ADMINISTRATIVELY_OPEN` | sit=1 | code 1 only | last-recorded "active"; **not** current operation | **MODIFY** — status descriptor only, caveat must travel |
| `STATUS_UNCERTAIN` | disclaimer, not a subset | the maintenance caveat | the register cannot certify real-time operation for any premises | no (a disclaimer) |

### C.13 · Interpretation limits

This evidence can **never**, on its own, claim: that any premises is trading today; a
count of active businesses; a count of business failures or closures; economic
decline, growth, success or commercial health; commercial vitality, saturation,
tourism pressure or overtourism; demand, turnover, revenue, footfall or visitor
numbers.

It **can** support: the number of premises remaining after the source's explicit
exclusion rules; the administrative status composition of documented
hospitality/commercial premises; how much of the source universe is administratively
unresolved or unclassified.

### C.14 · Gate C ruling — **GO to Gate D, with scoped sub-rulings**

| Question | Ruling |
|---|---|
| **`Abierto`** as a current-operation proxy | **NO-GO** (administrative status only; maintenance caveat applies) |
| **`Cerrado`** as business-cessation / failure evidence | **NO-GO** (bounded; source meaning kept verbatim, not independently verified closure, not permanent cessation, no date) |
| **`Baja` / `Baja R`** as explicit source exclusions | **GO** (unconditional source instruction; records retained) |
| **`PC Asociado`** as an explicit source exclusion | **GO** (not a physical premises) |
| **Source-excluded premises universe** as a reproducible administrative filtering rule | **GO** (research filtering rule, overlaps handled; **not** a production denominator — Gate F) |
| **Economic interpretation** | **NO-GO** (no status field supports trading/demand/success/failure/vitality/saturation) |
| **Overall Gate C** | **GO to Gate D** |

Mixed sub-rulings are the intended outcome: administrative filtering is **GO**,
current-operation inference is **NO-GO**, economic interpretation is **NO-GO**, and
the gate as a whole is **GO to Gate D**.

**What GO does not authorise.** No indicator, production count, ranking, score,
denominator, map or economic/operating reading is admitted. A status field is
administrative evidence; the source's own exclusion rules are reproducible, but
nothing here says a documented premises is trading, has failed, or carries any
economic meaning.

### Recommendation for Gate D (temporal comparability)

Gate D should test field/code/format homogeneity across the **whole** published
series (not the three months examined here), establish the earliest defensible
comparison window, and treat status transitions strictly as mutable administrative-
attribute changes — never as real openings/closures. Two Gate C facts bound that
work: situación is the *última situación* and a *variable de mantenimiento
complicado* (so cross-month deltas are register-update deltas, not events), and the
live data already departs from the mar/2022 document (undocumented access code 3,
absent situación 7), so category vocabularies must be read live per snapshot, not
assumed stable from the PDF.

---

## Gate D — Temporal Comparability

The reproducible evidence for this section is produced by
[`audit_temporal.py`](../research/hospitality_commercial_gate/audit_temporal.py) and
stored in
[`results/gate_d_resource_manifest.json`](../research/hospitality_commercial_gate/results/gate_d_resource_manifest.json)
(the full deterministic catalogue inventory + provenance),
[`results/gate_d_schema_eras.json`](../research/hospitality_commercial_gate/results/gate_d_schema_eras.json)
(the per-family schema eras + snapshot-identity model),
[`results/gate_d_temporal_compatibility.json`](../research/hospitality_commercial_gate/results/gate_d_temporal_compatibility.json)
(the sentinel vocabulary + identity-intersection evidence) and
[`results/gate_d_temporal_summary.json`](../research/hospitality_commercial_gate/results/gate_d_temporal_summary.json)
(the full report, including the drift classification, temporal tiers, earliest
defensible windows and the scoped ruling). Every count below is produced by that
script from the live source and stored in those files; none were typed by hand. The
audit imports the Gate A source contract (catalogue access, streamed fingerprinting,
per-file dialect detection) and the Gate B classification (`classify`, the CNAE
section/division map), so Gate D reads the same upstream the same way and classifies
activities identically to the earlier gates.

### D.0 · Scope

Gate D resolves **one** question: *which temporal comparisons across the historical
premises/activity census are scientifically defensible, and where must the series be
segmented, qualified or rejected?* It does **not** measure a trend, and builds **no**
production aggregate, chart, choropleth, ranking, score, denominator, "growth"
indicator or UI. It determines whether future trend measurement is valid. The Locales
and Actividades families are analysed; Terrazas and Licencias are counted only in the
catalogue inventory for structure context.

**Network discipline (reproducibility is partly an efficiency property).** Stage 0 was
one catalogue metadata call. Stage 1 read only the first 64 KiB of **every** Locales
and Actividades resource (280 HTTP Range requests, ≈18.4 MB total; the server honours
Range with `206`) to establish each month's schema without downloading it. Stage 2
fully downloaded **10 deliberately chosen sentinels** (≈769 MB) — one per schema era,
the structural breakpoints, one mid-history month, and the Sep 2025 / Sep 2026
controls — to measure identity, status, taxonomy and geography vocabulary. All 10
matched their catalogue-declared MD5. The full multi-gigabyte history was **not**
downloaded, and no raw CSV is committed.

### D.1 · Published historical coverage

Dataset **`209548-0-censo-locales-historico`**, licence CC BY 4.0. The catalogue holds
**860 resources**, of which **498 are CSV**: **Locales 141**, **Actividades 139**,
Terrazas 118 and Locales con información de licencia 100 monthly resources. Every CSV
description parses deterministically as `"<Family>. <Month> <Year>"` (**0 unparsed**).

| Family | Earliest | Latest | Months present | Expected in span | Missing |
|---|---|---|---:|---:|---:|
| Locales | Marzo 2014 | Septiembre 2026 | 141 | 151 | 10 |
| Actividades | Marzo 2014 | Septiembre 2026 | 139 | 151 | 12 |

Missing months (both families): Apr, May, Jul, Aug, Oct, Nov 2014 (2014 is **quarterly**
— only Mar/Jun/Sep/Dec), Jul 2015, Jan 2025, Feb 2025, Jul 2026. Actividades is
additionally missing Dec 2017 and Apr 2022 (the only two months Locales has but
Actividades does not). **A missing month is explicit and is never read as zero
activity.**

### D.2 · Snapshot identity and the revision model

**A nominal month label is not a snapshot identity.** Gate C proved the resource
labelled "Septiembre 2026" was re-published in place; Gate D formalises the rule:

> `snapshot_identity = (family, nominal_period, content_fingerprint)`

- **nominal_period** — the month the resource *represents* (parsed from the
  description). Necessary, never sufficient.
- **content_fingerprint** — *which published revision* was read. The project
  fingerprint is a **SHA-256** computed on download; the catalogue *also* declares an
  **MD5 + byte size** for every CSV, so a reader can detect a re-publication **without
  downloading** by comparing catalogue MD5+size.
- **retrieval timestamp**, HTTP `Last-Modified`/`ETag`, and — where present — a **cut
  timestamp embedded in the download URL** (e.g. `209548_20261001_045230.csv`) are
  recorded as corroborating revision signals.

**Resource id is insufficient as version identity.** The Sep 2026 Locales resource kept
id `209548-851` across the Gate A/B, Gate C and Gate D reads while its bytes changed
(Gate A/B SHA `2475e8bc…` → Gate C SHA `4ca33fed…` → this run's recorded SHA; catalogue
MD5 now `7e1aeea0…`, size 89,299,449, `Last-Modified` 2026-10-01). Each nominal month
maps to **exactly one** resource id (**0 duplicate nominal periods**), so re-publication
is in-place overwrite, which is precisely why the id cannot carry version identity. A
later re-publication does **not** invalidate an earlier fingerprinted result; it is a
*different version* of the same nominal period.

### D.3 · Resource continuity

The sequence is monthly from 2015 (quarterly in 2014) with the enumerated gaps in D.1.
There are **no** duplicate nominal periods and **no** two resource ids for one month, so
the catalogue cannot silently overwrite one month's result with another's. `created`/
`issued` are populated for all 498 CSVs; `Last-Modified` only for the most recently
touched resources (so the catalogue cannot, by itself, prove the full retrospective
revision history of older months — D.11).

### D.4 · Schema / format history

Reading the header of every month (Stage 1) yields contiguous **schema eras** per family
(delimiter `;` throughout):

**Locales** — 2014-03 (headerless, 38 col) · 2014-06 (33 col) · 2014-09…12 (38 col) ·
**2015-01…2022-09 (40 col)** · **2022-10…2024-09 (48 col)** · **2024-10…2026-09 (46 col,
current)**.
**Actividades** — 2014-03 (headerless, 44 col) · 2014-06…12 (44 col) ·
**2015-01…2022-09 (46 col)** · **2022-10…2024-09 (49 col)** · **2024-10…2026-09 (47 col,
current)**.

The first ≈40 Locales / ≈46 Actividades columns — identity, geography, status, access,
taxonomy — carry **identical names and order from 2015 onward**; the 48↔46 (and 49↔47)
differences are **trailing** columns only (`cod_postal`, `hora_*`, `fx_carga` added
2022-10; `fx_datos_ini`/`fx_datos_fin` added 2022-10 and dropped 2024-10). The 2014
schema is a genuinely different field set and order (and the 33-col Junio 2014 file
lacks `id_tipo_acceso_local`, `cod_barrio_local` and `id_seccion_censal_local`
altogether). **Encoding** is Latin-1 (ISO-8859-1) through ≈2022 and UTF-8(-sig) from the
2022-10 era. A compact `schema_signature` (sha256 of delimiter + header tuple, or
`HEADERLESS ncols=n`) is recorded per month; presentation attributes (BOM, quoting, the
2024-06 stray-byte header) are **excluded** from the signature so a pure format change
does not read as a structural break.

### D.5 · Status / access vocabulary history

| Period | situación representation | access representation |
|---|---|---|
| 2014 | **text only** (codes blank): Abierto/Cerrado/Uso vivienda/**Obras**/Baja/Baja R | **text only**: Puerta calle/Agrupado/PC Asociado |
| 2015, 2020 | **codes** 1/4/5/**7 En obras**/8/9 + undocumented **10 Baja PC Asociado** | text only (code blank) |
| 2022-10 | codes 1/4/5/**7**/8/9 (+10) | **codes 0/1/12** |
| 2025, 2026 | codes 1/4/5/8/9 (**7 and 10 gone**) | codes 0/1/12 **+ 3 "Interior"** |

Findings: status/access was recorded as **text, not codes, in 2014**; situación codes
appear from **2015**, access codes only from **2022-10**. Code **7 "En obras"** is
present 2015–2022 (1,093 → 785 → 127 rows) and **absent** by 2025/2026 — dating the
disappearance Gate C observed. An undocumented code **10 "Baja PC Asociado"** appears
2015–2022 then vanishes. Access code **3 "Interior"** (undocumented, Gate C) is absent
in 2022-10 and present (~50k rows) by 2025/2026. The code-9 description gains an accent
("Baja Reunificacion" → "Baja Reunificación"). Existing code **meanings are stable**; it
is the code **set** that drifts — so vocabulary must be read live per snapshot, and 2014
status must be segmented.

### D.6 · Activity-taxonomy stability

The three-level CNAE hierarchy is present in **every** era, with **0 multi-parent
epigraphs** throughout, and divisions **55 / 56 / 79** and sections **G / R** present in
every Actividades sentinel (2014 → 2026). So the Gate B class **map** projects backward.
**But** the *unclassified* set is represented differently across eras: blank epigraphs
are ~30% (2014), ~28.6% (2015) and ~23.6% (2026), yet the **2022-10…2024-09 era carries
zero blanks** and instead a sentinel section **`-1`** with divisions **`00`/`PT`** — which
a naïve backward projection of the Gate B map misreads as 42,454 AMBIGUOUS rows.
Separately, the **recorded accommodation (division 55) universe shows a large
discontinuity, 527 → 8,050 premises**, across the window — a major change in the
*recorded* accommodation universe whose **causal mechanism is unresolved**. The Gate D
artifacts carry division-level counts only, not per-epigraph counts (e.g. `551005`
*VIVIENDAS TURÍSTICAS*), so the discontinuity is **not attributed** to any specific
epigraph here. The class *map* is stable; the class *shares/counts* need explicit
normalisation (`-1`/`00`/`PT` → `UNCLASSIFIED_SOURCE_ACTIVITY`) and segmentation, not a
raw projection.

### D.7 · Identity stability

`id_local` is longitudinally sound with **no re-key signature**:

| From → To | Persistence of the earlier set | Appeared | Disappeared |
|---|---:|---:|---:|
| Sep 2014 → Sep 2015 | 99.706% | 2,414 | 417 |
| Sep 2015 → Sep 2020 | 99.679% | 4,341 | 463 |
| Sep 2020 → Oct 2022 | 99.958% | 2,570 | 62 |
| Oct 2022 → Sep 2025 | 99.926% | **52,024** | 112 |
| Sep 2025 → Sep 2026 | 99.999% | 1,345 | 3 |
| **Sep 2014 → Sep 2026** | **99.335%** | 62,582 | 945 |

Only 945 of 142,051 premises from 2014 are absent twelve years later. The large
**+52,024** somewhere within Oct 2022 → Sep 2025 is **additive** (112 disappear): the
`id_local` architecture is stable (no re-key), so this is an **observed administrative-
universe expansion whose cause is unresolved** — the two sentinels do not localise it
more precisely, and no official source documents a coverage-policy change. Identity
persists, but **total counts are not comparable as a trend across that break** regardless
of its cause. (The 2014 file carries one duplicate `id_local`; negligible.)

### D.8 · Geography-field stability (for Gate E, not reconciled here)

District count is **stable at 21** across all eras. The **barrio code system changes**:
a bare barrio number in 2014 (e.g. `11`) vs a district-concatenated code from 2015 (e.g.
`1502`, `704`, `104`); the distinct-barrio count moves **128 (2014/2015) → 131 (2020+)**.
Gate D only **reports** this source-code break; reconciliation to canonical geometry is
**Gate E**.

### D.9 · Temporal comparison tiers

- **TIER A — directly comparable** (fingerprint-aware): the current era (Locales/
  Actividades **2024-10 → 2026-09**).
- **TIER B — comparable after explicit normalisation**: the **2015-01…2022-09** and
  **2022-10…2024-09** eras vs current, for `id_local` identity and the stable 55/56/79/G
  classes — normalise encoding (Latin-1→UTF-8), BOM/quoting, trailing columns, the
  description accent drift and the 2022-era `-1`/`00`/`PT` sentinel. Count-level
  comparison across 2022→2025 stays blocked by the observed administrative-universe
  expansion (cause unresolved).
- **TIER C — segmented only**: the **2014** era(s) — different barrio code system,
  text-only status/access, headerless Marzo 2014, 33-col Junio 2014, Latin-1.
- **TIER D — NO-GO**: business-event inference from status transitions in any era;
  count-level "growth" across the 2022→2025 observed administrative-universe expansion;
  a single homogeneous 2014→2026 trend series.

### D.10 · Earliest defensible windows (by dimension)

There is **no** single universal start date. Each dimension carries evidence and a
caveat in `gate_d_temporal_summary.json`:

| Dimension | Earliest defensible | Mode |
|---|---|---|
| Premises identity (`id_local`) | **Sep 2014** | direct (persistence); counts not a trend |
| Status composition (by code) | **Sep 2015** | normalise; segment 2014 (text-only) |
| Source-excluded filtering (sit 8/9 ∪ acc 12) | **Oct 2022** | needs the access code; situación-only partial from 2015 |
| CORE_HOSPITALITY (56) | Sep 2014 map / **Sep 2015** clean | normalise; segment 2014 |
| ACCOMMODATION (55) | mapping to 2014; composition needs segmentation | segment; count comparison NO-GO (recorded-universe discontinuity, cause unresolved) |
| TOURISM_ADJACENT (79) | Sep 2014 map / **Sep 2015** clean | normalise; segment 2014 |
| GENERIC_COMMERCIAL (G) | Sep 2014 map / **Sep 2015** clean | normalise; segment 2014 |
| Barrio-level grouping | **Sep 2015** (current code system) | MODIFY pending Gate E; segment 2014 |

### D.11 · Monthly-transition semantics

`STATUS_TRANSITION ≠ BUSINESS_EVENT`. Month-to-month situación transitions are **register-
state changes**, not openings, closures, failures or reopenings — Gate C observed Baja/
Baja R premises reverting to Abierto, which a literal "disappeared" reading cannot
produce. **NO-GO** to labelling transitions as business events; permitted language is
"recorded status transition", "register-state change", "administrative transition".

### D.12 · Reproducibility / version protocol

Any future analytical use of a monthly resource must persist: source family, nominal
reference period, resource id, retrieval timestamp, source URL, HTTP `Last-Modified`,
`ETag` (when available), byte count, SHA-256, the catalogue-declared MD5+size, the
URL cut timestamp (when present), the parser/schema version and the observed
`schema_signature`. Only the currently published revision can be reconstructed for a
historical month once it is overwritten; raw CSVs are never committed.

### D.13 · Interpretation ceiling

A future historical series **may** claim: change in the number of administratively
documented premises (after the source's own exclusions); change in recorded activity
composition (CNAE class shares) within a comparable tier; change in administrative
source-status composition. It may **never** claim: businesses operating or trading;
openings/closures; survival; commercial success/failure; economic growth/decline;
tourist demand; overtourism; saturation; tourism pressure. A premises census remains
administrative evidence through time.

### D.14 · Gate D ruling — **GO to Gate E, with scoped sub-rulings**

| Question | Ruling |
|---|---|
| **Resource continuity** | **MODIFY** (deterministic and auditable — 0 duplicate periods — but NOT a complete uninterrupted series: 2014 quarterly, missing months; missing ≠ zero, never imputed) |
| **Snapshot version identity** | **GO** (family + nominal period + fingerprint; resource id insufficient) |
| **Schema continuity** | **MODIFY** (≥3 structural eras post-2014 + a distinct 2014 era; core normalisable) |
| **Premises identity longitudinally** | **GO** (`id_local` ≥99.3% to 2014, no re-key; counts are a separate question) |
| **Activity taxonomy longitudinally** | **MODIFY** (55/56/79/G/R map projects back, 0 multi-parent; unclassified representation era-specific; recorded accommodation-universe discontinuity, cause unresolved) |
| **Status composition longitudinally** | **MODIFY** (codes from 2015/2022-10; 2014 text-only; code set drifts) |
| **Month-to-month status transition as business events** | **NO-GO** |
| **Barrio grouping over time** | **MODIFY pending Gate E** (districts stable; barrio code system changes 2014→2015) |
| **Overall Gate D** | **GO to Gate E** |

Mixed sub-rulings are the intended outcome: recent-era (2024-10+) comparisons are
directly defensible and fingerprint-aware; the 2015→2024 history is comparable after
explicit normalisation with count-level comparison blocked across the observed 2022→2025
administrative-universe expansion (cause unresolved); 2014 is segmented; business-event
inference is NO-GO; and a single
homogeneous 2014→2026 trend series is NO-GO. **A shorter defensible window is preferred
over a longer false series.**

**What GO does not authorise.** No indicator, production count, chart, choropleth,
ranking, score, denominator, trend or "growth" claim is admitted. Gate D establishes
only *whether and where* future temporal comparison could be valid, never a measured
change.

### Recommendation for Gate E (geography reconciliation)

Gate E must resolve the source geography before any barrio-level temporal grouping: the
barrio **code system changes** between 2014 (bare barrio number) and 2015+ (district-
concatenated), and the distinct-barrio count moves 128 → 131, while districts stay at 21.
Reconcile the 2015+ source barrio codes to Lens's canonical 131 barrios (Gate A observed
the counts match in the current era, but this is to be *tested*, not assumed), decide
whether the 2014 barrio codes can be mapped at all, and treat a changed barrio code as a
coding change rather than a boundary change unless independent evidence says otherwise.
Gate D has deliberately performed **no** geometric reconciliation.

---

## Gate E — Geographic Reconciliation

The reproducible evidence for this section is produced by
[`audit_geography.py`](../research/hospitality_commercial_gate/audit_geography.py) and
stored in
[`results/gate_e_geography_summary.json`](../research/hospitality_commercial_gate/results/gate_e_geography_summary.json),
[`results/gate_e_geography_crosswalk.json`](../research/hospitality_commercial_gate/results/gate_e_geography_crosswalk.json)
(the **era-aware** code/entity crosswalk — one row per era × source barrio, **not** a
per-premises export),
[`results/gate_e_geography_quality.json`](../research/hospitality_commercial_gate/results/gate_e_geography_quality.json)
and
[`results/gate_e_geography_eras.json`](../research/hospitality_commercial_gate/results/gate_e_geography_eras.json).
Every count below is produced by that script and stored in those files; none were typed
by hand. The audit imports the Gate A source contract and the Gate D inventory/sentinel
helpers, so Gate E reads the same upstream the same way as the earlier gates.

### E.0 · Scope and the four evidence layers

Gate E resolves one question: *can premises/activity census records be assigned,
reproducibly, to Madrid's authoritative canonical district/barrio geography across time,
and under exactly what rules is spatial aggregation defensible?* It is a
methodology/research gate — **no** indicator, denominator, map layer, ranking, score,
choropleth or per-resident metric, and **no** production/UI change. Four evidence layers
are kept strictly separate and never silently merged: (1) **source-record** geography
(`id_distrito_local`, `id_barrio_local`, `cod_barrio_local`, `desc_*`, coordinates); (2)
**authoritative** Madrid geography — both **CURRENT** (131 barrios, v3.4.1) and official
**HISTORICAL** (1987, 128 barrios); (3) **project canonical geometry**
(`data/geography/madrid_admin.geojson`, current); (4) the **project reconciliation**
crosswalk, which is era-aware.

### E.0a · The documented 2017 administrative reorganisation (decisive context)

Madrid's barrio geography **changed administratively in 2017**, and this governs the
whole historical ruling. The official *"Barrios municipales de Madrid"* dataset (v3.4.1)
states verbatim that it incorporates *"los cambios en la definición de los barrios del
distrito de Vicálvaro que implica la creación de dos nuevos barrios y la modificación de
los existentes"* and *"el cambio de denominación del barrio 17.1 San Ándres a Villaverde
Alto, Casco Histórico de Villaverde, según el Pleno del Ayuntamiento de fecha 31-10-2017
BOAM nº 8034"*, and that *"La delimitación inicial corresponde a reestructuración
territorial de 1987."* The same dataset publishes a **"Divisiones administrativas
históricas"** resource (`300496-5-barrios-madrid`) carrying the **1987** geometry — the
128-barrio system in force until 2017. Gate E uses that official historical geometry
rather than reconstructing boundaries by assumption.

Consequently the earlier draft findings — *128→131 CAUSE UNRESOLVED*, *no boundary change
evidenced*, *2015+ barrio GO (normalise only)*, and treating old code `192 Ambroz` as
equivalent to current `192 Valdebernardo` — are **not defensible and are corrected here.**

### E.1 · Source geography fields

`id_barrio_local` is the only barrio key populated in every era and is the PRIMARY
source-native key; its **width scheme changes** (2014 `district*10+seq`; 2015+
`district*100+seq`), so each file is decoded under its own scheme and the raw string is
never compared across eras. `cod_barrio_local` (bare within-district seq) is **blank
before 2022-10**, so it is only a cross-check. `desc_distrito_local`/`desc_barrio_local`
(names) and UTM coordinates are present in every era; `cod_postal` from 2022-10.

### E.2 · Authoritative canonical geography (current) and E.3 · project geometry

`data/geography/madrid_admin.geojson` is built from **Ayuntamiento de Madrid — IDEAM**;
district dataset **v3.2.1**, barrio **v3.4.1** (CC BY 4.0); CRS **EPSG:25830**→**4326**;
**21 districts, 131 barrios**; barrio id = 3-digit code (2-digit district + 1-digit
sequence). Names are never identifiers; codes are. Provenance is established, and the
project geometry is the authoritative current geometry. Gate E does not modify it.

### E.3a · Authoritative HISTORICAL geography (1987)

Established authoritatively from the official *Divisiones administrativas históricas*
resource (`300496-5-barrios-madrid`, `…/Divisiones_Historicas.zip` → `SHAPES_1987/
Barrios_1987.shp`): **128 barrios**, 21 districts, CRS **EPSG:25830**, attributes
`CODBARRIO`/`NOMBARRIO`/`CODDISTRIT`/`NOMDISTRIT`. Barrio 171 is *"San Andrés"* (the
pre-2017 name); district 19 (Vicálvaro) has only barrios 191 and **192 "Ambroz"**;
district 18 has 181 and 182 (no 183). This is used — not reconstructed — as the
HISTORICAL_128 reference.

### E.4 · Current-era reconciliation (Sep 2026)

131 distinct source barrios / 21 districts → **all 131 EXACT_CODE_MATCH** to the CURRENT
canonical geography, **0** hierarchy conflicts, **0** many-to-one. The current-era
reconciliation remains **GO**.

### E.5 · Hierarchy integrity

Every reconciled source barrio maps to exactly one canonical barrio within its era; the
decoded district equals the source `id_distrito_local`; each canonical barrio's parent is
its 2-digit prefix; no multi-district barrio; no orphan in the current era. Point-in-
polygon corroborates nesting.

### E.6 · Name / code normalization

Code+district is authoritative; names are a cross-check. Cosmetic differences (accents,
articles, spacing, abbreviations) are handled deterministically; **fuzzy matching is not
used** as a reconciliation method. Crucially, a changed *name label* is **not** assumed
cosmetic — it is checked against the entity classification (E.11): `171 San Andrés →
Villaverde Alto…` is a documented rename over a stable entity (99.5% same territory), and
the source still records *"SAN ANDRES"* for code 171 even in Sep 2026 (the source name
label lags the official rename, while the code/entity is stable).

### E.7 · Coordinate validation (current era only)

Source coordinates are **empirically EPSG:25830** (labelled empirical; not documented by
the structure PDF), transformed to EPSG:4326 and tested against each premises' CURRENT
code-assigned barrio polygon. Two **distinct** rates are reported and must never be
conflated:

- **Coordinate availability** (a coverage rate): **152,818 / 203,688 ≈ 75.03 %** of
  premises carry a usable coordinate; **50,870 / 203,688 ≈ 24.97 %** carry the `(0,0)`
  missing sentinel and have *no* usable point coordinate (0 numerically invalid).
- **Point-in-polygon agreement** (a correctness rate, **conditional on a usable
  coordinate**): **99.978 %** of the 152,818 usable points fall inside their assigned
  barrio (incl. a 25 m boundary-edge tolerance, which is explicit and used only to
  *classify* — **no point is snapped**). This 99.978 % is **not** a universe-wide figure
  and must never be read as a coordinate-availability number (i.e. it is false to say
  "99.978 % lack coordinates").

Because ~24.97 % of premises have no usable coordinate, coordinate validation is a strong
corroboration of the code reconciliation, **not** a universe-wide spatial validation —
hence the **MODIFY** ruling; code-based reconciliation remains GO. **Historical
point-in-polygon is NOT performed here**: pre-2017 records must be validated against the
1987 historical polygons (now available), never against current polygons.

### E.8 · Geographic quality

Current era: 203,687/203,688 rows carry a barrio (1 blank, reported); 131/131
EXACT_CODE_MATCH; 0 conflicts. No hidden exclusions; row and distinct-`id_local` counts
are equal (Gate A).

### E.9 · Geography eras and the Censo implementation breakpoints

The Censo *source* did not adopt the 2017 geography in one step. Gate E determines the
geography era **from the observed source barrio set** (presence of 183/193/194 and the
name of code 192), not the calendar, and localises the breakpoints to single months:

| Geography era | Observed window | Barrios | Marker |
|---|---|---:|---|
| **HISTORICAL_128** | … → **Aug 2017** | 128 | matches the 1987 geometry |
| **TRANSITIONAL_129** | **Sep 2017** → **Jun 2018** | 129 | `183 Ensanche de Vallecas` added; Vicálvaro still `192 Ambroz` |
| **CURRENT_131** | **Jul 2018** → … | 131 | Vicálvaro reorg implemented: `192 Valdebernardo`, `193 Valderrivas`, `194 El Cañaveral` |

So the Censo implemented `183 Ensanche de Vallecas` at **Sep 2017** (last 128 = Aug 2017)
and the Vicálvaro reorganisation at **Jul 2018** (last 129 = Jun 2018). Each change has
three distinct dates, kept separate (E.12): `183 Ensanche de Vallecas` — legal decision
**31 May 2017**, BOAM nº 7927 **15 Jun 2017**, Censo **Sep 2017**; Vicálvaro reorg — legal
decision **31 Oct 2017**, BOAM nº 8034 **17 Nov 2017**, Censo **Jul 2018**. The Censo
implementation dates are observed data facts, **not** legal effective dates. Per-era
reconciliation: HISTORICAL snapshots 128/128, TRANSITIONAL 129/129, CURRENT 131/131 (plus,
in Jun/Jul 2018 only, one explicit source-null barrio *"VALOR NULO EN ORIGEN"* kept visible
as `GEOGRAPHY_MISSING`, never coerced).

### E.10 · 2014 and historical reconciliation

2014 uses the `district*10+seq` scheme, Latin-1 encoding, blank `cod_barrio_local`; it is
decoded under its own scheme and reconciled to the **HISTORICAL 1987** geography,
corroborated by the district field and name. 2014/2015/Aug-2017 reconcile 128/128 to the
historical set. 2014 barrio reconciliation is therefore defensible **within the historical
128-barrio geography**, and is **not** 1:1 to the current 131-barrio geography.

### E.11 · The 128 → 131 question — DOCUMENTED, and the code-reuse trap

The cause is **`DOCUMENTED_ADMINISTRATIVE_REORGANISATION_2017`**, not unresolved and not a
coverage gap. Comparing the official 1987 geometry to current v3.4.1 (geometry overlap,
both EPSG:25830) classifies every barrio code's entity relationship: **110 SAME_ENTITY,
10 NAME_CHANGE_ONLY, 7 BOUNDARY_CHANGED, 3 NEW_ENTITY, 1 REPLACED, 1 LEGACY_ENTITY.** The
three new current codes are `183 Ensanche de Vallecas` (99.6 % carved from old 181),
`193 Valderrivas` (100 % from old 191) and `194 El Cañaveral` (99.8 % from old 191). The
creation of `183 Ensanche de Vallecas` has an authoritative legal instrument — *Acuerdo de
31 de mayo de 2017 del Pleno del Ayuntamiento de Madrid* (creación del barrio y
modificación del Reglamento Orgánico de los Distritos), **BOAM nº 7927, 15/06/2017** — so
it is no longer an open item.

**The critical finding: numeric barrio-code equality across 2017 does NOT establish entity
identity.** Current `192 "Valdebernardo"` is **99.9 % carved from historical 191**, while
historical `192 "Ambroz"` was **absorbed into current 191** and is a **LEGACY_ENTITY** (no
current barrio is predominantly derived from it). Old `192 Ambroz` is therefore **not**
current `192 Valdebernardo`. The project canonical entity key is accordingly **era-aware**
(E.13).

### E.12 · Boundary-history finding (three distinct dates, not collapsed)

Madrid has **documented** barrio-level administrative boundary/entity changes in 2017. For
each change, three dates are kept strictly separate:

| Change | Legal decision | BOAM publication | Censo first observed |
|---|---|---|---|
| `183 Ensanche de Vallecas` | 31 May 2017 | nº 7927, 15 Jun 2017 | Sep 2017 |
| Vicálvaro reorg (191/192/193/194) + 171 rename | 31 Oct 2017 | nº 8034, 17 Nov 2017 | Jul 2018 |

The Censo source-implementation date is an **observed data fact, not a legal effective
date**, and the three date types are never collapsed. The **current geometry effective
period** is a fourth, separate concept (v3.4.1 — no published effective date; see the
geography meta). Official historical polygons (1987) are available, so pre-change records
can use the historical geography; current geometry represents current/recent snapshots.

### E.13 · Era-aware canonical key

The canonical entity key is **`{geography_era}:{barrio_code}`**. The era prefix is
mandatory: `HISTORICAL_128:192` (Ambroz) is a different entity from `CURRENT_131:192`
(Valdebernardo). For current work the current 3-digit official code remains valid; for
longitudinal work a bare code is insufficient and the era-aware key (or the explicit
crosswalk entity relationship) must be used. Names are never a primary key.

### E.14 · Reconciliation statuses

Fixed vocabulary: `EXACT_CODE_MATCH`, `NORMALIZED_NAME_MATCH`, `AMBIGUOUS`, `UNMATCHED`,
`GEOMETRY_CONFLICT`, `GEOGRAPHY_MISSING` (plus reserved `EXACT_NAME_AND_DISTRICT_MATCH`,
`LEGACY_CODE_MAPPED`). Unresolved/ambiguous/missing records are retained with an evidence
note and never silently coerced.

### E.15 · Unresolved-geography handling

Unresolved geography remains visible and is excluded only from analyses that require a
resolved unit. The explicit source-null barrio in Jun/Jul 2018 is kept as
`GEOGRAPHY_MISSING`, not bucketed into a real barrio and not deleted.

### E.16 · Geographic tiers

- **GEO A — direct.** CURRENT_131 era (≥ Jul 2018): source code maps exactly to current
  canonical geography.
- **GEO B — normalized.** Within HISTORICAL_128 (2015–Aug 2017) and TRANSITIONAL_129
  (Sep 2017–Jun 2018): source code maps exactly to the era-appropriate geography after
  presentation-level normalisation.
- **GEO C — legacy/segmented.** 2014 (`d*10+seq`, Latin-1) within historical geometry;
  and ALL cross-2017 barrio comparison (requires the explicit entity crosswalk —
  REPLACED/NEW/LEGACY cannot be bridged by code equality).
- **GEO D — NO-GO.** Treating a barrio code as one homogeneous entity across the 2017
  break; historical point-in-polygon against current polygons.

### E.17 · Earliest defensible windows

| Capability | Earliest / window | Mode |
|---|---|---|
| District-level aggregation | **Sep 2014** | direct (21 districts stable) |
| HISTORICAL_128 barrio comparison | Mar 2014 … **Aug 2017** | within 1987 geometry |
| TRANSITIONAL_129 barrio comparison | Sep 2017 … Jun 2018 | segment |
| CURRENT_131 barrio comparison | **Jul 2018** → | first proven post-reorg snapshot |
| Cross-2017 barrio comparison | — | **MODIFY/segmented**; requires the entity crosswalk |
| Point-in-polygon (current) | 2024-10+ | current polygons only |

### E.18 · Interpretation ceiling

Supports: counts/shares of administratively documented premises by canonical barrio/
district **within a geography era**; activity-class distribution by district; geography of
source-included premises. Does **not** support tourism pressure, overtourism, saturation,
commercial health, displacement, gentrification, resident burden, any per-resident metric
(Gate F), or **cross-2017 barrio trend without explicit harmonisation**.

### E.18a · Population geography joinability

**KEY compatibility only — no denominator.** The population asset joins **1:1** by
`official_id`/`parent_id` to the **CURRENT** canonical geography (131 barrios, 21
districts, 0 parent mismatches). A historical join would require the historical barrio
set. No residents value is joined and no per-resident indicator is constructed (Gate F).

### E.19 · Gate E ruling — **GO to Gate F, with scoped sub-rulings**

| Question | Ruling |
|---|---|
| **Current district reconciliation** | **GO** (21/21, 0 conflicts) |
| **Current barrio reconciliation** | **GO** (131/131 EXACT_CODE_MATCH to current, 0 conflicts) |
| **2015+ district compatibility** | **GO** |
| **2015+ barrio compatibility** | **MODIFY** — segmented across the documented 2017 geography break; cross-2017 barrio comparison needs explicit harmonisation (code 192 reused; 183/193/194 new; Ambroz legacy) |
| **2014 district compatibility** | **GO** |
| **2014 barrio compatibility** | **MODIFY** — defensible within the historical 128-barrio (1987) geography; not 1:1 to current 131 |
| **Coordinate validation** | **MODIFY** — 99.978 % point-in-assigned-barrio agreement *among the usable-coordinate subset* (conditional), while 50,870/203,688 (~24.97 %) have no usable point coordinate; availability and agreement are distinct rates; corroboration only; historical PiP not performed against current polygons |
| **Project current canonical geography** | **GO** (official IDEAM provenance, v3.2.1 / v3.4.1) |
| **Population geography joinability** | **GO** for the current canonical geography only (1:1 keys; **no denominator**) |
| **Overall Gate E** | **GO to Gate F** — the 2017 break and the historical segmentation are now explicit and reproducible, with official historical geometry and an era-aware crosswalk |

Mixed sub-rulings are the intended outcome. The spatial-assignment within each geography
era is GO; the cross-2017 barrio comparison is explicitly segmented (MODIFY), the 2014
barrio work is defensible only within the historical geometry (MODIFY), and coordinates
corroborate but do not validate the whole universe (MODIFY). **A shorter defensible
spatial series, segmented at a documented administrative break, is preferred over a false
continuity.**

**What GO does not authorise.** No indicator, count, denominator, choropleth, ranking,
score, per-resident metric or tourism-pressure/saturation reading, and no cross-2017
barrio trend without harmonisation.

### Recommendation for Gate F (denominator)

Gate F may rely on a 1:1 **current** canonical key shared by premises geography and the
Padrón population asset. It must: (1) choose the numerator universe (apply the Gate C
exclusions; decide `UNCLASSIFIED_SOURCE_ACTIVITY` / `Interior` handling); (2) restrict any
barrio-level per-resident indicator to the **CURRENT_131 era (≥ Jul 2018)** unless it
harmonises across the 2017 break via the era-aware entity crosswalk; (3) align the
premises snapshot with the Padrón reference period (geometry carries a version, not an
effective date); (4) carry forward the Gate D count-comparability blocks (2022→2025
expansion; accommodation discontinuity); and (5) never read a per-resident ratio as
tourism pressure, saturation or resident burden.

---

## Gate F — Denominator Construction & Indicator Admissibility

The reproducible evidence for this section is produced by
[`audit_denominator.py`](../research/hospitality_commercial_gate/audit_denominator.py)
and stored in
[`gate_f_denominator_audit.json`](../research/hospitality_commercial_gate/results/gate_f_denominator_audit.json),
[`gate_f_indicator_registry.json`](../research/hospitality_commercial_gate/results/gate_f_indicator_registry.json)
and
[`gate_f_summary.json`](../research/hospitality_commercial_gate/results/gate_f_summary.json).
The audit imports Gate A's resource resolver and fingerprinting, Gate B's classifier,
Gate C's exclusion-code constants and Gate E's current-barrio decoder. It does not
duplicate or alter those decisions. Raw CSVs are temporary (or externally cached after
MD5 verification) and are never committed.

### F.0 · Scope

Gate F answers: *which count, non-exclusive membership or density constructions are
methodologically admissible for the current Hospitality & Commercial Context layer,
for which management question, and under what interpretation ceiling?* It does not
build the layer. It creates no UI configuration, map, ranking, score, hotspot,
pressure index or production aggregate.

The audited source versions are deliberately exact:

| Family | Nominal period | Resource | SHA-256 |
|---|---|---|---|
| Locales | Sep 2026 | `209548-851-censo-locales-historico` | `4ca33fed004b836d…` |
| Actividades | Sep 2026 | `209548-857-censo-locales-historico` | `ba9279d6d187105b…` |

These are the re-published Sep-2026 revisions recorded by Gates C/D, not the earlier
Gate A/B cuts. Snapshot identity remains `family + nominal_period + content
fingerprint`; the month label alone is never enough.

The admissibility ladder is:

1. **Level 1 — descriptive count.** Strongest source fidelity, but still requires a
   premises universe and exclusions.
2. **Level 2 — source-internal non-exclusive membership.** Numerator and denominator
   come from the same administrative system; overlaps and blank taxonomy must remain
   explicit, and analytical classes are not a mutually exclusive partition.
3. **Level 3 — external-denominator density.** Requires conceptual, geographic and
   temporal compatibility with the external denominator.
4. **Level 4 — pressure/capacity/impact.** Requires independent evidence not present
   here. **NO-GO.**

There is no universal KPI. Counts, source-internal membership and residential-context
density answer different questions and are not interchangeable.

### F.1 · Candidate premises universes

Every universe is premises-level and deduplicated by `id_local`:

| Universe | Exact definition | Sep-2026 count |
|---|---|---:|
| **U0 — RAW_PREMISES** | all distinct `id_local` in Locales | **203,688** |
| **U1 — SOURCE_INCLUDED_PREMISES** | U0 minus `(situacion ∈ {8,9}) OR (access = 12)` | **184,279** |
| **U2 — SOURCE_INCLUDED_POPULATED_TAXONOMY_PREMISES** | U1 with at least one populated `id_epigrafe` | **142,107** |
| **U3 — SOURCE_INCLUDED_CORE_HOSPITALITY_PREMISES** | distinct U1 premises with division 56 | **19,532** |
| **U4 — SOURCE_INCLUDED_ACCOMMODATION_PREMISES** | distinct U1 premises with division 55 | **7,919** |
| **U5 — SOURCE_INCLUDED_TOURISM_ADJACENT_PREMISES** | distinct U1 premises with division 79 | **797** |
| **U6 — SOURCE_INCLUDED_GENERIC_COMMERCIAL_PREMISES** | distinct U1 premises in section G | **42,061** |

U2 is a mechanical **populated-source-taxonomy** universe. It includes every U1
premises with at least one populated epigraph, including populated section-Z code
`000000 / SIN ACTIVIDAD` under Gate B's `EXCLUDED` class. Those premises are **not
silently removed**. Blank taxonomy remains outside U2. A populated epigraph establishes
recorded taxonomy only: it does **not** establish verified current operation or even
that the source category represents current economic activity.

The Gate C exclusion union reproduces exactly: situación 8 **12,423**, situación 9
**4,120**, access 12 **2,881**; overlaps are 8∩12 **1**, 9∩12 **14**, 8∩9 **0**, triple
**0**. The naïve sum is 19,424, the union is **19,409**, and **15** double-subtractions
are avoided. No inferred status or access exclusion is added.

**Ruling — source-included universe: GO.** It is a reproducible administrative
premises universe, not a count of active/operating businesses and not automatically a
commercial or tourism universe.

### F.2 · Multi-activity handling

Class membership is **non-exclusive**. A premises belongs to every Gate B class for
which it has at least one populated activity row. It is deduplicated once within each
class, and no dominant or exclusive activity is invented.

Within U1, 1,504 premises belong to two of U3–U6 and 3 belong to three. The pairwise
overlaps include CORE_HOSPITALITY∩ACCOMMODATION **141** and
CORE_HOSPITALITY∩GENERIC_COMMERCIAL **1,334**. Consequently class-membership shares are
valid set-membership proportions but **are not a partition and need not sum to 100%**.

The row-count negative control shows why premises deduplication is mandatory. Among
source-included records, CORE_HOSPITALITY has 20,615 activity rows but 19,532 premises
(**5.54%** row inflation); GENERIC_COMMERCIAL has 50,954 rows but 42,061 premises
(**21.14%** inflation). Activity rows are never substituted for a premises numerator or
denominator.

### F.3 · Blank taxonomy treatment

After the explicit source exclusions, **42,172 U1 premises (22.8849%)** carry only the
Gate B handling label `UNCLASSIFIED_SOURCE_ACTIVITY`. They remain:

- **included** in U1 and in a denominator explicitly defined as all source-included
  documented premises;
- **excluded** from U2 and any denominator explicitly limited to populated source
  taxonomy;
- visible as source semantics **UNRESOLVED**, never interpreted as inactivity.

Their U1 status composition is Abierto 10,880, Cerrado 23,902 and Uso vivienda 7,390.
Their access composition is Agrupado 1,819, Puerta Calle 30,640 and Interior 9,713.
The complete code-sorted district and barrio counts are in the audit artifact.

Exclusion is not spatially neutral: barrio blank shares range from **3.1447%** to
**46.9118%**, with median **17.8419%**, p90 **35.2490%** and coefficient of variation
**0.446**. Dropping blank taxonomy from an “all documented premises” denominator would
therefore introduce material spatial bias. Exclusion is justified only when the
question itself is *membership within populated source taxonomy*.

**Ruling — blank handling: GO** under this split rule. A single silent include/drop
rule across every denominator family is NO-GO.

### F.4 · Access type `Interior`

Code 3 `Interior` appears on **51,501 raw premises (25.2843%)** and **42,093 U1
premises (22.8420%)**. Its source semantics remain undocumented; **9,408** Interior
records overlap the Gate C status exclusions. It occurs across taxonomy classes and
includes 9,713 U1 blank-taxonomy premises. Its barrio share ranges from **0.5348%** to
**61.4149%**.

No source evidence authorises excluding it. A diagnostic counterfactual exclusion
would remove all 42,093 U1 Interior premises. It changes U1-per-resident barrio order
materially (Spearman **0.933663**, mean absolute rank shift **10.23**, maximum **46**) and
changes the CORE/U2 membership-percentage order much more (Spearman **0.700490**, mean
shift **21.93**, maximum **95**). Those orderings are diagnostics only; no barrio
ranking is published.

**Ruling — GO to include under the explicit Gate C rule, with semantics flagged.**
Absence from the source documentation is not evidence for exclusion. The
counterfactual's material effect is precisely why an undocumented exclusion cannot be
introduced silently.

### F.5 · Population denominator provenance

| Field | Established value |
|---|---|
| Authority | Ayuntamiento de Madrid — Subdirección General de Estadística |
| Dataset | *Población por distrito y barrio a 1 de enero* (`300557-0-poblacion-distrito-barrio`) |
| Underlying register | Padrón Municipal de habitantes |
| Unit | persons registered in the municipal Padrón |
| Reference date | **2026-01-01** (*1 de enero de 2026*) |
| Period type | annual reference-date stock; **not** an annual average |
| Total | **3,497,277** registered residents |
| Coverage | 1 municipality, 21 districts, 131 barrios |
| Geography join | exact 3-digit `official_id` + 2-digit parent, CURRENT_131 only |
| Artifact contract/version | `1.0.0`; JSON SHA-256 `e6bc8a209927…` |

District and municipality totals are derived deterministically from the 131
source-reported barrio values. The population asset joins 1:1 to barrio geography
v3.4.1 and district v3.2.1. It measures registered residents, not present population,
daytime population, workers, visitors, tourists, households or dwellings.

### F.6 · Temporal alignment

The premises/activity source has nominal period **September 2026**; it provides no
exact within-month reference day. Population is a stock at **2026-01-01**. The nominal
month offset is **8 calendar months**; if the premises month is conservatively anchored
at 1 September, the lower-bound day gap is **243 days**, but an exact day gap cannot be
claimed.

The monthly Padrón dataset (`200076`) is a potentially closer source, but it has rolling
end-of-month semantics and is not a committed/audited CURRENT_131 denominator in this
project. Gate F does not silently substitute it for the explicit annual stock.

**Ruling — population denominator: MODIFY.** The annual value is acceptable for a
bounded *residential-context* density if both source periods are displayed separately.
It may not be labelled simply “2026” or presented as simultaneous with the premises
snapshot.

There are **no zero-population barrios** and none below 1,000 residents. Six are below
5,000: codes `027` (2,939), `081` (3,472), `082` (3,567), `096` (3,161), `158`
(1,690) and `212` (1,928). These can amplify rates and must be available as denominator
metadata. Gate F applies **no winsorisation or suppression**: it discloses the issue
instead. Any later product design may add a transparent small-denominator flag but may
not hide or cap values without a separate decision.

### F.7 · Candidate indicators

The citywide arithmetic below is an audit cross-check, not a published KPI or area
ranking.

| Machine key | Public label | Audit value | Method ruling | Release status |
|---|---|---:|---|---|
| `source_included_premises_count` | Source-included premises | 184,279 | **GO** | `PRODUCTION_CANDIDATE` |
| `core_hospitality_premises_count` | Documented hospitality-class premises | 19,532 | **GO** | `PRODUCTION_CANDIDATE` |
| `accommodation_class_premises_count` | Documented accommodation-class premises | 7,919 | **GO** | `PRODUCTION_CANDIDATE` |
| `tourism_adjacent_premises_count` | Documented travel-trade-class premises | 797 | **CONTEXT ONLY** | `CONTEXT_ONLY` |
| `core_hospitality_membership_share_of_populated_taxonomy_premises` | Premises with a documented core-hospitality activity (%) | 13.7446% | **GO** | `PRODUCTION_CANDIDATE` |
| `core_hospitality_share_of_source_included_premises` | Hospitality-class membership share of source-included premises | 10.5991% | **MODIFY** | `CONTEXT_ONLY` |
| `source_included_premises_per_1000_residents` | Source-included premises per 1,000 registered residents | 52.6921 | **MODIFY** | `CONTEXT_ONLY` |
| `core_hospitality_premises_per_1000_residents` | Documented hospitality-class premises per 1,000 registered residents | 5.5849 | **MODIFY** | `CONDITIONAL_PRODUCTION_CANDIDATE` |
| `accommodation_class_premises_per_1000_residents` | Documented accommodation-class premises per 1,000 registered residents | 2.2643 arithmetic only | **NO-GO** | `NO_GO` |
| `premises_per_km2` | Source-included premises per gross administrative km² | not admitted | **NO-GO** | `NO_GO` |
| `core_hospitality_premises_per_km2` | Documented hospitality-class premises per gross administrative km² | not admitted | **NO-GO** | `NO_GO` |

`PRODUCTION_CANDIDATE` is reserved for the four methodologically GO candidates.
`CONDITIONAL_PRODUCTION_CANDIDATE` is distinct: the per-resident indicator remains
methodologically MODIFY and may be proposed only if every registry condition travels
with it. Neither status is production approval and nothing is wired here.

### F.8 · Source-internal non-exclusive membership

`CORE_HOSPITALITY / U2` is a coherent **non-exclusive membership rate**: numerator and
denominator use the same source, snapshot, geography, exclusion rule and populated-
taxonomy condition. Its exact public meaning is: *percentage of source-included
premises with populated taxonomy that have at least one documented CORE_HOSPITALITY
activity.* It is not a mutually exclusive compositional partition. U2 retains populated
`000000 / SIN ACTIVIDAD`; populated taxonomy does not mean verified operation. Class
membership percentages are not expected to sum to 100%.

`CORE_HOSPITALITY / U1` is also arithmetically defined but answers a different question:
hospitality membership among all source-included premises, including blank taxonomy.
Because the blank share varies strongly in space, it is **MODIFY / CONTEXT ONLY**, not a
replacement for the populated-taxonomy membership rate.

Source-internal membership is more internally coherent than population density, but it
does not “win”: it answers documented class membership, while population density
answers residential context. Neither is capacity or impact.

### F.9 · Population-based density

`CORE_HOSPITALITY / registered residents` is **MODIFY** and may proceed only as:
**Documented hospitality-class premises per 1,000 registered residents**. It describes
administrative hospitality presence relative to residential population. It is useful
for asking where the recorded class is relatively concentrated compared with the
residential base.

It does not account for daytime population, commuters, visitors, land use, premises
size, seats, turnover, opening status or impacts. Central/non-residential areas may have
a small residential denominator relative to their functions. The six under-5,000
barrios require denominator visibility. The indicator must display Sep-2026 premises
and 2026-01-01 population as separate periods.

Its `CONDITIONAL_PRODUCTION_CANDIDATE` conditions are mandatory: premises period
**Sep 2026**; resident denominator date **01 Jan 2026**; denominator named as
**registered residents / Padrón reference-date stock**; dual dates displayed
separately; no shared “2026” wording implying simultaneity; residential-context
density only; and explicit prohibitions on tourism pressure, resident burden,
saturation, overtourism and verified operating-business density.

Broad `U1 / population` is **MODIFY / CONTEXT ONLY**: its numerator combines populated-
taxonomy, blank-taxonomy, Cerrado and Uso-vivienda records that the source does not
explicitly exclude. It is a legitimate administrative-density arithmetic but a weak
destination-management KPI.

### F.10 · Area-based density

The audit derives gross area from the committed canonical WGS84 polygons using a
spherical polygon-area calculation (holes subtracted): municipality **603.705 km²**;
the sum of barrio areas agrees to rounding. Barrio gross area ranges from **0.249 km²**
to **187.491 km²** and has a coefficient of variation of **3.699**.

Gross administrative area includes parks, protected/open land, infrastructure and
other non-buildable or non-commercial space. No canonical built-up, developable or
commercial-floor-area denominator is available. Therefore both area candidates are
**NO-GO for production**. A mathematically valid quotient cannot be rescued by a safer
label when the denominator does not represent the relevant exposure surface.

### F.11 · Sensitivity analysis

No ranking is authorised or emitted. Rank correlation and absolute order movement are
used only to diagnose whether denominator choice changes the spatial story:

| Diagnostic comparison | Spearman ρ | Mean absolute shift | Maximum shift |
|---|---:|---:|---:|
| A U1/population vs B U2 populated-taxonomy premises/population | 0.974526 | 6.41 | 28 |
| A U1/population vs C CORE/population | 0.881711 | 12.72 | 75 |
| C CORE/population vs D CORE/U2 non-exclusive membership | 0.136946 | 39.68 | 122 |
| raw/population vs source-excluded-union U1/population | 0.996429 | 2.08 | 17 |

The first comparison shows that blank-taxonomy handling changes order non-trivially;
the last shows Gate C exclusions are less disruptive but still not inert. The near-zero
association between CORE/population and CORE/U2 is not an instability defect: the two
denominators answer fundamentally different questions (residential context versus
non-exclusive source membership). It is evidence against presenting them as
interchangeable KPIs.

Premises versus activity-row sensitivity is material (F.2), and the Interior
counterfactual is especially material for source membership (F.4). These findings
support explicit denominator families, not a composite score.

Geographic completeness does not drive the result: only **1 U0/U1 premises** lacks a
barrio code (it is also U3). By contrast, **50,870** premises have no usable coordinate,
and all 50,870 are still code-resolved. Coordinate missingness is never an eligibility
filter; code assignability and coordinate QA are separate.

### F.12 · Decision relevance

Admitted questions are bounded:

- How many source-included administrative premises are documented?
- Where is documented division-56 hospitality activity present?
- What percentage of populated-taxonomy premises has at least one documented
  CORE_HOSPITALITY activity?
- Where is documented hospitality presence relatively concentrated compared with
  registered residents, with both dates shown?
- Where are heterogeneous division-55 accommodation-class premises documented (count
  only, with no capacity reading)?

Division 79 is mathematically clear but has limited decision relevance as a per-resident
construction. Its count remains **CONTEXT ONLY**; a travel-agency-per-resident rate is
not added merely because it is calculable.

Not legitimate: which barrio suffers most; where residents bear the greatest burden;
where tourism stress, saturation or overtourism is highest; or any “hot/worst/top”
area question.

### F.13 · Naming and interpretation ceilings

Admitted labels use **source-included**, **administratively documented**, **recorded**
and **class premises**. They do not use active businesses, operating restaurants,
tourism businesses, hospitality supply or tourism capacity.

The three admitted count labels are guarded explicitly: `source_included_premises_count`
remains premises, never “businesses”; `core_hospitality_premises_count` remains
documented hospitality-class premises, never operating restaurants; and
`accommodation_class_premises_count` remains documented division-55/accommodation-class
premises, never beds, capacity or licensed accommodation stock.

The per-resident ratio is a **conditional**, not unconditional, production candidate.
It may never claim:

- pressure on residents, resident burden or tourism stress;
- carrying capacity, saturation or overtourism;
- tourism/visitor demand, present-person exposure or commercial vitality;
- verified operating businesses; or
- accommodation capacity, tourist beds or tourist intensity.

The accommodation class is especially constrained. Division 55 mixes hotels/motels,
hostales, apart-hotels, viviendas turísticas, albergues, student residences, pensiones
and casas de huéspedes. A premises count is not capacity. Gate D also found a major
recorded-universe discontinuity. **Accommodation count: GO with the exact class label.**
**Accommodation per resident: NO-GO.** It is not merged with the licensed-VUT or Madrid
Destino universes.

### F.14 · Indicator registry and required metadata

The machine-readable registry contains, for every candidate: machine key, public label,
exact numerator, denominator, unit, current geography/version, reference period and
fingerprints, ruling, release status, legitimate decision question, interpretation,
interpretation ceiling, temporal-use rule, required metadata, known sensitivity,
reason, and a non-numeric risk matrix covering source validity, numerator clarity,
denominator clarity, temporal/geographic compatibility, sensitivity, interpretive risk
and decision relevance.

Every admitted candidate must carry:

- numerator universe and source exclusions;
- unit;
- denominator authority/source/reference date where applicable;
- CURRENT_131 geography and published versions;
- premises/activity family + nominal period + content fingerprint;
- denominator artifact/data version;
- interpretation ceiling; and
- temporal-use rule.

No `NO_GO` entry is a production candidate.

Release readiness is also categorical: four GO indicators are
`PRODUCTION_CANDIDATE`; the one MODIFY density is separately
`CONDITIONAL_PRODUCTION_CANDIDATE` with its mandatory conditions embedded in the
registry. These statuses must never be collapsed.

### F.15 · Gate F ruling — **GO, scoped to the exact admitted set**

| Question | Ruling |
|---|---|
| Source-included premises universe | **GO** |
| Blank taxonomy handling | **GO** — retain in U1; exclude only from explicitly populated-taxonomy membership |
| Interior access handling | **GO** — include under explicit source rules; semantics flagged |
| Populated-taxonomy-premises denominator | **GO** — U2, populated epigraph, premises-deduplicated; includes populated `SIN ACTIVIDAD`; not verified operation |
| Population denominator | **MODIFY** — residential-context only; dual dates; current geography |
| Area denominator | **NO-GO** — gross-area land-use bias; no built-up denominator |
| CORE_HOSPITALITY membership percentage within U2 | **GO** — non-exclusive membership rate; analytical-class percentages need not sum to 100% |
| CORE_HOSPITALITY per resident | **MODIFY** — administrative residential-context density only |
| ACCOMMODATION per resident | **NO-GO** — heterogeneous premises class is not capacity |
| Pressure / saturation / overtourism indicator | **NO-GO** |
| **Overall Gate F** | **GO to a later, scoped implementation proposal only for the exact unconditional and conditional sets below** |

The exact unconditional `PRODUCTION_CANDIDATE` set is:

1. `source_included_premises_count`
2. `core_hospitality_premises_count`
3. `accommodation_class_premises_count`
4. `core_hospitality_membership_share_of_populated_taxonomy_premises`

The exact `CONDITIONAL_PRODUCTION_CANDIDATE` set is:

1. `core_hospitality_premises_per_1000_residents`

The conditional candidate remains MODIFY and may be proposed only with all dual-period,
denominator and interpretation requirements above. Neither readiness class is a UI
authorisation; a later implementation change must consume the registry contract and be
reviewed separately.

**Temporal-use rule.** Gate F approves a current fingerprinted snapshot only. It does
not authorise a trend chart. A later CURRENT_131 series must still satisfy Gate D's
snapshot/version and administrative-universe segmentation. Current 2026 population is
never applied to HISTORICAL_128 records; cross-2017 per-resident analysis remains
NO-GO unless era-compatible historical population is independently established.