Voice and Language Models¶
Speaking to a robot in a corridor is the capability with the shortest path to a delighted customer and the shortest path to a serious problem. This page describes how it is wired, who owns which half, and what a partner may build against today.
1. Three parts, three owners¶
| Part | What it does | Where it runs |
|---|---|---|
| The shell | Owns the microphone and the loudspeaker. Records while a button is held, plays the answer, shows a state chip. | The Android kiosk application on the tablet |
| The assistant service | Wake word, context, phrase commands, the address speech is sent to, and the health of the whole chain. | A service on the site, reachable over HTTP |
| The operator surface | Offers the tile that starts and stops listening, and shows whether the chain is configured at all. | The uGo server and its browser view |
The split is not an accident of history. The microphone belongs to the shell because Android gives the permission to an application, not to a web page. The context belongs to the service because it is what the robot says, and that must be changeable without shipping a new app. The tile belongs to the surface because that is where a resident touches the robot.
2. The service interface¶
The assistant service is a NestJS application and publishes its own specification at
/docs-json. The groups relevant to an integrator:
| Route | Method | Purpose |
|---|---|---|
/api/chatbot/config |
GET, PUT | Configuration of the assistant |
/api/chatbot/context |
PUT | The system context — what the robot knows about where it is and whom it speaks to |
/api/chatbot/address |
GET, PUT | Where captured speech is sent for recognition |
/api/chatbot/commands |
POST | Register a phrase that triggers an action |
/api/chatbot/commands/{phrase} |
DELETE | Remove one |
/api/wake-word/config |
GET, PUT | The wake word |
/api/intercommunicator/* |
— | The speech path itself |
/api/health, /api/ready |
GET | Liveness and readiness |
MEASURED 27.08.2026 against a running service.
3. How the operator surface reaches it¶
Through our own server, at /api/chatbot/**, and never directly from the browser. The
reasons are the same three that govern every proxy in this system: the browser must not hold
the address of a device, the address belongs in one place in the runtime configuration, and
the surface must know only its own server.
Two restrictions on that proxy are worth stating, because they are what makes it safe to have at all:
It requires a technician sign-in. Whoever changes the system context changes what the robot says to residents. That is not an operator action.
The speech path is blocked, deliberately. communicate and intercommunicator return
403 through our proxy. They belong to the shell, which owns the microphone. Two paths for
voice data would be two paths somebody has to audit, and the second one would exist only for
convenience.
4. The seam to the shell¶
The tile in the operator surface does not record anything. It asks the shell to start and to stop, and it asks for the state to display. The shell offers three methods under one name; the browser side is a thin wrapper with its own tests.
| Method | Behaves like |
|---|---|
| start listening | pressing and holding the shell's own microphone button |
| stop listening | releasing it |
| state | one of unconfigured, listening, capturing, sending, playing, cooldown, error |
The tile only draws itself when the shell offers the bridge. If it does not, nothing appears. This is worth a sentence because the alternative is worse than a missing feature: a resident who presses a button and gets no reaction concludes the robot is broken, and tells everybody so.
State as of 27.08.2026
The bridge is built and tested on the browser side. On the shell side it is not yet present, so today the tile stays hidden. Nothing further is needed from the surface once it appears.
A security note that belongs with it. Exposing an interface to a web view opens the application to every page that view loads. It is acceptable here only because the shell restricts itself to the host of its start address. That restriction has to stay; without it the bridge becomes a way in.
5. Where speech actually goes — and why this page says no more¶
Captured audio leaves the robot to be recognised. Where it goes, over which protocol, and what happens to it afterwards are questions with answers, and those answers are being worked through with the operator of that service before the first customer deployment.
This page does not print them. Not because they are embarrassing, but because an interface description is the wrong place for the current state of somebody's transport security: a finding gets fixed and then described, not published while it is open. What a partner needs from us here is the shape of the chain, and that is above.
What is fixed, and what a data protection officer can be told today:
- Speech is captured only while a button is held. There is no always-on microphone in this design, and the wake word is a separate, configurable feature that is off unless a site asks for it.
- The robot works in full without any of this. A site that does not want a voice assistant simply has no address configured, and the tile never appears.
6. Open¶
| Question | State |
|---|---|
| Recognition service: operator, location, processing agreement | OPEN — to be settled before the first customer deployment |
| Retention of recordings after recognition | OPEN |
| The bridge on the shell side | OPEN — three methods, described above |
| Multilingual assistant answers | The surface carries six languages; the assistant's own language handling is not yet described |