# When the route changes, the screen must change with it

A shopper asks a directory how to reach a store. The map knows where the store is, but the corridor normally used to reach it has just closed for maintenance. A confident spoken answer can now be worse than an honest “I cannot confirm that route.” The important problem is not how human the screen looks. It is how the building keeps a route current, withdraws it when necessary and explains a verified alternative.

This article proposes a narrowly scoped digital-signage pilot for ordinary, non-emergency shopping-centre navigation. Its subject is change control: what happens between a facilities update and the directions a visitor sees or hears. Kasamila would supply the optional browser-rendered avatar, not the floor map, indoor positioning, live building feed or routing engine. The workflow below is a suggested integration, not a shipped mall product, customer deployment or measured result.

## A different job from a digital concierge

A directory can find a tenant by name while still failing at the next task: getting a visitor there using a currently permitted route. Temporary corridor closures, access restrictions and uncertain lift availability require more than a conversational FAQ. The operator needs an accountable source of building information and a defined response when that source is missing or stale.

Digital directories and accessibility options are real operational features in shopping centres. For example, Mall of America's own accessibility information describes digital directories, an Accessibility button and Guest Services. That is useful context, not evidence of a Kasamila installation or endorsement. Each centre must establish its own actual facilities, public routes and assistance arrangements. [1]

Start with one directory at a known fixed position, a small approved public area and a few destinations. Do not add indoor tracking, camera recognition, individual visitor profiles or personalised advertising. A fixed starting point avoids pretending the application knows where someone is after they walk away. Emergency evacuation, incident response and safety-critical navigation are outside this pilot: existing signs, site procedures and staff instructions remain authoritative.

## Make a route a controlled data object

The application should not ask a language model to invent turn-by-turn directions from a loose description of the building. The mall and its integrator first need a maintained representation of allowed spaces and connections. OGC's IndoorGML provides a conceptual model for indoor navigation networks. It is a reference for thinking about topology and connectivity, not a ready-made routing engine, live closure feed or certification of accessibility. A limited pilot may use a simpler operator-approved data structure if it meets the same practical need. [2]

For each candidate route, record the fixed origin, destination, permitted connections, map version, closure-status version, relevant route constraints and time of validation. The site operator must set a defensible freshness policy and identify who can approve a closure or reopening. “Updated recently” is not enough if the relevant corridor changed afterward. Reopening should require positive approved information, not merely the disappearance of an old warning.

Keep the base map and temporary closure overlay distinct. A closure can disable an otherwise valid connection without redrawing the whole building. Publish a matched map-and-closure version as one approved snapshot, and have each display acknowledge which snapshot it is using. If a display still holds an older cache, it must not advertise a route as current. For the initial single-screen pilot this is simple to inspect; expansion to multiple screens requires tested propagation, acknowledgement and rollback behaviour. A rollback must never silently restore a route through a connection that remains closed.

A route advertised as step-free requires verified information about the entire relevant path, including any lift it depends on. Knowing where a lift is does not establish that it is working or usable now. If that information is unavailable, do not silently substitute stairs or promise an accessible alternative. Explain that the requested route cannot currently be confirmed and show the approved staffed-help contact. Avoid inferring a visitor's needs from appearance; let them choose the relevant route option without disclosing a diagnosis.

![Concept illustration: Operator-approved route data and system responsibilities](/portal/media/a642c64a-7881-4083-9d98-15cfa63d8968)

Figure 1. Concept illustration, not a product screenshot or real deployment.

## Follow one visitor through a change

The screen begins with a readable directory and a known “You are here” location. A visitor selects a destination and, if useful, a step-free option. The app requests a route from the operator-controlled service. A verified result produces a map and short written steps. The visitor can choose an optional spoken explanation through the avatar, but neither voice nor a conversation is required to see the route.

Now consider a closure update arriving while the explanation is playing. The app should invalidate the affected route, stop the old queued narration and visibly mark the result as being checked. It should not keep speaking directions that the map has already withdrawn. A version check before playback, together with update handling during the session, reduces this mismatch; the integrator still needs to test the race conditions on the actual device.

If the service verifies an alternative, the app presents a new card and clearly identifies the change. The avatar may explain that approved result using the same facts. If no route can be verified, the screen says so and offers the established staffed-help option. It must not claim someone has been contacted unless a separate authorised communication has actually succeeded. A proposed fallback is information, not a promise that staff are already on the way.

