Record Quality & Compliance

Overall outcome of the most recent validation pass. The WIM platform blocks publication of any record whose validation_status is not passed. A single failed check sets this field to failed regardless of how many other checks passed.

UUID of the user account or automated service that performed the most recent validation pass. For automated pipeline validators, this references the service identity registered in the tenant's system registry. Updated on every validation run.

UTC timestamp of when the most recent validation pass completed. Used by governance dashboards to flag records whose last validation is stale — records older than the site's re-validation interval must be re-checked before serving to consumers.

Format: ISO 8601 — Timezone: always UTC (Z)

How the validation was conducted. Distinguishes fully automated pipeline checks from human-in-the-loop reviews, which carry higher governance weight for regulated environments such as healthcare campuses and transport hubs.

Identifier of the validation tool, system, or service that ran the check — for example, the WIM Validator CLI version, an external certification body, or a third-party GIS audit service. Enables reproducibility: knowing the tool allows the same check to be re-run against a later revision.

Max: 128 chars — Convention: TOOL-VENDOR-VERSION slug

Versioned identifier of the rule set applied during this validation pass. Rule sets are maintained centrally and versioned; a given rule set version always produces the same result for the same input, making validation outcomes deterministic and auditable over time.

Format: RULESET-ID@semver — Example: wim-core@1.0 · accessibility@2.1

Whether the record's full JSON structure passes validation against the WIM JSON Schema for the declared wim.schema_version. A false value here immediately sets validation_status to failed. All other checks are skipped until schema validity is confirmed.

Whether any standards compliance checks have been executed during this validation pass. When false, all *_valid and *_checked fields must be treated as indeterminate rather than passing. Used to distinguish a record that genuinely passed checks from one that was never checked at all.

Overall rolled-up compliance level across all checked standards. Computed automatically as the lowest compliance level of any individual standard check. full means every applicable check passed. partial means at least one check failed but others passed. none means no standards checks passed.

Whether the spatial geometry in the record's topology and place objects conforms to the OGC IndoorGML 1.1 standard. IndoorGML governs the indoor spatial model: cells, transitions, and the navigation network. Required for all records where routing graph generation is enabled.

Standard: OGC IndoorGML 1.1

Whether the record's geometry and feature identifiers conform to Apple's Indoor Mapping Data Format (IMDF) 1.0. IMDF validity is required for records intended for delivery to Apple Maps, iOS indoor positioning, and IMDF-native routing engines. Governs venue, level, unit, opening, and anchor feature types.

Standard: IMDF 1.0 — Governs: venue, level, unit, opening, anchor

Whether the record's spatial data conforms to the OGC CityGML 3.0 standard, which governs the semantic 3D city model including buildings, rooms, and indoor infrastructure. Required for records shared with BIM or GIS systems that consume CityGML as their canonical spatial format.

Standard: OGC CityGML 3.0

Whether the record's accessibility object has been checked against the EN 17210 standard for accessibility and usability of the built environment. EN 17210 governs step-free routes, tactile guidance, hearing loops, and low-stimulation path designation. Required for all public-facing destinations in the EU.

Standard: EN 17210:2021

Whether the record's channels output objects have been checked for WCAG 2.2 Level AA compliance. Applies to digital screen, kiosk, and web channel renderings. Required for public-sector operators under the EU Web Accessibility Directive and UK Equality Act.

Standard: WCAG 2.2 Level AA — Applies to: digital channel outputs

Automated completeness score for the record, expressed as a float between 0.0 and 1.0. Computed by the validator as the proportion of recommended (not just required) fields that are populated with non-null values. Records below 0.7 are flagged for steward review; records below 0.5 cannot be published.

Range: 0.0 – 1.0 — Publish block: < 0.5 — Review flag: < 0.7

Overall GDPR compliance status of this record. Covers data minimisation, lawful basis, retention periods, and privacy-by-design obligations. Any record with a sensory object containing camera or Wi-Fi probe data must reach compliant before publication.

