SplitSec is being evaluated in real-world pilots. Performance claims should include definitions, sample size, device context, measurement method, and limitations—not just a single headline accuracy number.
Different systems can call very different things “accuracy.” SplitSec keeps these categories separate.
| Term | What it means | What it does not mean |
|---|---|---|
| Detection | A device classified a sound as possible gunfire on-device. | It does not establish that gunfire occurred. |
| Corroboration | Multiple participating devices met applicable matching conditions. | It does not independently verify gunfire or its source. |
| Verification | An event supported by independent ground truth appropriate to the test. | Do not use this label based only on app responses or user self-reports. |
Single-device detections are processed internally. Users receive possible-gunfire alerts only when required corroboration conditions are met.
False-positive behavior includes sounds misclassified as possible gunfire, environmental noise patterns, and single-device detections that help tune models and operating guidance.
Where controlled ground truth is available, measure whether known events were detected and under what conditions.
Missed-event testing should state whether the reference is controlled live-fire, official incident data, participant report, or another source—and publish denominators such as monitored hours and known events.
Measure time from acoustic event to local prompt, corroboration, and delivered awareness.
Latency includes on-device detection time, any corroboration window, notification delivery, and the time for a user or operator to receive and act on the alert.
Phone model, microphone path, OS version, app state, normalization, battery behavior, and model version can all affect results.
Avoid hiding Android/iOS or noisy/quiet environment differences inside one aggregate number. Device and OS context should be published alongside any performance summary.
How many active participating phones are available in the footprint and how density affects corroboration and alert delivery.
Coverage includes armed time, permission status, connectivity, battery health during the pilot window, and how many devices were available when an event occurred.
Early pilot snapshots are reviewed with partners before publication. Specific performance numbers are shared only when definitions, denominators, and limitations are clear.
SplitSec community pilots produce monitored-hours, alert-count, and participant-feedback summaries. These snapshots are too small to support general accuracy claims on their own, and participant reports do not prove that gunfire occurred.
Published pilot metrics require SplitSec review and partner alignment before they appear on this page.
Any performance discussion should include how the system can fail, not only how it can succeed.
Actual gunfire can be missed, and other sounds can be classified as possible gunfire.
It can reduce some false alerts but can delay or miss an alert when another participating device is not available.
Displayed areas and estimated origins can be inaccurate, delayed, shifted, generalized, or associated with the wrong location.
Network, OS, carrier, permission, battery, server, and device conditions can delay or prevent delivery.
A SplitSec pilot should begin with an agreed footprint, device count, operating conditions, success metrics, and review period.