The project owner confirmed a correct spoken answer on the experimental wearable after a wake request. The answer was very slow. A greeting was also heard.
Evidence and limits
Established: a correct spoken answer heard on the physical development device in a bounded test.
Still open: acceptable response time, speaker clarity, sustained capture and repeatable recovery. A later saved-greeting test was silent and the connection went offline. After a recovery update, the startup greeting was heard again, but another wake request produced no answer; further physical checks are needed.
Next: check startup, saved greetings and repeated exchanges before treating the conversation path as reliable.
Reviewed against the project owner’s development tests, 7 October 2026. Component results are not evidence of a launch-ready product.
An experimental wearable microphone recording reached our development system in full over mobile data. Its received playback was reviewed by the project owner and confirmed as clear.
What this establishes
Established: microphone capture and delivery of a complete recording in this particular hardware test, supported by a human playback review.
Limit: this result does not yet prove spoken replies on the wearable, a complete conversation, continuous capture or reliable operation across changing conditions.
Next: verify the returned speech and conversation path together on the physical wearable.
A correct spoken answer has now been heard on the wearable. The connected checks now focus on response time, repeatable exchanges, saved greetings and recovery. Idle periods, reconnects and noise also need validation.
What this establishes
Current position: the clear recording and complete upload provide a foundation for the next physical check.
Still open: repeatable conversation, acceptable response time and recovery have not been established. Idle, reconnect and noise behaviour also remain open.
Next: review the full exchange and recovery behaviour before treating the wearable conversation as demonstrated.
The local owner-app prototype brings together a separate Home and Calendar for each cat, local care notes, reminders and reviewed reports. The website’s app tour offers a small, fictional example of that approach.
What this establishes
Demonstrated: a local prototype for organising records and care around the selected cat, with separate Home and Calendar views.
Limit: the website tour uses fictional examples. Tour notes and reminders stay in page memory; they are not an owner account, real animal monitoring or a connected care record.
Next: continue checking the owner experience alongside the connected wearable work and future customer testing.
The photographic style of the 18 advocate portraits in knitwear was accepted. The website and local app prototypes now share the BatCat master design in Night mode, including the original BAT–logo–CAT identity.
What this establishes
Accepted direction: the portrait style and a common design basis for BatCat’s local experiences.
Limit: a character portrait does not establish a new voice approval or a live conversation. The website guide is scripted. Separate saved prototype auditions are available to listen to; they are not live conversations or confirmation of launch voice availability.
Next: apply the shared design consistently as the product and its connected experience are reviewed.
