One record. Every surface. The channels object carries pre-structured, pre-formatted output for every downstream consumer — physical signs, digital screens, mobile apps, kiosks, voice AI, and API subscribers — all driven from the same authoritative source. No adapter logic per integration. No bilateral syncs.
The channels object eliminates per-channel integration logic. Each channel sub-object carries exactly what its consumer needs — pre-formatted, pre-validated, ready to render. Physical sign firmware, mobile SDKs, voice platforms, and CMS systems all read from the same record without transformation.
A shared channel context object carries the spatial and routing identifiers common to all surfaces. Six typed channel objects — physical_sign, digital_sign, mobile_map, kiosk, voice_ai, api — carry surface-specific payloads derived from it.
Digital channel output meets WCAG 2.2 accessibility. Location context uses WGS84 coordinates and What3Words. Voice channel SSML follows W3C SSML 1.1. API channel follows MCP (Model Context Protocol) for AI-agent integration.
Shared spatial and routing context object consumed by all channel sub-objects. Carries the identifiers, coordinates, and route references that every downstream surface needs to contextualise its output. Must be present for any channel output to be valid. All channel sub-objects inherit from this context.
Array of WIM record identifiers that describe this physical location — typically the place.id and the associated topology.node_id. Enables channel consumers to cross-reference the full record graph for a location without separate API calls.
What3Words address for this destination — a globally unique, human-memorable 3-word reference to a 3 m² square at or nearest to the destination entrance. Used in voice AI and kiosk channel output as an unambiguous spoken location reference, particularly useful in large campuses where building/level descriptions are insufficient for external navigation handoff.
Format: word.word.word (3 lowercase words separated by dots)
"what_three_words": "fills.smart.tower"WGS84 latitude of the destination entrance or primary access point. Used by mobile map channels for GPS handoff when transitioning from outdoor to indoor navigation, and by kiosk channels when generating printed maps with a location marker. Should reference the most accessible entrance for the user's profile.
Format: decimal degrees — Datum: WGS84 / EPSG:4326 — Precision: ≥ 5 decimal places
"latitude": 52.08532WGS84 longitude of the destination entrance or primary access point. Used alongside latitude for outdoor-to-indoor navigation handoff, deep linking into third-party map apps, and generating shareable location links for mobile channels.
Format: decimal degrees — Datum: WGS84 / EPSG:4326 — Precision: ≥ 5 decimal places
"longitude": 5.12201Identifier of the primary named route to this destination from the campus or building's primary entrance. Referenced by all channel sub-objects when generating route instructions. Maps to a topology.route_segment_id in the navigation graph.
Human-readable name of the primary route, as displayed on physical and digital signage. Consistently used across all channels so that a traveller following a colour-coded corridor sees the same route name on a sign, a screen, their phone, and hears it from a kiosk. Max 48 characters for physical sign compatibility.
Max: 48 chars — Consistency rule: must match physical signage text exactly
"route_name": "Blue Route 3"The place.id of the destination this channels object serves. The anchor that ties the channels output back to the canonical place record. All channel sub-objects derive their output for this destination ID. Required for any channel consumer to validate it is rendering the correct record.
The primary human-readable name of the destination, matching place.name.primary. Reproduced here so that channel consumers can access the destination name without a separate place record lookup. All channel sub-objects use this as the default display name.
Must match: place.name.primary exactly — Max: 64 chars
"destination_name": "Cardiology Clinic"Building identifier, reproduced from place.location.building. Included in channel context so that physical sign firmware, digital sign CMS, and voice AI can all reference the building without parsing the full place record. Used in short-form location descriptions across all channels.
Floor/level identifier, reproduced from place.location.level. Used by all channels to surface a consistent level reference — "Level 2" on a screen, "Level 2" in a voice AI answer, "Level 2" on a printed kiosk map. Ensures level naming is consistent across every surface without per-channel mapping.
Wing or zone name within the building, when the facility uses named wings as a primary wayfinding landmark (e.g. "West Wing", "Orange Zone", "Block C"). Included in channel output when the wing label is more recognisable to visitors than the unit or level reference. Null when wings are not used in this facility's wayfinding taxonomy.
"wing": "West Wing"The door or opening identifier where the route terminates — the final landmark in turn-by-turn instructions. Routing engines use this to generate the arrival instruction ("You have arrived at door A-02-145-main"). Matches the topology.nearest_door identifier.
Output payload for physical (printed or illuminated) wayfinding signs. When present, the sign management system (signage CMS or signagent firmware) reads this object to determine which physical sign assets to update, what text to display, and where the signs are mounted. Null or absent when no physical signage is provisioned for this destination.
Array of physical sign asset identifiers that display wayfinding information for this destination. Each ID corresponds to a specific sign panel at a decision point in the navigation graph. When the record updates, the signage CMS pushes a content change to every sign in this array simultaneously.
"sign_ids": ["sign-A-00-04", "sign-A-02-12"]Exact text string to be rendered on all physical signs in sign_ids. Formatted for sign panel constraints — typically destination name followed by route colour and number. Maximum 48 characters to fit standard panel dimensions without truncation at 20mm+ font size.
Max: 48 chars — Format: "[Destination] — [Route Name]"
"display_text": "Cardiology Clinic — Blue Route 3"Description or identifier of the primary mounting location for the sign controlling this route segment — the junction or decision point where the sign is physically installed. Used by estate management and signage maintenance teams to locate and inspect the primary sign asset in the field.
"mounting_location": "junction-A-00-04"Identifier of the signagent — the edge device or firmware instance responsible for driving the physical sign hardware for this destination. Signagent systems poll or subscribe to the WIM API and push content changes to their connected sign panels. This ID enables the WIM to push targeted updates to a specific signagent without broadcasting to the full estate.
Convention: sa-{site}-{unit} — Protocol: MCP or vendor-specific push API
"signagent_id": "sa-main-hospital-001"Output payload for digital display screens — lobby screens, corridor monitors, lift lobby panels, and reception displays. The digital signage CMS reads this object to determine which screens to update, what message to display, at what priority, for how long, and on what schedule. Null or absent when no digital screens are provisioned for this destination.
Array of digital screen asset identifiers that display content for this destination. Each ID maps to a specific screen in the digital signage CMS. When the record updates, content changes propagate to every screen in this array in the next CMS polling cycle or via push webhook.
"screen_ids": ["screen-main-lobby-A", "screen-lift-lobby-A-02"]Message string rendered on digital screens. May be longer than the physical sign equivalent — screens support more characters and can render multi-line content. Formatted for clarity at reading distance; avoid abbreviations. When status.live_message is set, it is appended to this text automatically by the channel renderer.
Max: 120 chars — Rendered as: primary text on screen template
"display_text": "Cardiology Clinic: follow Blue Route 3"Display priority for this content item in the screen's content playlist. Lower numbers take higher priority — a priority: 1 item preempts standard playlist content and displays immediately on status change (e.g. a department closure or emergency message). Standard wayfinding content typically uses priority 5–10.
Range: 1 (urgent) – 100 (background) — Default: 5
"priority": 5Duration in seconds this content item is displayed per playlist cycle on digital screens. Determines dwell time — how long a traveller has to read the message before the screen cycles to the next item. Standard wayfinding messages typically display for 8–15 seconds. Emergency messages should use a shorter duration to repeat more frequently.
Units: seconds — Typical range: 5 – 30 — Emergency: 3 – 8
"duration_seconds": 10Operating schedule during which this content is active on the assigned screens, expressed in OSM opening_hours format. Outside of this schedule, the screen CMS suppresses this content item and falls back to default or idle content. Enables automatic time-gated signage without manual intervention.
Format: OSM opening_hours — Example: "Mo-Fr 07:00-20:00; Sa 08:00-14:00"
"schedule": "Mo-Fr 07:00-20:00"Output payload for mobile application map channels. Drives in-app map state, deep link generation, push notifications, and offline map availability. The mobile SDK reads this object to activate indoor map rendering, display the route overlay, and send contextual push messages to users approaching the destination.
Whether the map tile and route overlay for this destination should currently be visible in the mobile app. false suppresses the destination from the in-app map — used when the destination is temporarily closed or the route is disrupted. Defaults to true when the status object reports open: true.
Deep link URI that opens the mobile app directly to an active route to this destination. Used in push notifications, QR codes on physical signs, and kiosk-generated print outputs. When scanned or tapped, the app launches directly into turn-by-turn navigation from the user's current location to this destination.
Scheme: wim:// (custom) or https:// universal link — Format: wim://route/{from}/{destination_id}
"deep_link": "wim://route/main-entrance-A/dept-cardiology-001"Whether a static route preview (a rendered map image of the full route from entrance to destination) is available for this destination. true enables the mobile app to show a preview thumbnail before the user starts navigation — useful for complex routes, and for pre-journey planning in appointment reminder notifications.
Push notification message sent to a user's mobile device when they approach or check in near this destination. Short, contextual, and actionable — typically combined with the deep link to allow one-tap navigation start. Respects notification opt-in permissions; never sent without explicit user consent to location-based push notifications.
Max: 100 chars — Tone: concise, actionable — Consent required
"push_message": "Your destination is Cardiology Clinic, Level 2. Tap to navigate."Whether the indoor map tile and route data for this destination has been pre-cached for offline use in the mobile app. true means a traveller in a poor signal environment (basement, reinforced concrete, shielded clinical area) can still access full turn-by-turn navigation without a live API connection.
Output payload for self-service wayfinding kiosk terminals. Drives the kiosk's output modes — screen display, printed route slip, and audio output — from a single record. The kiosk reads this object to determine what output types to offer the user and how to render them. Null when no kiosk is provisioned at this location.
Whether this destination is enabled for kiosk output. false suppresses this destination from kiosk search results and disables kiosk output for this record — used when a destination is temporarily closed or not yet commissioned for kiosk routing. Defaults to true for published records.
Array of output modes supported by the kiosk for this destination. The kiosk UI presents only the modes listed here — enabling destinations to be configured for the subset of outputs the site's kiosk hardware supports. At least one mode must be present when enabled is true.
Whether a printable route slip (a formatted A5 or receipt-sized paper map with turn-by-turn directions) is available for this destination at the kiosk. true activates the "Print my route" button in the kiosk UI. The printed slip is generated from the topology object's step data and the channel context's route name and building/level references.
Whether the kiosk can deliver spoken turn-by-turn directions for this destination through its audio speaker or headphone jack. true enables the kiosk's audio output button and uses the voice_ai.long_answer field as the spoken route script, rendered via the kiosk's text-to-speech engine.
Whether the kiosk renders this destination in accessible mode — a simplified, high-contrast, large-font interface with reduced interaction complexity. When true, the kiosk UI switches to its accessible template when a user activates the accessibility mode button, applying WCAG 2.2 AA contrast ratios and minimum 18pt type for all displayed content.
Output payload for voice AI channels — conversational assistants, IVR systems, smart speakers, and AI agent tools consuming the record via MCP. Pre-authored answers in short, long, and SSML formats eliminate hallucination risk in AI-generated wayfinding responses by providing the authoritative answer directly in the record. Every voice channel reads this object rather than generating answers from context.
Whether voice AI output is active for this destination. false instructs the voice AI channel to fall back to a generic "I don't have information for that destination" response rather than attempting to answer from this record. Used when a destination is not yet cleared for voice output (e.g. during a soft launch or data quality review).
A concise spoken answer for voice queries that ask for a quick location reference — "Where is Cardiology?" Used by smart speakers, IVR menus, and ambient voice assistants where brevity is required. Maximum two natural spoken sentences. Should convey building, level, and route name only — no full step-by-step directions.
Max: 120 chars — Target: ≤ 2 spoken sentences — Includes: building + level + route name
"short_answer": "Cardiology Clinic is on Level 2 in Building A. Follow Blue Route 3."Full spoken wayfinding answer including turn-by-turn directions, building, level, route name, and estimated walk time. Used by conversational AI assistants, kiosk audio output, and voice navigation modes in mobile apps. Authored for natural spoken delivery — written as it should be heard, not read. Must remain factually synchronised with the topology object's route steps.
Max: 512 chars — Includes: full turn-by-turn + ETA — Written for speech, not reading
"long_answer": "The Cardiology Clinic is on Level 2 in Building A. Follow Blue Route 3 from the main entrance. Take the lift to Level 2, then turn left. Estimated walk time is 4 minutes."W3C SSML 1.1 markup version of the voice answer, for text-to-speech engines that support SSML. Enables precise pronunciation control, strategic pauses, emphasis, and number/ordinal formatting ("Level say-as ordinal 2") that plain text cannot express. Used by high-fidelity voice AI platforms, IVR engines, and voice-over kiosk systems.
Standard: W3C SSML 1.1 — Wrapping element: <speak> — Fallback: long_answer used when SSML not supported
"ssml": "<speak>The <emphasis>Cardiology Clinic</emphasis> is on Level <say-as interpret-as='ordinal'>2</say-as> in Building A.</speak>"Phonetic pronunciation hint for the destination name or any unusual terms in the voice answer that a TTS engine is likely to mispronounce. Expressed as a plain-text phonetic guide (IPA or respelled pronunciation). Used by voice AI pipeline operators to add custom TTS lexicon entries for this destination. Not read aloud — metadata only.
Format: plain phonetic respelling or IPA — Example IPA: /ˌkɑːdiˈɒlədʒi/ — Not spoken aloud
"pronunciation_hint": "Cardiology: kar-dee-OL-uh-jee"API integration metadata for machine-to-machine consumers — third-party apps, AI agents via MCP, BMS integrations, and webhook subscribers. Carries the endpoint, webhook, subscriber list, and rate limit configuration for this record. Enables external systems to discover and subscribe to record changes without manual integration configuration.
The canonical HTTPS API endpoint for this specific record. Resolves to the current published JSON for this destination. Consumers use this to fetch the full WIM record on demand. Matches wim.canonical_uri and supports conditional GET with If-None-Match ETag headers per RFC 7232.
Protocol: HTTPS — Auth: Bearer token — Supports: RFC 7232 conditional GET
"endpoint": "https://wim.umc.nl/api/v1/records/dept-cardiology-001"HTTPS webhook endpoint to which the WIM platform posts a push notification whenever this record changes. Subscribers listed in api.subscribers are notified via this URL. The payload contains the full updated record. Enables real-time push distribution without polling — critical for physical sign and digital signage systems that must react to status changes within seconds.
Method: POST — Payload: full updated WIM record JSON — Auth: HMAC-SHA256 signature header
"webhook_url": "https://wim.umc.nl/webhooks/dept-cardiology-001"Array of system identifiers currently subscribed to push updates for this record via the webhook. Each subscriber is a named integration — a signage CMS, mobile platform, voice AI system, or BMS. When the record changes, the WIM platform pushes to every subscriber in this array. Subscribers are added and removed via the API subscription management endpoint, not by editing this field directly.
"subscribers": ["signage-cms", "mobile-app", "voice-platform", "bms-integration"]Maximum number of API requests per minute permitted for this record endpoint per authenticated consumer. Consumers exceeding this limit receive a 429 Too Many Requests response. Set per-record to allow high-frequency polling for dynamic status records (e.g. live queue data) while enforcing stricter limits on stable structural records. Use ETag conditional GETs to minimise requests against the rate limit.
Units: requests per minute — Default: 60 — High-frequency status: up to 300
"rate_limit": 60channels object — exampleA fully populated Multi-Channel Output object for the Cardiology Clinic at UMC Utrecht — all seven sub-objects active. Required fields always present; optional fields shown with representative values.