Scheduled and real-time events tied to a destination — influencing routes, crowd flows, and channel messaging simultaneously. Each event carries its own access rules, attendance data, and messaging payload, so routing engines and output channels always reflect live conditions without adapter logic.
The events object describes any time-bounded occurrence at a destination that changes routing, access, crowd flow, or channel messaging. A single event update propagates across physical signage, digital screens, mobile map, kiosk, and voice AI simultaneously — with no per-channel adapter code.
The events object is a root-level sibling of wim, place, status, and channels. It is structured as an array to allow multiple concurrent or sequential events at the same destination, each independently actionable by routing engines.
Datetime fields follow ISO 8601 with timezone offsets. Recurring events use RFC 5545 RRULE syntax — the same format as iCalendar and Google Calendar — enabling native import into scheduling systems without conversion.
Globally unique identifier for this event. Immutable after creation — used to reference the event from routing engines, access control systems, and channel adapters without ambiguity.
Format: RFC 4122 UUID v4 — Immutable after creation
"event_id": "e9f2a3b1-7c4d-4e8f-a5b6-1d2e3f4a5b6c"Classification of the event. Drives which routing rules, access filters, and channel rendering templates apply. Routing engines use this to decide whether to suppress navigation to a destination, redirect crowds, or surface an alert.
Human-readable name for this event. Surfaced directly in channel messaging — physical signage, digital screens, kiosk listings, and voice AI announcements — so it must be clear and unambiguous to visitors unfamiliar with internal naming conventions.
Max length: 120 characters — Must be visitor-facing safe
"event_name": "Cardiology Outpatient Clinic — Morning Session"Current lifecycle state of the event. Routing engines evaluate this before serving navigation: active events may restrict or override routes; cancelled and postponed events trigger channel alerts and suppress event-specific routing overlays.
The date and time at which the event begins. Routing engines use this to activate event-specific overlays ahead of time — typically applying route and messaging changes 15–30 minutes before start to manage pre-event crowd flow.
Format: ISO 8601 with timezone offset — Includes UTC offset for local time
"event_start": "2026-05-06T08:00:00+01:00"The date and time at which the event concludes. When reached, routing engines automatically deactivate event overlays and restore default route patterns. If event_delay_minutes is set, the effective end time is extended accordingly.
Format: ISO 8601 with timezone offset — Must be after event_start
IANA timezone database identifier for the event location. Required in addition to the UTC offset in event_start / event_end to correctly handle daylight saving time transitions for recurring events.
Source: IANA tz database — Example values: Europe/Amsterdam, America/New_York, Asia/Tokyo
"event_timezone": "Europe/Amsterdam"RFC 5545 RRULE string defining the recurrence pattern for repeating events. When present, scheduling systems and routing engines use this to generate future event instances automatically without manual entry. Null for one-off events.
Format: RFC 5545 RRULE — Compatible with: iCalendar, Google Calendar, Outlook
"event_recurrence": "RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR"The topology node identifier for the physical location of this event. Used by routing engines to spatially anchor the event on the navigation graph — determining which edges, paths, and adjacent nodes are affected by crowd flow or access restrictions.
References: topology.node_id — Must exist in the current topology graph
The WIM record ID of the destination to which this event is attached. Links the event to the full place, status, and channels records — enabling routing engines to merge event state with live destination state before computing output.
Format: RFC 4122 UUID v4 — References: wim.record_id of a destination record
Whether this event activates a custom routing overlay that supersedes the default shortest-path calculation. When true, routing engines switch to the event-specific crowd flow plan defined in event_crowd_flow_plan for the event's duration.
Default: false — Requires: event_crowd_flow_plan to be set when true
Identifier of the pre-configured crowd flow plan to activate for this event. Crowd flow plans define directed pedestrian movement patterns — one-way corridors, managed entry/exit points, overflow zones — that routing engines enforce when event_route_override is true.
Nullable: null when no override plan is active — References: a crowd flow plan in the routing engine registry
"event_crowd_flow_plan": "cfp-cardio-clinic-morning"The department, team, or individual responsible for organising the event. Used for audit trails, stewardship workflows, and to route event-related alerts and queries to the correct contact. Not surfaced in public channel output.
Internal use only — not rendered on visitor-facing channels
"event_organiser": "UMC Cardiology Department"Maximum number of attendees permitted at this event. Used by routing engines as a threshold: when event_actual_attendance approaches or exceeds this value, overflow routing is triggered and capacity warning messages are surfaced on digital channels.
Unit: persons — Triggers overflow routing when actual_attendance ≥ capacity
"event_capacity": 48Forecast attendance figure provided at the time of event creation. Used to pre-configure crowd flow plans, staff allocation, and channel messaging thresholds before the event goes live. Compared against event_actual_attendance for post-event capacity planning.
Unit: persons — Set at creation, not updated during the event
"event_expected_attendance": 42Live or final count of attendees at the event, typically fed from a check-in system, access control gate, or occupancy sensor. When updated in real time, routing engines use this to dynamically adjust crowd flow plans and surface capacity warnings or overflow instructions across all channels.
Unit: persons — Updated in real time when check-in integration is active
"event_actual_attendance": 38Who is permitted to attend this event. Routing engines cross-reference the visitor's user profile against this value — public events are navigable by all; staff and restricted events are suppressed from public channel output and only surfaced on authenticated staff-facing channels.
Whether attendees must complete a check-in process before entering the event space. When true, wayfinding routes are augmented with a mandatory check-in waypoint step and channel messaging includes check-in instructions on all output surfaces.
Default: false — When true: check-in waypoint injected into all routes to this destination
"event_check_in_required": trueWhether a valid ticket, booking reference, or pre-registration is required for entry. When true, channel messaging surfaces a ticket reminder at route start and again at the event entrance node, and kiosk channels surface a ticket validation prompt.
Default: false — Combines with event_check_in_required for full entry flow
Short-form message for physical and digital signage displays. Designed for constrained screen contexts — typically rendered on corridor wayfinding panels and LED sign boards where character space is limited. Should be self-contained and unambiguous without additional context.
Max length: 80 characters — Rendered on: physical_sign, digital_sign channels
"event_signage_message": "Cardiology Morning Clinic · Room A-02-145 · Level 2"Full-form message for digital channel surfaces — mobile app, kiosk screens, and voice AI. Supports longer, more contextual messaging than event_signage_message. Voice AI channels receive this text as the spoken welcome or instruction when the visitor arrives at the event destination.
Max length: 280 characters — Rendered on: mobile_map, kiosk, voice_ai channels
"event_digital_message": "Welcome to the Cardiology Clinic. Please check in at reception on arrival."Primary language of the event content and messaging. When set, channel adapters that support multilingual output use this as the source language for translation. Defaults to wim.language_default if omitted.
Format: BCP 47 language tag — Default: inherits from wim.language_default
Whether this event has been cancelled after initial publication. Distinct from setting event_status to cancelled — this boolean is a fast-path flag for real-time integrations. When true, all channel messaging is immediately replaced with a cancellation notice and event-specific routing overlays are deactivated.
Default: false — When true: supersedes all other messaging fields; cancellation notice surfaced on all channels
"event_cancelled": falseNumber of minutes by which the event start or end has been delayed relative to its scheduled time. When set to a non-zero value, routing engines extend active event overlays accordingly and channel messaging surfaces a delay notice alongside the revised timing. Use 0 when the event is running on schedule.
Unit: minutes — 0 = on schedule — extends effective event end by this value
"event_delay_minutes": 0ISO 8601 UTC timestamp of the most recent change to any field in this event record. Used by routing engines and channel adapters as an ETag-equivalent for cache invalidation — consumers compare this value against their locally cached copy to determine if a re-fetch is required.
Format: ISO 8601 UTC — Auto-set on any field change — used for cache invalidation
"event_last_updated": "2026-05-06T07:45:00Z"events object — exampleA fully populated event record for the Cardiology Outpatient Clinic morning session. All 25 fields shown with representative values for an active recurring clinic event.