A curator approved browser guide for museum object stories

A proposed adult visitor pilot with Kasamila

A visitor stops in front of an unfamiliar object. The label identifies it, but a smaller question remains: Why does the surface look like that? How was it made? Which parts of its story are known, and which are still debated? A short browser guide could help the visitor ask that question without turning a gallery visit into a long conversation with a screen.

This article proposes an adult visitor pilot using Kasamila for an optional avatar presentation. It is a design concept, not a museum deployment or a report of measured results. The aim is simple: help someone understand one object, recognize uncertainty, and look back at the object with a more informed question.

Start with one object and one useful question

Imagine a fictional clay vessel chosen only to illustrate the workflow. No actual museum object, photograph, attribution, or collection record is being represented here. A curator would replace this placeholder with an object whose public interpretation and media have been approved for the pilot.

The opening screen offers three prompts: materials, making, and history. A visitor chooses one, reads a short answer, and may ask a limited follow-up. A small observation prompt then returns attention to the display: look at the surface, compare the outline, or notice a feature identified in the approved interpretation. It must never invite touching, moving closer than permitted, or handling the object.

Keep the interaction narrow enough to finish comfortably. A visitor should be able to learn something without creating an account, speaking aloud, or discovering how a chatbot works. An always-visible finish control gives the encounter a clear end. The exhibition label and staff remain available whether the digital guide succeeds or fails.

Figure 1 One question should lead attention back to the object

Original concept illustration. Not a screenshot or deployment.

Make the boundary of knowledge visible

The answer store should distinguish supported facts from interpretation and unresolved questions. These are editorial categories, not confidence scores invented by a language model. Each answer needs an approved wording, its supporting record, an owner, and a review date. Where several interpretations are appropriate for public release, show them as alternatives rather than blending them into a single fluent story.

For the fictional vessel, a sample response might say: ‘The approved record identifies the material as fired clay. The maker is not identified in this example. The purpose of this particular surface mark has not been established.’ A follow-up could ask the visitor which part they can observe directly. The value lies in separating observation, documented information, and interpretation without making uncertainty sound like a system error.

If a question falls outside the approved material, the guide should say so and offer a relevant published resource or a staff enquiry route. It should not improvise an appraisal, conservation instruction, safety decision, or cultural provenance verdict. It should not speak as a historical person or suggest that an animated presenter has lived experience of the events described.

Give curators control after launch

Appoint a named editorial owner and a deputy. Publish dated answer versions, record why changes were made, and make withdrawal an ordinary operation. A withdrawn passage must disappear from search, suggested prompts, generated responses, and cached presentation content. Test that process before visitors arrive, including a device that was already open when the withdrawal occurred.

Permission is more specific than availability online. The National Museum of the American Indian explains that culturally sensitive images or information may be withheld and that published material may be removed after concerns are raised. That is an example of a museum's publication boundary, not a Kasamila partnership or endorsement. This proposed pilot needs its own institution's permissions and review process. [6]

Figure 2 Keep curatorial approval separate from presentation technology

Original concept illustration. Not a screenshot or deployment.

Let visitors choose how to participate

Begin with a quiet text screen. Make audio an explicit choice, and show the same answer in text when it plays. Place volume, stop, and text-only controls where a keyboard or touch user can find them. A visitor who declines the avatar should still receive the same substance. W3C's audio guidance favors user-initiated sound and controls that do not depend on system volume. Its motion guidance explains when pause, stop, or hide controls are required. These are design references, not a claim of WCAG conformance. [4] [5]

Make the presenter visibly contemporary and describe its role plainly: an optional guide reading curator-approved material. Avoid a face, costume, or voice that implies an actual historical person is answering. Keep the object image or text prompt more prominent than the presenter. When the answer ends, offer a quiet pause rather than another unsolicited speech.

For this pilot, require no visitor name or contact details. Prefer prompt selection and typed questions before adding microphone input. If speech is offered, explain its processing and retention before activation, provide an equally usable alternative, and keep microphone status unmistakable. Minimize logs; do not save raw audio or unrestricted transcripts by default. The institution must review the chosen providers and its own data handling.

Connect the guide without confusing responsibilities

Kasamila presents a browser-driven avatar capability. Its integration guide places the permanent API key on the application backend and gives the browser a short-lived Runtime token; the browser SDK accepts audio and performs avatar inference and WebGL rendering. Server-side MCP orchestration is separate from that browser runtime. [1] [2]

In the proposed application, the museum's approved answer store supplies the content. Start with deterministic answers to the three prompts. If an LLM is introduced for question routing or answer composition, restrict it to approved material and check its output before presentation. Speech recognition and speech synthesis, when needed, are separate provider choices. The avatar layer does not supply curatorial approval or make those providers equivalent.

