Acceptance tests
Twenty-seven pass/fail tests that define integrated, plus the seven measurements to take on your own hardware before you deploy to a customer.
6 min read
On this page
Ship against these. Each is pass or fail, each maps to a failure we expect, and together they are what integrated means. Run the whole every-mode block plus the block for the mode you are deploying.
Every mode
| # | Test | Pass criterion |
|---|---|---|
| 1 | Boot with valid provisioning | Heartbeat within 30 s; your server records the device as online |
| 2 | Boot with a missing property_id | Device refuses to run and shows a fault. It does not guess |
| 3 | Unknown MAC | Stops cleanly. No retry loop |
| 4 | Blocked device (403) | Stops cleanly. No retry loop |
| 5 | Server unreachable at boot | Backs off to the 60 s cap. Does not hammer |
| 6 | Bad TLS certificate | Refuses to connect and files a TLS_FAIL incident |
| 7 | Kill Wi-Fi mid-operation | Reconnects with backoff |
| 8 | Reboot the access point with ten or more devices attached | Reconnects spread over time — no simultaneous burst |
| 9 | Remote REBOOT command | Acknowledged, executed, result reported |
| 10 | OTA to a new version and back | Progress reported, checksum verified, rollback reported honestly |
| 11 | Ten-minute soak | No resets; sample-rate drift measured and recorded |
Mode A — push-to-talk streaming
| # | Test | Pass criterion |
|---|---|---|
| 12 | Keyed transmission | Valid udp-v1 packets; your server logs a session; a transcript appears |
| 13 | device_session changes on reboot | A new session key server-side, not a continuation of the last one |
| 14 | Button released | Transmission stops. Zero packets while unkeyed |
| 15 | Identity fields | property_id present on every packet; the transcript lands on the right site |
Mode B — request and response
| # | Test | Pass criterion |
|---|---|---|
| 16 | Framed post | Start and end markers present; 200 ok |
| 17 | Echo round trip | The returned WAV is clean: no clipping, correct rate, intelligible |
| 18 | Notification poll | 204 when empty; audio played when 200 |
| 19 | Release mid-utterance | The server still transcribes what it received |
Mode C — full-duplex agent
| # | Test | Pass criterion |
|---|---|---|
| 20 | Connect, handshake, greet | ready received; agent audio plays within 3 s of the press |
| 21 | Complete a two-item transaction with a modifier | Correct records server-side |
| 22 | Mic mute | Zero uplink frames while the speaker is active. Count them server-side |
| 23 | Button interrupt | Audio stops within 200 ms of the press. Measure and record |
| 24 | Long reply over ten seconds of speech | No overrun, no reset; record the buffer high-water mark |
| 25 | Idle five minutes mid-session | The connection survives via ping and pong |
| 26 | Print a ticket | Prints once, acknowledged, does not reprint |
| 27 | Print with the printer unplugged | The ticket returns to the queue after the claim timeout |
Measurements to take on your own hardware
These cannot be determined from documentation, they vary by form factor and room, and they are what a sizing conversation is built on. Record them once, per deployment shape.
- 1Playback buffer high-water mark under a long reply.
- 2Button press to audio actually stopping — the barge-in that matters.
- 3Speaker ring-out time. This sets your real tail_ms.
- 4True sample rate over a ten-minute soak.
- 5Mic-mute engage and release latency.
- 6Time from button press to the first uplink audio frame.
- 7Sustained bandwidth per device during normal operation.
Something wrong or missing on this page? Tell us.