ApneaSense / Evaluation path
Start with your product question, capture conditions and required evidence. Existing iOS and Android App engines provide a starting point for discussion; a buyer-ready SDK is not packaged today.
No downloadable buyer SDK, public API key or fixed integration schema.
Current maturity
Separate iOS and Android engines run inside SomniSense with matched models, audio front ends and calibration. The App demonstrates candidate labels, estimated timing, quality handling and waveform/audio review.
Public methods and preprints can be inspected without an inquiry. They are not an integration kit or a release of participant recordings.
Define capture conditions, desired candidate fields and quality states, authorized representative data and reference criteria where appropriate.
Agree errors by task and complete-pipeline latency, memory and power measures for your target device.
Portability, buyer-device performance and intended-use suitability require evaluation. The engines are not one interchangeable binary.
Package format, interface, documentation, licensing and support are uncommitted. There is no public price or fixed delivery schedule.
Discussion example · not a fixed package
Use this as a starting point for scoping. In the first scope discussion, confirm the people involved, data permissions, work, fees and timing before deciding whether to proceed.
Target device, microphone and capture conditions; availability of authorized representative data. Start with specifications and a description—do not send sensitive files in the first email.
The task, intended use, authorization and data handling; acceptance criteria, operating limits and resource budget. Assign responsibilities and stopping conditions before evaluation work begins.
Configuration and data inventory, task-specific error examples and agreed target-device resource results; a recommendation to continue, narrow or stop. Scope and availability depend on separate agreement.
A runnable buyer example, fixed interface, quote or delivery date is not available here. Public methods are research code; the App interface is workflow evidence, not a transferable integration kit.
No. The research measures a stated CoreML forward pass on Apple M2, excluding audio preprocessing and post-processing. Measure the complete pipeline on your hardware before setting a product latency or power claim.
Requirements depend on actual function, intended use, market and claims. They need specific assessment; neither an SDK label nor licensing automatically removes them. Responsibilities require a separate agreement.
Your next step
Define a bounded evaluation, with the evidence and conditions your team needs to make a decision.