Whether a human GDPR review has been conducted for this record, in addition to automated checks. Required for records that contain personal data references or link to sensor types that could facilitate individual tracking. Automated checks alone are insufficient for these record types.

UTC timestamp of when the most recent human GDPR review was completed. Used to determine whether the review is still current — most operators require re-review annually or whenever the record's sensory configuration changes.

Format: ISO 8601 — Timezone: always UTC (Z)

Whether the record's data architecture has been verified to follow Privacy by Design principles as required by GDPR Article 25 — specifically: data minimisation, purpose limitation, storage limitation, and default privacy. Required for all records involving occupancy sensors, cameras, or Bluetooth/Wi-Fi tracking.

Standard: GDPR Art. 25 — Privacy by Design & Default

Whether the automated validator detected any field values that could constitute personal data under GDPR — for example, names in free-text fields, individual-level sensor readings, or non-anonymised camera counts. When true, a mandatory GDPR review is triggered and publication is blocked until resolved.

Whether it has been verified that all data processing pipelines feeding this record operate only on anonymised or aggregate data. When true, the record is exempt from several GDPR obligations including data subject access rights and the right to erasure for sensor data.

Whether a human accessibility specialist has reviewed the record's accessibility object against real-world conditions at the physical location. Automated EN 17210 checks verify data structure; this flag confirms a specialist has validated the data matches on-the-ground reality.

Whether all geometry objects in the record (footprints, level boundaries, unit polygons) are topologically valid per OGC Simple Features rules: no self-intersections, no unclosed rings, no degenerate geometries. A false value blocks routing graph generation for this record.

Standard: OGC Simple Features Access — ISO 19125

Whether the routing graph defined in the record's topology object is internally consistent: all referenced node IDs exist, no orphaned edges, no disconnected subgraphs for nodes that should be reachable. Required before any routing engine can use this record to compute paths.

Whether at least one end-to-end routing test has been successfully executed using this record as a waypoint. Routing tests traverse the record's topology graph in both directions and verify that the computed path arrives at the correct destination. Required for published status in routing-critical environments.

Whether a person physically visited the location and confirmed that the record's data matches the real-world environment — correct room number, accurate floor, working entrance, correct accessibility features present. The highest-confidence validation signal; overrides concerns raised by automated checks when true.

Whether the wayfinding output for this record has been tested with real end users — ideally including users with accessibility needs — before publication. User testing validates that the rendered output (signage instructions, voice guidance, screen content) is comprehensible and leads correctly to the physical destination.

Whether the validator detected a conflict between this record and another record in the same site — for example, two records claiming the same room identifier, overlapping geometry, or contradictory accessibility data for a shared corridor. When true, conflict_details must be populated.

Human-readable description of any detected conflict, including the conflicting record's ID and the nature of the clash. Required when conflict_detected is true. Null when no conflict exists. Used by data stewards to resolve the conflict before re-running validation.

Max: 1024 chars — Required when: conflict_detected: true

Human approval state for this record. Distinct from validation_status — a record can pass all automated checks but still be pending human sign-off. The WIM platform requires approved before a record's wim.record_status can be set to published.

UUID of the user account that granted final approval for this record. Must reference a human account with the record_approver role — automated services cannot approve records. Null while approval_status is pending.

UTC timestamp of when the final approval was granted. Combined with approved_by, this provides a complete approval audit trail. Null while approval_status is pending. Does not reset if the record is later suspended and re-approved — a new validation run is required instead.

Format: ISO 8601 — Timezone: always UTC (Z)

UUID referencing the immutable audit log entry for this validation run in the WIM platform's audit service. Consumers with audit access can dereference this ID to retrieve the full detailed log: every check result, timestamp, input hash, and validator identity for this validation pass.

Format: RFC 4122 UUID v4 — Dereferenceable: via WIM audit API