Protect session issuance with appropriate application or device authorization and rate limits without requiring a visitor identity. Build a keyboard-accessible text path that survives an avatar or audio failure. Test the exact device, operating system, browser, WebGL support, audio permissions, network conditions, and background-tab behavior intended for the gallery. Also test interruption, reconnection, and denied microphone permission. Do not infer universal hardware support, native-app support, or telephone connectivity from this browser concept.

Before deployment, verify the selected release in the production registry and complete application acceptance. Repository checks are not evidence of credentialed provider end-to-end validation. A working example is a starting point for those tests, not the final acceptance result. [3]

Test whether the avatar adds value

Use a three-condition comparison: touch or keyboard text only; the same text with a voice; and an avatar with that same voice and text. Keep the object, answer wording, prompt order, and task difficulty matched. Otherwise, a stronger script or better audio could be mistaken for an avatar benefit. Offer accessible alternatives throughout; participation and the choice to stop must remain voluntary.

Before recruiting, write down what a useful result would look like. Ask visitors a short comprehension question about the answer and another about what remains uncertain. Have them identify the relevant feature on the object or explain what they would look for. This checks whether the interpretation travels beyond the screen. Use a short, disclosed observation protocol rather than face recognition or covert attention tracking.

Record task completion, opt-outs, requests for assistance, and technical failures alongside comprehension. Ask why someone switched to text or stopped. A preference for silence, a confusing button, and an audio fault are different findings. Keep them separate. Use anonymous session-level measurements where possible, with a clear notice and a defined retention period.

Do not make dwell time the success target. A longer interaction might reflect interest, but it might also mean the visitor is waiting, confused, or watching the presenter instead of the object. The pilot should reward useful understanding with a manageable interaction, not maximum time in front of the avatar.

A small exploratory pilot can reveal usability and content problems; it cannot automatically establish a general improvement in learning. Agree the sample plan and decision criteria before examining results. Report the number of participants, exclusions, missing responses, and device failures. If the avatar adds cost without a credible benefit over the identical voice-and-text condition, retain the simpler experience.

Figure 3 Compare matched experiences and account for the complete session

Original concept illustration. Not a screenshot or deployment.

Count the whole session

Ordinary sessions accrue time from creation; listening, muted, silent, or hidden states do not by themselves end billing. Use destroy() or authorized session termination, and verify the end server-side. Stopping audio is not sufficient. [2] [3]

The proposed idle screen should therefore remain a lightweight poster or text interface until the visitor chooses the avatar. Give finish, inactivity, withdrawal, and failure paths explicit termination behavior. Check the server record after each test, including closing the tab or losing the network. If an end cannot be confirmed immediately, record that uncertainty and reconcile it rather than assuming the visible screen tells the whole story.

A volume example can make the exposure concrete without inventing a price: 120 avatar sessions averaging two billed minutes from creation to confirmed end represent 240 session-minutes. If each accidentally retains one extra minute, that is another 120 minutes. These are illustrative planning assumptions, not observed museum usage or a quoted tariff. Actual cost depends on current account terms, session behavior, concurrency, and template arrangements. LLM, STT, and TTS charges are separate from Kasamila Runtime charges.

For each condition, track operating cost per completed task alongside visitor outcomes. Include content preparation, staff assistance, device support, and maintenance as well as metered services. A cheap runtime is not a cheap programme if every session needs someone to recover the browser or explain the controls.

Launch only after a complete rehearsal

A sensible first rehearsal involves one approved object, a limited adult audience, one supported device profile, and staff who know how to switch the guide off. Walk through a correct answer, an uncertain answer, an unsupported question, a content withdrawal, an inaccessible control, a provider outage, and an unconfirmed session end. Fix the failures before extending the invitation.

After the pilot, bring the evidence back to curators, accessibility reviewers, visitor services, and the technical owner. Decide whether to revise the script, remove the presenter, change the interaction, or expand cautiously. Preserve a dated record of the decision. Expansion to another collection, language, device, or audience should trigger fresh content and acceptance checks rather than inherit approval automatically.

The strongest outcome may be a very short encounter: a visitor asks one question, understands the answer and its limits, then turns back to the object. That is the standard this browser guide should earn. The avatar is worth keeping only if it helps that happen.

SOURCES

Verified 27 October 2026

[1] Kasamila official portal https://www.kasamila.com/portal?lang=en

[2] Kasamila Runtime integration guide https://github.com/kasamila/kasamila-dev/blob/main/docs/api_v1_runtime_integration_guide.md

[3] Kasamila developer resources https://github.com/kasamila/kasamila-dev

[4] W3C Understanding Audio Control https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html

[5] W3C Understanding Pause Stop Hide https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html

[6] National Museum of the American Indian collections statement https://americanindian.si.edu/collections-statement