The card should explain the limit of the service: these are directions checked at the directory, not continuous navigation after departure. Do not silently turn a displayed route into a live tracking service. When the visitor finishes or leaves the interaction, the application clears the visible session and explicitly ends any active runtime. The ordinary directory can remain available without keeping an avatar session running.

![Concept illustration: Route update lifecycle and stale narration cancellation](/portal/media/c391ae85-7c4d-4617-8328-80f384b046d1)

Figure 2. Concept illustration, not a product screenshot or real deployment.

## Give each system one clear responsibility

The facilities team owns public-route permissions, closures, reopening approval and the help fallback. Its update process is a prerequisite, not a small task to leave until after the avatar demo. The integrator owns the route calculation, data-version checks, freshness decisions and operational logs. The browser application owns the accessible map card, optional audio, device controls and session lifecycle. A language model, if used at all, can help phrase approved information; it must not override a rejected route or fabricate a missing connection.

Kasamila's documented path supplies audio-driven avatar rendering in a browser. Its Runtime Integration Guide describes browser rendering and scoped runtime sessions; the permanent API key belongs on the backend rather than in a public directory page. Use the SDK information returned for the session and follow the official integration contract rather than inventing a general “latest” script URL. MCP session orchestration should not be confused with the browser rendering layer. [3]

The proposed route service and building feed are separate engineering work. Public samples and mocked tests do not establish a production connection to a mall's management system, a signage player or a specific touchscreen. They also do not establish real-time accuracy of its facilities data. The screen can only explain the information the operator has actually maintained and the application has actually verified.

## Build the pilot in the order risk appears

First, agree the operating boundary. Name the person who approves map changes, the person who can suspend route guidance, the information-only fallback and the excluded emergency uses. Select actual destinations and inspect the paths. Keep private and staff-only areas out of the visitor data.

Second, make the route service work without an avatar. Exercise known closures, contradictory updates, delayed messages and reopening. Require an explicit invalid or unavailable result when the service cannot establish a permitted path. Do not treat a cached success as a default answer after its validity has ended. Log route versions and outcomes so staff can reconstruct a failure without recording a visitor's identity or full conversation.

Third, validate the actual screen environment. Record its operating system, browser or WebView version, graphics support, resolution, audio output, input methods, network and power arrangements. Test foreground and background behaviour, page reloads and recovery after connectivity loss. A modern-looking screen is not proof of compatible browser rendering. A pilot on one device does not establish support for every signage player, offline operation or low-power embedded hardware.

Fourth, add the optional explanation to the verified card. Keep the same route facts across text and audio, stop stale narration and test interruption. If microphone input is unnecessary for the selected task, omit it. If added, obtain the appropriate device permission and make its state and stop control clear. Never autoplay an ongoing conversation simply because someone passes the directory.

Fifth, review accessibility with representative users and the site's accessibility lead. Provide usable text directions alongside the map, not colour alone. Keep the web interface keyboard-operable and test the actual kiosk’s input and access arrangements. Provide audio controls and make route-status changes available to assistive technology rather than only animating a character. W3C guidance on keyboard access, audio control, complex images and status messages provides relevant design principles; it does not by itself certify a kiosk or route as accessible. [4]

## Test freshness before testing personality

Begin with a correctness gate. Use a fixed set of origin-destination tasks and controlled data changes: an ordinary valid route, a closed corridor, a route requiring a lift whose status is unknown, an out-of-order update and a stale feed. Check that withdrawn paths are not shown or narrated, that current permitted alternatives are correctly represented, and that uncertainty produces a clear refusal to give unverified directions. These are acceptance tests to perform, not results already achieved.

Only after that gate passes should the operator compare the explanation layer. Use the same verified route cards in three conditions: text and map; the same card with voice; and the same voice with an avatar. Balance task difficulty and conditions, rather than comparing a simple text task with an unusually complicated avatar task. Where possible, test simulated closures in a controlled setting instead of sending visitors toward a real obstruction.

Measure correct next-step comprehension, wrong-route selection, stale-route rejection, time to understand the alternative, ability to recover without audio and requests for staffed help. Record how often guidance is withheld because data is unavailable. A high withholding rate may expose a facilities-data problem, not a need for a more persuasive character. Review failures by route version and scenario, not only by average satisfaction.

