Ash’s voice: identity, validation, and the remaining wait
What was deployed, which responses were prepared, what the model actually generated, and why a successful turn still felt slow.
Published 2026-11-01 · Dated evidence, not a live status feed
A bounded development deployment
The November 1 change added approved identity and roster handling and personality cues to the Pi development voice path. The deployment evidence verified eight scoped files and preserved the existing services and audio event record. That deployment step itself did not run listening, generation or synthesis.
The Windows regression report ran 155 tests with zero failures, zero errors and eight platform skips. The Pi report ran 155 with zero failures, zero errors and no skips. Eleven helper checks passed. These are software and helper checks, not 155 live conversations.
Separate the prepared route from the model
The owner-operated launcher bounded capture and playback to one turn. Dr. Jenny’s role was answered correctly through the approved roster route without invoking the model. A prepared rough-day cue also played successfully. Neither result qualifies general emotional understanding or unconstrained conversation.
Bishop’s audible name was correct while a Windows text boundary produced mojibake. Native output was explicitly decoded as UTF-8 before helper logs were saved. Offline native-boundary fixtures reproduced the earlier corruption and verified the correction, with the system code page unchanged. The ASCII Jenny reply did not qualify live accented speech text.
A complete answer can still fail validation
The first natural-response test reached the model, but its complete 51-word draft exceeded the unchanged 50-word validator. The recorded fallback was therefore not proof that the model had been unable to generate an answer.
The owner approved a prompt-only correction: state the hard numeric maximum, aim for 20–35 words in ordinary replies, and avoid forcing a question when an acknowledgement or answer is enough. After masking the prompt assignment, the executable syntax tree was unchanged. Model, voice, generation options, validator and approved facts were preserved.
The corrected regression runs again recorded 155 tests on each platform with the same zero-failure and platform-skip distinctions. An isolated Pi staging attempt initially omitted four reviewed-answer fixtures; the omission was corrected with verified copies and the initial failed report retained. This was test staging, not a hidden change to the product validator.
The later successful turn still took 62.645 seconds
A later owner-present run produced a fresh 28-word model response. The complete response passed unchanged, a speech file was created and playback completed. This is one observed success after the prompt correction, not a broad reliability pass.
The recorded pipeline was 62.645 seconds; it excludes the launcher’s longer owner-input and feedback interval. The components show why shortening the answer alone did not remove the wait.
| Recorded component | Seconds |
|---|---|
| Listening and transcription | 9.082 |
| Model loading | 7.397 |
| Prompt evaluation | 23.890 |
| Answer generation | 11.241 |
| Speech synthesis | 10.981 |
| Complete recorded pipeline | 62.645 |
What remains open
The prompt dominated more time than answer generation in this turn. Keeping tests close together and shortening repetitive prompt text were proposals for later investigation; no prompt-compression implementation or latency resolution is claimed here.
No outcome was recorded for the proposed visual-capability test. General conversation reliability, sustained multi-turn behavior and sensing honesty still need their own observed tests. The public website remains separate from the live development voice path.