Inspiration

A hospital visit involves more than medical treatment. Finding the next counter, understanding an instruction, or asking the same question again can be difficult—especially in an unfamiliar place.

Nightingale explores a small, approachable companion for these everyday moments. Instead of another dashboard to learn, it prioritizes one next step, large primary text, generous controls, and a familiar pixel-art bird. It is intended to complement volunteers and hospital staff, not replace them.

What it does

Nightingale is an English and Traditional Chinese hospital-wayfinding prototype. A person types a destination request, such as “I need to pick up my medicine.” NVIDIA Nemotron, accessed through Nebius Token Factory, interprets the request as an allowed destination or returns uncertainty. The person confirms the destination before a demonstration route starts.

The interface presents one next instruction and an on-screen bird cue. When the system is uncertain, it stops guessing and offers a “Help me ask” card. Selectable male and female help recordings let the person play the displayed request aloud.

A separate clinic lookup uses Tavily Extract to retrieve public campus and department information from Taipei City Hospital's official registration site. People can choose a campus, search departments, and open official registration links. This lookup does not create routes, book appointments, or provide symptom triage.

The model interpretation and Tavily integration are real; indoor navigation is simulated. The venue is synthetic, with one clinical department and supporting registration, elevator, cashier, pharmacy, and exit checkpoints. Developer controls simulate progression. There is no continuous indoor positioning or operating physical bird.

How we built it

The frontend uses React, TypeScript, and Vite, hosted on Firebase Hosting. A Hono proxy on Google Cloud Run keeps provider credentials server-side and connects to Nebius Token Factory and Tavily.

The indoor interpreter uses nvidia/nemotron-3-super-120b-a12b. Its job is deliberately narrow: understand destination intent, not invent geography. A deterministic engine controls checkpoints, instructions, confidence, and bird cues. Model output must match an allowed destination; recognition still requires the person's confirmation.

English help recordings use Kokoro-generated audio and Traditional Chinese help recordings use MiniMax. Playback checks that the recording matches the displayed text, with device speech as a fallback.

Inference is request-driven. Submitting a destination calls the model; waiting and checkpoint progression do not continuously invoke it. Clinic retrieval is user-triggered and has a one-hour per-instance cache.

Challenges we ran into

The central challenge was keeping flexible language understanding from becoming invented directions. We separated destination interpretation from route truth and made uncertainty a normal result, not an error to hide.

Interaction details mattered too: a late model response must not revive a rejected destination, and changing the input must invalidate an old confirmation. The interface also needed a generic help request when no destination was known.

Bilingual text and audio had to stay aligned. Another important boundary was distinguishing live Nemotron results from the explicitly labeled Mock interpreter used for development and some connection failures. A Mock result is not evidence of a successful model call.

Accomplishments that we're proud of

The prototype connects a working cloud interpreter, user confirmation, deterministic demonstration guidance, bilingual help, and official-source clinic lookup in a single experience.

The most important accomplishment is its restraint: the bird can remain present without pretending to know. It supports asking another person rather than silently converting uncertainty into confident-looking directions.

What we learned

A useful AI experience is not necessarily one where the model does everything. Natural-language interpretation and deterministic rules can serve different roles, with confirmation connecting them.

We also learned to distinguish an intended benefit from evidence. Large controls, friendly voices, and one-step guidance are design choices—not proof that the product reduces anxiety or is accessible to every older adult. Those questions require evaluation with intended users.

What's next for Nightingale

The next step would be a carefully scoped pilot with hospital-verified routes for one department, clear route ownership, accessibility checks, and human support. Evaluation should measure whether people understand the next step, recover from uncertainty, and know how to ask for help, alongside actual API usage and operating effort.

Voice input for the indoor flow is future work; the current indoor demo uses typed destination requests. We would also explore privacy and deployment options before any real-world use. Appointment assistance, medication reminders, and retaining nurse-provided instructions are longer-term concepts—not delivered features.

Nightingale is not clinically validated, partnered with a hospital, or ready for production hospital navigation.