Record Identity

The WIM specification version this record was authored against. Consumers use this to select the correct parser and validate the record structure.

Pattern: semver major.minor — Current: "1.0"

JSON Schema document version used to validate this record. Distinct from the WIM spec version — allows schema iterations within a spec version without breaking compatibility.

Pattern: YYYY-MM — Current: "2026-01"

The API version of the system that produced this record. Used by consumers to know which endpoint features and response formats apply.

Pattern: "v" + integer — Current: "v1"

Globally unique, immutable identifier for this WIM record. Assigned on creation and never changes across revisions. Use this to reference the record from external systems.

Format: RFC 4122 UUID v4 — Immutable after creation

Top-level classification of the entity this record describes. Drives which object schemas are required and which channel renderers apply.

Subclassification within a record type. Used to apply domain-specific rendering rules and routing logic beyond what the top-level type provides.

Lifecycle status of this record. Controls whether the record is served to consumers and which downstream systems receive updates.

Visibility scope of the record. Determines which consumer systems and API clients are permitted to receive and cache this record.

Identifier of the tenant (top-level account) that owns this record. Used for multi-tenant isolation — ensures records from different operators never cross-contaminate.

Organisation sub-unit within a tenant that is responsible for this record. Enables different departments or facilities within a tenant to manage their own record sets independently.

Physical site (campus or facility) this record belongs to. Ties the record into the IMDF site graph and determines which coordinate reference system applies.

Logical namespace used to segment records within a site. Prevents name collisions between facilities sharing the same physical campus. Reverse-DNS convention recommended.

Pattern: lowercase, hyphens — Max: 64 chars

Stable, dereferenceable HTTPS URI for this record. Guaranteed not to redirect. Consumers use this as the permanent reference — safe to store in third-party systems and deep-link to.

Must resolve to: the current published record JSON

UTC timestamp of when this record was first created. Set by the system on record creation and never modified. Used for audit purposes and chronological ordering.

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

UUID of the user account or service identity that created this record. May reference a human user or an automated import service. Immutable after creation.

UTC timestamp of the most recent modification to any field in any object of this record. Updated automatically on every write. Primary field for cache invalidation and sync detection.

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

UUID of the user account or service identity responsible for the most recent modification. Updated on every write alongside updated_at.

UTC timestamp when this record was first transitioned to published status. Null while in draft or review. Does not reset if the record is later suspended and republished.

UTC timestamp when this record was permanently retired. Once set, the record is no longer served by the live API. Null for all non-retired records.

Start of the window during which this record is considered current and authoritative. Used for pre-scheduling record activations, e.g. a department opening on a future date.

End of the validity window. Consumers must not treat this record as authoritative past this timestamp. Used for temporary facilities, pop-up clinics, and seasonal services.

Monotonically increasing counter incremented on every write to this record. Starts at 1 on creation. Consumers use this to detect missed updates during a sync gap — a gap in numbers indicates skipped revisions.

Min: 1 — Never resets

Human-readable description of why this record was modified. Free text. Recommended for all changes affecting physical signage or routing — provides an audit paper trail for operations teams.

Max: 512 chars

Classifies the nature of the change that produced this revision. Downstream systems use this to decide propagation urgency — a structural_change triggers immediate sign updates; a metadata_update may batch.

SHA-256 hash of the canonical serialisation of the full record payload (excluding the checksum and etag fields themselves). Consumers use this to verify record integrity after transport and to detect silent modifications.

Algorithm: SHA-256 — Encoding: lowercase hex

HTTP ETag value for this record version, following RFC 7232. Consumers pass this in If-None-Match headers to receive 304 Not Modified responses when the record has not changed. Dramatically reduces bandwidth on high-frequency polling.

Format: Quoted string per RFC 7232 — changes on every revision

Recommended time-to-live for caching this record, in seconds. Set by the data owner based on expected change frequency. Consumers must not cache beyond this value. Physical signage systems should halve this value for safety.

Min: 30 — Max: 86400 (24h) — Default: 300

Default language for all free-text fields in this record. All text fields without an explicit language tag are assumed to be in this language. Follows BCP 47 language tags.

Format: ISO 639-1 + optional region subtag

UUID of the person or role accountable for the accuracy and completeness of this record. Receives notifications on validation failures and escalation alerts. Should reference a named individual, not a shared mailbox.

UUID of the operational steward responsible for day-to-day record maintenance. Receives workflow tasks for pending updates. Distinct from data_owner — steward acts, owner is accountable.

Identifier of the originating system when this record is created via an automated import or integration (e.g. a Building Management System, CAFM, or CMDB). Useful for tracing data lineage and debugging conflicting updates.

Max: 64 chars — Convention: SYSTEM-SUBSYSTEM-ID

Priority weight used when the same record is fed from multiple source systems. Lower number = higher priority. When two systems update the same record simultaneously, the update from the lower source_priority wins.

Range: 1 (highest) – 100 (lowest) — Default: 50

Data quality confidence score for this record, expressed as a float between 0.0 and 1.0. Computed automatically from field completeness, last-verified date, and source reliability scores. Records below 0.7 trigger a steward review workflow.

Range: 0.0 – 1.0 — Review threshold: < 0.7 — Computed, not editable