Flock Says 'Just Gunshots.' Its Product Pages List More Sounds
Flock chief executive Garrett Langley said the company's gunshot-detection microphones detect "just gunshots." He made the remarks onstage at TechCrunch Disrupt in an interview with TechCrunch editor-in-chief Connie Loizos. The account was published Oct. 14, 2026. TechCrunch
Flock's own product language describes a wider set of sounds. Its website states its audio systems can detect street takeovers early and identify severe crashes in real time. The same materials say the systems can expand awareness beyond gunfire with alerts for car crashes, fireworks, and sideshows. The Gunshot Detection product description adds that it listens for gunshots and other ambient audio across nearby neighborhoods to provide earlier awareness of public safety events.
Flock spokesperson Paris Lewbel kept that wider description. She said Flock's gunshot detection technology is primarily used to detect gunfire but is also capable of detecting fireworks, sideshows, and potential car crashes.
Langley addressed part of the history onstage. When Flock announced its Gunshot Detection feature, it said the technology would listen for sounds of "screaming." Langley said only a couple of customers prototyped distress detection with Flock and the company then decided the product would do gunshots plain and simple.
Company documentation frames the system as event-driven and bounded. Flock Safety states its Gunshot and Audio Detection is event-triggered and policy-governed. It states the system activates only when it detects an acoustic signature of interest, a distinctive sound pattern, such as a gunshot. Flock Safety The company states the system is designed to recognize specific sound events, not people, and states it cannot understand speech or analyze language. Flock Safety It says the audio signals connect with footage and license plate data through FlockOS to enable a multi-angle view of incidents, pairing with video, license plate readers, and drones to give officers layered evidence beyond shell casings.
The broader context here is definitional, not only technical. "Primarily used for" and "capable of" are different claims than "just." One describes deployment policy. The other describes classifier coverage, what the software is trained to sort into categories. Both matter for procurement, validation, and community review. A narrow gunshot-only model implies one set of training data, testing regimes, and false-positive budgets, the allowance for mistaken alerts. A multi-class acoustic detector for crashes, fireworks, and sideshows implies another, with different edge cases around urban noise, overlapping signatures, and thresholds for alerting.
In my view, this is where Flock needs precision. Microphone networks in public space live or die on trust in their triggering logic, retention rules, and fusion with cameras and license plate readers. Event-triggered architectures help, but only if the event list is public and stable. Engineers evaluating such systems will want to know which sound types are active in a given deployment, how they were validated, and how policy governs expansion to new types. The optimistic case remains real. Earlier crash awareness and faster gunfire localization can save minutes that matter for victims and responders. That outcome is easier to evaluate, and easier to defend, when what the microphone hears is stated the same way onstage and on the product page.
