SUPERMARIO.WORKS LTD · Universal Builder System

06 — Macrosection 02 — Location, Address & Geographic Relations

Universal Accommodation Data Model v0.1

APPROVED WORKING DRAFT

Architecture Constitution v1.0: FROZEN · Architecture Consensus: 100% AGREEMENT · Implementation Design: OPEN

Purpose

This macrosection defines how locations, addresses, geographic positions and geographic relations are represented inside the Universal Builder System.

The objective is to allow Accommodation and future vertical modules to connect to geographic data without hard-coding the administrative structure of Oxfordshire, Puglia or any other area into the Core.

Core principle: Location and Address are independent objects. Geographic hierarchy is represented through relations rather than fixed country-specific administrative fields.

A — Location Object

The Location Object represents an independent and reusable geographic place. It may represent an administrative location or a recognised geographic, territorial, historical or cultural area.

Technical Key	Label	Description	Data Type	Required	Universal / Territorial	Public / Private	Editable By	Plan	Validation	Relations	Multilingual	Searchable	Filterable	API-ready
`object_uid`	Universal Object ID	Immutable universal identity of the Location.	UUID / String	YES	Universal	Internal	System / Admin	All	Unique, immutable	All relations	No	No	No	Yes
`public_id`	Public Location ID	Human-readable identifier for the Location.	String	YES	Universal	Public	System / Admin	All	Unique	Location	No	Yes	Yes	Yes
`location_name`	Location Name	Official or primary name of the place.	String	YES	Universal	Public	Admin / Editor	All	Non-empty	Location	Yes	Yes	Yes	Yes
`location_type`	Location Type	Functional classification of the place.	Controlled Vocabulary	YES	Universal	Public	Admin	All	Controlled values	Location hierarchy	Labels only	Yes	Yes	Yes
`location_status`	Location Status	Operational status of the Location record.	Controlled Vocabulary	YES	Universal	Internal	Admin	All	Controlled values	—	No	No	Yes	Yes
`alternative_names`	Alternative Names	Alternative, historical or locally recognised names.	Structured List	NO	Universal	Public	Admin / Editor	All	Structured values	—	Yes	Yes	No	Yes

location_type must not impose one universal administrative hierarchy. Technical classification keys remain stable; displayed labels may be translated.

B — Address Object

Address is maintained separately from both Location and Accommodation. An Accommodation may therefore change address without changing its universal identity.

Technical Key	Label	Description	Data Type	Required	Universal / Territorial	Public / Private	Editable By	Plan	Validation	Relations	Multilingual	Searchable	Filterable	API-ready
`object_uid`	Universal Object ID	Universal identity of the Address Object.	UUID / String	YES	Universal	Internal	System / Admin	All	Unique, immutable	Address relations	No	No	No	Yes
`public_id`	Public Address ID	Readable identifier for the Address Object.	String	YES	Universal	Internal	System / Admin	All	Unique	Address	No	No	No	Yes
`address_line_1`	Address Line 1	Primary address line.	String	YES*	Universal	Public	Authorised User / Admin	All	Text	Accommodation / Location	Yes	Yes	No	Yes
`address_line_2`	Address Line 2	Additional address information.	String	NO	Universal	Public	Authorised User / Admin	All	Text	—	Yes	No	No	Yes
`postal_locality`	Postal Locality	Locality used for postal addressing.	String	NO	Universal	Public	Authorised User / Admin	All	Text	Location	Yes	Yes	Yes	Yes
`postal_code`	Postal Code	Postal code according to the applicable country format.	String	NO	Universal	Public	Authorised User / Admin	All	Country-aware	—	No	Yes	Yes	Yes
`country_code`	Country Code	Standardised country code for the postal address.	String	YES	Universal	Public	Admin / System	All	ISO-compatible	Location	No	Yes	Yes	Yes

* Requirement may be adapted for valid cases where a conventional street address does not exist.

The Core does not require fixed fields such as county, province, region or comune. Geographic hierarchy belongs to Location Relations.

C — Geo Position

Geographic coordinates describe a position but never constitute the universal identity of an object.

Technical Key	Label	Description	Data Type	Required	Universal / Territorial	Public / Private	Editable By	Plan	Validation	Relations	Multilingual	Searchable	Filterable	API-ready
`latitude`	Latitude	Geographic latitude.	Decimal	NO	Universal	Public	Admin / System	All	-90 / +90	Location / Address / Object	No	Geo	Geo	Yes
`longitude`	Longitude	Geographic longitude.	Decimal	NO	Universal	Public	Admin / System	All	-180 / +180	Location / Address / Object	No	Geo	Geo	Yes
`geo_precision`	Geo Precision	Precision level associated with the geographic position.	Controlled Vocabulary	NO	Universal	Internal	Admin / System	All	Controlled values	Geo Position	No	No	Yes	Yes

D — Geographic Relations

Geographic hierarchy is represented through relations rather than a fixed country-specific column structure.

Accommodation ↓ LOCATED_IN Oxford ↓ LOCATED_IN Oxfordshire ↓ LOCATED_IN England ↓ LOCATED_IN United Kingdom

Initial Relation Vocabulary

LOCATED_IN — an object is geographically located within a Location.

PARENT_OF — explicit or inverse hierarchical relation where required by the Relations Contract.

NEAR — geographic proximity without implying geographic containment.

Definitive relation semantics, directionality and inverse rules will be formalised in the Relations Contract v1.0.

E — Non-Administrative Areas

The Universal Builder System supports Locations that are not necessarily official administrative divisions.

This may include:

territorial areas;
cultural areas;
historical areas;
geographic areas;
recognised destinations;
other ecosystem-configurable geographic concepts.

For example, Salento may exist as a Location Object without being incorrectly represented as an administrative province or region.

Accommodation ↓ LOCATED_IN Lecce ↓ LOCATED_IN Salento ↓ LOCATED_IN Puglia ↓ LOCATED_IN Italy

The actual relation structure remains configurable. The Core does not impose this example as a mandatory hierarchy.

F — Object Separation

ACCOMMODATION │ ├── relation → LOCATION │ └── relation → ADDRESS LOCATION │ ├── relation → LOCATION └── geo position ADDRESS │ └── geo position (when required)

This separation prevents repeated copies of geographic entities such as Oxford, Oxfordshire, Lecce, Salento or Puglia inside individual Accommodation records.

G — Macrosection Rules

02-R01 — Location is an independent and reusable object.
02-R02 — Address is separate from Location and vertical objects.
02-R03 — No country-specific administrative hierarchy is hard-coded into the Core.
02-R04 — Geographic containment is represented through Relations.
02-R05 — Administrative and non-administrative Locations are supported.
02-R06 — Geographic coordinates never constitute universal identity.
02-R07 — Oxfordshire, Puglia and other ecosystems provide Territorial Config and data; they do not modify the Core.
02-R08 — Locations must be reusable across Accommodation and future Builder modules.
02-R09 — Technical keys and relation keys remain stable independently of display language.
02-R10 — Map, geocoding and external geographic providers are not part of the Canonical Data Model.

Practical Result

An Accommodation does not need to duplicate the complete geographic hierarchy inside its own record. It connects to the appropriate Location and Address objects through defined relations.

When the same Builder is deployed from OXFORDSHIRE.world to Puglia.world, the Core remains unchanged. Location data and Territorial Config change; the Universal Builder does not need to be reconstructed.