What One FlockNova Search Can Find
FlockNova is Flock Safety's person-search tool, and its search box understates what one clue can reach. A name, plate, email, phone, street address, internet address, or username can fan out across selected sources and produce people, cases, vehicles, accounts, location signals, and sensitive identifiers. The privacy risk begins when that first match branches into records and associations nobody has verified.
In FlockNova, an identifier is not necessarily the destination of a search. It can be the dispatcher.
The readable client takes a name, email, phone, address, plate, IP address, or another selector and maps it to one or more source configurations. The operator's selected sources are checked against visible permission flags, valid requests run in parallel, and successful responses are merged into client state. Some agency-record handlers can then follow links into additional people, cases, and vehicles.
The application is designed to combine, and combination is where a narrow lead can become a dossier.
The query is a dispatcher
The quick-search interface declares thirteen real query categories. Its compact runtime map connects each category to a configured set of source families. Email maps to email enrichment, online accounts, device signals, and Dark Data. Name maps to person, sex-offender, Dark Data, RMS person, RMS vehicle, and arrest configurations. Plate maps to integrated LPR, Dark Data, RMS vehicle, RMS case, and RMS CAD-event configurations.
One plate selector is compatible with five different source contracts. Figure 2. The runtime map defines which source configurations are associated with each quick-search category.
These arrays describe compatibility in the captured client.
The useful conclusion is architectural: one query type can select more than one source contract. That is what makes an email more than an email lookup, or a plate more than a camera hit.
Selected sources run together
The generic executor initializes a status for each selected source. It looks up the source configuration and checks a decoded permission key. A source without a valid configuration or visible permission is skipped. The remaining source requests are executed inside Promise.all, and each successful response is handed to its configured response handler.
This fan-out explains how a single action can create heterogeneous results. One source can return identity enrichment, another account associations, another device observations, another agency records. The client does not wait for the first source before starting the next.
What the request contracts accept
The Person request shape includes first, middle, and last name fields, date of birth, phone, email, address lines, and Social Security number. The Dark Data contract accepts or derives selectors for email, name, city, state, keyword, username, phone, Social Security number, IP address, cryptocurrency, and payment-card number.
The contracts accept everything from names to SSNs and payment cards. Figure 4. The captured source contracts accept identity, contact, network, and financial selectors.
The code shows what the browser is prepared to submit to those configured endpoints.
The selector breadth has privacy consequences. Search terms can include identifiers that are hard to change and dangerous to expose, such as Social Security numbers, payment-card numbers, and persistent online or device identifiers. Those terms can also surface in browser logs, recent-search features, or screenshots if the surrounding product does not minimize them.
One hit can become an association path
The plate handler gives the link-expansion behavior a concrete shape. It sets fetchLinkedEntities true unless explicitly disabled. When RMS vehicle data returns, it can invoke a processor that walks each record's links and collects person, case, and vehicle identifiers. The processor tracks handled IDs and applies a maximum depth, so the shown behavior is bounded rather than unlimited.
This is where a narrow selector can widen. A plate can identify an RMS vehicle record. The vehicle can carry an owner key or links. Those links can lead to a person, case, or another vehicle. The result is an association path generated from the returned record structure.
Owners change. Vehicles are shared. Addresses become stale. A person can appear in a case as a witness, victim, reporting party, or administrative contact. A graph edge is not a finding of guilt.
Why the architecture matters
FlockNova's power is not any single configured endpoint. It is the reduction of friction between them. Source selection, parallel execution, shared client state, and link expansion make it easier to move from one clue to several data domains.
Every feature that reduces friction needs a matching safeguard.
That creates three recurring risks:
- Scope growth: the search moves beyond the target or source that justified the original lookup;
- context collapse: records with different provenance and meaning appear in one operational picture;
- association harm: linked people are treated as investigative subjects without enough attention to why they are connected.
The safeguards should match that architecture. Source-specific permission is only one layer. A robust system also needs purpose binding, provenance, confidence, contradiction display, bounded link depth, meaningful audit, and separate approval when a pivot reaches a more sensitive source.
The readable frontend is built to turn one query category into several selected source requests and, in some agency paths, into a bounded linked-record expansion.