VELA.
A voice first healthcare navigation system that turns “I need care” into a clear, priced, and consent approved path forward.
Where this started.
The question that started the build was narrow and uncomfortable. Can a healthcare agent help someone move from uncertainty to a priced path without inventing confidence or taking control away from the user?
Everything below is a notebook entry against that question. The system was built over a hackathon weekend and it behaves like a prototype, but the behaviors it tests are the ones we care about long after the weekend ends.
Care begins as a sentence, not a billing code.
Healthcare navigation asks patients to translate a human need into billing codes, provider networks, prices, coverage rules, and scheduling steps. Each translation is a place where a person can be quietly overcharged, misrouted, or simply stopped.
Most tools answer the easy half of that translation and leave the consequential half, price and coverage and action, to the patient.
Can one journey hold all of it?
Can a local agentic system combine voice, transparent pricing, error recovery, insurance context, and consent gated action into one understandable journey?
The test is not whether the agent can answer. The test is whether a person can follow the reasoning and stay in control of it.
A useful agent clarifies before it completes.
A useful healthcare agent should not merely answer. It should clarify ambiguity, expose evidence, compare options, ask permission, and return proof of action.
That hypothesis sets a behavioral bar rather than a model bar. Every design decision in VELA is measured against whether it makes those five behaviors legible to the user.
From spoken need to auditable receipt.
A user describes the care they need out loud. VELA transcribes the request and identifies the likely procedure. Where the request is ambiguous it asks a clarifying question instead of guessing a billing code.
Once the procedure is settled, VELA searches real hospital price transparency records and returns comparable providers with the source of each price attached. The user can scan an insurance card in the browser, and VELA compares the current plan against alternative paths.
Consequential actions are separated from information. Booking or enrollment handoffs are gated behind explicit consent for that specific action, and each completed action returns a timestamped, idempotent receipt.
The hackathon prototype demonstrated an MRI for a knee without contrast. VELA compared five real Seattle hospitals and identified Fred Hutchinson Cancer Center at approximately $299 as the lowest shown option. That price was read from real hospital price transparency records rather than estimated by a model. The underlying dataset included approximately 4.2 million federally mandated hospital price transparency records.
Voice input and transcription through Parakeet ASR, with spoken responses through Magpie TTS.
Procedure clarification and an explicit refusal to guess a billing code when the request is underspecified.
Real hospital price comparison read from federally mandated price transparency records.
Browser based insurance card OCR, then current plan and alternative path comparison.
Live Discord webhook delivery, explicit consent before consequential actions, and timestamped idempotent receipts.
Speech recognition, reasoning, and speech generation running locally on NVIDIA GB10 hardware.
One pipeline, bounded at every step.
The pipeline is deliberately linear so that a user can name the step they are in. Model calls in the demonstration ran locally on NVIDIA GB10 hardware, which keeps voice, insurance imagery, and reasoning inside the machine in front of the user.
Nothing crosses from evidence to action without passing through consent. That boundary is the architecture, not a setting.
The prompt we designed to fail.
We tested VELA with the deliberately vague prompt “I need an MRI.” The system did not select a code. It asked which body part and whether contrast was required, then continued only once both were answered.
The reason is empirical. During testing, an underspecified knee search once matched a hardware implant record instead of an imaging scan. The failure was quiet, plausible, and would have produced a confident price for the wrong thing.
Underspecified input is not a user error to be smoothed over. It is a branch the system has to take.
We treat this as a branching and error recovery lesson. The clarification turn is cheap. The wrong billing code is not.
The submitted walkthrough.
Submission demonstration, NVIDIA Spark Hack Seattle, August 2026.
The weekend, on the record.
The team built across a hectic weekend and continued the final submission work across Seattle and Nashville.
First Place Winner, Do Track.
VELA won first place in the Do track at NVIDIA Spark Hack Seattle in August 2026.
The Do track rewarded working systems. What was judged was the end to end journey: a spoken request, a clarification, a sourced price, a coverage comparison, a consent gate, and a receipt.
First Place Winner, Do Track
NVIDIA Spark Hack Seattle
August 2026
Five observations we are keeping.
Trust is a system behavior
Trust is a system behavior, not a disclaimer. Users read what the system does with ambiguity and consent, not what it says about itself.
Clarification beats completion
Clarification is often more valuable than confident completion. One extra question removed an entire class of wrong answers.
A price needs a provenance
A price is only useful when its source and assumptions are visible. An unsourced number is a guess wearing a dollar sign.
Consent is scoped
Consent must be specific to the action. Blanket permission is not permission for the thing that actually happens.
Local inference moves the boundary
Local inference changes the privacy boundary. Voice, insurance imagery, and reasoning stayed on the machine in front of the user.
What this prototype is not.
This was a hackathon research prototype. Displayed prices still require verification before care is booked, and coverage and out of pocket estimates depend on complete plan information.
Provider availability and booking integrations vary. Insurance enrollment requires licensed and compliant pathways that the prototype does not implement.
The system is not medical advice and does not diagnose conditions.
What we test next.
The next phase tests the system with Washington and Massachusetts data and expands the set of shoppable procedures beyond imaging.
Alongside that, we validate price and provider matching against source records, and study whether users understand and trust the recommended path well enough to act on it.
Every system in the Decision Systems Lab is engineered to outlive its author : a small, durable piece of operational thinking made legible to the next engineer.
The complete systems engineering case study, including data flow specifications, rule definitions, validation harness, and deployment notes, is available as a downloadable PDF.