The avatar has a plausible but unproven role: a brief, optional explanation may help some visitors understand why the usual path is unavailable. It may also slow down someone who only needs a map, distract from directions or create unnecessary noise. Retain it only if it adds useful comprehension beyond the same audio and card. Increased screen dwell time is not automatically a benefit; it can mean confusion. Set decision thresholds before the trial and report uncertainty when the sample is small.

![Concept illustration: Correctness gates and explanation-layer comparison](/portal/media/272775cf-4f8c-41be-93c6-5c2d2903128c)

Figure 3. Concept illustration, not a product screenshot or real deployment.

## Keep the directory available without an idle avatar bill

Kasamila's runtime billing is based on session elapsed time from creation, including listening, speaking, silence and hidden states. Muting, stopping audio or hiding the character is not session termination. Explicitly use the documented destroy() or authorised session-end path and verify the outcome. Without explicit termination, the full reserved lease is consumed at expiry. Where used, LLM, STT and TTS services are separately charged and need their own lifecycle handling. [3]

Create a runtime only when the visitor chooses the avatar explanation. Define a maximum interaction duration, an inactivity policy and a recovery path for failed shutdown; do not depend only on a browser unload callback. Closure revalidation is an application operation and should not leave an unnecessary talking session alive. Log billable duration and closure failures separately from route requests.

Budget for actual runtime usage, applicable current Kasamila charges, upstream speech/model services, hosting and the work of keeping route information current. Compare actual cost per correctly understood route task, with withheld and failed attempts reported separately. No numerical price or trial entitlement is assumed here. Check the current applicable commercial terms before approving a deployment budget. [5]

## A useful screen knows when not to give directions

The first deliverable is not an avatar. It is an operational agreement that connects approved building changes to the route on the screen. An optional character can then explain a verified alternative, while the map, written instructions and staffed help remain available. If the building cannot keep its route information current, pause that dynamic guidance rather than make stale information sound more reassuring.

## Sources

[1] Mall of America, Accessibility. Example of a real operator's directory and assistance information, not a Kasamila customer reference. [https://www.mallofamerica.com/plan-your-trip/accessibility](https://www.mallofamerica.com/plan-your-trip/accessibility)

[2] Open Geospatial Consortium, IndoorGML standard and IndoorGML 2.0 conceptual model announcement. These describe indoor navigation data modelling, not a live facilities service. [https://www.ogc.org/standards/indoorgml/](https://www.ogc.org/standards/indoorgml/) and [https://www.ogc.org/announcement/ogc-publishes-indoorgml-2-0-part-1-conceptual-model-standard/](https://www.ogc.org/announcement/ogc-publishes-indoorgml-2-0-part-1-conceptual-model-standard/)

[3] Kasamila official documentation bundle: Runtime Integration Guide, SDK release contract and developer repository. Browser responsibilities, credentials and runtime lifecycle are documented; the mall workflow in this article is proposed. [https://github.com/kasamila/kasamila-dev/blob/main/docs/api_v1_runtime_integration_guide.en.md](https://github.com/kasamila/kasamila-dev/blob/main/docs/api_v1_runtime_integration_guide.en.md) ; [https://github.com/kasamila/kasamila-dev/blob/main/docs/sdk_2_runtime_release_contract.en.md](https://github.com/kasamila/kasamila-dev/blob/main/docs/sdk_2_runtime_release_contract.en.md) ; [https://github.com/kasamila/kasamila-dev](https://github.com/kasamila/kasamila-dev)

[4] W3C Web Accessibility Initiative, Understanding Keyboard, Audio Control and Status Messages; Complex Images tutorial. [https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html) ; [https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html](https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html) ; [https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html) ; [https://www.w3.org/WAI/tutorials/images/complex/](https://www.w3.org/WAI/tutorials/images/complex/)

[5] Kasamila official portal. Verify the applicable current commercial terms before deployment. [https://www.kasamila.com/portal?lang=en](https://www.kasamila.com/portal?lang=en)

Editorial note: Prepared for review on 24 October 2026. All diagrams are original conceptual illustrations, not product screenshots or evidence of deployment. No real device, route feed or end-to-end mall integration was tested for this article.