# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-23T05:08:22Z", "synthesisSha256": "c1e936d8684cb70635b0a3916498213bad76e00b7d9ffee454b10e9b1b22c2cf", "providers": [ "Claude", "Grok" ] }, "metaModel": { "id": "WM-XCT-010", "registryId": "vr.wm-xct-010", "name": "Location Referencing / Address", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "mixin", "family": "World Models", "category": "Cross-cutting context", "industry": [ "Cross-industry" ], "domain": [ "XCT.LOC" ], "tags": [ "location", "referencing", "address", "xct.loc" ], "status": "research draft" }, "canonicalUrl": "https://ver.cy/models/wm-xct-010-location-referencing-address/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-xct-010", "model": { "registry_id": "vr.wm-xct-010", "model_id": "WM-XCT-010", "name": "Location Referencing / Address", "entry_kind": "mixin", "purpose": "Provide a format-neutral, reusable referencing fabric — addresses, thoroughfares, postal designations, geocodes, reference systems, gazetteer identifiers, points of interest and place names — that any subject model can mix in to state where something is, without absorbing the semantics of the thing located.", "scope_statement": "This model governs location references as first-class governed records with their own identity, authority, lifecycle and provenance, independent of the objects they designate. It covers the structure of an address and its components and locators (ISO 19160-1, INSPIRE Addresses), the authority and numbering rules under which addresses are assigned and retired, postal designation and template-driven rendering (ISO 19160-4 / UPU S42), coordinate positions with their geometry specification, method, accuracy and coordinate reference system and epoch (ISO 19111), non-coordinate code and grid references, spatial referencing by geographic identifiers and gazetteers (ISO 19112), points of interest and toponyms, and the matching, quality, provenance, access and interoperability concerns that make a reference trustworthy. It is deliberately storage- and interface-neutral: register rows, feature collections, Markdown records, graph triples and API responses are projections of the same semantics.", "in_scope": [ "Address records: identifiers, class/profile, components, locators and sub-address levels, aliases and rendered representations", "Addressing authority, jurisdiction, address reference systems (numbering schemes) and assignment/retirement acts", "Address lifecycle status, real-world validity period and record version lifespan, recorded separately", "Binding of an address to an addressable object in a sibling model, including basis and exclusivity", "Thoroughfare naming for addressing purposes, name decomposition, renaming and name continuity", "Postal descriptors, delivery point types, country templates and postal address rendering rules", "Geocodes: position geometry, geometry specification and method, default position, positional accuracy and precision", "Coordinate reference systems, dynamic CRS coordinate epochs, axis order and coordinate operations used by stored positions", "Spatial reference systems using geographic identifiers, location types, location instances and gazetteers", "Open code and grid references (e.g. Open Location Code) as derived location value objects", "Points of interest as referenceable named places, with category, operating status and existence confidence", "Toponyms with language, script, romanisation and official standardisation status", "Geocoding and address matching operations, match quality, ambiguity and interpolation", "Address data quality tests, anomaly status against the governing reference system, and validation evidence", "Source lineage, observation/ingestion time, licensing, sensitivity, suppression and crosswalk/conformance declarations" ], "out_of_scope": [ "The physical or legal objects addressed — buildings, premises, units, land parcels — including their geometry, construction and tenure", "Administrative unit and settlement hierarchies, boundaries and geometry; these are referenced as address components but defined by a sibling model", "Persons and organisations as addressees, recipients, occupiers or owners, and the addressee/organisation segments of a postal address", "Occupancy, tenancy, residence registration and mail forwarding", "Transport network topology, road segment geometry and linear referencing for asset management", "Mail and parcel logistics: items, routing execution, delivery scan events and track-and-trace", "Indoor navigable geometry and floor-plan models beyond the sub-address designators used for addressing", "Geodetic infrastructure operation: control networks, datum realisation and survey adjustment (referenced via a geodetic parameter registry, not defined here)", "Routing, isochrones and wayfinding algorithms that consume geocodes", "Data protection compliance programme design; ISO 19160-4 explicitly excludes data protection specification and this model records constraints rather than legal advice" ], "boundary_notes": [ { "neighbor": "Building & structure model (legacy U1) and premises/spatial unit model (legacy U2)", "distinction": "INSPIRE models Address with associations to building and parcel rather than embedding them; this model owns the address record and the binding act, while the host model owns the object, its geometry and its condition. A unit number is a locator here and a spatial unit there.", "source_refs": [ "SRC-005", "SRC-001" ] }, { "neighbor": "Land parcel / cadastre model (legacy P2)", "distinction": "An address may designate a parcel where no building stands; the cadastral parcel identifier, rights and boundaries stay in the cadastre model and are referenced, never copied, by the address record.", "source_refs": [ "SRC-005", "SRC-008" ] }, { "neighbor": "Administrative units, settlements and geographical names (INSPIRE Annex I themes 3 and 4)", "distinction": "AdminUnitName and AddressAreaName are address components that reference authoritative administrative units and named places; their boundaries, hierarchy and legal status belong to the administrative-unit model. This model retains only the toponym facets needed to reference and display a place.", "source_refs": [ "SRC-005", "SRC-007" ] }, { "neighbor": "Transport network model", "distinction": "INSPIRE ThoroughfareName carries a transportLink association; this model owns the official name, its decomposition and its addressing use, while centreline geometry, topology and network attributes belong to the transport model.", "source_refs": [ "SRC-005" ] }, { "neighbor": "Party model (person / organisation)", "distinction": "ISO 19160-4 structures a postal address into elements, constructs and segments including an addressee specification; this model owns only the location-bearing segments and delegates addressee and organisation identification to the party model.", "source_refs": [ "SRC-002" ] }, { "neighbor": "Geodetic parameter registry (external, e.g. an authority-coded CRS dataset)", "distinction": "ISO 19111 defines CRS, datum, dynamic CRS and coordinate epoch; this model references CRS definitions by authority code and version and never redefines datums or transformation parameters.", "source_refs": [ "SRC-004" ] }, { "neighbor": "Public mandate / authority model (legacy A12)", "distinction": "The registrar's legal power to assign and retire addresses is a mandate instrument owned by the mandate model; this model records the authority reference, jurisdiction extent and effective period as constraints on assignment acts.", "source_refs": [ "SRC-008" ] }, { "neighbor": "Emergency response / NG9-1-1 dispatch model", "distinction": "CLDXF-US and RFC 5139 define civic location exchange for emergency calls; this model supplies the civic location content and its precision, while call handling, dispatch and PSAP routing belong to the emergency model.", "source_refs": [ "SRC-009", "SRC-019" ] } ] }, "sources": [ { "id": "SRC-001", "title": "ISO 19160-1:2015 Addressing — Part 1: Conceptual model", "organization": "International Organization for Standardization (ISO/TC 211)", "url": "https://committee.iso.org/standard/61710.html", "version_or_date": "Edition 1, published 2015-12; status Published", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Defines the conceptual address model with lifecycle, metadata and address aliases in UML; states that a class conforming to 'Model - Lifecycle' has mandatory unique identifier and lifecycle attributes, and that the model exists to cross-map between address specifications rather than replace them." }, { "id": "SRC-002", "title": "ISO 19160-4:2023 Addressing — Part 4: International postal address components and template language", "organization": "International Organization for Standardization (ISO/TC 211)", "url": "https://committee.iso.org/standard/83470.html", "version_or_date": "Edition 2, published 2023-04; status Published", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Three-level component structure (elements, constructs, segments), sub-element mechanism, component codes, postal address rendering rules and a machine-processable template language; explicitly excludes data protection specification." }, { "id": "SRC-003", "title": "ISO 19112:2019 Geographic information — Spatial referencing by geographic identifiers", "organization": "International Organization for Standardization (ISO/TC 211)", "url": "https://committee.iso.org/es/sites/isoorg/contents/data/standard/07/07/70742.html", "version_or_date": "Edition 2, published 2019-02; confirmed 2024-06-11", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "General model for spatial referencing by geographic identifiers, components of such a spatial reference system, conceptual schema for a gazetteer, location type and location instance, and a mechanism for recording complementary coordinate references." }, { "id": "SRC-004", "title": "ISO 19111:2019 Geographic information — Referencing by coordinates", "organization": "International Organization for Standardization (ISO/TC 211)", "url": "https://committee.iso.org/standard/74039.html", "version_or_date": "Edition 3, published 2019-01; confirmed 2024, under revision", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Conceptual framework for coordinate reference systems and the minimum data to define them, dynamic CRS whose coordinate values change with time, parametric/temporal/compound systems, and coordinate transformation operations with descriptive metadata." }, { "id": "SRC-005", "title": "INSPIRE Addresses application schema (XML Schema, Addresses.xsd, version 4.0)", "organization": "European Commission / INSPIRE", "url": "https://inspire.ec.europa.eu/schemas/ad/4.0/Addresses.xsd", "version_or_date": "Application schema version 4.0", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Normative element declarations for Address (inspireId, alternativeIdentifier, position, status, validFrom, validTo, beginLifespanVersion, endLifespanVersion, locator, parcel, parentAddress, building, component), abstract AddressComponent and its subtypes AddressAreaName, AdminUnitName (name, level, adminUnit), PostalDescriptor (postName, postCode), ThoroughfareName (name, transportLink), plus AddressLocator (designator, name, level, withinScopeOf) and GeographicPosition (geometry, specification, method, default)." }, { "id": "SRC-006", "title": "INSPIRE Data Specification on Addresses – Technical Guidelines", "organization": "European Commission Joint Research Centre / INSPIRE Knowledge Base", "url": "https://knowledge-base.inspire.ec.europa.eu/publications/inspire-data-specification-addresses-technical-guidelines_en", "version_or_date": "Publication date 2024-07-31", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Current technical guidance publication for the Addresses spatial data theme; establishes the maintained status and publication date of the address data specification used as the European alignment target." }, { "id": "SRC-007", "title": "Commission Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC as regards interoperability of spatial data sets and services (consolidated text)", "organization": "European Union (EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02010R1089-20141231", "version_or_date": "Regulation of 2010-11-23; consolidated version of 2014-12-31", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Legally binding interoperability requirements including common types, coordinate reference systems, geographical grid systems, geographical names and administrative units — the statutory basis that makes address component referencing a legal obligation rather than a convention in the EU." }, { "id": "SRC-008", "title": "United States Thoroughfare, Landmark, and Postal Address Data Standard, FGDC-STD-016-2011, Part 2: Address Data Content", "organization": "Federal Geographic Data Committee (maintenance authority: U.S. Census Bureau)", "url": "https://www.fgdc.gov/standards/projects/address-data/AddressDataContentStandardPart2", "version_or_date": "FGDC-STD-016-2011, endorsed February 2011", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Four-part standard (content, classification, transfer, quality); Address Lifecycle Status with values potential, proposed, active and retired; Address Anomaly Status for an address not correct under the Address Reference System governing it; Address Authority among lineage attributes; landmark and postal delivery address classes, the latter having no definite relation to the recipient's location." }, { "id": "SRC-009", "title": "RFC 5139: Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5139.html", "version_or_date": "February 2008; Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Enumerated civic address types: country and A1–A6 subdivisions; RD, RDSEC, RDBR, RDSUBBR, PRM, POM road elements; HNO, HNS, STS, PRD, POD; LMK, LOC, FLR, NAM, PC; BLD, UNIT, ROOM, SEAT; PLC, PCN, POBOX, ADDCODE — an independent, machine-oriented decomposition to test the model's component coverage against." }, { "id": "SRC-010", "title": "RFC 7946: The GeoJSON Format", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc7946.html", "version_or_date": "August 2016; Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Mandates WGS 84 with decimal degrees and fixed longitude-then-latitude order, defines the seven geometry types and bbox ordering, advises against spurious precision (six decimal places is about 10 cm), and requires antimeridian-crossing geometry to be cut — the concrete encoding constraints a position projection must satisfy." }, { "id": "SRC-011", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339.html", "version_or_date": "July 2002; Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Internet date/time format with mandatory four-digit years and an always-present offset expressed as Z, as ±HH:MM, or as -00:00 for an unknown local offset; permits second value 60 for leap seconds. Governs every timestamp in this model." }, { "id": "SRC-012", "title": "Addressing Solutions — S42 international addressing standard and Universal POST*CODE DataBase", "organization": "Universal Postal Union (UPU)", "url": "https://www.upu.int/en/Postal-Solutions/Programmes-Services/Addressing-Solutions", "version_or_date": "S42 document dated 2020-02-26; POST*CODE DataBase release 2026.1 dated 2026-03-02", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "S42 Part A defines postal address components and formatting rule languages; Part B provides country-specific address templates. The POST*CODE DataBase covers all 192 member countries and is released as dated versions, evidencing that postal reference data is a serial, versioned artifact. UPU notes more than 200 address formats and at least 20 scripts in official use." }, { "id": "SRC-013", "title": "Publication 28 — Postal Addressing Standards", "organization": "United States Postal Service", "url": "https://pe.usps.com/text/pub28/welcome.htm", "version_or_date": "October 2024 (PSN 7610-03-000-3688)", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Delivery address line and last line structure, secondary unit designators, standardized street suffix and state abbreviations, ZIP+4, and coverage of rural routes, highway contract routes, general delivery, military and PO Box addresses — a concrete national rendering and standardisation profile." }, { "id": "SRC-014", "title": "Spatial Data on the Web Best Practices", "organization": "W3C and Open Geospatial Consortium (joint)", "url": "https://www.w3.org/TR/sdw-bp/", "version_or_date": "W3C Group Draft Note, 19 September 2023", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Best practices for persistent HTTP URIs for spatial things, choosing and declaring coordinate reference systems, describing relative position and using appropriate relation types, providing information on the changing nature of spatial things, exposing validation schemas online, including spatial metadata, describing positional accuracy, and interacting with spatial data responsibly." }, { "id": "SRC-015", "title": "Overture Maps Foundation — Addresses theme schema reference (address)", "organization": "Overture Maps Foundation", "url": "https://docs.overturemaps.org/schema/reference/addresses/address/", "version_or_date": "Schema version 1; documentation updated 2026-07-24", "source_type": "schema", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "A working global address schema: id linked to the Global Entity Reference System, point geometry, ISO 3166-1 alpha-2 country, postcode, street, number (may be non-numeric, e.g. 74B), unit, address_levels (1–5 sub-country levels in descending generality), postal_city distinct from the actual locality, per-feature sources and version." }, { "id": "SRC-016", "title": "Overture Maps Foundation — Places theme schema reference (place)", "organization": "Overture Maps Foundation", "url": "https://docs.overturemaps.org/schema/reference/places/place/", "version_or_date": "Schema version 1; documentation updated 2026-08-12", "source_type": "schema", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "POI schema with GERS id, point geometry, names, multi-level categories including a basic-level category, existence confidence 0–1 (zero paired with permanent closure), operating_status distinct from opening hours, websites/socials/emails/phones, brand, addresses and per-property sources with confidence and timestamps." }, { "id": "SRC-017", "title": "Open Location Code Specification", "organization": "Google (open-location-code project)", "url": "https://raw.githubusercontent.com/google/open-location-code/main/Documentation/Specification/specification.md", "version_or_date": "main branch as retrieved 2026-08-23", "source_type": "standard", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "20-symbol alphabet chosen to reduce writing errors, '0' as padding and '+' as format separator inserted after eight digits, code lengths 2–15 with only even lengths below 10, precision from about 2226 km at two digits to about 4x14 mm at fifteen, full versus short codes with recoverNearest reference recovery, and the rule that codes including padding must not be shortened." }, { "id": "SRC-018", "title": "United Nations Group of Experts on Geographical Names (UNGEGN)", "organization": "United Nations Statistics Division", "url": "https://unstats.un.org/unsd/ungegn/", "version_or_date": "Programme page as retrieved 2026-08-23; sessions 2025-04-28/2025-05-02 and 2027-04-26/2027-04-30", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Mandate for national and international standardization of geographical names, support for national names authorities, multilingual and culturally informed naming practices, and authoritative geographical names information for administration, emergency response, cultural heritage and data integration." }, { "id": "SRC-019", "title": "NENA Next Generation 9-1-1 United States Civic Location Data Exchange Format (CLDXF-US) Standard, NENA-STA-004.2-2024", "organization": "National Emergency Number Association (NENA)", "url": "https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-STA-004.2-2024_CLDXF_20.pdf", "version_or_date": "NENA-STA-004.2-2024", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Defines detailed data elements for United States civic location exchange and the US profile of IETF PIDF-LO; companion NENA-REF-007.1-2024 documents the crosswalk between FGDC and CLDXF-US elements — direct evidence that address models require explicit, maintained crosswalks rather than assumed equivalence." }, { "id": "SRC-020", "title": "ISO 19160-1:2015 Addressing — Part 1: Conceptual model", "organization": "ISO/TC 211", "url": "https://www.iso.org/standard/61710.html", "version_or_date": "2015-12, confirmed 2026-07-20", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Conceptual address model, lifecycle, aliases, metadata and cross-map hub role." }, { "id": "SRC-021", "title": "ISO 19160-2:2023 Addressing — Part 2: Assigning and maintaining addresses for objects in the physical world", "organization": "ISO/TC 211", "url": "https://www.iso.org/standard/81674.html", "version_or_date": "2023-11", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Assignment, maintenance, reassignment, retirement, mandate holders and signage process." }, { "id": "SRC-022", "title": "ISO 19160-3:2020 Addressing — Part 3: Address data quality", "organization": "ISO/TC 211", "url": "https://www.iso.org/standard/71247.html", "version_or_date": "2020-02, confirmed 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Address data quality elements, measures and reporting as a profile of ISO 19157." }, { "id": "SRC-023", "title": "ISO 19160-4:2023 Addressing — Part 4: International postal address components and template language", "organization": "ISO/TC 211 with Universal Postal Union S42 Version 8", "url": "https://www.iso.org/standard/83470.html", "version_or_date": "2023-04", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Postal segments, constructs, elements, country templates and rendering rules." }, { "id": "SRC-024", "title": "ISO 19112:2019 Geographic information — Spatial referencing by geographic identifiers", "organization": "ISO/TC 211", "url": "https://www.iso.org/standard/70742.html", "version_or_date": "2019-02, confirmed 2024-06-11", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Gazetteers, location instances and spatial referencing by geographic identifiers." }, { "id": "SRC-025", "title": "ISO 19111:2019 Geographic information — Referencing by coordinates", "organization": "ISO/TC 211", "url": "https://www.iso.org/standard/74039.html", "version_or_date": "2019-01, confirmed 2024, Amd 1:2021, Amd 2:2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Coordinate reference systems, dynamic CRS, epochs and coordinate operations." }, { "id": "SRC-026", "title": "United States Thoroughfare, Landmark, and Postal Address Data Standard FGDC-STD-016-2011", "organization": "Federal Geographic Data Committee, maintained by U.S. Census Bureau", "url": "https://www.fgdc.gov/standards/projects/address-data", "version_or_date": "endorsed 2011-02", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "US thoroughfare, landmark and postal address content, address reference system and linear reference locations." }, { "id": "SRC-027", "title": "SEMIC Core Location Vocabulary 2.1.0", "organization": "European Commission SEMIC", "url": "https://semiceu.github.io/Core-Location-Vocabulary/releases/2.1.0/", "version_or_date": "SEMIC Recommendation 2024-05-06", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Core Location address components, geometry encodings, location definition and geographic names." }, { "id": "SRC-028", "title": "RFC 5870 A Uniform Resource Identifier for Geographic Locations (geo URI)", "organization": "Internet Engineering Task Force", "url": "https://www.rfc-editor.org/rfc/rfc5870", "version_or_date": "2010-06", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Geo URI point encoding, WGS-84 default, uncertainty and location privacy considerations." }, { "id": "SRC-029", "title": "Open Location Code / Plus Codes specification and library", "organization": "Google Open Location Code project", "url": "https://github.com/google/open-location-code", "version_or_date": "living specification; repository accessed 2026-08-23", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Plus Codes as open area-based grid identifiers, offline encoding, shortening and recovery." }, { "id": "SRC-030", "title": "United Nations Group of Experts on Geographical Names mandate", "organization": "United Nations Statistics Division / ECOSOC", "url": "https://unstats.un.org/unsd/ungegn/mandate/", "version_or_date": "mandate through ECOSOC resolution 2018/2 and UNCSGN programme", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Mandate for national standardisation of geographical names and single romanisation systems." }, { "id": "SRC-031", "title": "Commission Regulation (EU) No 1089/2010 as amended, Annex theme Addresses", "organization": "European Commission / EUR-Lex", "url": "https://eur-lex.europa.eu/eli/reg/2010/1089/2023-11-19/eng", "version_or_date": "consolidated 2023-11-19", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "INSPIRE Addresses theme requirements including unique identifier, country component and lifespan versioning." }, { "id": "SRC-032", "title": "ISA Programme Location Core Vocabulary (locn) namespace document", "organization": "EU ISA Programme / W3C Locations and Addresses Community Group", "url": "https://www.w3.org/ns/locn", "version_or_date": "2015-03-23 second version in w3.org/ns space", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "locn namespace properties for address components, geographic names, endonym/exonym forms and geometry encodings." }, { "id": "SRC-033", "title": "RFC 5139 Revised Civic Location Format for PIDF-LO", "organization": "Internet Engineering Task Force", "url": "https://www.iana.org/go/rfc5139", "version_or_date": "2008-02", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Civic location format with road hierarchy and indoor locator elements for PIDF-LO." } ], "structure": { "bundles": [ { "id": "address-record", "name": "Address record and structure", "description": "What an address is as a governed record: its identifier, the specification and class it instantiates, the components that scope it, the locators that pinpoint it, and its aliases and rendered representations.", "rationale": "ISO 19160-1 treats the address as a modelled class with mandatory identity, lifecycle and metadata, and exists to allow cross-mapping between address specifications; INSPIRE realises that as a concrete schema with Address, AddressComponent subtypes and AddressLocator. Structure must therefore be modelled before any use of an address.", "source_refs": [ "SRC-001", "SRC-005", "SRC-008" ], "layers": [ { "id": "address-identity", "name": "Address identity and classification", "description": "Identifiers that make an address referable and de-duplicable, and the class and specification profile that determine which structure is legal for it.", "source_refs": [ "SRC-001", "SRC-005", "SRC-008", "SRC-014" ], "findings": [ { "id": "address-identifier-and-uniqueness", "name": "Address identifier and uniqueness scope", "description": "The identifier or identifiers that designate the address record itself, distinct from the identifier of the object addressed or of any position, together with the scope in which uniqueness holds and the change events that force a new identifier.", "source_refs": [ "SRC-001", "SRC-005", "SRC-008", "SRC-014", "SRC-015" ], "questions": [ { "id": "aiu-q1", "text": "Which authoritative master-system identifier designates this address, and which register issued it?", "kind": "identity", "answer_data": [ "Issuing register or authority reference", "Identifier value", "Identifier scheme or namespace" ] }, { "id": "aiu-q2", "text": "Does the address carry a governed global identifier or resolvable IRI in addition to the local register key, and is it persistent?", "kind": "identity", "answer_data": [ "Global identifier or HTTP IRI", "Persistence commitment and its custodian", "Resolution endpoint or projection reference" ] }, { "id": "aiu-q3", "text": "Which alternative, legacy or third-party identifiers are recorded, and to which system is each scoped?", "kind": "provenance", "answer_data": [ "Alternative identifier value", "Owning system reference", "Trust or precedence rank" ] }, { "id": "aiu-q4", "text": "Under which changes does the identifier stay stable, and which change compels minting a new one?", "kind": "lifecycle", "answer_data": [ "Stability rule statement", "Enumerated identifier-breaking change kinds", "Supersession link to prior identifier" ] }, { "id": "aiu-q5", "text": "Within what scope is uniqueness enforced — single register, jurisdiction, country or globally?", "kind": "constraint", "answer_data": [ "Uniqueness scope declaration", "Duplicate detection rule", "Collision resolution procedure" ] } ], "data_elements": [ { "id": "address-id", "name": "Address identifier", "description": "Primary identifier of the address record, issued by the addressing authority's register; mandatory wherever the record claims lifecycle conformance.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-005", "SRC-008" ] }, { "id": "address-id-scheme", "name": "Identifier scheme", "description": "Namespace or scheme under which the identifier is issued, allowing two identifiers from different registers to be told apart.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "address-iri", "name": "Governed global identifier", "description": "Stable HTTP URI or other governed global identifier for the address as a spatial thing.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-015" ] }, { "id": "alternative-identifier", "name": "Alternative identifier", "description": "External or legacy identifier for the same address, each qualified by its owning system.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "identifier-stability-rule", "name": "Identifier stability rule", "description": "Declared rule stating which changes preserve and which changes break identifier continuity.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-014" ] } ], "artifacts": [ { "id": "address-register-entry", "name": "Address register entry", "description": "The authoritative record for one address held by the issuing register, carrying the identifier, components, locators, status and position; the unit that a resolvable identifier dereferences to.", "media_or_form": [ "register record", "dataset feature", "resolvable identifier document", "tabular extract row" ], "serial": false, "identity_strategy": "Register key issued by the addressing authority, optionally expressed as a persistent HTTP URI when the register publishes resolvable identifiers.", "source_refs": [ "SRC-005", "SRC-008", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "address-classification-and-profile", "name": "Address class and governing specification profile", "description": "The class of address the record instantiates and the national or community address specification that fixes which components are legal, mandatory or forbidden for that class.", "source_refs": [ "SRC-001", "SRC-008", "SRC-009" ], "questions": [ { "id": "acp-q1", "text": "Which address class does this record instantiate — numbered thoroughfare, landmark, postal delivery, or another declared class?", "kind": "classification", "answer_data": [ "Address class code", "Class definition source", "Class-specific mandatory component set" ] }, { "id": "acp-q2", "text": "Which address specification or class profile governs this record, and at which version?", "kind": "authority", "answer_data": [ "Specification reference", "Specification version identifier", "Issuing community or authority" ] }, { "id": "acp-q3", "text": "Does the record designate a location, a point of postal delivery, or both, and how is that role encoded?", "kind": "definition", "answer_data": [ "Role code (location, delivery, dual)", "Justification or basis", "Consumers permitted to rely on each role" ] }, { "id": "acp-q4", "text": "How does this class map to the corresponding classes of each standard the register claims alignment with?", "kind": "interoperability", "answer_data": [ "Target standard and class", "Mapping cardinality", "Unmapped residue note" ] } ], "data_elements": [ { "id": "address-class", "name": "Address class", "description": "Classification of the address into a declared class such as numbered thoroughfare, landmark or postal delivery address.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "address-specification-ref", "name": "Governing address specification", "description": "Reference to the address specification or class profile that constrains the record's structure.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "address-role", "name": "Address role", "description": "Whether the record designates a physical location, a delivery point, or both; postal delivery addresses may bear no definite relation to the recipient's location.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "class-profile-version", "name": "Profile version", "description": "Version identifier of the governing specification at the time the record was validated.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "address-specification-profile", "name": "Address specification / class profile", "description": "The document or machine-readable profile that declares the address classes recognised in a jurisdiction and the components permitted, required or prohibited for each.", "media_or_form": [ "specification document", "machine-readable profile", "constraint table" ], "serial": true, "identity_strategy": "Specification identifier plus semantic version; each published edition carries an RFC 3339 issue timestamp.", "source_refs": [ "SRC-001", "SRC-008" ] } ], "inline_only_rationale": null } ] }, { "id": "address-composition", "name": "Address composition and locators", "description": "The internal parts of an address: scoping components in their hierarchy, locator designators and sub-address levels, and alias or rendered representations.", "source_refs": [ "SRC-002", "SRC-005", "SRC-009", "SRC-013", "SRC-015" ], "findings": [ { "id": "address-components-and-hierarchy", "name": "Address components and their hierarchy", "description": "The administrative, address-area, postal and thoroughfare components that scope an address, the level at which each sits, and whether each is a reference to an authoritative feature or free text.", "source_refs": [ "SRC-002", "SRC-005", "SRC-009", "SRC-015" ], "questions": [ { "id": "ach-q1", "text": "Which components scope this address, and what level does each occupy in the hierarchy?", "kind": "composition", "answer_data": [ "Component reference or name", "Component type (admin unit, address area, postal descriptor, thoroughfare)", "Hierarchy level index" ] }, { "id": "ach-q2", "text": "Which components are mandatory, conditional or prohibited for this class in this country?", "kind": "constraint", "answer_data": [ "Component obligation code", "Governing condition expression", "Country or territory scope" ] }, { "id": "ach-q3", "text": "Does each component reference an authoritative external feature, or repeat a name as unlinked text?", "kind": "relationship", "answer_data": [ "Referenced feature identifier", "Owning sibling model", "Reference-versus-text flag" ] }, { "id": "ach-q4", "text": "How are sub-country administrative levels ordered and labelled, and how does that ordering survive exchange?", "kind": "interoperability", "answer_data": [ "Level ordering convention", "Level labels per country", "Target-format level mapping" ] } ], "data_elements": [ { "id": "component-ref", "name": "Address component", "description": "A component that defines the scope of the address: administrative unit name, address area name, postal descriptor or thoroughfare name.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "component-type", "name": "Component type", "description": "Which kind of address component the entry is, drawn from the governing specification's component vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-002" ] }, { "id": "admin-level-index", "name": "Administrative level index", "description": "Ordinal position of an administrative component in the hierarchy, descending in generality.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-015" ] }, { "id": "component-obligation", "name": "Component obligation", "description": "Whether the component is mandatory, conditional or prohibited for the address class in the applicable territory.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Components are structural parts of the address record: they are carried either inline as names or as references to features owned by sibling models, and produce no separate document. The document that fixes their obligations is the address specification profile already held in the address-classification finding." }, { "id": "locator-designators-and-subaddressing", "name": "Locator designators and sub-addressing", "description": "The human-readable designators and names that distinguish the addressable object within its component scope, including house numbers with non-numeric parts and the building, floor, unit, room and seat levels beneath them.", "source_refs": [ "SRC-005", "SRC-009", "SRC-013", "SRC-015" ], "questions": [ { "id": "lds-q1", "text": "Which locator designators identify the object within its scope, and at which locator level does each apply?", "kind": "composition", "answer_data": [ "Designator value", "Designator type code", "Locator level", "Component the locator is within the scope of" ] }, { "id": "lds-q2", "text": "Is the house number a plain ordinal, a range, a hyphenated compound or a non-numeric token, and how is it normalised for sorting and matching?", "kind": "identity", "answer_data": [ "Raw designator token", "Parsed numeric part and suffix", "Normalisation and sort key rule" ] }, { "id": "lds-q3", "text": "Which sub-address levels are addressable in their own right, and which are descriptive only?", "kind": "constraint", "answer_data": [ "Recognised sub-address level list", "Addressable-versus-descriptive flag per level", "Authority that decides" ] }, { "id": "lds-q4", "text": "When a sub-address exists, does it reference a parent address record or stand alone, and what breaks if the parent is retired?", "kind": "relationship", "answer_data": [ "Parent address reference", "Standalone-versus-derived flag", "Cascade rule on parent retirement" ] } ], "data_elements": [ { "id": "locator-designator", "name": "Locator designator", "description": "Numbers, characters or codes that distinguish the addressable object within its scope, such as a house number and its suffix.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005", "SRC-009", "SRC-015" ] }, { "id": "locator-type", "name": "Locator designator type", "description": "Type of the designator, for example address number, building name, unit designator, floor or room.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-009" ] }, { "id": "locator-level", "name": "Locator level", "description": "Level at which the locator applies — site, access, unit or postal delivery point.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "locator-name", "name": "Locator name", "description": "Proper name identifying the addressable object, such as a building or estate name, used alongside or instead of a number.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "parent-address-ref", "name": "Parent address", "description": "Reference to the parent address that a sub-address is derived from.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "secondary-unit-designator-list", "name": "Sub-address designator vocabulary", "description": "The controlled list of secondary unit and sub-address designators (apartment, suite, floor, building, room, seat) with approved abbreviations for a territory.", "media_or_form": [ "controlled vocabulary", "abbreviation table", "code list" ], "serial": true, "identity_strategy": "Publisher identifier plus publication edition; USPS Publication 28 dated October 2024 is one such edition.", "source_refs": [ "SRC-013", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "address-alias-and-representation", "name": "Address aliases and rendered representations", "description": "Alias relations between address records and the language-, script- and purpose-specific rendered forms of the same address, including which form is authoritative for which use.", "source_refs": [ "SRC-001", "SRC-002", "SRC-012", "SRC-015" ], "questions": [ { "id": "aar-q1", "text": "Which address records are aliases of which primary address, and what is the alias relation type?", "kind": "relationship", "answer_data": [ "Primary address reference", "Alias relation type", "Period during which the alias is honoured" ] }, { "id": "aar-q2", "text": "Which rendered or transliterated representations exist, and in which language and script is each written?", "kind": "interoperability", "answer_data": [ "Rendered address text", "Language tag", "Script code", "Transliteration or romanisation system" ] }, { "id": "aar-q3", "text": "Which representation is authoritative for legal service of documents, and which for mail delivery?", "kind": "authority", "answer_data": [ "Representation reference", "Authoritative purpose", "Deciding authority" ] }, { "id": "aar-q4", "text": "May an alias be used as a matching key, and with what confidence penalty?", "kind": "validation", "answer_data": [ "Match-eligibility flag", "Confidence adjustment", "Audit requirement when an alias resolves a match" ] } ], "data_elements": [ { "id": "alias-of-ref", "name": "Alias of", "description": "Reference from an alias record to the primary address it stands for.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "alias-type", "name": "Alias type", "description": "Nature of the alias: vanity address, historic form, postal variant, transliteration or common usage.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "representation-text", "name": "Rendered representation", "description": "A complete rendered form of the address as a string or ordered lines, qualified by language and script.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-012" ] }, { "id": "representation-language", "name": "Representation language and script", "description": "Language tag and script of the rendered form; the UPU notes at least twenty scripts in official addressing use.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "authoritative-purpose", "name": "Authoritative purpose", "description": "The purpose for which a given representation is the authoritative one, such as legal service, emergency dispatch or delivery.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Aliases and rendered representations are relational and derived data held inside the address register: an alias is a typed link between two register entries, and a rendering is produced on demand by applying a template. The template itself is an artifact and is held in the postal rendering finding rather than duplicated here." } ] } ] }, { "id": "assignment-and-lifecycle", "name": "Assignment authority, lifecycle and object binding", "description": "Who may create, change and retire an address, under which numbering rules, through which lifecycle states and temporal versions, and to which object in a sibling model the address is bound.", "rationale": "FGDC-STD-016-2011 places Address Authority among lineage attributes and defines Address Lifecycle Status and Address Anomaly Status relative to a governing Address Reference System; ISO 19160-1 makes lifecycle attributes mandatory for lifecycle-conformant classes; INSPIRE separates real-world validity from record version lifespan. Authority, rules, states and binding are therefore not optional metadata but the core of a trustworthy reference.", "source_refs": [ "SRC-001", "SRC-005", "SRC-008" ], "layers": [ { "id": "addressing-authority", "name": "Addressing authority and numbering rules", "description": "The mandated body, its jurisdiction, and the address reference system whose numbering scheme determines whether a candidate address is well formed.", "source_refs": [ "SRC-008", "SRC-018" ], "findings": [ { "id": "addressing-authority-and-jurisdiction", "name": "Addressing authority, mandate and jurisdiction", "description": "The body legally empowered to assign, alter and retire addresses in a territory, the instrument granting that power, the extent within which it applies, and how non-authoritative address creation is handled.", "source_refs": [ "SRC-008", "SRC-018", "SRC-007" ], "questions": [ { "id": "aaj-q1", "text": "Which body holds the mandate to assign, alter and retire addresses here, and under what legal instrument?", "kind": "authority", "answer_data": [ "Authority identifier", "Mandate instrument reference", "Mandate effective period" ] }, { "id": "aaj-q2", "text": "Who stewards the address record, as distinct from whoever owns the object addressed?", "kind": "ownership", "answer_data": [ "Steward role and party reference", "Stewardship scope", "Escalation contact" ] }, { "id": "aaj-q3", "text": "What is the geographic extent of the authority's jurisdiction, and how are overlaps or gaps at its boundary resolved?", "kind": "spatial", "answer_data": [ "Jurisdiction extent geometry or identifier", "Overlap precedence rule", "Gap escalation procedure" ] }, { "id": "aaj-q4", "text": "What status is given to an address created by a developer, occupier or crowd source rather than the authority?", "kind": "exception", "answer_data": [ "Non-authoritative origin flag", "Adoption or rejection procedure", "Interim usability constraints" ] } ], "data_elements": [ { "id": "authority-ref", "name": "Address authority", "description": "The address authority responsible for the address, recorded as a lineage attribute of the record.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "mandate-instrument-ref", "name": "Mandate instrument", "description": "Reference to the statute, by-law or delegation that grants addressing power.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-007" ] }, { "id": "jurisdiction-extent", "name": "Jurisdiction extent", "description": "Territory within which the authority may assign addresses, as a geometry or an administrative unit reference.", "value_kind": "geometry", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "authority-effective-period", "name": "Authority effective period", "description": "Period during which the mandate was in force, so historic records can be judged against the authority of their time.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "addressing-mandate-instrument", "name": "Addressing mandate instrument", "description": "The statute, ordinance, by-law or delegation document that designates an addressing authority and delimits its jurisdiction and powers.", "media_or_form": [ "legal instrument", "ordinance", "delegation letter", "published notice" ], "serial": true, "identity_strategy": "Official instrument number issued by the enacting body, with commencement date recorded as an RFC 3339 timestamp; a date alone is never the identifier.", "source_refs": [ "SRC-008", "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "address-reference-system-rules", "name": "Address reference system and numbering rules", "description": "The numbering scheme governing an area — axis origin and direction, block ranges, intervals, parity and reservation rules — and the tests that decide whether a candidate address conforms to it.", "source_refs": [ "SRC-008", "SRC-003" ], "questions": [ { "id": "arsr-q1", "text": "Which numbering scheme governs this address, including axis origin, direction, interval, parity and block ranges?", "kind": "constraint", "answer_data": [ "Reference system identifier", "Axis and origin definition", "Interval and parity rules", "Block range table" ] }, { "id": "arsr-q2", "text": "What test determines that a candidate number is valid within the governing reference system?", "kind": "validation", "answer_data": [ "Validation rule expression", "Pass or fail outcome", "Anomaly status when the test fails" ] }, { "id": "arsr-q3", "text": "How are numbers reserved, skipped or reissued when a parcel is subdivided or consolidated?", "kind": "process", "answer_data": [ "Reservation policy", "Gap and infill rule", "Reissue cooling-off period" ] }, { "id": "arsr-q4", "text": "Where two schemes overlap the same ground, which one governs, and who decides?", "kind": "exception", "answer_data": [ "Precedence rule", "Deciding authority", "Record of the resolution" ] } ], "data_elements": [ { "id": "reference-system-id", "name": "Address reference system identifier", "description": "Identifier of the numbering scheme that governs addresses in an area.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "numbering-axis", "name": "Numbering axis and origin", "description": "Description of the axis, origin and direction along which numbers increase.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "number-range", "name": "Permitted number range", "description": "Low and high bounds permitted for a block or segment under the scheme.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "parity-rule", "name": "Parity rule", "description": "Rule assigning odd and even numbers to sides of a thoroughfare.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "address-reference-system-definition", "name": "Address reference system definition", "description": "The published definition of a numbering scheme: grid or axis description, range tables, parity conventions and the map or geometry delimiting where the scheme applies.", "media_or_form": [ "ordinance or scheme document", "range table", "reference grid geometry" ], "serial": true, "identity_strategy": "Reference system identifier assigned by the addressing authority, versioned on each amendment with an RFC 3339 effective timestamp.", "source_refs": [ "SRC-008" ] } ], "inline_only_rationale": null } ] }, { "id": "address-lifecycle", "name": "Lifecycle state and temporal versioning", "description": "Lifecycle status and its permitted transitions, and the separate axes of real-world validity and record version lifespan.", "source_refs": [ "SRC-001", "SRC-005", "SRC-008", "SRC-011" ], "findings": [ { "id": "address-lifecycle-status", "name": "Lifecycle status and permitted transitions", "description": "The current lifecycle status of an address, the transition and evidence that produced it, the distinction between official status and lifecycle status, and how long a retired address remains resolvable.", "source_refs": [ "SRC-001", "SRC-005", "SRC-008" ], "questions": [ { "id": "als-q1", "text": "What is the current lifecycle status of the address, and which transition produced it?", "kind": "state", "answer_data": [ "Lifecycle status value", "Transition event reference", "Transition timestamp" ] }, { "id": "als-q2", "text": "Which transitions are permitted, who may authorise each, and what evidence must accompany them?", "kind": "lifecycle", "answer_data": [ "Permitted transition matrix", "Authorising role", "Required evidence type" ] }, { "id": "als-q3", "text": "Is a retired address retained for historical resolution, and for how long does it stay resolvable?", "kind": "retention", "answer_data": [ "Retention decision", "Resolvable-after-retirement period", "Tombstone representation" ] }, { "id": "als-q4", "text": "May an address be reserved or proposed before the object exists, and what obligations follow from that state?", "kind": "process", "answer_data": [ "Pre-existence status value", "Obligations and expiry of the reservation", "Consumers permitted to use a pre-active address" ] }, { "id": "als-q5", "text": "How does official status differ from lifecycle status in this register, and can a record be active but unofficial?", "kind": "classification", "answer_data": [ "Official status value", "Lifecycle status value", "Combination legality matrix" ] } ], "data_elements": [ { "id": "lifecycle-status", "name": "Address lifecycle status", "description": "Lifecycle status of the address, typically potential, proposed, active or retired.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-005" ] }, { "id": "official-status", "name": "Official status", "description": "Whether the address is officially recognised by the authority, independent of whether it is in current use.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "status-changed-at", "name": "Status change time", "description": "Time at which the current status took effect, as an RFC 3339 timestamp with an explicit offset or Z.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-008" ] }, { "id": "superseded-by-ref", "name": "Superseding address", "description": "Reference to the address that replaces a retired record, enabling historic resolution to a current one.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "address-assignment-decision", "name": "Address assignment or retirement decision record", "description": "The authority's decision that creates, changes or retires an address, recording the basis, the affected object, the resulting status and the approving officer.", "media_or_form": [ "decision record", "notice of assignment", "case file entry" ], "serial": true, "identity_strategy": "Decision or case number issued by the addressing authority; decision timestamps are RFC 3339 and never substitute for the number.", "source_refs": [ "SRC-008", "SRC-001" ] } ], "inline_only_rationale": null }, { "id": "temporal-validity-and-versioning", "name": "Real-world validity versus record version lifespan", "description": "The two distinct time axes an address carries — the period the address is valid in the real world, and the period a particular version of the record was current in the register — together with observation and ingestion times and the separation of corrections from real change.", "source_refs": [ "SRC-005", "SRC-011", "SRC-014", "SRC-016" ], "questions": [ { "id": "tvv-q1", "text": "When did the address become valid in the real world, and when did it cease to be valid?", "kind": "temporal", "answer_data": [ "Valid-from timestamp", "Valid-to timestamp", "Basis for each boundary" ] }, { "id": "tvv-q2", "text": "When did this version of the record begin and end in the register, independent of real-world validity?", "kind": "temporal", "answer_data": [ "Version begin timestamp", "Version end timestamp", "Version identifier" ] }, { "id": "tvv-q3", "text": "Are all recorded times expressed per RFC 3339 with seconds and an explicit offset or Z, and how is an unknown local offset represented?", "kind": "constraint", "answer_data": [ "Timestamp format conformance statement", "Offset handling rule including -00:00 for unknown offset", "Validation test result" ] }, { "id": "tvv-q4", "text": "How is a correction to a past record distinguished from a real-world change, and does a correction alter the validity period?", "kind": "provenance", "answer_data": [ "Change kind code", "Corrected attribute list", "Effect on validity versus version period" ] }, { "id": "tvv-q5", "text": "What is the observation or ingestion time of this version, and does it differ from the event time it reports?", "kind": "provenance", "answer_data": [ "Observed or ingested timestamp", "Event timestamp", "Lag and its cause" ] } ], "data_elements": [ { "id": "valid-from", "name": "Valid from", "description": "Time when the address started, or is planned to start, being used in the real world.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-011" ] }, { "id": "valid-to", "name": "Valid to", "description": "Time when the address ceased, or is expected to cease, being used in the real world.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "version-begin", "name": "Version begin", "description": "Time at which this version of the record was inserted into the register.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "version-end", "name": "Version end", "description": "Time at which this version of the record was superseded or removed from the register.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "observed-at", "name": "Observation or ingestion time", "description": "Time at which the asserting party observed or ingested the fact, kept separate from the event time it describes.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-011" ] }, { "id": "change-kind", "name": "Change kind", "description": "Whether a new version records a real-world change, a correction of an error, or an enrichment from a new source.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [ { "id": "address-register-change-log", "name": "Address register change log", "description": "The ordered history of record versions for an address or register, from which any past state can be reconstructed and corrections told apart from real-world change.", "media_or_form": [ "change log", "version history", "append-only event stream", "periodic delta release" ], "serial": true, "identity_strategy": "Register identifier plus monotonically increasing version or sequence number; each entry timestamped in RFC 3339 with an explicit offset or Z.", "source_refs": [ "SRC-005", "SRC-011", "SRC-014" ] } ], "inline_only_rationale": null } ] }, { "id": "addressable-object-binding", "name": "Binding to the addressable object", "description": "How an address attaches, as a mixin, to an object owned by a sibling model, and what governs that attachment.", "source_refs": [ "SRC-001", "SRC-005", "SRC-008" ], "findings": [ { "id": "finding-addressable-object-binding", "name": "Address-to-object binding and its basis", "description": "The act that binds an address to an addressable object in another model, its evidential basis, its cardinality in both directions, its exclusivity per purpose, and what happens when the object is demolished, merged or subdivided.", "source_refs": [ "SRC-001", "SRC-005", "SRC-008" ], "questions": [ { "id": "aob-q1", "text": "Which addressable object does this address designate, in which sibling model, and by which identifier?", "kind": "relationship", "answer_data": [ "Object identifier", "Owning model reference", "Object kind (building, parcel, unit, other)" ] }, { "id": "aob-q2", "text": "Can one object hold several addresses and one address designate several objects, and which combinations are legal here?", "kind": "composition", "answer_data": [ "Cardinality rule in each direction", "Legal multiplicity exceptions", "Primary-address selection rule" ] }, { "id": "aob-q3", "text": "What basis justified the binding — building permit, survey, occupancy certificate or field observation?", "kind": "evidence", "answer_data": [ "Basis code", "Supporting document reference", "Recording officer" ] }, { "id": "aob-q4", "text": "What happens to the address when the object is demolished, merged or subdivided?", "kind": "lifecycle", "answer_data": [ "Cascade policy per object event", "Resulting address status", "Successor address links" ] }, { "id": "aob-q5", "text": "Is the binding exclusive for legal service, emergency dispatch and delivery alike, or may these differ?", "kind": "constraint", "answer_data": [ "Purpose-specific binding", "Conflict resolution rule", "Authoritative source per purpose" ] } ], "data_elements": [ { "id": "addressable-object-ref", "name": "Addressable object", "description": "Reference to the object the address designates, held in a sibling model such as building, parcel or spatial unit.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005", "SRC-001" ] }, { "id": "object-model-ref", "name": "Owning model", "description": "Identifier of the sibling model that defines the referenced object, so the reference can be resolved without guessing.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "binding-basis", "name": "Binding basis", "description": "Evidential basis on which the address was bound to the object.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "binding-effective-from", "name": "Binding effective from", "description": "RFC 3339 timestamp from which the binding takes effect.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "binding-purpose", "name": "Binding purpose", "description": "The purpose for which this binding is authoritative, such as legal service, emergency response or delivery.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-019" ] } ], "artifacts": [ { "id": "address-binding-record", "name": "Address binding record", "description": "The record of the act that attaches an address to an addressable object, carrying object reference, basis, purpose and effective period; the concrete form the mixin takes when applied to a host subject.", "media_or_form": [ "binding record", "association table row", "act record", "link assertion" ], "serial": false, "identity_strategy": "Composite of address identifier and object identifier plus effective-from timestamp, or a register-issued binding key where the authority issues one.", "source_refs": [ "SRC-005", "SRC-008" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "thoroughfare-and-postal", "name": "Thoroughfares and postal designation", "description": "Named ways used in addressing and their continuity across renaming, and the postal descriptors, delivery point types and templates that turn a stored address into a deliverable one.", "rationale": "INSPIRE models ThoroughfareName as an address component associated with a transport link, RFC 5139 decomposes road elements into named parts, and ISO 19160-4 with UPU S42 governs postal components and rendering templates. Naming and postal rendering are distinct concerns from address identity and are governed by different bodies.", "source_refs": [ "SRC-002", "SRC-005", "SRC-009", "SRC-012", "SRC-013" ], "layers": [ { "id": "thoroughfare-naming", "name": "Thoroughfare identity, naming and continuity", "description": "Official names of streets, roads and waterways used for addressing, their decomposition into parts, and their behaviour under renaming, splitting and merging.", "source_refs": [ "SRC-005", "SRC-009", "SRC-013", "SRC-018" ], "findings": [ { "id": "thoroughfare-identity-and-naming", "name": "Thoroughfare identity and name decomposition", "description": "The identifier of a thoroughfare independent of its current name, the decomposition of a complete street name into directional, type, modifier and base parts, its addressing-relevant extent, and the kinds of way admissible for addressing.", "source_refs": [ "SRC-005", "SRC-009", "SRC-013" ], "questions": [ { "id": "tin-q1", "text": "Which identifier designates the thoroughfare independently of whatever name it currently bears?", "kind": "identity", "answer_data": [ "Thoroughfare identifier", "Issuing register", "Stability rule across renaming" ] }, { "id": "tin-q2", "text": "How is the complete street name decomposed into pre-directional, pre-type, pre-modifier, base name, post-type, post-directional and post-modifier parts?", "kind": "composition", "answer_data": [ "Complete street name string", "Part values by part type", "Ordering and separator rules" ] }, { "id": "tin-q3", "text": "What is the addressing extent of the thoroughfare, and how does it link to the transport network feature that carries its geometry?", "kind": "spatial", "answer_data": [ "Transport link references", "Extent description or geometry reference", "Segmentation used for numbering" ] }, { "id": "tin-q4", "text": "Which kinds of way are admissible as addressing thoroughfares in this jurisdiction, and which are excluded?", "kind": "classification", "answer_data": [ "Admissible thoroughfare kinds", "Exclusions and their basis", "Handling of unnamed ways" ] } ], "data_elements": [ { "id": "thoroughfare-id", "name": "Thoroughfare identifier", "description": "Identifier of the thoroughfare as an addressing component, stable across name changes.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "complete-street-name", "name": "Complete street name", "description": "The full official name as written, from which parts are derived.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005", "SRC-013" ] }, { "id": "street-name-part", "name": "Street name part", "description": "An individual part of the name with its part type, such as pre-directional, street type or post-modifier.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-013" ] }, { "id": "thoroughfare-kind", "name": "Thoroughfare kind", "description": "Kind of way — road, street, path, waterway or other passage used for addressing.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "transport-link-ref", "name": "Transport link", "description": "Reference to the transport network feature whose geometry and topology the transport model owns.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "street-name-register-entry", "name": "Official street name register entry", "description": "The authority's record of an officially named thoroughfare, carrying identifier, name forms, kind, extent and approval reference.", "media_or_form": [ "register record", "gazette notice", "dataset feature" ], "serial": false, "identity_strategy": "Thoroughfare identifier issued by the naming authority; names are versioned attributes of that identifier, never identifiers themselves.", "source_refs": [ "SRC-005", "SRC-018" ] } ], "inline_only_rationale": null }, { "id": "thoroughfare-renaming-and-continuity", "name": "Renaming, splitting and name continuity", "description": "How renaming, splitting and merging events are recorded, how long superseded names remain usable for delivery, dispatch and legal documents, and what happens to the addresses on the affected way.", "source_refs": [ "SRC-005", "SRC-018", "SRC-011" ], "questions": [ { "id": "trc-q1", "text": "What renaming, splitting or merging events has this thoroughfare undergone, and when did each take effect?", "kind": "event", "answer_data": [ "Event kind", "Effective timestamp", "Prior and resulting thoroughfare references" ] }, { "id": "trc-q2", "text": "For how long do superseded names remain acceptable for delivery, emergency dispatch and legal documents, and do those periods differ?", "kind": "temporal", "answer_data": [ "Grace period per purpose", "Authority setting each period", "Expiry handling" ] }, { "id": "trc-q3", "text": "How are the addresses on the thoroughfare preserved or reissued across the change?", "kind": "lifecycle", "answer_data": [ "Affected address list", "Reissue or preserve decision per address", "Superseded-by links" ] }, { "id": "trc-q4", "text": "Which body approves a renaming, what consultation is required, and where is the decision recorded?", "kind": "authority", "answer_data": [ "Approving body", "Consultation requirement", "Decision record reference" ] } ], "data_elements": [ { "id": "name-event", "name": "Name change event", "description": "A renaming, splitting or merging event affecting the thoroughfare, with kind and effective time.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-018" ] }, { "id": "previous-name", "name": "Previous name", "description": "A superseded name form retained for historical resolution and legacy matching.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "name-validity-period", "name": "Name validity period", "description": "Period during which a given name form was official, expressed with RFC 3339 timestamps.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-005" ] }, { "id": "name-grace-period", "name": "Acceptance grace period", "description": "Duration for which a superseded name is still accepted for a stated purpose.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Renaming continuity is expressed as versioned name attributes and typed event links inside the street name register; the approving instrument is captured by the addressing mandate artifact and the register change log, so a separate artifact here would duplicate them." } ] }, { "id": "postal-delivery", "name": "Postal designation, delivery points and rendering", "description": "Postcodes and post names, delivery point types, and the country templates and rules that render stored components into a deliverable address.", "source_refs": [ "SRC-002", "SRC-005", "SRC-012", "SRC-013", "SRC-015" ], "findings": [ { "id": "postal-descriptor-and-delivery-point", "name": "Postal descriptor and delivery point type", "description": "The postcode and post name that route mail, the operator that maintains them, whether the descriptor bears an authoritative extent, whether the postal city may differ from the municipality, and which kind of delivery point is designated.", "source_refs": [ "SRC-005", "SRC-012", "SRC-013", "SRC-015", "SRC-008" ], "questions": [ { "id": "pdp-q1", "text": "What postcode and post name apply, and which designated postal operator maintains them?", "kind": "identity", "answer_data": [ "Postcode value", "Post name", "Operator reference", "Source release version" ] }, { "id": "pdp-q2", "text": "Is this a physical delivery point, a post office box, poste restante, a rural or highway contract route, or a military address?", "kind": "classification", "answer_data": [ "Delivery point type code", "Delivery point identifier where issued", "Recipient-location relationship note" ] }, { "id": "pdp-q3", "text": "Does the postal descriptor have a geographic extent, and is that extent authoritative or an approximation derived from delivery points?", "kind": "spatial", "answer_data": [ "Extent geometry or absence statement", "Authoritative-versus-derived flag", "Derivation method" ] }, { "id": "pdp-q4", "text": "May the postal city name differ from the municipality of location, and which is authoritative for which purpose?", "kind": "constraint", "answer_data": [ "Postal city value", "Municipality value", "Purpose-authority mapping" ] }, { "id": "pdp-q5", "text": "How often does the operator revise postal codes, and how are revisions propagated to bound addresses?", "kind": "process", "answer_data": [ "Release cadence and latest release identifier", "Propagation procedure", "Reconciliation backlog measure" ] } ], "data_elements": [ { "id": "postcode", "name": "Postcode", "description": "Code created and maintained for postal purposes to identify a subdivision of addresses and delivery points.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-012" ] }, { "id": "post-name", "name": "Post name", "description": "Name created and maintained for postal purposes to identify a subdivision of addresses and delivery points.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "postal-operator-ref", "name": "Postal operator", "description": "Designated operator responsible for the postal descriptors used.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "delivery-point-type", "name": "Delivery point type", "description": "Kind of delivery point: physical address, post office box, rural or highway contract route, general delivery or military address.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-008" ] }, { "id": "postal-city", "name": "Postal city", "description": "Alternate city name used for mailing when it differs from the actual locality of the address.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] } ], "artifacts": [ { "id": "postal-code-reference-dataset", "name": "Postal code and delivery point reference dataset", "description": "The operator-maintained reference data used to validate, cleanse and standardise addresses, released as dated versions covering a territory.", "media_or_form": [ "reference dataset release", "code table", "validation service dataset" ], "serial": true, "identity_strategy": "Publisher plus release identifier and release date, for example a universal postcode database release such as 2026.1 dated 2026-03-02.", "source_refs": [ "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "postal-template-and-rendering", "name": "Postal address template and rendering rules", "description": "The country-specific template and rendering rules that select, order, concatenate and format components into output lines, the contextual parameters that vary the result, and the handling of components with no target in the destination template.", "source_refs": [ "SRC-002", "SRC-012", "SRC-013" ], "questions": [ { "id": "ptr-q1", "text": "Which country template governs rendering for this destination, at which version, and where is it obtained?", "kind": "process", "answer_data": [ "Template identifier and destination country", "Template version", "Template source and licence" ] }, { "id": "ptr-q2", "text": "What line identification, ordering, concatenation and formatting rules apply, and which components are optional in each line?", "kind": "constraint", "answer_data": [ "Output line definitions", "Component ordering and separators", "Required-versus-optional component flags", "Casing and abbreviation rules" ] }, { "id": "ptr-q3", "text": "Which contextual parameters change the rendering, such as origin country, domestic versus international, or script?", "kind": "decision", "answer_data": [ "Parameter names and values", "Resulting variant", "Default when a parameter is absent" ] }, { "id": "ptr-q4", "text": "How are addressee and organisation segments kept separate from the location components this model owns?", "kind": "interoperability", "answer_data": [ "Segment boundary definition", "Party model reference for addressee data", "Joining rule at render time" ] }, { "id": "ptr-q5", "text": "What is done when a stored component has no mapping in the destination template?", "kind": "exception", "answer_data": [ "Unmapped component policy", "Fallback placement or omission", "Loss disclosure to the caller" ] } ], "data_elements": [ { "id": "template-ref", "name": "Postal address template", "description": "Reference to the country template expressing rendering rules for the destination.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-012" ] }, { "id": "template-language", "name": "Template language", "description": "The formal language in which the template is expressed for computer processing.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-012" ] }, { "id": "rendered-line", "name": "Rendered output line", "description": "An ordered output line produced by applying the template to the address components.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-013" ] }, { "id": "rendering-context", "name": "Rendering context", "description": "Parameters that contextualise rendering, such as origin country, domestic or international posting and target script.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "unmapped-component-policy", "name": "Unmapped component policy", "description": "Declared behaviour when a component cannot be placed by the destination template.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "country-postal-template", "name": "Country postal address template", "description": "The machine-processable template that expresses a country's postal address rendering rules, together with its human-readable form and the sample address set used to derive and test it.", "media_or_form": [ "machine-readable template", "natural-language template notation", "sample address set" ], "serial": true, "identity_strategy": "Country code plus template identifier and version issued by the publishing body; each edition carries an RFC 3339 publication timestamp.", "source_refs": [ "SRC-002", "SRC-012" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "spatial-referencing", "name": "Spatial position and reference systems", "description": "Coordinate positions with their meaning, method and accuracy; the coordinate and geographic-identifier reference systems that give them sense; and non-coordinate code and grid references.", "rationale": "ISO 19111 requires a CRS and, for dynamic systems, a coordinate epoch before a coordinate has meaning; INSPIRE requires every geographic position to declare what it specifies, by what method, and whether it is the default; ISO 19112 provides the parallel model for referencing by geographic identifier. GeoJSON and Open Location Code show that encodings impose their own hard constraints.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-010", "SRC-017" ], "layers": [ { "id": "geocode-position", "name": "Position, specification and accuracy", "description": "What a stored coordinate actually points at, how it was obtained, which of several positions is default, and how accurate and how precise it is.", "source_refs": [ "SRC-005", "SRC-010", "SRC-014", "SRC-017" ], "findings": [ { "id": "position-and-geometry-specification", "name": "Position, geometry specification and method", "description": "The geometry stored for an address or place, an explicit statement of which real-world feature it specifies (entrance, building, parcel, delivery point, utility connection or segment interpolation), the method by which it was determined, and which position is the default among several.", "source_refs": [ "SRC-005", "SRC-010", "SRC-015" ], "questions": [ { "id": "pgs-q1", "text": "What does this position represent — entrance, building, parcel, postal delivery point, utility connection or street segment interpolation?", "kind": "spatial", "answer_data": [ "Geometry specification code", "Referenced feature", "Justification where ambiguous" ] }, { "id": "pgs-q2", "text": "By what method was the position determined, and by whom?", "kind": "provenance", "answer_data": [ "Geometry method code", "Determining party", "Determination timestamp" ] }, { "id": "pgs-q3", "text": "Which of several positions is the default, and which position should routing, dispatch and statistics each use?", "kind": "decision", "answer_data": [ "Default position flag", "Purpose-to-position mapping", "Selection rule when the preferred position is missing" ] }, { "id": "pgs-q4", "text": "In which geometry type and dimensionality is the position expressed, including any vertical or floor-level component?", "kind": "measurement", "answer_data": [ "Geometry type", "Dimensionality", "Vertical value or Z-level" ] } ], "data_elements": [ { "id": "position-geometry", "name": "Position geometry", "description": "The geometry, normally a point, representing the position of the address or place.", "value_kind": "geometry", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005", "SRC-010", "SRC-015" ] }, { "id": "geometry-specification", "name": "Geometry specification", "description": "Statement of which feature the position specifies, such as entrance, building, parcel, postal delivery point or segment.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "geometry-method", "name": "Geometry method", "description": "How and by whom the position was determined or derived.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "is-default-position", "name": "Default position flag", "description": "Whether this position is the default one to use when a consumer expresses no preference.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "z-level", "name": "Vertical or floor level", "description": "Vertical component or floor level qualifying the position where the address is not at ground level.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "A position is an intrinsic, multi-valued attribute of the address or place record rather than a separable document; the evidence for how it was obtained is held by the geocoding result artifact and the accuracy evaluation artifact in adjacent findings." }, { "id": "positional-accuracy-and-precision", "name": "Positional accuracy and meaningful precision", "description": "The stated accuracy of a position with its measure and confidence, the number of digits that are actually meaningful, containment tests that detect implausible coordinates, and how accuracy travels to consumers that accept only a bare point.", "source_refs": [ "SRC-010", "SRC-014", "SRC-017", "SRC-004" ], "questions": [ { "id": "pap-q1", "text": "What is the stated positional accuracy of this coordinate, under which measure and at what confidence level?", "kind": "measurement", "answer_data": [ "Accuracy value and unit", "Accuracy measure definition", "Confidence level" ] }, { "id": "pap-q2", "text": "How many decimal places or code digits are meaningful here, and which published digits are spurious precision?", "kind": "quality", "answer_data": [ "Meaningful digit count", "Ground resolution implied", "Rounding or truncation policy" ] }, { "id": "pap-q3", "text": "What test rejects a position falling outside the parcel, building footprint or jurisdiction it claims?", "kind": "validation", "answer_data": [ "Containment test definition", "Reference geometry used", "Result and tolerance" ] }, { "id": "pap-q4", "text": "How is accuracy conveyed to a consumer whose format carries only a point without metadata?", "kind": "interoperability", "answer_data": [ "Out-of-band accuracy channel", "Degradation or refusal policy", "Consumer warning text" ] } ], "data_elements": [ { "id": "horizontal-accuracy", "name": "Horizontal positional accuracy", "description": "Quantified horizontal accuracy of the position, with unit and measure.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "accuracy-confidence", "name": "Accuracy confidence level", "description": "Confidence level at which the accuracy figure holds.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "coordinate-precision-digits", "name": "Meaningful coordinate digits", "description": "Number of decimal places or code digits that carry real information; six decimal degrees corresponds to roughly ten centimetres.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-017" ] }, { "id": "containment-check-result", "name": "Containment check result", "description": "Outcome of testing whether the position lies within the geometry it claims to be in.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [ { "id": "positional-accuracy-report", "name": "Positional accuracy evaluation report", "description": "The record of an accuracy evaluation over a set of positions: method, sample, reference data, measures obtained and containment failures found.", "media_or_form": [ "evaluation report", "quality measure record", "test result set" ], "serial": true, "identity_strategy": "Evaluation run identifier assigned by the evaluating party, with an RFC 3339 execution timestamp and the evaluated dataset version.", "source_refs": [ "SRC-014", "SRC-008" ] } ], "inline_only_rationale": null } ] }, { "id": "reference-systems", "name": "Coordinate and geographic-identifier reference systems", "description": "The systems that give positions and identifiers their meaning: coordinate reference systems with datums and epochs, and spatial reference systems using geographic identifiers with their gazetteers.", "source_refs": [ "SRC-003", "SRC-004", "SRC-010" ], "findings": [ { "id": "crs-and-coordinate-epoch", "name": "Coordinate reference system, epoch and axis order", "description": "The declared CRS with its authority code and version, whether it is dynamic and therefore requires a coordinate epoch, the axis order and units in force, any vertical CRS, and the coordinate operation used when transforming for a consumer.", "source_refs": [ "SRC-004", "SRC-010", "SRC-014" ], "questions": [ { "id": "cce-q1", "text": "In which coordinate reference system is this position expressed, cited by authority code and dataset version?", "kind": "identity", "answer_data": [ "CRS authority and code", "Registry dataset version", "CRS name" ] }, { "id": "cce-q2", "text": "Is the CRS dynamic, and if so which coordinate epoch applies to the stored coordinates?", "kind": "temporal", "answer_data": [ "Dynamic-versus-static flag", "Coordinate epoch", "Deformation model reference where used" ] }, { "id": "cce-q3", "text": "What axis order and units apply, and how is that reconciled with encodings that fix longitude before latitude?", "kind": "interoperability", "answer_data": [ "Axis order as defined by the CRS", "Encoding axis order", "Reconciliation or swap rule" ] }, { "id": "cce-q4", "text": "Which coordinate operation, at what accuracy, is applied when transforming into a consumer's CRS?", "kind": "process", "answer_data": [ "Operation identifier", "Operation accuracy", "Area of validity" ] }, { "id": "cce-q5", "text": "Is a vertical or compound CRS declared for any height component, and what is its datum?", "kind": "constraint", "answer_data": [ "Vertical CRS reference", "Vertical datum", "Height type" ] } ], "data_elements": [ { "id": "crs-ref", "name": "Coordinate reference system", "description": "Reference to the CRS in which coordinates are expressed, cited by authority code.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-014" ] }, { "id": "coordinate-epoch", "name": "Coordinate epoch", "description": "Epoch to which coordinates in a dynamic CRS refer, without which those coordinates are ambiguous.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "axis-order", "name": "Axis order and units", "description": "Order and units of coordinate axes as defined by the CRS or overridden by the encoding.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-010" ] }, { "id": "vertical-crs-ref", "name": "Vertical CRS", "description": "Reference to the vertical CRS applying to any height component.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "coordinate-operation-ref", "name": "Coordinate operation", "description": "Reference to the transformation or conversion applied between reference systems, with its stated accuracy.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "crs-definition-record", "name": "Coordinate reference system definition record", "description": "The authoritative definition of a CRS, datum or coordinate operation obtained from a geodetic parameter registry, including area of validity and accuracy, referenced rather than redefined by this model.", "media_or_form": [ "registry record", "well-known text definition", "parameter dataset entry" ], "serial": true, "identity_strategy": "Registry authority name plus code plus dataset version; codes are stable while dataset versions change, so both are required.", "source_refs": [ "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "geographic-identifier-and-gazetteer", "name": "Geographic identifiers, location types and gazetteers", "description": "Spatial referencing by geographic identifier: the location types a reference system defines, the location instances that populate it, the gazetteer that is custodian of record, complementary coordinate references, and instance lifecycle.", "source_refs": [ "SRC-003", "SRC-018", "SRC-014" ], "questions": [ { "id": "gig-q1", "text": "Which location types does this spatial reference system define, and what identifier form does each use?", "kind": "definition", "answer_data": [ "Location type names and definitions", "Identifier form and syntax per type", "Theme or domain of the reference system" ] }, { "id": "gig-q2", "text": "How do location instances nest, adjoin or overlap, and which of those relationships are recorded?", "kind": "relationship", "answer_data": [ "Parent and child instance references", "Adjacency or overlap assertions", "Relationship semantics" ] }, { "id": "gig-q3", "text": "Which gazetteer is custodian of record for each location type, and over what territory of use?", "kind": "authority", "answer_data": [ "Gazetteer reference and custodian", "Territory of use", "Scope and coverage statement" ] }, { "id": "gig-q4", "text": "Does each location instance carry a complementary coordinate reference, and at what geometry level?", "kind": "spatial", "answer_data": [ "Complementary position or extent", "Geometry level (point, bounding, full)", "CRS of the complementary reference" ] }, { "id": "gig-q5", "text": "How are location instances added, merged, split and retired, and are historic instances retained?", "kind": "lifecycle", "answer_data": [ "Instance lifecycle states", "Merge and split event records", "Historic retention policy" ] } ], "data_elements": [ { "id": "location-type", "name": "Location type", "description": "A class of location within the spatial reference system, such as country, municipality or postal area.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "location-instance-id", "name": "Location instance identifier", "description": "Geographic identifier of an individual location instance of a given location type.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "gazetteer-ref", "name": "Gazetteer", "description": "Reference to the gazetteer that holds and maintains the location instances for a location type.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "parent-location-ref", "name": "Parent location instance", "description": "Reference to a location instance within which this instance falls.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "complementary-position", "name": "Complementary coordinate reference", "description": "Coordinate position or extent recorded alongside the geographic identifier.", "value_kind": "geometry", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "gazetteer-publication", "name": "Gazetteer publication", "description": "The published register of location instances for one or more location types, with identifiers, names, positions or extents, and administrative metadata about the custodian and territory of use.", "media_or_form": [ "gazetteer register", "dataset release", "query service snapshot" ], "serial": true, "identity_strategy": "Gazetteer identifier plus release version; instances are identified by their geographic identifier within the declared location type.", "source_refs": [ "SRC-003", "SRC-018" ] } ], "inline_only_rationale": null } ] }, { "id": "code-based-references", "name": "Code and grid based location references", "description": "Derived, non-coordinate references such as open location codes and grid squares that stand in for an address where none exists.", "source_refs": [ "SRC-017", "SRC-010", "SRC-014" ], "findings": [ { "id": "grid-and-code-based-reference", "name": "Open code and grid location references", "description": "Code-based location references: the scheme and code length in use, the ground area a length resolves, whether a code is full or shortened and therefore needs a reference location, whether the scheme is openly reversible or vendor-dependent, and its role where no civic address exists.", "source_refs": [ "SRC-017", "SRC-010", "SRC-014" ], "questions": [ { "id": "gcb-q1", "text": "Which code scheme is used, at what code length, and what ground area does that length resolve?", "kind": "measurement", "answer_data": [ "Scheme identifier", "Code value and length", "Resolved area dimensions" ] }, { "id": "gcb-q2", "text": "Is the code full or shortened, and if shortened, which reference location is required to recover it?", "kind": "constraint", "answer_data": [ "Full-versus-short flag", "Reference location or feature", "Recovery procedure and its ambiguity risk" ] }, { "id": "gcb-q3", "text": "Is the scheme openly specified and reversible without a proprietary service, or does resolution depend on a vendor?", "kind": "interoperability", "answer_data": [ "Specification availability and licence", "Vendor dependency statement", "Offline reversibility flag" ] }, { "id": "gcb-q4", "text": "How does the code relate to the underlying coordinate reference system and to any civic address for the same place?", "kind": "relationship", "answer_data": [ "Underlying CRS", "Linked address reference", "Agreement or discrepancy note" ] }, { "id": "gcb-q5", "text": "Where no civic address exists, what governs the use of the code as the operative location reference?", "kind": "exception", "answer_data": [ "Accepting parties and purposes", "Fallback rules", "Limits on legal or postal use" ] } ], "data_elements": [ { "id": "location-code-value", "name": "Location code value", "description": "The code string identifying an area, including any format separator and padding characters.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-017" ] }, { "id": "code-scheme", "name": "Code scheme", "description": "The scheme that defines the code's alphabet, structure and semantics.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-017" ] }, { "id": "code-length", "name": "Code length", "description": "Number of significant digits, which determines the resolved area; padded codes must not be shortened.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "code-reference-location", "name": "Reference location for short codes", "description": "The location required to recover a full code from a shortened one.", "value_kind": "geometry", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "scheme-openness", "name": "Scheme openness", "description": "Whether the scheme is openly specified and offline-reversible or dependent on a vendor service.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-014" ] } ], "artifacts": [], "inline_only_rationale": "A code reference is a derived value object computed deterministically from coordinates and a scheme; it carries no document of its own. The governing specification is recorded as an external alignment rather than held as a model artifact." } ] } ] }, { "id": "places-and-names", "name": "Named places and toponyms", "description": "Points of interest used for orientation and discovery, and the toponyms that name places across languages, scripts and periods of official recognition.", "rationale": "Overture's places schema shows that a POI carries identity, multi-level categories, existence confidence and operating status distinct from any address; UNGEGN establishes that geographical names are standardised by national authorities and that multilingual, culturally informed naming matters for administration and emergency response. Both are referencing assets, not attributes of the things they name.", "source_refs": [ "SRC-016", "SRC-018", "SRC-003" ], "layers": [ { "id": "points-of-interest", "name": "Points of interest", "description": "Named places usable for orientation, discovery and reference, with category, status and confidence.", "source_refs": [ "SRC-016", "SRC-008" ], "findings": [ { "id": "poi-identity-and-status", "name": "POI identity, category, status and confidence", "description": "The identifier of a point of interest independent of its operator and name, the taxonomy and level that classify it, its operating status as distinct from opening hours, its resolution to addresses and buildings, and the confidence that it exists at all.", "source_refs": [ "SRC-016", "SRC-008", "SRC-014" ], "questions": [ { "id": "pis-q1", "text": "Which identifier designates the point of interest independently of its operator, brand and current name?", "kind": "identity", "answer_data": [ "POI identifier", "Issuing scheme or reference system", "Stability rule across operator change" ] }, { "id": "pis-q2", "text": "Which category taxonomy classifies the POI, at which level, and which alternate categories also apply?", "kind": "classification", "answer_data": [ "Primary category and taxonomy", "Alternate categories", "Basic-level or human-intuitive category" ] }, { "id": "pis-q3", "text": "What is the operating status of the POI, and when was it last confirmed?", "kind": "state", "answer_data": [ "Operating status value", "Last confirmation timestamp", "Confirming source" ] }, { "id": "pis-q4", "text": "How does the POI resolve to one or more addresses, to a building or unit, and to a brand?", "kind": "relationship", "answer_data": [ "Address references", "Building or unit reference", "Brand reference" ] }, { "id": "pis-q5", "text": "What existence confidence is asserted, on what evidence, and what threshold gates publication?", "kind": "quality", "answer_data": [ "Confidence score", "Evidence and contributing sources", "Publication threshold and reviewer" ] } ], "data_elements": [ { "id": "poi-id", "name": "POI identifier", "description": "Stable identifier for the point of interest as a referenceable entity.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "poi-name", "name": "POI name", "description": "Recognised names of the place, including primary and common variants with language qualification.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "poi-category", "name": "POI category", "description": "Classification of the place, with primary, alternate and basic-level categories from a declared taxonomy.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "poi-operating-status", "name": "Operating status", "description": "Whether the place is open, temporarily closed or permanently closed, distinct from time-of-day opening hours.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "poi-existence-confidence", "name": "Existence confidence", "description": "Score between zero and one for the certainty that the place exists; zero is paired with permanent closure.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "poi-address-ref", "name": "POI address", "description": "Reference to one or more addresses at which the place is situated.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [ { "id": "poi-catalogue-entry", "name": "POI catalogue entry", "description": "The catalogue record for a point of interest, including identifier, names, categories, position, status, confidence and per-attribute sources; may originate from an operator's own listing submission.", "media_or_form": [ "catalogue record", "listing submission", "dataset feature" ], "serial": false, "identity_strategy": "Catalogue-issued POI identifier under a declared reference scheme; operator-supplied identifiers are retained as alternative identifiers, never as the primary key.", "source_refs": [ "SRC-016" ] } ], "inline_only_rationale": null } ] }, { "id": "toponyms", "name": "Toponyms and multilingual names", "description": "Place names with their language, script, romanisation, official standardisation status and history.", "source_refs": [ "SRC-018", "SRC-005", "SRC-007", "SRC-012" ], "findings": [ { "id": "toponym-language-and-status", "name": "Toponym language, script and official status", "description": "Which place a toponym names, the language and script of each name form and its relation to a source form, which form is officially standardised by the national names authority, how contested or reinstated names are recorded, and which form to display for a given audience.", "source_refs": [ "SRC-018", "SRC-007", "SRC-005", "SRC-012" ], "questions": [ { "id": "tls-q1", "text": "Which named place does this toponym name, and is the same name borne by other places within the same scope?", "kind": "identity", "answer_data": [ "Named place reference", "Homonym set within scope", "Disambiguation rule" ] }, { "id": "tls-q2", "text": "In which language and script is each name form recorded, and which forms are romanisations of which source form?", "kind": "classification", "answer_data": [ "Language tag", "Script code", "Romanisation or transliteration system", "Source form reference" ] }, { "id": "tls-q3", "text": "Which form is officially standardised by the national names authority, and which are endonyms, exonyms or historic forms?", "kind": "authority", "answer_data": [ "Name status value", "Standardising authority", "Decision reference and date" ] }, { "id": "tls-q4", "text": "How are contested, reinstated or superseded names recorded without erasing prior forms?", "kind": "lifecycle", "answer_data": [ "Name status history with periods", "Contest or objection record", "Retention policy for superseded forms" ] }, { "id": "tls-q5", "text": "Which name form should a consumer display for a stated audience locale, and what is the fallback?", "kind": "interoperability", "answer_data": [ "Locale-to-form mapping", "Fallback chain", "Prohibited or discouraged forms" ] } ], "data_elements": [ { "id": "toponym-text", "name": "Toponym", "description": "A name form for the place as written in a specific language and script.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-018", "SRC-005" ] }, { "id": "name-language", "name": "Name language", "description": "Language of the name form, needed for multilingual and culturally informed naming.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "name-script", "name": "Name script", "description": "Script in which the name form is written.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-012" ] }, { "id": "name-status", "name": "Name status", "description": "Standardisation status of the name form: official, standardised, historic, endonym, exonym or unofficial.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "romanisation-system", "name": "Romanisation system", "description": "The transliteration or romanisation system used to derive a Latin-script form.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "name-authority-ref", "name": "Names authority", "description": "National or regional names authority that standardised the form.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] } ], "artifacts": [ { "id": "standardised-names-list", "name": "Standardised geographical names list", "description": "The national names authority's published list of standardised names with language, script, status and decision references, used as the reference for official display and exchange.", "media_or_form": [ "names authority publication", "gazette decision", "names database release" ], "serial": true, "identity_strategy": "Authority identifier plus publication or release version; individual entries are keyed by the place identifier, not by the name string.", "source_refs": [ "SRC-018" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "assurance-access-exchange", "name": "Matching, quality, provenance, access and exchange", "description": "How references are resolved and scored, how their quality is tested and defects recorded, where each attribute came from and when, under what licence and protection they may be used, and how they cross into other models and encodings without silent loss.", "rationale": "FGDC defines a distinct data quality part and an Address Anomaly Status; Overture records per-attribute sources with confidence and timestamps; W3C and OGC best practice requires published validation schemas, declared accuracy and responsible interaction; ISO 19160-1 exists precisely to enable cross-mapping. These concerns determine whether a reference can be relied upon.", "source_refs": [ "SRC-001", "SRC-008", "SRC-014", "SRC-015", "SRC-016", "SRC-019" ], "layers": [ { "id": "matching-and-quality", "name": "Matching, quality tests and anomalies", "description": "Resolution of input strings and positions to reference records with scored outcomes, and the tests, anomalies and defect handling that keep the register trustworthy.", "source_refs": [ "SRC-008", "SRC-013", "SRC-014" ], "findings": [ { "id": "geocoding-and-matching", "name": "Geocoding and address matching outcomes", "description": "The normalisation and parsing that precede matching, the reference dataset version matched against, the score and type of a match, the threshold that separates automatic acceptance from review, and the explicit representation of ambiguity, partial matches and interpolation.", "source_refs": [ "SRC-013", "SRC-008", "SRC-014", "SRC-015" ], "questions": [ { "id": "gam-q1", "text": "What normalisation and parsing steps precede matching, and against which reference dataset version was the match run?", "kind": "process", "answer_data": [ "Normalisation rule set and version", "Parser and its component output", "Reference dataset identifier and version" ] }, { "id": "gam-q2", "text": "What match score, match type and matched component set does the operation return?", "kind": "measurement", "answer_data": [ "Match score", "Match type code", "Components matched and unmatched" ] }, { "id": "gam-q3", "text": "Which score threshold accepts a match automatically, and what routes a candidate to human review?", "kind": "decision", "answer_data": [ "Acceptance threshold", "Review trigger conditions", "Reviewer role and turnaround" ] }, { "id": "gam-q4", "text": "Is the result stored as an attribute of the address or as a separate derived observation with its own timestamp and inputs?", "kind": "provenance", "answer_data": [ "Storage form decision", "Observation timestamp", "Inputs and engine version" ] }, { "id": "gam-q5", "text": "How are ambiguous, partial and interpolated results represented rather than silently resolved to one answer?", "kind": "exception", "answer_data": [ "Candidate set with scores", "Interpolation flag and method", "Disclosure to the consumer" ] } ], "data_elements": [ { "id": "match-score", "name": "Match score", "description": "Numeric score expressing confidence that the input resolved to the matched reference record.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-014" ] }, { "id": "match-type", "name": "Match type", "description": "Kind of match achieved: exact, standardised, partial, interpolated or unmatched.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-008" ] }, { "id": "matched-address-ref", "name": "Matched address", "description": "Reference to the address record the input resolved to.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "reference-dataset-version", "name": "Reference dataset version", "description": "Version of the reference dataset used for matching, without which a result cannot be reproduced.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "candidate-set", "name": "Candidate set", "description": "Alternative candidates with their scores, retained when the match is ambiguous.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "interpolation-flag", "name": "Interpolation flag", "description": "Whether the position was interpolated along a segment rather than observed.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-008" ] } ], "artifacts": [ { "id": "geocoding-result-record", "name": "Geocoding or matching result record", "description": "The reproducible record of one matching run: input, normalisation applied, reference dataset version, engine version, candidates, chosen result, score and timestamp.", "media_or_form": [ "result record", "batch match report", "service response log" ], "serial": true, "identity_strategy": "Run identifier issued by the matching service, combined with the input record key; execution time recorded in RFC 3339 with an explicit offset or Z.", "source_refs": [ "SRC-013", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "quality-tests-and-anomalies", "name": "Quality tests, anomaly status and defect handling", "description": "The tests a record must pass — syntax, completeness, conformity to the governing reference system, duplication and positional containment — the anomaly status recorded when it fails, whether an anomalous address remains usable, and how defects are notified and resolved with retained evidence.", "source_refs": [ "SRC-008", "SRC-014", "SRC-019" ], "questions": [ { "id": "qta-q1", "text": "Which quality tests does this record pass or fail, and against which rule set version were they run?", "kind": "validation", "answer_data": [ "Test identifiers and definitions", "Pass or fail per test", "Rule set version" ] }, { "id": "qta-q2", "text": "What anomaly status applies when the address is not correct under its governing reference system, and may it still be used?", "kind": "quality", "answer_data": [ "Anomaly status value or explanatory note", "Usability decision", "Consumers warned" ] }, { "id": "qta-q3", "text": "Who is notified of a defect, within what period must it be resolved, and what status applies meanwhile?", "kind": "process", "answer_data": [ "Notified role or party", "Resolution deadline", "Interim record status" ] }, { "id": "qta-q4", "text": "What evidence is retained to show that a test was executed against a specific record version?", "kind": "evidence", "answer_data": [ "Test execution timestamp", "Record version tested", "Executor and tooling version" ] }, { "id": "qta-q5", "text": "Is the validation rule set published so that consumers can check records before submitting them?", "kind": "interoperability", "answer_data": [ "Published schema or rule set location", "Publication licence", "Version alignment with the register" ] } ], "data_elements": [ { "id": "quality-test-id", "name": "Quality test", "description": "Identifier of a test applied to the record, drawn from the published rule set.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-008", "SRC-014" ] }, { "id": "test-result", "name": "Test result", "description": "Outcome of a quality test for the record version tested.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "anomaly-status", "name": "Address anomaly status", "description": "Status flag or explanatory note for an address that is not correct according to the address reference system that governs it.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "tested-at", "name": "Test execution time", "description": "RFC 3339 timestamp at which the test was executed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "validation-schema-ref", "name": "Published validation schema", "description": "Reference to the online schema or rule set used for validation.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [ { "id": "quality-conformance-report", "name": "Quality and conformance test report", "description": "The published outcome of running the declared test suite over a register or delivery, listing measures, failures, anomaly counts and the record versions and rule set versions involved.", "media_or_form": [ "conformance report", "quality measure summary", "defect register" ], "serial": true, "identity_strategy": "Report identifier issued by the testing party plus the dataset version tested; execution timestamps in RFC 3339.", "source_refs": [ "SRC-008", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "quality-elements-measures-and-reporting", "name": "Quality elements, measures and reporting", "description": "ISO 19160-3 is a profile of ISO 19157 that establishes data quality elements and measures for address data, procedures for reporting, and guidelines for use. Elements include completeness, logical consistency, positional accuracy, temporal quality, thematic accuracy and usability. The standard does not define minimum acceptable quality; fitness depends on use.", "source_refs": [ "SRC-022" ], "questions": [ { "id": "quality-elements-measures-and-reporting-q01", "text": "Against which dataset or record scope, product specification and intended use was quality evaluated?", "kind": "measurement", "answer_data": [ "quality-scope", "product-specification", "intended-use" ] }, { "id": "quality-elements-measures-and-reporting-q02", "text": "What completeness, logical consistency, positional accuracy, temporal quality, thematic accuracy and usability results were obtained?", "kind": "measurement", "answer_data": [ "completeness-result", "logical-consistency-result", "positional-accuracy-result", "temporal-quality-result", "thematic-accuracy-result", "usability-result" ] }, { "id": "quality-elements-measures-and-reporting-q03", "text": "When was the evaluation performed, by which method, and is the result still current relative to subsequent updates?", "kind": "temporal", "answer_data": [ "evaluated-at", "evaluation-method", "evaluator", "currency-flag" ] }, { "id": "quality-elements-measures-and-reporting-q04", "text": "Does the consumer impose a minimum quality threshold that ISO 19160-3 itself does not define, and is that threshold recorded as a local constraint?", "kind": "constraint", "answer_data": [ "local-threshold", "pass-fail", "constraint-id" ] } ], "data_elements": [ { "id": "quality-elements-measures-and-reporting-data01", "name": "quality-scope", "description": "Dataset, series or record scope of the evaluation", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-022" ] }, { "id": "quality-elements-measures-and-reporting-data02", "name": "completeness-result", "description": "Commission and omission measures", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "quality-elements-measures-and-reporting-data03", "name": "logical-consistency-result", "description": "Conceptual, domain, format and topological consistency", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "quality-elements-measures-and-reporting-data04", "name": "positional-accuracy-result", "description": "Absolute or relative positional accuracy", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "quality-elements-measures-and-reporting-data05", "name": "temporal-quality-result", "description": "Temporal accuracy and validity", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "quality-elements-measures-and-reporting-data06", "name": "thematic-accuracy-result", "description": "Correctness of classification and attributes", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "quality-elements-measures-and-reporting-data07", "name": "usability-result", "description": "Fitness for a stated use", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "quality-elements-measures-and-reporting-data08", "name": "evaluated-at", "description": "Quality evaluation time", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] } ], "artifacts": [ { "id": "quality-elements-measures-and-reporting-artifact01", "name": "Address quality report", "description": "Evaluation results against ISO 19160-3 elements for a stated scope and use", "media_or_form": [ "evaluation report" ], "serial": true, "identity_strategy": "Identified by evaluated scope, product specification and RFC 3339 evaluation time; a new evaluation adds a report rather than altering address identity.", "source_refs": [ "SRC-022" ] } ], "inline_only_rationale": null } ] }, { "id": "provenance-and-versioning", "name": "Source lineage and attribution of facts", "description": "Per-attribute lineage, source and ingestion times, contributor rights and precedence when sources disagree.", "source_refs": [ "SRC-015", "SRC-016", "SRC-008", "SRC-014" ], "findings": [ { "id": "source-lineage-and-observation-time", "name": "Per-attribute source lineage and observation time", "description": "Which source dataset and source record contributed each attribute, the separate source-update, ingestion and event times, the rights a contributor retains in what they contributed, and the precedence rule that decides between conflicting sources without discarding the loser.", "source_refs": [ "SRC-015", "SRC-016", "SRC-008", "SRC-011" ], "questions": [ { "id": "slo-q1", "text": "From which source dataset and source record did each attribute of this record derive?", "kind": "provenance", "answer_data": [ "Source dataset identifier", "Source record identifier", "Attributes contributed by that source" ] }, { "id": "slo-q2", "text": "What are the source update time, the ingestion time and the real-world event time for each contributed attribute, and where do they diverge?", "kind": "temporal", "answer_data": [ "Source update timestamp", "Ingestion timestamp", "Event timestamp", "Divergence explanation" ] }, { "id": "slo-q3", "text": "Which contributor holds rights in each contributed attribute, and does that constrain redistribution of the merged record?", "kind": "ownership", "answer_data": [ "Rights holder per attribute", "Licence terms inherited", "Effect on redistribution of the whole" ] }, { "id": "slo-q4", "text": "When two sources conflict on the same attribute, which precedence rule decides, and is the rejected value retained?", "kind": "decision", "answer_data": [ "Precedence rule and its basis", "Winning and rejected values", "Retention of the rejected assertion" ] }, { "id": "slo-q5", "text": "What confidence does each source attach to its own assertion, and how is that combined into the published record?", "kind": "quality", "answer_data": [ "Per-source confidence", "Combination method", "Published confidence value" ] } ], "data_elements": [ { "id": "source-dataset-ref", "name": "Source dataset", "description": "Reference to a dataset that contributed one or more attributes of the record.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-015", "SRC-016" ] }, { "id": "source-record-id", "name": "Source record identifier", "description": "Identifier of the specific record in the source dataset that supplied the value.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "source-update-time", "name": "Source update time", "description": "Time at which the source asserted or last updated the value, as an RFC 3339 timestamp.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-011" ] }, { "id": "attribute-scope", "name": "Attribute scope of lineage", "description": "The specific attribute or property path to which a lineage entry applies.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "precedence-rule", "name": "Source precedence rule", "description": "Rule deciding which source wins for a given attribute when sources disagree.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Lineage is carried as per-attribute reference data on each record version, pointing at datasets and records that are themselves owned and published elsewhere. Holding a separate lineage document here would duplicate the register change log and the external source datasets, both already treated as artifacts or external references." } ] }, { "id": "access-and-protection", "name": "Licensing, access and protection", "description": "The licence and access conditions attached to reference data, and the privacy, safety, suppression and retention constraints that limit its publication.", "source_refs": [ "SRC-002", "SRC-012", "SRC-014", "SRC-007" ], "findings": [ { "id": "licensing-and-access", "name": "Licence, redistribution and access conditions", "description": "The licence governing use, redistribution and derivation, licence encumbrance carried in from individual components, the effect of a statutory duty to publish, and the obligations that follow derived geocodes.", "source_refs": [ "SRC-012", "SRC-007", "SRC-014", "SRC-015" ], "questions": [ { "id": "laa-q1", "text": "Under what licence may this dataset be used, redistributed and built upon, and does the licence differ by component?", "kind": "access", "answer_data": [ "Licence reference and version", "Permitted uses", "Component-specific variations" ] }, { "id": "laa-q2", "text": "Which components are encumbered by a third-party licence that blocks open publication of the merged whole?", "kind": "ownership", "answer_data": [ "Encumbered component list", "Encumbering licence", "Separation or removal options" ] }, { "id": "laa-q3", "text": "Does a statutory duty to publish spatial data override or coexist with a commercial licence here?", "kind": "authority", "answer_data": [ "Statutory obligation reference", "Interaction with the licence", "Resolution adopted" ] }, { "id": "laa-q4", "text": "What attribution, share-alike or field-of-use restriction attaches to geocodes derived from this data?", "kind": "constraint", "answer_data": [ "Attribution text required", "Share-alike scope", "Field-of-use limits" ] } ], "data_elements": [ { "id": "licence-ref", "name": "Licence", "description": "Reference to the licence under which the reference data is made available.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-014" ] }, { "id": "licence-scope", "name": "Licence scope", "description": "The components, attributes or territories to which a given licence applies.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "redistribution-permitted", "name": "Redistribution permitted", "description": "Whether the recipient may redistribute the data or derivatives of it.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "attribution-requirement", "name": "Attribution requirement", "description": "Attribution text or notice that must accompany use or derivation.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-015" ] } ], "artifacts": [ { "id": "data-licence-agreement", "name": "Licence or data use agreement", "description": "The instrument that grants and limits use of the reference dataset, including attribution, redistribution, field-of-use and term.", "media_or_form": [ "licence text", "data use agreement", "open data notice" ], "serial": true, "identity_strategy": "Licence identifier and version issued by the licensor; agreement instances additionally keyed by contract number and RFC 3339 commencement timestamp.", "source_refs": [ "SRC-012", "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "privacy-safety-and-suppression", "name": "Privacy, safety, suppression and retention", "description": "When a location reference becomes personal data, which records are suppressed or coarsened for safety and by whose decision, how long records and matching logs are kept, what is deleted versus tombstoned, and how authorised responders still reach a suppressed record.", "source_refs": [ "SRC-002", "SRC-014", "SRC-007", "SRC-019" ], "questions": [ { "id": "psr-q1", "text": "At what point does this location reference become personal data, and which linkage causes that?", "kind": "privacy", "answer_data": [ "Linkage that identifies a person", "Resulting classification", "Controlling legal basis" ] }, { "id": "psr-q2", "text": "Which records are suppressed or coarsened for safety, by whose decision, and for how long?", "kind": "security", "answer_data": [ "Sensitivity class", "Suppression decision reference and decider", "Review or expiry date" ] }, { "id": "psr-q3", "text": "What precision reduction applies when publishing a sensitive position, and is the reduction reversible from published data?", "kind": "access", "answer_data": [ "Coarsening rule and resulting resolution", "Irreversibility test result", "Re-identification risk assessment" ] }, { "id": "psr-q4", "text": "How long are retired addresses, assignment records and matching logs retained, and what is hard-deleted versus tombstoned?", "kind": "retention", "answer_data": [ "Retention period per record class", "Deletion mode", "Legal or archival basis" ] }, { "id": "psr-q5", "text": "What lawful-access route allows emergency services or another authorised party to reach a suppressed record?", "kind": "exception", "answer_data": [ "Authorised parties", "Access route and authentication", "Audit obligation for each access" ] } ], "data_elements": [ { "id": "sensitivity-class", "name": "Sensitivity class", "description": "Classification governing whether and at what resolution the reference may be published.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "suppression-decision-ref", "name": "Suppression decision", "description": "Reference to the decision that suppressed or coarsened the record, including its decider and review date.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "coarsening-rule", "name": "Coarsening rule", "description": "Rule reducing published precision for sensitive records, for example truncating code digits or snapping to an area centroid.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-014" ] }, { "id": "retention-period", "name": "Retention period", "description": "Duration for which a record class is retained before deletion or archival transfer.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "deletion-mode", "name": "Deletion mode", "description": "Whether expiry results in hard deletion, tombstoning with identifier retention, or archival transfer.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "suppression-decision-record", "name": "Suppression or sensitivity decision record", "description": "The decision that classifies a location reference as sensitive and sets the publication constraint, its reviewer, review date and the lawful-access route retained for authorised parties.", "media_or_form": [ "decision record", "protection order reference", "access exception register entry" ], "serial": true, "identity_strategy": "Decision number issued by the deciding authority, with RFC 3339 effective and review timestamps; the affected record is referenced by identifier, never by name alone.", "source_refs": [ "SRC-014", "SRC-019" ] } ], "inline_only_rationale": null } ] }, { "id": "interoperability", "name": "Crosswalks, conformance and projections", "description": "Declared mappings to external address models, the evidence behind any conformance claim, and the encoding projections that expose the canonical record.", "source_refs": [ "SRC-001", "SRC-010", "SRC-019", "SRC-014" ], "findings": [ { "id": "crosswalks-conformance-and-encodings", "name": "Crosswalks, conformance evidence and encoding projections", "description": "The external models this register is mapped to and where those mappings lose information, the evidence supporting any conformance claim, the published encoding projections and their derivation from one canonical record, and the handling of components with no target in a receiving model.", "source_refs": [ "SRC-001", "SRC-010", "SRC-019", "SRC-014", "SRC-009" ], "questions": [ { "id": "cce2-q1", "text": "To which external address or location models is this register crosswalked, at which versions, and where is each mapping lossy?", "kind": "interoperability", "answer_data": [ "Target model and version", "Element-to-element mapping", "Lossy or unmapped elements" ] }, { "id": "cce2-q2", "text": "What evidence supports each claimed conformance class, and was a conformance test actually executed?", "kind": "evidence", "answer_data": [ "Conformance class claimed", "Test executed and its result", "Evidence artifact reference" ] }, { "id": "cce2-q3", "text": "Which encoding projections are published, and are they all derived from a single canonical record?", "kind": "interoperability", "answer_data": [ "Projection list and formats", "Canonical record reference", "Derivation pipeline and its version" ] }, { "id": "cce2-q4", "text": "Which fields does each projection drop or default, and is that projection therefore non-authoritative?", "kind": "constraint", "answer_data": [ "Dropped or defaulted field list", "Authoritative-versus-derived flag", "Consumer warning" ] }, { "id": "cce2-q5", "text": "How is a component with no target in the receiving model conveyed without silent loss?", "kind": "exception", "answer_data": [ "Extension or annotation mechanism", "Loss disclosure", "Agreement with the receiving party" ] } ], "data_elements": [ { "id": "crosswalk-ref", "name": "Crosswalk", "description": "Reference to a documented mapping between this model's elements and an external model's elements.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-019" ] }, { "id": "target-model-version", "name": "Target model version", "description": "Version of the external model to which the crosswalk applies.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "mapping-loss-note", "name": "Mapping loss note", "description": "Statement of the information lost or defaulted in a given direction of the mapping.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "conformance-claim", "name": "Conformance claim", "description": "A claimed conformance class against an external standard, valid only when accompanied by test evidence.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "projection-id", "name": "Encoding projection", "description": "Identifier of a published projection of the canonical record into a specific encoding or interface.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-014" ] } ], "artifacts": [ { "id": "crosswalk-and-conformance-pack", "name": "Crosswalk table and conformance evidence pack", "description": "The maintained element-level mapping between this register and an external model, paired with the executed conformance test results that justify any conformance claim.", "media_or_form": [ "mapping table", "conformance test report", "reference implementation notes" ], "serial": true, "identity_strategy": "Crosswalk identifier plus the pair of source and target model versions; each pack carries an RFC 3339 publication timestamp and the test run identifiers it evidences.", "source_refs": [ "SRC-001", "SRC-019" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "assign-address", "name": "Assign address", "description": "Create a new address record binding an address to an addressable object under a governing address reference system, producing an authority decision and an initial lifecycle status.", "inputs": [ "Addressable object reference and owning model", "Governing address reference system identifier", "Proposed locator designators and components", "Basis evidence reference" ], "outputs": [ "Address record with identifier and lifecycle status", "Assignment decision record", "Address assigned event" ], "preconditions": [ "The acting authority holds a mandate in force covering the object's location", "The proposed designator passes the numbering rules of the governing reference system", "The addressable object is resolvable in its owning model" ], "effects": [ "A new address identifier is issued and made resolvable", "Lifecycle status is set and status change time recorded in RFC 3339", "A new record version is opened in the register change log" ], "source_refs": [ "SRC-001", "SRC-005", "SRC-008" ] }, { "id": "retire-address", "name": "Retire address", "description": "Withdraw an address from current use while retaining it for historical resolution, optionally linking to a superseding address.", "inputs": [ "Address identifier", "Reason code", "Superseding address reference where applicable", "Effective time" ], "outputs": [ "Updated address record with retired status", "Retirement decision record", "Address retired event" ], "preconditions": [ "The address exists and is not already retired", "The acting authority is competent for the address's jurisdiction", "Any dependent sub-addresses have a declared cascade outcome" ], "effects": [ "Lifecycle status becomes retired and validity end time is set", "Historic resolution remains available for the declared retention period", "Downstream consumers are notified through the change log" ], "source_refs": [ "SRC-008", "SRC-005", "SRC-001" ] }, { "id": "validate-address", "name": "Validate address", "description": "Test an address record against its governing specification profile and address reference system, returning per-test results and an anomaly status where it fails.", "inputs": [ "Address record version", "Governing specification profile and version", "Address reference system definition", "Validation rule set version" ], "outputs": [ "Per-test pass or fail results", "Anomaly status where applicable", "Validation evidence with execution timestamp" ], "preconditions": [ "The governing profile and reference system are resolvable", "The published validation rule set version is known" ], "effects": [ "Anomaly status is set or cleared on the record", "A test execution record is retained against the specific record version", "Defects are routed to the responsible steward" ], "source_refs": [ "SRC-008", "SRC-014", "SRC-001" ] }, { "id": "render-postal-address", "name": "Render postal address", "description": "Apply a destination country template to stored address components to produce ordered, formatted output lines for postal use.", "inputs": [ "Address record", "Destination country template and version", "Rendering context parameters", "Addressee segment supplied by the party model" ], "outputs": [ "Ordered rendered output lines", "Applied template reference and version", "Report of components that had no target" ], "preconditions": [ "A template exists for the destination country at a known version", "Mandatory components required by the template are present" ], "effects": [ "A rendered representation is produced and may be cached with its template version", "Unmapped components are disclosed rather than dropped silently" ], "source_refs": [ "SRC-002", "SRC-012", "SRC-013" ] }, { "id": "parse-address", "name": "Parse address string", "description": "Decompose an unstructured address string into typed components and locators under a declared country profile, retaining the original string.", "inputs": [ "Unstructured address text", "Assumed country and language or script", "Parser rule set version" ], "outputs": [ "Typed component and locator set", "Parse confidence and unparsed residue", "Original string retained verbatim" ], "preconditions": [ "A parsing profile exists for the assumed country", "Character encoding and script of the input are known or detectable" ], "effects": [ "A structured candidate is produced for matching or validation", "Residue and low confidence are surfaced instead of being discarded" ], "source_refs": [ "SRC-002", "SRC-009", "SRC-013" ] }, { "id": "geocode-address", "name": "Geocode address", "description": "Resolve a structured or unstructured address to one or more reference records and positions, returning scored candidates rather than a forced single answer.", "inputs": [ "Address input or parsed components", "Reference dataset identifier and version", "Acceptance threshold" ], "outputs": [ "Matched address reference and position", "Match score, match type and matched component set", "Candidate set when ambiguous" ], "preconditions": [ "The reference dataset version is available and its licence permits the use", "Normalisation rules for the territory are defined" ], "effects": [ "A reproducible geocoding result record is written with an RFC 3339 execution timestamp", "Ambiguous or interpolated outcomes are flagged for review" ], "source_refs": [ "SRC-013", "SRC-008", "SRC-014", "SRC-015" ] }, { "id": "reverse-geocode-position", "name": "Reverse geocode position", "description": "Resolve a coordinate position to candidate addresses, geographic identifiers or points of interest, qualified by distance and the geometry specification of each candidate.", "inputs": [ "Position geometry with its CRS and epoch", "Search radius or tolerance", "Candidate types requested" ], "outputs": [ "Ranked candidate references with distances", "Geometry specification of each candidate position", "Statement when no candidate meets the tolerance" ], "preconditions": [ "The input CRS is declared and transformable to the reference dataset CRS", "Positional accuracy of the input is stated or assumed and disclosed" ], "effects": [ "Candidates are returned with their own accuracy and specification", "No candidate is asserted as authoritative beyond its stated confidence" ], "source_refs": [ "SRC-004", "SRC-005", "SRC-014" ] }, { "id": "transform-position-crs", "name": "Transform position between reference systems", "description": "Convert or transform a position from one coordinate reference system to another using a declared coordinate operation, preserving epoch and accuracy information.", "inputs": [ "Source position with CRS and coordinate epoch", "Target CRS", "Selected coordinate operation" ], "outputs": [ "Transformed position in the target CRS", "Operation identifier and its stated accuracy", "Combined accuracy statement" ], "preconditions": [ "Both CRSs are resolvable from a geodetic parameter registry with a known dataset version", "The position lies within the operation's area of validity", "A coordinate epoch is present when either CRS is dynamic" ], "effects": [ "Accuracy degradation introduced by the operation is recorded, not hidden", "Axis order and units are adjusted to the target CRS or the target encoding" ], "source_refs": [ "SRC-004", "SRC-010" ] }, { "id": "resolve-geographic-identifier", "name": "Resolve geographic identifier", "description": "Look up a location instance of a declared location type in a gazetteer, returning its identifier, names, relationships and any complementary coordinate reference.", "inputs": [ "Geographic identifier or name query", "Location type", "Gazetteer reference" ], "outputs": [ "Location instance with identifier and names", "Parent and related instance references", "Complementary position or extent where held" ], "preconditions": [ "The gazetteer is the declared custodian of record for the location type", "The territory of use covers the query" ], "effects": [ "Ambiguity across homonyms is surfaced with disambiguating context", "Retired instances are returned marked as historic rather than omitted" ], "source_refs": [ "SRC-003", "SRC-018" ] }, { "id": "attach-location-reference", "name": "Attach location reference to a host subject", "description": "Apply this model as a mixin to a subject in another model by recording a typed binding to an address, geographic identifier, position or code reference, with basis, purpose and effective period.", "inputs": [ "Host subject identifier and owning model", "Reference kind and target reference", "Binding basis and purpose", "Effective from timestamp" ], "outputs": [ "Binding record linking subject and location reference", "Validation result for the binding", "Binding created event" ], "preconditions": [ "The host subject is resolvable in its owning model", "The target location reference exists and is not retired, or its historic use is explicitly permitted", "The binding purpose is among those the target is authoritative for" ], "effects": [ "The host subject becomes locatable without absorbing referencing semantics", "Cardinality and exclusivity rules for the purpose are enforced", "The binding is versioned with RFC 3339 effective timestamps" ], "source_refs": [ "SRC-005", "SRC-001", "SRC-008" ] }, { "id": "publish-reference-release", "name": "Publish reference data release", "description": "Cut a dated, versioned release of a register, gazetteer or reference dataset together with its licence, validation schema and crosswalk pack, and emit the delta since the previous release.", "inputs": [ "Register or gazetteer identifier", "Release scope and cut-off time", "Licence and access conditions", "Suppression and coarsening rules to apply" ], "outputs": [ "Versioned release artifact with release identifier", "Delta or change log since the previous release", "Conformance and quality report for the release" ], "preconditions": [ "All records in scope have a current validation result", "Suppression decisions in force have been applied", "Third-party licence encumbrances permit the intended publication" ], "effects": [ "A citable, serial release exists with an RFC 3339 publication timestamp", "Consumers can reproduce a past state by release identifier", "Sensitive records are coarsened or withheld per the applied rules" ], "source_refs": [ "SRC-012", "SRC-003", "SRC-014", "SRC-008" ] }, { "id": "maintain-address", "name": "Maintain address", "description": "Modify address components, reassign the address to a different object, or retire it while retaining identifier history.", "inputs": [ "Address identifier", "Maintenance event type" ], "outputs": [ "Updated address version record" ], "preconditions": [ "The address exists in the register" ], "effects": [ "Components are modified, the address is reassigned, or the address is retired", "Identifier history remains resolvable" ], "source_refs": [ "SRC-021" ] }, { "id": "rename-thoroughfare", "name": "Rename thoroughfare", "description": "Record an official thoroughfare name change, preserve former names as aliases, and identify affected addresses without silently changing their master identifiers.", "inputs": [ "Thoroughfare identifier", "New official name" ], "outputs": [ "Thoroughfare rename record", "Former-name aliases" ], "preconditions": [ "The actor is the thoroughfare naming authority" ], "effects": [ "Former names remain resolvable as aliases", "Affected addresses are identified without automatic master-identifier change" ], "source_refs": [ "SRC-021", "SRC-026" ] }, { "id": "evaluate-address-quality", "name": "Evaluate address quality", "description": "Measure completeness, logical consistency, positional accuracy, temporal quality, thematic accuracy and usability for a stated scope and use.", "inputs": [ "Evaluation scope", "Product specification and intended use" ], "outputs": [ "Address quality report" ], "preconditions": [ "An intended use is stated, because no universal minimum quality is defined" ], "effects": [ "Quality results are recorded for the stated scope and use" ], "source_refs": [ "SRC-022" ] }, { "id": "crosswalk-profile", "name": "Crosswalk profile", "description": "Map an address or location record between ISO 19160-1 profiles, INSPIRE, FGDC, CLDXF, locn or postal templates, recording lossiness and conflicts.", "inputs": [ "Source profile record", "Target profile" ], "outputs": [ "Mapped record", "Lossiness and conflict log" ], "preconditions": [ "A documented mapping rule exists between the two profiles" ], "effects": [ "Dropped or unmappable elements are recorded rather than invented" ], "source_refs": [ "SRC-020", "SRC-026", "SRC-027", "SRC-019" ] } ], "composition": [ { "target": "Any locatable subject model (host of this mixin)", "relation": "MIX-IN", "purpose": "Supply address, geographic identifier, position and code-reference capability to any subject that must state where it is, without the host absorbing addressing authority, lifecycle or reference-system semantics.", "required": false, "source_refs": [ "SRC-001", "SRC-005", "SRC-003" ] }, { "target": "Building and structure model (legacy U1)", "relation": "REFERENCE", "purpose": "Bind addresses to buildings as addressable objects; the address record carries the reference while the building model owns the structure, its geometry and its condition.", "required": false, "source_refs": [ "SRC-005", "SRC-001" ] }, { "target": "Premises and spatial unit model (legacy U2)", "relation": "REFERENCE", "purpose": "Resolve sub-address locators — building, floor, unit, room and seat levels — to spatial units defined and governed by the premises model.", "required": false, "source_refs": [ "SRC-005", "SRC-009" ] }, { "target": "Land parcel and cadastre model (legacy P2)", "relation": "REFERENCE", "purpose": "Bind addresses to parcels where no building stands, and support positional containment tests against parcel geometry, without importing tenure or rights.", "required": false, "source_refs": [ "SRC-005", "SRC-008" ] }, { "target": "Administrative units and settlements model (legacy U4)", "relation": "REFERENCE", "purpose": "Resolve administrative unit name and address area name components to authoritative administrative units and named places rather than repeating their names as free text.", "required": true, "source_refs": [ "SRC-005", "SRC-007" ] }, { "target": "Transport network model", "relation": "REFERENCE", "purpose": "Link thoroughfare names used for addressing to the transport link features that carry centreline geometry and network topology.", "required": false, "source_refs": [ "SRC-005" ] }, { "target": "Public mandate and authority model (legacy A12)", "relation": "REFERENCE", "purpose": "Resolve the addressing authority and its mandate instrument, jurisdiction extent and effective period, which condition the validity of every assignment act.", "required": true, "source_refs": [ "SRC-008", "SRC-007" ] }, { "target": "Party model (person and organisation)", "relation": "REFERENCE", "purpose": "Supply the addressee and organisation segments needed to render a complete postal address at run time, while keeping party identity outside this model.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "Geodetic parameter registry (external CRS and coordinate operation authority)", "relation": "REFERENCE", "purpose": "Resolve coordinate reference systems, datums, epochs and coordinate operations by authority code and dataset version instead of redefining them.", "required": true, "source_refs": [ "SRC-004" ] }, { "target": "ISO 19160-1:2015 Addressing — Part 1: Conceptual model", "relation": "ALIGN", "purpose": "Align the address record, its components, aliases, lifecycle attributes and metadata with the international conceptual address model, and use its cross-mapping intent as the basis for declared crosswalks rather than assumed equivalence.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "ISO 19160-4:2023 international postal address components and template language, with UPU S42", "relation": "ALIGN", "purpose": "Align postal components, sub-elements, rendering rules and country templates; note that S42 Part A and Part B are the operational carrier of country templates.", "required": false, "source_refs": [ "SRC-002", "SRC-012" ] }, { "target": "ISO 19112:2019 Spatial referencing by geographic identifiers", "relation": "ALIGN", "purpose": "Align location types, location instances, gazetteers and complementary coordinate references so that identifier-based referencing is modelled to the same schema as the coordinate-based path.", "required": false, "source_refs": [ "SRC-003" ] }, { "target": "INSPIRE Addresses application schema 4.0 and Regulation (EU) No 1089/2010", "relation": "ALIGN", "purpose": "Align address component subtypes, locator structure, geographic position specification and the split between real-world validity and record version lifespan with the binding European schema.", "required": false, "source_refs": [ "SRC-005", "SRC-006", "SRC-007" ] }, { "target": "FGDC-STD-016-2011 United States Thoroughfare, Landmark, and Postal Address Data Standard", "relation": "ALIGN", "purpose": "Align address classes, lifecycle status values, address authority lineage and the anomaly-against-reference-system concept; treat it as a national profile, not a universal one.", "required": false, "source_refs": [ "SRC-008" ] }, { "target": "IETF RFC 5139 civic location format and NENA-STA-004.2-2024 CLDXF-US", "relation": "ALIGN", "purpose": "Align civic address element decomposition for emergency location exchange, and adopt the documented FGDC-to-CLDXF crosswalk pattern as evidence that mappings must be maintained explicitly.", "required": false, "source_refs": [ "SRC-009", "SRC-019" ] }, { "target": "IETF RFC 7946 GeoJSON", "relation": "ALIGN", "purpose": "Constrain the position projection: WGS 84 in decimal degrees, longitude before latitude, cut antimeridian geometries, and avoid publishing precision beyond what accuracy supports.", "required": false, "source_refs": [ "SRC-010" ] }, { "target": "IETF RFC 3339 timestamps", "relation": "ALIGN", "purpose": "Fix the encoding of every timestamp in the model, including the explicit-offset requirement and the -00:00 convention for an unknown local offset.", "required": true, "source_refs": [ "SRC-011" ] }, { "target": "W3C and OGC Spatial Data on the Web Best Practices", "relation": "ALIGN", "purpose": "Adopt persistent identifiers for spatial things, declared coordinate reference systems, described positional accuracy, published validation schemas, change information for spatial things, and responsible interaction with spatial data.", "required": false, "source_refs": [ "SRC-014" ] }, { "target": "Open Location Code specification", "relation": "EXTEND", "purpose": "Extend the model's reference kinds with an openly specified, offline-reversible code scheme for places without civic addresses, while recording that shortened codes are not self-contained identifiers.", "required": false, "source_refs": [ "SRC-017" ] }, { "target": "UNGEGN national names authorities and standardised names lists", "relation": "ALIGN", "purpose": "Align toponym language, script, romanisation and standardisation status with nationally standardised names, and treat names authority decisions as the authority for official display forms.", "required": false, "source_refs": [ "SRC-018" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "An adopting Dimension must name a single accountable address registrar or reference-data steward, and record the mandate instrument, jurisdiction extent and effective period that authorise assignment and retirement within its scope.", "It must declare, per territory it operates in, the governing address specification profile, the address reference systems in force, the coordinate reference systems and their dataset versions, and the gazetteers it treats as custodian of record — each by identifier and version, not by name alone.", "It must publish its validation rule set, its crosswalks with versions and known losses, its licence and access conditions, and its retention and suppression rules before publishing any address, position or place record." ], "namespace_guidance": "Use a stable namespace for this model that separates the reference (address, thoroughfare, geocode, reference system, location instance, place, toponym) from the referent, so that a host subject can carry a location reference without inheriting its namespace. Identifiers minted by the Dimension must be namespaced by issuing register and never reuse a retired value; identifiers imported from an external authority keep that authority's namespace and are recorded as alternative identifiers rather than rewritten. Territory-specific profiles belong in sub-namespaces so that two national profiles can coexist without collision.", "registry_links": [ "Vercy registry entry vr.wm-xct-010 (WM-XCT-010, Location Referencing / Address), navigation path NAV.XCT.LOC, entry kind mixin", "External geodetic parameter registry for coordinate reference systems, datums and coordinate operations, cited by authority code and dataset version", "Postal reference data registry for postcodes and delivery points, cited by publisher and dated release identifier", "National gazetteer and names authority registers for location instances and standardised toponyms", "INSPIRE application schema registry for the Addresses theme, cited by schema version" ] }, "canon_and_patch": { "canonicalization_rules": [ "The canonical form is the semantic record — identifiers, components, locators, positions with their specification and method, statuses and timestamps — independent of any encoding; every published form is a derived projection labelled as such.", "Every timestamp is canonicalised to RFC 3339 with seconds and either Z or an explicit numeric offset; an unknown local offset is written -00:00 and is never silently converted to Z.", "Every position is canonicalised with an explicit coordinate reference system cited by authority code and dataset version, plus a coordinate epoch whenever the CRS is dynamic; coordinates are stored at no more precision than the stated accuracy supports.", "Real-world validity and record version lifespan are canonicalised as two independent interval pairs and are never collapsed into a single date range.", "Names, designators and codes are canonicalised with an explicit language tag and script where applicable; the original verbatim form is retained alongside any normalised form." ], "patch_rules": [ "A change is classified before it is applied as either a real-world change, a correction of an error, or an enrichment from a new source; the classification is stored with the resulting version.", "A real-world change closes the prior validity interval and opens a new one; a correction closes the prior record version only and leaves the validity interval unchanged unless the validity itself was the error.", "Patches are additive at the attribute level and carry per-attribute lineage; a superseded value is retained in the change log rather than overwritten in place.", "A patch that would break identifier continuity is rejected and must be expressed as a retirement plus a new assignment linked by supersession.", "Patches to suppressed or sensitive records follow the same audit path as reads and record the acting party and authorisation." ], "compatibility_rules": [ "Adding an optional attribute, an alias, a new alternative identifier, a new projection or a new crosswalk is backward compatible.", "Changing the meaning of an existing code value, tightening a cardinality, or altering the interpretation of an existing position's geometry specification is breaking and requires a new model version and a migration note.", "Conformance claims are version-bound: a claim against one edition of an external standard does not carry to a later edition without a re-executed test.", "A projection that drops fields is permanently marked non-authoritative; consumers must be able to reach the canonical record from any projection.", "Retiring a code value requires a documented successor or an explicit statement that no successor exists; consumers get at least one release cycle of overlap." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the register or authority of record — for example the address identifier from the addressing authority's register, a gazetteer's geographic identifier, a CRS authority code, or a decision number.", "Governed global identifier or resolvable IRI where a recognised scheme exists and commits to persistence.", "UUID or ULID minted by the adopting Dimension, used only when neither of the above exists, and recorded as Dimension-scoped rather than authoritative." ], "timestamp_rule": "All times are recorded per RFC 3339 with seconds and either Z or an explicit numeric offset; an unknown local offset uses -00:00. Event time, real-world validity boundaries, record version boundaries and observation or ingestion time are stored as separate fields and never conflated. A date value is never used as an identifier.", "serial_naming_rule": "Serial artifacts are named by stable artifact identifier plus an ordered release or version token, with the RFC 3339 publication timestamp as metadata rather than as the name — for example a reference dataset release token, a gazetteer release version, a template version per country code, or a decision number issued by the authority. Sequence tokens are monotonic within an artifact identifier and are never reused after withdrawal.", "integrity_rule": "Every published artifact carries the identifier and version of the canonical records it was derived from, the rule-set and crosswalk versions applied, the suppression rules in force at cut-off, and a content digest, so that any consumer can verify that a projection corresponds to a stated register state and detect silent substitution." }, "policies": [ "No conformance to an external standard is claimed without a recorded, re-executable test result; alignments are declared as crosswalks with named losses, and an unmapped element is disclosed rather than defaulted.", "Authority precedes convenience: an address, name or position published without a resolvable authority, governing reference system and lifecycle status is marked provisional and is not usable for legal service, emergency dispatch or delivery.", "Precision is never published beyond stated accuracy, and precision reduction applied for safety is one-way; a coarsened position must not be recoverable from published data.", "Retired references are retained and remain resolvable for the declared retention period with a clear historic marker, because addresses, street names and place names outlive the things they designate.", "Every position carries its coordinate reference system, and every dynamic-CRS position carries its coordinate epoch; a bare coordinate pair is treated as incomplete data.", "Addresses, thoroughfares, geocodes and standardised names are reference assets independent of occupants, owners and current land use.", "The default change operation for withdrawn addresses is retire-and-retain, not physical delete, except where a documented legal erasure right applies to personal addressee data or similarly protected precise location.", "Civic, postal and emergency-service address classes may disagree for the same site; consumers must request the class they need rather than assume equivalence.", "Public gazetteer projections omit occupancy, ownership and, where policy requires, full-precision coordinates.", "ISO 19160-1 is the cross-map hub; alignment with INSPIRE, FGDC, CLDXF, locn or UPU templates is not evidence of conformance unless a test suite result is recorded.", "Coordinate comparison across records is invalid unless CRS, and coordinate epoch for dynamic CRS, are explicit." ], "crud": { "read": [ "Read of published, non-sensitive reference records is open by default to any consumer holding the applicable licence, at the resolution the release permits.", "Reads resolve by identifier; name-based lookup returns a scored candidate set with disambiguating context rather than a single asserted answer.", "Reads of a specific past state are served by release identifier or record version, never by re-deriving from the current state.", "Reads of suppressed or sensitive records require an authorised role, an authorisation reference and an audit entry." ], "create": [ "Only a party holding a mandate in force for the jurisdiction may create an address, thoroughfare name or address reference system record.", "Creation requires the governing specification profile, the reference system identifier and a basis reference; records failing the numbering rules are created only with an explicit anomaly status.", "Third-party contributions — operator POI listings, crowd-sourced positions — are created as candidate records with source lineage and never enter the authoritative set without steward acceptance.", "Every creation opens a record version and emits an event with RFC 3339 timestamps." ], "update": [ "Updates are classified as real-world change, correction or enrichment before application, and always open a new record version rather than mutating a prior one.", "An update may not silently re-point an identifier to a different real-world referent; that requires retirement and new assignment with supersession links.", "Updates to positions must restate the CRS, epoch, geometry specification, method and accuracy; a position may not be updated to higher precision without evidence of higher accuracy.", "Bulk updates from an external source record the source dataset version and the precedence rule applied per attribute." ], "delete": [ "Retirement, not deletion, is the normal end state for addresses, thoroughfare names, place names and location instances, so that historic documents remain resolvable.", "Hard deletion is reserved for records created in error and for data whose retention period has expired under a stated legal or archival basis; the identifier is tombstoned and never reissued.", "Deletion of personal-data-bearing linkages does not delete the underlying location reference unless the reference itself is the personal data.", "Every deletion records the basis, the acting party, the deletion mode and an RFC 3339 timestamp, and is itself retained in the change log." ] }, "roles": [ { "name": "Address registrar / reference steward", "responsibilities": [ "Assign, amend and retire addresses and thoroughfare names within the mandated jurisdiction", "Maintain the address reference systems and their numbering rules", "Decide supersession, cascade and grace-period outcomes for renaming and object change", "Accept or reject third-party candidate records into the authoritative set" ] }, { "name": "Geodetic and reference-system custodian", "responsibilities": [ "Declare the coordinate reference systems, dataset versions and coordinate operations in force", "Ensure dynamic-CRS positions carry a coordinate epoch and that transformations stay within their area of validity", "Approve changes to the positional accuracy and precision policy", "Maintain the register of gazetteers treated as custodian of record per location type" ] }, { "name": "Names authority liaison", "responsibilities": [ "Track national names authority decisions and reflect standardised toponym forms, language, script and status", "Maintain romanisation and display-form rules per audience locale", "Record contested, reinstated and historic name forms without erasing prior ones", "Advise on culturally sensitive naming changes before publication" ] }, { "name": "Quality and conformance officer", "responsibilities": [ "Publish and version the validation rule set and run it against every record version", "Maintain anomaly status handling, defect routing and resolution deadlines", "Execute and retain conformance tests behind every alignment claim, and maintain crosswalks with named losses", "Produce release-level quality and conformance reports" ] }, { "name": "Access, licensing and protection officer", "responsibilities": [ "Maintain licence and redistribution conditions, including encumbrances inherited from contributed components", "Classify sensitivity, approve suppression and coarsening rules, and set review dates", "Define retention periods and deletion modes per record class and their legal basis", "Operate and audit the lawful-access route for authorised responders" ] }, { "name": "Integration and projection engineer", "responsibilities": [ "Derive every published projection from the single canonical record and label non-authoritative ones", "Enforce encoding constraints such as fixed axis order and antimeridian handling in position projections", "Maintain the AGENTS.md bootstrap contract and keep its URLs resolvable", "Emit deltas and change logs so consumers can reconstruct any past release state" ] } ], "access": { "default_rule": "Published, non-sensitive location reference records are readable by default under the declared licence; creation, amendment and retirement are restricted to the mandated authority and its delegates; sensitive or suppressed records are closed by default and opened only through a named exception with an audit entry.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Suppressed or coarsened records — protected persons, shelters, sensitive sites — are withheld or degraded in public projections while remaining available in full to authorised emergency and law-enforcement roles through the recorded lawful-access route.", "Licence-encumbered components contributed by third parties may be withheld from open releases even where the surrounding record is open, with the encumbrance disclosed rather than the record silently truncated.", "Pre-active addresses in potential or proposed status are visible to the authority and to permit applicants but are not published as usable references until they become active.", "Personal-data-bearing linkages between a location reference and an identified person are accessible only under a stated lawful basis and are excluded from bulk projections.", "Historic and retired records remain readable for resolution but are marked historic and are excluded from projections intended for current operational use, such as delivery routing and dispatch.", "Legal erasure of personal postal addressee data.", "Emergency-only indoor locators and service addresses.", "Precision reduction or withholding of coordinates for protected sites.", "Embargoed assignment events before public announcement of a street name or numbering scheme." ], "audit_requirements": [ "Every read of a suppressed, sensitive or personal-data-linked record records the acting party, the authorisation reference, the purpose and an RFC 3339 timestamp.", "Every assignment, amendment, retirement and deletion records the acting party, the mandate relied upon, the change classification and the resulting record version.", "Every published release records the canonical record versions, rule-set and crosswalk versions and suppression rules applied at cut-off, together with a content digest.", "Audit entries are immutable, retained at least as long as the records they describe, and themselves subject to the declared retention and deletion policy.", "Access exceptions are reviewed on their recorded review date, and the review outcome is written back as a new decision version rather than an in-place edit.", "Every create, status change, reassignment, geocode revision, quality evaluation and privileged read of full-precision or personal location data must record actor, role, event time and ingestion time.", "Identifier reuse without an explicit reassignment event is an integrity incident." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID and registry ID", "Entry kind and composition role", "Authority and steward contact", "Licence and access conditions URL", "Coordinate reference system and epoch policy URL", "Crosswalk and conformance evidence URL" ], "read_order": [ "AGENTS.md — identify the model, its type, and where its specification, storage, interface and process contracts live", "Specification URL — read scope, boundaries and the bundle, layer and finding structure before touching any record", "Storage type URL — learn the projection in use (register, document store, graph, file tree) and that it is a projection, not the semantics", "Interface URL — learn how to resolve identifiers, request past releases and negotiate projections", "Processes URL — learn the assignment, validation, publication, suppression and retention procedures and which role may invoke each", "Licence and access conditions URL — confirm permitted use before reading, deriving from or redistributing any record" ] } }, "coverage": { "claim": "The merged model covers the decision and operating surface of location referencing as a governed mixin: address identity, class profile, components and locators, assignment authority and numbering rules, dual-axis lifecycle (real-world validity versus record version lifespan), binding to the addressable object, thoroughfare naming and continuity, postal descriptors and template rendering, position with geometry specification, method, accuracy, CRS and coordinate epoch, geographic identifiers and gazetteers, code-based references, points of interest, toponyms, matching, quality (now including the ISO 19160-3 element and measure vocabulary imported from grok), per-attribute provenance, licensing, protection and interoperability. It is explicitly not a claim of universal completeness: the source set skews to ISO, the EU, the US and the UPU; linear referencing along addressing features, non-OLC grid families and national register profiles are unmodelled; and the privacy, suppression and retention content remains a structural placeholder pending jurisdiction-specific legal grounding.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "ISO 19160-1 makes the unique identifier mandatory for lifecycle-conformant address classes; INSPIRE supplies inspireId and alternativeIdentifier; FGDC supplies Address ID; W3C/OGC best practice requires persistent HTTP URIs for spatial things. Identity priority and the rule that a date is never an identifier are enforced in artifact rules." }, { "dimension": "lifecycle", "status": "covered", "notes": "FGDC Address Lifecycle Status (potential, proposed, active, retired) plus Address Official Status; INSPIRE status with validity; ISO 19160-1 lifecycle conformance class. Transitions, authorising roles, evidence and post-retirement resolvability are all questioned." }, { "dimension": "relationships", "status": "covered", "notes": "INSPIRE associations (building, parcel, parentAddress, component, situatedWithin, adminUnit, transportLink) and ISO 19112 parent/child location instances ground the binding, component and gazetteer relationship findings. W3C/OGC best practice on using appropriate relation types is adopted." }, { "dimension": "temporal", "status": "covered", "notes": "The INSPIRE separation of validFrom/validTo from beginLifespanVersion/endLifespanVersion is modelled as two independent axes, with observation/ingestion time recorded separately and all timestamps constrained by RFC 3339 including the -00:00 unknown-offset convention. Coordinate epoch is treated as a distinct temporal concern under ISO 19111." }, { "dimension": "provenance", "status": "covered", "notes": "Overture per-property sources with confidence and timestamps, FGDC address lineage attributes including Address Authority, and W3C/OGC change-information practice ground per-attribute lineage, precedence between conflicting sources and retention of rejected assertions." }, { "dimension": "ownership", "status": "covered", "notes": "Addressing authority and mandate, record stewardship distinguished from ownership of the object addressed, and contributor rights per attribute are covered. Ownership of the referent itself is deliberately excluded and delegated to sibling models." }, { "dimension": "validation", "status": "covered", "notes": "FGDC quality part and Address Anomaly Status (an address not correct under its governing Address Reference System), W3C/OGC practice of exposing validation schemas online, and reference-system conformity, duplication and positional containment tests are modelled with retained execution evidence." }, { "dimension": "access", "status": "covered", "notes": "Licence, redistribution, statutory publication duty and encumbrance inherited from contributed components are modelled; scopes cover bundle, layer, finding and artifact, with named exceptions and audit obligations." }, { "dimension": "retention and deletion", "status": "gap", "notes": "No primary source in this set specifies normative retention periods or deletion modes for address registers, geocoding logs or suppression decisions; those derive from national archives and records law that was not researched. The model provides the fields, roles and policy hooks but the periods themselves must be set per jurisdiction and are marked provisional." }, { "dimension": "interoperability", "status": "covered", "notes": "ISO 19160-1 exists to enable cross-mapping between address specifications; NENA-REF-007.1-2024 evidences that FGDC-to-CLDXF conversion needs an explicit maintained crosswalk; RFC 7946 imposes hard encoding constraints. Conformance claims require executed test evidence." }, { "dimension": "spatial referencing", "status": "covered", "notes": "ISO 19111 for CRS, dynamic CRS and coordinate epoch; ISO 19112 for geographic identifiers and gazetteers; INSPIRE GeographicPosition for what a position specifies and by what method; Open Location Code for code-based references and their precision-by-length behaviour." }, { "dimension": "classification", "status": "covered", "notes": "FGDC address classes, ISO 19160-1 address class profiles, RFC 5139 civic address types, Overture multi-level POI categories including a basic-level category, and ISO 19112 location types give independent classification grounding." }, { "dimension": "authority and mandate", "status": "covered", "notes": "FGDC records Address Authority as a lineage attribute; Regulation (EU) No 1089/2010 provides a statutory example of binding interoperability requirements; UNGEGN establishes national names authorities. Jurisdiction extent, overlap precedence and non-authoritative origin are all questioned." }, { "dimension": "measurement and accuracy", "status": "covered", "notes": "W3C/OGC practice on describing positional accuracy and appropriate precision, RFC 7946 guidance that six decimal degrees is roughly ten centimetres, and Open Location Code precision from about 2226 km to about 4x14 mm ground the accuracy and meaningful-precision finding." }, { "dimension": "privacy and safety", "status": "gap", "notes": "ISO 19160-4 explicitly excludes data protection specification and no address standard in this set normatively defines suppression, coarsening or re-identification thresholds. The finding is grounded only in W3C/OGC responsible-use best practice and general reasoning; treat its content as a structural placeholder requiring jurisdiction-specific legal grounding." }, { "dimension": "multilingual naming", "status": "covered", "notes": "UNGEGN mandate for multilingual and culturally informed naming, UPU's observation that at least twenty scripts are in official addressing use, and INSPIRE geographical name structures ground language, script, romanisation and official-status modelling." }, { "dimension": "process and events", "status": "covered", "notes": "Assignment, retirement, renaming, revision, registration and closure are modelled as authority acts with decision records and change-log entries rather than as bare status fields, grounded in FGDC lineage and INSPIRE version lifespans." }, { "dimension": "evidence and quality", "status": "covered", "notes": "Binding basis, conformance test evidence, quality reports, match reproducibility with reference dataset and engine versions, and Overture-style existence confidence with a publication threshold are all modelled as retained evidence rather than assertions." } ], "known_omissions": [ "ISO 19160-2 (assigning and maintaining addresses), ISO 19160-3 (address data quality) and ISO 19160-5 (address rendering) were not retrieved; no claim is made about their content, and the assignment, quality and rendering findings here are grounded in other sources that may diverge from them.", "ISO 19157 data quality, ISO 19115 metadata, ISO 19148 linear referencing, IndoorGML, OGC API - Features, GeoSPARQL and OASIS xAL/CIQ were not consulted; the quality-measure vocabulary and the graph/API projections are therefore under-specified.", "Direct HTTPS fetches of the FGDC and NENA pages returned HTTP 403; their element names, status values and standard designations were obtained through the search index rather than read verbatim from the documents. Element-level detail attributed to SRC-008 and SRC-019 should be treated as indicative and re-verified against the published PDFs before implementation.", "ISO documents are paywalled: titles, editions, dates, statuses and published scope/abstract text were verified, but normative clause text, full UML class diagrams and conformance test specifications were not read. Nothing here asserts conformance to an ISO conformance class.", "The UPU S42 PDF and the ISO 19160-1 sample PDF could not be parsed as text; S42 structure is grounded in the UPU's own web description of Part A and Part B rather than the standard text.", "Proprietary location schemes such as three-word address systems were not evaluated; the code-based reference finding is grounded only in an openly specified scheme and may under-represent vendor-dependent alternatives.", "No source was consulted on address handling in informal settlements, refugee camps, disputed territories or unaddressed rural areas beyond the general motivation stated by the Open Location Code project.", "Address matching and geocoding algorithm families, and certification regimes for address standardisation software, were not researched beyond the existence of national postal standardisation guidance.", "Full ISO 19160-1 UML class diagrams remain paywalled; component lists are grounded in public abstracts plus INSPIRE/SEMIC properties rather than the complete UML.", "UPU S42 Version 8 text is cited through ISO 19160-4 rather than a first-party UPU HTML publication.", "ISO 19148 linear-referencing operations were not fetched from iso.org in this run; linear locations are grounded in FGDC and marked as an alignment gap for operations.", "What3Words and other proprietary three-word encodings have no open primary specification here and are excluded.", "National registers such as UK UPRN/AddressBase, Australia G-NAF, Netherlands BAG, France BAN and AS/NZS 4819 are profiles not modelled instance by instance.", "H3, S2, MGRS, GARS, Maidenhead and Geohash are recognised geographic-identifier families but lack dedicated primary fetches in this run except GeoHash as a locn encoding option.", "IndoorGML and indoor routing graphs are sibling omissions; only civic locators are in scope.", "A dedicated international POI category vocabulary was not found among the primary sources; POI category is a local extension gap.", "Physical address-sign assets as built-environment objects are a process in ISO 19160-2, not a signage product model.", "Japan chome/banchi and Korea dual jibun/road-name systems are acknowledged as regional numbering cultures, not fully encoded profiles." ], "conflicts": [ "Temporal modelling conflicts between sources: INSPIRE separates real-world validity (validFrom/validTo) from record version lifespan (beginLifespanVersion/endLifespanVersion), while FGDC combines a lifecycle status with start and end dates. This model adopts the INSPIRE separation and treats the FGDC pattern as a lossy projection of it — an explicit design choice, not a neutral merge.", "Axis order conflict: RFC 7946 fixes WGS 84 with longitude before latitude for GeoJSON, while ISO 19111 lets the coordinate reference system define axis order, and widely used geographic CRS definitions order latitude first. Any position projection must state which convention applies; silent reliance on either causes transposed coordinates.", "Class-model conflict: FGDC address classes (numbered thoroughfare, landmark, postal delivery), INSPIRE's locator-and-component structure, and RFC 5139's flat civic-type list have no one-to-one mapping. Landmark addresses in particular have no first-class INSPIRE equivalent. Crosswalks must be declared with losses rather than assumed.", "Postal versus civic conflict: FGDC states that postal delivery addresses may bear no definite relation to the recipient's location, and Overture carries a postal_city that may differ from the actual locality. Treating a postal address as a location reference is therefore unsafe without a declared role.", "Standard-lineage claim not verified: secondary material describes UPU S42 as registered as ISO 19160, but the UPU's own addressing page does not state a relationship to ISO 19160-4, and ISO publishes 19160-4 as its own standard with a 2023 second edition. This model treats S42 and ISO 19160-4 as aligned but distinct, and makes no equivalence claim.", "Identifier self-containment conflict: shortened Open Location Codes require an external reference location to be recovered, so they fail the self-contained identifier test even though the scheme is openly specified and offline-reversible for full codes.", "Governance conflict: postcodes are modelled by INSPIRE as an address component (PostalDescriptor) but are maintained by postal operators as routing keys with their own release cycle and licence. This model keeps them as components with an optional, explicitly non-authoritative extent, and records that the two views disagree about what a postcode is.", "NENA: a postal address is frequently not valid for emergency service; civic, postal and service addresses can differ for one site.", "ISO 19160-1 is a cross-map hub and is not intended to replace other conceptual models; claiming a single global address class is false.", "SEMIC locn is more flexible than INSPIRE Address; INSPIRE-conformant detail can be expressed in locn, but the reverse is not generally true.", "RFC 5870 excludes civic addresses and complex geometries from geo URI; coordinates and civic references are complementary, not substitutes.", "Plus Codes encode areas, not points, and shortened codes are ambiguous without a nearby reference location.", "ISO 19160-4 adds telephone number as a postal address element, which collides with a contact/party sibling if treated as location semantics.", "WGS-84 default in RFC 5870 versus national projected CRS required by many address maps; comparison without transformation is invalid.", "FGDC, CLDXF and USPS Publication 28 share US ancestry but serve repository, emergency-exchange and postal-rendering purposes that still conflict in classification." ], "regional_assumptions": [ "The primary sources skew to ISO, the European Union, the United States and the Universal Postal Union. No primary source was consulted for East Asian block-and-lot addressing (for example chōme-banchi systems), South Asian, Middle Eastern or African national addressing conventions beyond the generic template mechanism, so the component and locator vocabularies may be incomplete for those regions.", "The model assumes that an addressing authority with a mandate exists and that a governing numbering scheme is identifiable. Large parts of the world lack assigned civic addresses entirely — the stated motivation for open code schemes — and in those settings the address-centred bundles degrade to code and geographic-identifier referencing.", "Postcode semantics are assumed to vary: some territories have no postcode, some postcodes are routing keys without a stable geographic extent, and some are areas. The model does not assume a postcode is an area.", "Sub-address vocabulary (secondary unit designators, floors, rooms) is grounded chiefly in United States practice and RFC 5139; other jurisdictions use different level structures that may not map cleanly.", "The separation of real-world validity from record version lifespan is a European modelling convention adopted here as the canonical form; registers built to other national standards will need a migration rather than a field rename.", "Retention, suppression and personal-data treatment are assumed to be set by national law that was not researched; the European regulatory context is the only legal context represented in the source set, and even there only through an interoperability regulation rather than data protection law.", "ISO 19160-2's typical registrar is a local government supported by national and postal agencies; some states use a national address register as master.", "Thoroughfare-plus-locator civic form is treated as the common international pattern; it does not cover all numbering cultures.", "WGS-84 / EPSG 4326 or 4979 is the default exchange CRS for compact geo identifiers; national mapping CRS remain first-class for local geocodes.", "Latin-script postal rendering and ISO 3166-1 country codes are default exchange practice; UNGEGN romanisation is required when the endonym is non-Roman.", "European INSPIRE constraints (country component, default geographic position, lifespan versioning) apply to EU public-sector exchange, not globally.", "US FGDC and NENA CLDXF content is authoritative for United States thoroughfare taxonomy and NG9-1-1 civic exchange, not for other states." ], "adversarial_checks": [ "Tested whether a geocode can be collapsed into a plain coordinate attribute of the address. Rejected: INSPIRE requires every geographic position to declare what it specifies, by what method and whether it is the default, and ISO 19111 requires a CRS and, for dynamic systems, a coordinate epoch. A bare coordinate pair loses information that is normatively required, so position is modelled with its own qualifying structure.", "Tested whether a POI belongs in this model at all. Overture separates places — with operating status, existence confidence, brand and contact channels — from addresses, and much of that is business-entity data. Resolution: only the referencing facets (identity, category, position, status, name, address resolution, confidence) are retained here; operator, brand and contact data are pushed to sibling models, and the finding says so.", "Tested whether an address is one thing or two. FGDC states that postal delivery addresses may have no definite relation to the recipient's location, so a single entity that silently serves both location and delivery roles is wrong. Resolution: an explicit address role is required, and the purpose for which a binding is authoritative is modelled separately from the binding itself.", "Tested whether thoroughfare geometry should be owned here. Rejected: INSPIRE ThoroughfareName carries only a transportLink association, leaving centreline geometry and topology to the transport network theme. Owning geometry here would duplicate a sibling model and create two sources of truth for road position.", "Tested whether a date can serve as a version identifier for an address record. Rejected under the identity rule: multiple versions can share a date, and dates carry no issuing authority. Version identity uses a register key plus a monotonic sequence, with RFC 3339 timestamps as metadata.", "Tested whether 'postcode' should be promoted to a reference system rather than a component. Evidence is genuinely split — INSPIRE models it as an AddressComponent while the UPU maintains it as versioned routing reference data with its own release cadence. Resolution: kept as a component with an optional, explicitly flagged non-authoritative extent, and the disagreement is recorded as a conflict rather than resolved by fiat.", "Tested whether claiming alignment with ISO 19160-1 could be stated as conformance. Rejected: the normative clause text and conformance tests were not read, and no test was executed. All external standards are recorded as alignments, and the model requires executed test evidence before any conformance class is claimed.", "Tested whether an open code scheme could replace address identity where no civic address exists. Partially rejected: full codes are deterministic and offline-reversible, but shortened codes need an external reference location and codes containing padding must not be shortened, so codes are modelled as derived value objects rather than as authoritative identifiers.", "If an agent treats an address as an attribute of a building, it will drop historic addresses after demolition; ISO 19160-2 requires independent assignment and retirement.", "If an agent geocodes without a CRS, ISO 19111 and RFC 5870 make the point ambiguous and comparisons unsafe.", "If an agent uses a postal form for emergency dispatch, NENA states that postal addresses are frequently invalid for 9-1-1.", "If an agent treats a Plus Code as a point coordinate or recovers a short code without a nearby reference, location error follows from the OLC definition.", "If an agent deletes retired addresses to tidy a database, provenance and alias resolution required by ISO 19160-1/2 are destroyed.", "If an agent claims INSPIRE or ISO 19160-4 conformance solely because locn or FGDC fields are populated, the claim is unevidenced." ] }, "researchAdjudication": { "boundaryDecision": { "entry_kind": "mixin", "status": "accepted", "rationale": "Both providers independently derived entry_kind=mixin for the same registry id, and both draw the same outer boundary: the address, geocode, geographic identifier, toponym and POI are governed reference records with their own identity and lifecycle, while the addressed object (building, premises, parcel), the party (addressee, occupier, owner), the transport network geometry, the geodetic parameter registry and the public-law mandate instrument stay in sibling models and are referenced only. The base provider supports that boundary with eight source-cited boundary notes plus adversarial tests that were run against the hardest cases (POI versus business entity, thoroughfare geometry ownership, geocode collapse into a bare coordinate, postal versus civic role), so the boundary is accepted as drawn rather than split or reclassified." }, "decisions": [ { "concept": "Base provider selection", "disposition": "accepted: claude as base", "rationale": "Claude states eight source-cited boundary notes against named sibling models, a seventeen-item in-scope and ten-item out-of-scope list, and per-finding inline_only_rationale explaining why a concept carries no artifact. Grok's boundaries are sound but coarser (six notes) and it collapses authority, reference-system rules, lifecycle and object binding into a single finding. The decision rests on boundary clarity and separation of concerns, not on the 27-versus-16 finding count." }, { "concept": "ISO 19160-3 quality elements and measures", "disposition": "accepted as an addition into matching-and-quality", "rationale": "Closes a gap the base itself declares as a known omission, using a tier-1 source the base never retrieved, and is conceptually distinct from the base's rule-conformance and anomaly-status finding rather than a restatement of it." }, { "concept": "ISO 19160-2 assignment, maintenance and authority (grok finding)", "disposition": "rejected as a finding; source deferred for retrieval", "rationale": "Grok's single finding is spread across four base findings — addressing-authority-and-jurisdiction, address-reference-system-rules, address-lifecycle-status and finding-addressable-object-binding — so importing it would duplicate structure. The underlying source is genuinely absent from the base and is carried instead as deferred research plus a publication hold, with reassignment-to-a-different-object and physical signage installation named as the specific content to re-check once the normative text is available." }, { "concept": "Linear referencing along addressing features", "disposition": "deferred, not added", "rationale": "The base already covers street-segment interpolation as a position specification and block ranges, intervals and parity under address reference system rules, so the concept is partly covered; grok grounds the finding on a single source (FGDC) whose element-level detail neither provider read verbatim, and concedes ISO 19148 was not fetched. Overriding the base's explicit, source-cited transport-network boundary on that evidence would be weakly supported structure." }, { "concept": "Gazetteer location instances (grok finding)", "disposition": "rejected as duplicative", "rationale": "The base finding geographic-identifier-and-gazetteer already models ISO 19112 location types, instance nesting and adjacency, custodian of record, complementary coordinate references and instance lifecycle. Grok adds no element the base lacks." }, { "concept": "Geo URI and locn interchangeable geometry encodings", "disposition": "rejected as a finding; folded into existing scope", "rationale": "Compact and alternative encodings of a position are projections of one canonical record, which the base already governs in crosswalks-conformance-and-encodings alongside the RFC 7946 constraint. This belongs at question level inside that finding, not as new structure, and adding it would create a second home for encoding rules." }, { "concept": "POI framing", "disposition": "base framing retained; grok finding rejected", "rationale": "Both providers agree only the referencing facets of a POI belong here and that category vocabularies are local extensions rather than ISO-standard; the base states this as an adversarial check and models identity, category, operating status, address resolution and existence confidence. Grok's parallel finding restates it with weaker grounding." }, { "concept": "Profile crosswalk and conflicts (grok finding)", "disposition": "rejected as a finding; accepted as a function", "rationale": "The base's crosswalks-conformance-and-encodings finding already requires declared lossiness and executed conformance-test evidence, so the finding would duplicate. The missing piece was operational, which is why crosswalk-profile is imported as a function instead." }, { "concept": "Engineering and moving-platform CRS", "disposition": "rejected", "rationale": "Grok's CRS finding extends to engineering CRS and CRS on moving platforms. These are ISO 19111 capabilities with no addressing use case in this model, and the base explicitly delegates geodetic infrastructure to an external parameter registry. Importing them would widen the boundary the base deliberately drew." }, { "concept": "Plus Code encode, shorten and recover operation", "disposition": "rejected", "rationale": "The base treats code references as derived value objects computed deterministically from coordinates and a scheme, and is format-neutral by design; naming a single vendor-originated scheme in the function set would privilege one encoding over the code-scheme-neutral treatment the base argues for. The capability is reachable through the existing code-based-reference finding." }, { "concept": "Dual temporal axis (real-world validity versus record version lifespan)", "disposition": "base design choice retained", "rationale": "The base adopts the INSPIRE separation and records the FGDC combined-status-with-dates pattern as a lossy projection of it, declaring this as a design choice rather than a neutral merge. Grok independently models the same separation, so the two providers agree and no adjudication is needed; the European-convention assumption stays recorded as a regional assumption." }, { "concept": "Civic versus postal versus emergency-service address roles", "disposition": "base treatment retained, reinforced by grok evidence", "rationale": "The base requires an explicit address role and models the purpose for which a binding is authoritative separately from the binding. Grok's NENA-sourced statement that a postal address is frequently invalid for emergency service corroborates the same rule and needs no new structure." }, { "concept": "Low-similarity cross-matches in the comparison report", "disposition": "treated as metric noise", "rationale": "The comparison pairs address-identity with access-privacy-retention at 0.508 and licensing-and-access with coordinate-point-precision-and-encoding at 0.53. These are not real correspondences and must not drive merge behaviour; only the high-similarity pairs (postal-delivery, reference-systems, points-of-interest) reflect actual overlap." }, { "concept": "Service layer merging", "disposition": "accepted", "rationale": "The base's assurance-access-exchange bundle and grok's quality-interop-and-stewardship bundle address the same cross-cutting service concerns, so the merged model keeps a single service layer set under the base's finer decomposition rather than carrying two parallel groupings." }, { "concept": "EUR-Lex Regulation 1089/2010 citation", "disposition": "adopt grok's consolidation date as the pin", "rationale": "The base cites the 2014-12-31 consolidated text while grok cites the 2023-11-19 consolidation of the same instrument. The later consolidation supersedes the earlier one for any statement about the Addresses theme, so the source pin moves to grok's version and the change is recorded as a publication hold requiring a live check." } ], "publicationHolds": [ "Source verification, FGDC and NENA: the base's direct HTTPS fetches of FGDC-STD-016-2011 Part 2 and NENA-STA-004.2-2024 returned HTTP 403, so element names, address class values, anomaly status values and lifecycle status values attributed to those sources came from a search index rather than the published documents. Re-verify verbatim before publication and mark any element-level claim provisional until then.", "Source verification, paywalled ISO standards: neither provider read the normative clause text, full UML or conformance test specifications of ISO 19160-1, 19160-2, 19160-3, 19160-4, 19112 or 19111. The imported ISO 19160-3 quality element list rests on public scope and abstract text. No conformance class may be claimed for any of these standards; all are to be published as alignments only.", "Standard lineage unverified: the providers disagree on the UPU S42 to ISO 19160-4 relationship. Grok attributes ISO 19160-4 to ISO/TC 211 together with UPU S42 Version 8, while the base records that the UPU's own addressing page states no such relationship and treats the two as aligned but distinct. Publish no equivalence or derivation claim until a first-party UPU or ISO statement is read.", "Live-version pinning: the two providers cite the same standards through different URL families (iso.org versus committee.iso.org), different EUR-Lex consolidations (2014-12-31 versus 2023-11-19), and different Open Location Code artefacts (a pinned raw specification file versus a living repository). Resolve to one live-checked canonical URL and explicit version pin per source before publication.", "Multi-profile validation incomplete: the model has been validated only against ISO, EU/INSPIRE, US (FGDC, NENA, USPS) and UPU profiles. Component, locator and numbering vocabularies are unvalidated for East Asian block-and-lot systems (Japan chome-banchi, Korea dual jibun and road-name), South Asian, Middle Eastern and African conventions, and for settings with no assigned civic addresses at all. Hold publication of any universality statement until at least one non-Western national profile has been run through the model.", "Privacy, suppression and retention remain a structural placeholder: ISO 19160-4 explicitly excludes data protection specification and no consulted source normatively defines suppression thresholds, coarsening rules, re-identification limits or retention periods. The relevant findings provide fields, roles and policy hooks only, and must be published as requiring jurisdiction-specific legal grounding rather than as canonical guidance." ], "deferredResearch": [ "Retrieve ISO 19160-2:2023 and ISO 19160-5 and re-check the assignment, maintenance and rendering findings against normative text, specifically reassignment of an address to a different object and whether physical address-sign installation belongs in the addressing process or is fully delegated to a sibling model.", "Retrieve ISO 19157 and ISO 19115 to ground the quality measure vocabulary and dataset metadata behind the imported ISO 19160-3 finding, and ISO 19148 to decide whether linear reference locations along addressing features warrant a finding in the spatial-referencing bundle or stay excluded with the transport network.", "Research non-Western addressing cultures — Japan chome-banchi, Korea dual jibun and road-name, South Asian, Gulf and African conventions — and confirm whether the component, locator and sub-address vocabularies survive them or need profile-specific extension.", "Research national register profiles (UK UPRN and AddressBase, Australia G-NAF, Netherlands BAG, France BAN, AS/NZS 4819) to test the identity, uniqueness-scope and lifecycle rules against operating master registers rather than standards alone.", "Research grid and geographic identifier families beyond Open Location Code — H3, S2, MGRS, GARS, Maidenhead, Geohash — and settle the treatment of proprietary three-word schemes that lack an open first-party specification.", "Research retention, erasure and lawful-access law per jurisdiction to replace the placeholder retention periods and suppression rules, including how a legal erasure right interacts with the retire-and-retain default for historic addresses.", "Research address matching and geocoding algorithm families and any certification regimes for address standardisation software, which neither provider examined beyond the existence of national postal guidance." ] }, "statistics": { "sources": 33, "bundles": 6, "layers": 16, "findings": 28, "questions": 128, "artifacts": 22, "functions": 15 } }