A clean demo clip proves the optics and ISP work. It doesn't prove an operations team can rely on that footage as an auditable job record.

When scoping an enterprise camera-glasses pilot, I separate hardware evaluation from workflow acceptance using three checks:

1. Capture — Pick one repeatable, consented task with zero sensitive customer data. Define upfront what counts as valid visual evidence and what triggers a retake. Lock and log the exact hardware, firmware, and companion app versions.
2. Transfer — Trace the raw file all the way to the receiving backend, not just to local phone playback. Deliberately kill the connection mid-upload and retry the same job. You want to see whether interrupted transfers create silent data loss or duplicate tickets.
3. Review & Ownership — Assign a specific human role to approve, amend, or bounce the record back. Map out who actually owns the downstream layer—transcription, report generation, and work-order sync. Having a hardware SDK on paper doesn't mean that integration pipeline exists.

My baseline acceptance rule for failed uploads is simple: the job stays in a pending state and the local source file remains traceable until confirmed by the server. (Note: this is an evaluation criterion to test against your chosen build, not a claim about an out-of-the-box feature.)

Ultimately, a usable record has to tie together the Job ID, raw file, transfer state, reviewer sign-off, and final approved version so anyone picking up the queue knows exactly what's closed and what's blocked.

For teams who have run hands-free capture pilots in field service or QA—where did your pipeline break first: Wi-Fi/BLE handoff, duplicate records, or reviewer bottleneck?

Disclosure: I'm Vanda Zhao (VandaGeek), co-founder at SmartXY. Sharing this as a pilot scoping framework, not a specific device test result or customer deployment.

My wife was inspired to film this and it gave me an excuse to be Batman so I wasnt going to say no lol

Plus it shows off my custom mask build with the RayNeos in it.