# Claims and limitations ## What this application does - Lets you move one or two spatial lenses across central Madrid and see **descriptive counts** of tourism POIs, accommodation, and mobility nodes inside each lens. - Shows **HATI-Madrid's bounded, model-derived UTCI evidence** at 14 outdoor sample points, for a single historical pilot day (21 August 2023), at three modelled times of day. - Compares two lenses' descriptive statistics side by side. - Shows the **Radial Halo V3** outward radial bars around each Lens (in single-lens and Compare mode) for **Tourism POIs, Hotels & stays, Mobility nodes and mean HATI UTCI**. Each bar prints its own **raw value** inside the Lens; for the three count metrics the bar **length** is that lens's represented **density** (records or nodes per km²) relative to a fixed Madrid reference density, so unequal A/B radii stay comparable; UTCI's bar is the mean's position in a model-derived Celsius band. Bar lengths are comparable within a metric only, not across metrics. Canonical metric slots are fixed at Tourism POIs 12, Stays 2, Mobility 6 and UTCI 9 o'clock on both lenses; focusing a slot highlights its partner and comparison row. Bars are screen-space graphics attached outside the Lens, not extensions of its analytical radius. Lens A, Lens B and B−A values remain in the panel; **pedestrian activity is panel-only** (observed counter evidence, not a count). See `docs/radial-halo-v3.md`. - Keeps Lens A and Lens B radii independent with one active-Lens slider. First enable of B copies A's radius; later re-enables preserve B. Equal-radius Tourism POI/stay comparisons use raw represented counts. Unequal-radius comparisons retain raw counts and use represented records/km² only when both complete circles fit inside Madrid's canonical municipality polygon and evidence states are compatible. Mobility deltas are withheld for unequal radii; pedestrian and UTCI remain in native units. - Names the **official barrio and district** containing the active lens's centre, and reports that barrio's **registered residents** from the municipal Padrón, with its reference date (1 January 2026). - Reports, for that same **whole official barrio**, the **licensed tourist-dwelling (VUT) units** and the **granted VUT activity licences** the Ayuntamiento's Agencia de Actividades documents there, with a descriptive **licensed VUT units per 1,000 registered residents** figure and both raw counts always shown beside it. - Reports, for the **whole municipality of Madrid** and separately from anything about the Lens, the **hotel travellers** and **overnight stays** the official INE hotel occupancy survey published for the latest available month, their **residence composition**, a **same-month-previous-year** comparison, and a 24-month trend. - Reports, for the **official planning ámbito** that contains a Lens centre, what the K6 current dated official edition publishes about that **whole ámbito**: its official denomination and exact official code, the **four independent published development-phase values** (verbatim), the characteristic use, the published surface, and the **available buildability** (*edificabilidad disponible*) by documented use class in **m² edificable** — each figure with its unit, its whole-ámbito scope and the edition's stated reference date. It also lists **which** planning ámbitos a Lens circle touches, and nothing more about that intersection. K7 adds a secondary comparison of the explicitly named **2025-07-01 and 2026-01-01** editions for that same ámbito. The two dates are displayed with the comparison. See [Planning-ámbito evidence V1](PLANNING_AMBITO_EVIDENCE_V1.md) and [Official edition change detection V1](AMBITO_CHANGE_DETECTION_V1.md). ## What this application does NOT claim or establish This is a deliberate ceiling, not an oversight. The application does **not** establish, measure, or infer: - Tourist pressure or overtourism - Destination carrying capacity - Tourist behaviour or preferences - Tourist-specific footfall or visitor flow from the pedestrian counters - Safety outcomes of any kind - Tourism "quality," attractiveness, or competitiveness - A winner, ranking, composite score, or Madrid benchmark from the halo. Each count bar's length is a within-metric density magnitude, `clamp((rawCount / circleAreaKm2(radius)) / referenceDensity, 0..1)`, against a fixed deterministic Madrid reference density (p95 of per-feature local density) shared by Lens A and Lens B; UTCI uses a model-derived Celsius band and is never area-normalized. It is comparable within a metric only, never across metrics, and is not a percentage, score or target. - A zero value from absent evidence. The halo distinguishes a valid number, a valid observed zero (printed `0` with a zero mark, no bar), unavailable (printed `N/A`) and off (printed `OFF`); unavailable data never renders as zero. - A complete POI or accommodation inventory from a represented-record rate. Unequal-radius rates are normalized to the full geometric circle area only inside the canonical Madrid municipality AOI; they are not population denominators, census coverage, accommodation density, or supply density. - Independent observations from overlapping or nested windows. Records and sampled assets may be shared between Lenses. - Economic impact - Causal effects of heat on tourism, health, or behaviour - Real-time or current thermal conditions - City-wide HATI coverage — the evidence layer is 14 points in one small study area, not a Madrid-wide heat map. The dashed study-area rectangle in the UI shows the original pilot boundary only; it does not imply continuous thermal evidence inside that rectangle - An exhaustive inventory of any POI category — when a layer is running on its SNAPSHOT SAMPLE fallback, its count reflects only the records curated into that sample, not the true total number of museums, hotels, or tourist info points at that location - A continuous pedestrian-flow surface between permanent counters - Current/live pedestrian conditions — the activity layer is a historical deployment snapshot of the latest published permanent-counter distribution - Complete green-space coverage — the optional Principal parks layer reflects the municipality's published list of principal/significant parks and gardens, not every green space in Madrid - Any inference that a mapped park is cooler, shadier, healthier, more biodiverse, more accessible, higher quality, or more attractive to tourists - The number of people inside a lens circle — the Area Profile's resident figure describes the **whole official barrio** containing the lens centre, never the part of it the circle happens to cover, and is never scaled, weighted or interpolated into the circle - Any accommodation-per-resident, hotels-per-1,000-residents, tourism-density or tourism-pressure figure. The application holds a Madrid Destino accommodation layer and a resident denominator and deliberately computes **no ratio between them**: a Gate A audit examined exactly that division and ruled NO-GO, because that layer is a tourism-promotion catalogue, not an administrative register ([ACCOMMODATION_NUMERATOR_AUDIT.md](ACCOMMODATION_NUMERATOR_AUDIT.md)). The one per-resident figure the application does publish uses a **different, separately qualified source** — granted municipal VUT activity licences, admitted at Gate B ([ACCOMMODATION_NUMERATOR_GATE_B.md](ACCOMMODATION_NUMERATOR_GATE_B.md)) — and is bounded by everything in the section below - That the licensed VUT dwellings are **currently operating**. The source records licences **granted**; it carries no revocation, expiry or cessation field and publishes no retention policy, so nothing in the application says *active*, *operating* or *current* tourist dwellings, and the extract is not described as a cumulative stock - That the licensed VUT figures are **all** tourist dwellings or **all** accommodation. Regional VUT responsible declarations, the Comunidad de Madrid inventory and online platform listings are all outside the source, and the publisher names tourist apartments, hostels, guest houses, hotels, pensions and aparthotels as excluded modalities - The **legality** of any platform listing. The application makes no correspondence between a licence record and any advertised accommodation - That a licence is a dwelling. One granted licence can contain many tourist-dwelling units — up to 48 in the current extract — so the licence count and the unit count are different figures and are never substituted for one another - A **share of homes or households**. The per-1,000 denominator is registered **residents**, so the figure is never "X% of homes are tourist apartments" - A **rank, band, percentile, hotspot, score or choropleth** of licensed VUT. The figure is presented identically at every value: a barrio with more licensed units is not styled, coloured or worded as a problem - Daytime, present, working or visiting population — registered residents are persons on the municipal register at the reference date, not people at a place at a moment Observed pedestrian counts describe people passing fixed municipal counters. They do not identify tourists, trip purpose or destination demand. A lens with no counter returns **no sensor evidence** rather than an interpolated estimate. Lens A/B pedestrian differences compare only the published observations at counters that fall inside each lens. A mobility-node count is descriptive infrastructure presence, not service frequency, capacity, accessibility, travel time, or connectivity quality. Metro and Cercanías station records may represent different modes at the same interchange and are not deduplicated into a single multimodal hub. Metro and Cercanías stations were requested only inside a central rectangle of Madrid (40.385–40.455 N, −3.745…−3.645 E, about 11 % of the municipality). A Lens circle that is not wholly inside that rectangle therefore has its combined Mobility count **withheld** — shown as "Withheld", never as a number or a zero — because missing stations would otherwise read as absence. Inside the rectangle the count is shown, but the completeness of the source within it is **not verified**: the rectangle is an extraction boundary, not evidence of complete coverage. Accommodation type filters are descriptive source classifications. They do not imply quality, price, legal status, availability, occupancy, or suitability. Records without source type metadata remain unclassified rather than being guessed from their names. A POI count is a count, not a quality or pressure indicator. A UTCI mean is the mean of the HATI samples that happen to fall inside a lens on 21 August 2023 at a chosen hour — not a forecast, not a live reading, and not a verdict on whether a place is "safe" or "recommended" to visit. Likewise, a metric such as "Hotels & stays: 6" must never be read as "exactly six accommodations exist here" if that layer is on its snapshot fallback; it means six sample records happen to fall inside the lens. A barrio's administrative statistics — its registered-resident count and its licensed VUT figures alike — and a lens's circle measurements have **different geometries**, and are presented as separate sections for that reason. When two lenses fall in the same barrio they point at **one** set of administrative statistics, and the interface says so rather than repeating the figures. When no official area contains the centre, when the centre is outside Madrid, or when a record is absent or incoherent, the interface abstains explicitly — it never shows `0`. One `0` in the interface is real, and it is scoped: a barrio for which the committed licensed-VUT extract reports no granted licence genuinely shows `0`, because that extract enumerates licence records across the whole municipality, so absence within it is an observation. This is the single documented exception to the project's "missing is not zero" rule, and it never applies to a load or validation **failure**, which reads *unavailable*. A barrio with a genuinely small non-zero figure displays `<0.1` rather than a rounded `0.0`, so a real figure is never printed as nothing. Datasets keep their own periods and are never implied to be synchronised: administrative geography carries no effective date (only a published dataset version), registered residents are dated 1 January 2026, the HATI pilot is 21 August 2023, and the pedestrian counters are a 2024 published period. The application has no global time control, because there is nothing to align. The licensed-VUT numerator is the sharpest case. Its source declares **no reference date and no effective date at all**, so the application reports a **source file state** — the HTTP `Last-Modified` header observed on the resource file, September 2026 — and says in its disclosure that this describes the file served and is **not** a publisher-declared publication, effective or reference date. The per-1,000 figure therefore combines two sides with **different temporal semantics**, which the interface shows separately: *Reference 1 Jan 2026* for the residents, *source file state Sep 2026* for the licences. A shared label such as "VUT & population — 2026" is forbidden, and so is presenting the HTTP header as a VUT reference date. The licensed-VUT artifact is a **committed administrative snapshot**. It is not rebuilt when the site deploys: deployment validation verifies the committed file, so a successful deployment does not mean the upstream source was re-fetched. Refreshing it requires re-running the builder and reviewing the diff. Nothing about this layer is live data. ### Registered unemployment in the Area Profile The Area Profile shows the publisher's barrio-level *tasa absoluta de paro registrado* (SEPE registered unemployed over the 16–64 Padrón population) for the whole official barrio containing the Lens centre. It is contextual socioeconomic evidence about residents. It is **not** a tourism impact, does **not** show that tourism or visitor activity relates to, causes or relieves unemployment, is **not** the EPA unemployment rate, and is **not** a measure of vulnerability, deprivation or poverty. It is never ranked, banded, scored, compared between barrios as a difference, mapped as a surface or combined into an index, and it is never allocated into the Lens circle. Its reference month, February 2026, is confirmed against the Ayuntamiento's monthly Banco de Datos series 1.1.D; the publisher's own year table in the panel PDF (2025) is stale (see `docs/DATA_PROVENANCE.md`). The rate's SEPE numerator (February) and Padrón denominator (1 January 2026) are different instants. ### Destination Context — hotel demand The Destination Context surface reports **hotel-sector demand in the municipality of Madrid** from the official INE *Encuesta de Ocupación Hotelera*. **It does not establish:** - **Total tourism demand.** The survey covers **hotel establishments only**. It excludes tourist apartments, tourist dwellings (VUT), campsites, rural accommodation, day visitors and everyone staying in unpaid or private accommodation. Hotel demand is a **part** of tourism, never a proxy for it. - **How many people visited Madrid.** *Travellers* counts arrivals **per establishment**: one person staying in two hotels is counted twice. It is not a count of unique people. - **Anything about any barrio, district or Lens circle.** This is a single citywide figure. The artifact carries no coordinates and no sub-municipal identifier, so it cannot be distributed into a smaller area even by accident. Dragging a Lens never changes it. - **Domestic versus international tourists.** The composition is the publisher's own **place of residence** split (*Residentes en España* / *Residentes en el extranjero*). Residence is not nationality, not trip purpose and not a domestic/international tourist classification. - **Tourism pressure, overtourism, saturation, carrying capacity, intensity or attractiveness.** The figures are never ranked, banded, scored or mapped. - **Why a figure changed.** The product reports the observation. It offers no attribution to events, weather, prices, policy or anything else, and uses no evaluative language — no *strong*, *weak*, *boom*, *crisis*, *success*, *failure*, *surge* or *record*. - **Hotel profitability.** ADR and RevPAR exist in the publisher's catalogue but come from a **different statistical operation** and are deliberately excluded. **What it does carry honestly:** - The **source geography is stated, not hidden.** The compact card shows *Madrid* with *whole municipality* beside it; the source disclosure states the publisher's own term (*punto turístico* `Madrid`) together with municipality code **28079**. INE defines a *punto turístico* as a municipality and publishes this one under that code. - **Provisional data is labelled.** The current statistical year is published provisional and revised later, so a same-month-previous-year comparison routinely compares a provisional figure with a definitive one. That is stated rather than smoothed over. - **A withheld month stays withheld.** Where the publisher published nothing (May and June 2020), the product shows nothing and the trend line breaks. It is never rendered as a zero and never interpolated. April 2020 — a **real published zero** — is kept distinct from those. The hotel-demand artifact is a **committed statistical snapshot**. It is not rebuilt when the site deploys, and the browser never calls the publisher's API at runtime. Refreshing it requires re-running the builder and reviewing the diff. ### Destination Context — domestic origins The same municipality-level surface also reports published **origin municipalities** for residents travelling to Madrid municipality **from another Spanish province** in a selected source month. Same-province travel, including travel within Madrid province, is outside the source universe. It uses INE's direct internal-tourism workbook and destination code **28079**, corroborated by the workbook's Madrid destination and province fields. **It does not establish:** a Lens, barrio or district origin; a complete distribution of domestic tourism; an all-origin share; unique people; market attractiveness; causality; or a forecast. INE publishes only origin-destination crossings with **more than 30 tourists**. An origin absent from the published table may therefore be outside the source universe or, within that universe, suppressed; it is **not zero** and no residual “other origins” category is made. The source-reported `turistas` count remains a count for that published crossing in that month. The artifact is a committed, Madrid-only snapshot. Its source month, workbook year, retrieval time and latest actually published month are stored separately; moving a Lens cannot alter any origin value. The **Top published origins map** places the ten or twenty-five highest published origin municipalities of the selected month as circles whose area is proportional to the source-reported count, relative to the largest circle shown. Positions are IGN municipality reference points, a separate and separately licensed source. The map **does not establish** where in the origin municipality the tourists live (the point sits in the main population nucleus, not at the centre of the territory), any flow, route, travel path or volume between places, a complete or ranked-by-importance origin market, an all-origin share, a density or hotspot, or anything about the origins that are not shown or not published. Circle size encodes only the published count of the crossing in that month; unpublished origins are not zero and are not drawn. Domestic Origin Dynamics compares a selected source month only with the exact prior calendar month when it is present in the committed artifact. It describes published municipality sets: published in both months, newly present in the published set, and no longer present in the published set. A row entering or leaving that set does **not** establish that tourism started or stopped, because the source publishes only crossings above 30 tourists. An absent value is never converted to zero. Observed count changes and percentages are shown only where the source publishes both monthly values. This is descriptive, not causal or predictive, and it does not establish visitor retention, all-origin shares, province totals, international origins or any geography within Madrid. ### Permanent ceilings for urban-development evidence Gate K reframed the product around urban-development evidence (see [`PRODUCT_SEMANTICS.md`](PRODUCT_SEMANTICS.md)). Two ceilings it established are **methodological rules**, binding on every present and future surface, not one-off disclaimers about a dataset that happens to ship. They apply now, before any planning or ámbito layer exists, so that no later increment can quietly breach them. - **No dwelling or protected-dwelling counts from non-unit quantities.** Where an official source publishes buildability (m² by use class) or any other quantity that is not itself a count of dwelling units, the application must **not** derive, estimate or imply a number of dwellings, protected dwellings, homes or households from it. Buildability is floor area the plan permits, not housing delivered; the two are different indicators and are never converted into one another. **Correction to Gate K §6.6**, which claimed no dwelling-count field exists: Gate L §16 found that dataset 203182 *does* publish `Colectiva. Nº Viviendas` and `Unifamiliar. Nº Viviendas`, documented as *"Nº de viviendas disponibles … en unidades"*. It then measured their values as exactly residential buildability ÷ 100, fractional, at a match rate of 1.0 across every row — a mechanical m²/100 proxy at an assumed 100 m² per dwelling, **not a count of dwelling units**, with no protected-housing count column at all. Those columns are read and counted at build time so the exclusion is a recorded observation, and are then **excluded by name**. The ceiling is unchanged and binding: buildability ships in m² only, and no dwelling count is published or derivable. - **No overall development stage, progress, percentage or timeline.** The four published phase fields of a planning ámbito are, empirically, **multi-dimensional and not an ordered funnel**, and the publisher documents no ordering between them (Gate L §12: `MULTI_DIMENSIONAL_NO_SCALAR_STAGE`). The application therefore reports **four independent published values** and never derives an overall stage, a stage number, a progression, a percentage, a completion figure, advancement, delay, a timeline, a progress bar or an overall status from them. No single element summarises the four, and the order they are listed in is the publisher's column order, not a rank. - **A published planning state is not physical construction.** `PLANNING_STATE_TRANSITION ≠ PHYSICAL_URBAN_CHANGE`. A phase value such as `Urbanización. Obras = En Ejecución` is an **administrative state** recorded by the plan. It is not a measurement of work on the ground, not a completion percentage, and not evidence that anything has been built. - **Available buildability is not a forecast.** It is what the plan makes available for lucrative uses in currently-valid ámbitos, according to situación. It is **not** "remaining to be built", "yet to be constructed", construction remaining, development remaining, unallocated land, or an estimate of what will necessarily be built. The application never implies it will be consumed. - **`No Necesita` has no established meaning.** The publisher lists it as a distinct expected phase value but **never defines it** (Gate L §13). The application preserves the verbatim label, keeps it structurally distinct from `Sin Iniciar`, and states that its precise meaning is not defined in the audited documentation. It is never rendered as, mapped to or equated with "no aplica", "not applicable", `Sin Iniciar`, zero, unavailable, complete or skipped. - **`PGOUM-85` and `PGOUM-97` are not progress states.** They are plan-of-origin markers that occupy phase cells — 42.4 % of all phase cells (Gate L §11) — and are preserved verbatim, never inserted into a sequence and never treated as errors. - **An edition difference is not physical urban change.** K7 compares exactly two named tabular editions, **2025-07-01 → 2026-01-01**, within the shared current S1 and S2 schema eras. The 15 published editions are not one comparable series: schemas before 2025 use earlier structures, and cross-era comparisons abstain. S2 keeps every published row; only a unique, stable SITUACION DEL ÁMBITO value supports row matching. Ambiguous or unmatched rows leave numeric buildability comparisons withheld. An eligible numeric result is labelled an **observed published difference**; it does not establish what happened on the ground or why the source values differ. K7 has no additional editions, map geometry comparison or derived dwelling quantity. The audit retains 54 legacy cosmetic text observations as non-substantive; the row-aware production count is reconciled separately in [Official edition change detection V1](AMBITO_CHANGE_DETECTION_V1.md). - **The planning geometry's currency is unknown.** The official layer publishes no edition date, no effective date and no cadence, so the application shows **no date for the geometry** and never infers one from a retrieval time, a catalogue record date or an HTTP header. - **The raw planning layer is not a count of ámbitos.** It is a mixed universe of planning ámbitos, Norma Zonal grade records and non-developable land classes. The application filters to the documented ámbito universe, reports every exclusion by class and count, and never describes the raw feature count as a number of ámbitos. - **A Lens∩ámbito reading is membership only.** It answers *which* official planning ámbitos a Lens circle touches. It never answers what share of an ámbito's published state, surface or available buildability lies inside the circle — no proportional, area-weighted or population-weighted allocation exists, and the model exposes no overlap area or fraction from which one could be computed. - **No apportionment of a whole-area quantity to a part of it.** A value whose **scope** is a whole official area — a barrio, a district, an ámbito, the municipality — must **never** be scaled, weighted or redistributed into a smaller area merely because their geometries overlap or intersect. Overlap is not evidence of how a whole-area total is distributed inside the area. This generalises the existing rule that a barrio's registered-resident and licensed-VUT figures are never apportioned to the lens circle that sits inside the barrio: the same prohibition binds every whole-area quantity the product may ever read, including planning quantities reported per ámbito. - **A granted urban licence is not construction.** The K9 licence layer counts licences the municipality **granted** (`RESOLUCION = Conceder`). A granted licence means an administrative grant was recorded; it is **never** evidence that work started, construction occurred or completed, occupancy happened, or the permitted quantity was built. - **There is no approval or rejection rate.** The licence register is granted-only, with no applications/refusals denominator, so no approval rate, rejection rate, refusal count or success rate exists or is derivable. - **The three licence families are never one total.** Building/urbanistic, activity and temporary-activity licences are counted separately; the product never sums them into a single cross-family total. - **The mapped licences are the resolved subset.** 97.97% of pinned granted records resolve to an official address point through the current + historical Callejero Oficial (artifact-derived, never hardcoded); the 233 unresolved rows are reported, not mapped, and never dropped from the denominator. No third-party geocoder is used, and the layer never claims complete coverage. Licence counts are address points inside a Lens circle — never a barrio-level figure, a barrio or district ranking, or a density/heatmap/choropleth surface — and are never summed with Censo de Locales, VUT or hospitality evidence as unique sites. ### No AI assistant; the contract that would constrain one - **This product contains no AI assistant and no language model.** There is no chat, no input box, no conversational surface and no "Ask Madrid". There is no LLM, no model call, no API key, no network request, no prompt, no embedding and no vector store anywhere in it, and it generates no natural-language text about the evidence. - What the product does have is a pure, deterministic **Evidence Registry query contract** (`js/evidence-registry.js`, documented in `docs/EVIDENCE_REGISTRY_QUERY_CONTRACT.md`): a closed set of registered question shapes, each answered from a shipped artifact or model and returned with its full provenance, and each able to **abstain**. It answers "what supports this value, when was it updated, and what does it not permit" from the registry rather than from prose. - Public query provenance is registry-bound: an arbitrary ISO date or unknown source cannot be presented as publisher provenance. Ámbito comparison values are re-resolved from committed codes/edition identities, and an edition change is returned only after validating the code against both committed edition universes. Composite Area Profile and Destination Context objects are labelled as deterministic assemblies even though the publisher observations inside them remain direct official facts. - **Any future assistant would be constrained by this contract, not freed by it.** If a language model is ever added, its only permitted roles are classifying the question and phrasing an answer whose every factual token already came out of a query result. It would never compute a number, choose a date, decide a scope, apportion a whole to a part, rank, score, recommend, make a causal or legal claim, present a dwelling count, or answer where the evidence does not support it. A refusal is a correct answer. No such assistant exists today, and none may be built before this contract closes. ## Evidence states shown in the UI - **MODEL-DERIVED** — one or more HATI samples fall inside the active lens; the app reports their count and mean, both explicitly labelled as model-derived. - **NO EVIDENCE** — no HATI sample falls inside the lens. The app never substitutes an interpolated, estimated, or default value in this case. - **live** — the layer's current data came from a successful runtime fetch of its public API this session. It describes how the data was obtained, not how frequently the underlying source itself updates. - **SNAPSHOT SAMPLE** — the live fetch failed (or was not attempted) and the layer is running on a small, manually curated fallback dataset committed in this repository. Its count is a sample count, not a complete inventory. - **UNAVAILABLE** — neither a live fetch nor a verified packaged source exists for a layer right now. The UI shows "No data" rather than a numeric zero, since a zero would be indistinguishable from a genuinely empty area. - **Official register** — a figure read from an administrative register that enumerates a universe at a published reference date. The registered-resident count carries this state (`ADMINISTRATIVE_REGISTER`). - **Administrative licence** — a figure read from records of administrative acts that were **granted**, with no declared reference date and no revocation field. The licensed-VUT figures carry this state (`ADMINISTRATIVE_LICENSE`). It is deliberately a different state from *Official register*: a granted act is not an enumerated universe, and neither inherits the other's ceiling. - **Official statistics** — a figure read from a **sample-based estimate** produced by an official statistical operation, carrying the publisher's own revision status (*definitive* or *provisional*) and its own statistical confidentiality. The hotel-demand figures carry this state (`OFFICIAL_STATISTICAL_SERIES`). It is deliberately distinct from the three above: nobody is enumerated as in a register, nothing is a record of a granted act, and it is an estimate rather than an observation — but it is also not *model-derived*, because it comes from a statutory survey of real establishments rather than a simulation. ## Relationship to HATI-Madrid This project reads a small, explicitly cited slice of HATI-Madrid's locked evidence (see [DATA_PROVENANCE.md](DATA_PROVENANCE.md)). It does not modify, extend, reinterpret, or re-run any part of the HATI pipeline, and it does not carry forward any of HATI's feasibility/recommendation labels (e.g. "FEASIBLE WITH CONDITIONS") — only the raw UTCI values and the official Bröde et al. stress category they fall into.