A Flock Safety Search Reason Is Not a Case Number or Warrant
Suppose an officer uses Flock Safety to check where an ex-partner has been driving. A reason box records whatever that officer types; a case number can connect the search to an institutional file; a warrant reflects legal authority approved outside the app. Those are three different things. The distinction is no longer theoretical: documented Flock misuse cases have involved officers searching people they dated, their former partners, spouses, and other personal targets.
A reason box, a case number, and a warrant are three different controls.
In at least the captured visual-search workflow, an officer may be able to proceed past the client's case-number gate without entering a case number. The code defines four organization-level case-number states: UNSPECIFIED, UNAVAILABLE, OPTIONAL, and REQUIRED. In visual search, a missing case number triggers an error only when the organization preference resolves to REQUIRED.
That is the load-bearing finding. The same captured client separately rejects a blank reason in standard search, and the visual-search validator also checks a reason when that field is configured as required. The code reveals a distinction: a typed purpose and a formal case identifier are different controls, and the latter is not represented as a universal client-side precondition.
For a driver, vehicle owner, borrower, passenger, rental customer, or person whose car appears near an event, that distinction matters because the identifier that ties a query to a durable institutional record may be absent at the moment the client validates it.
The client contains four case-number states
In Milwaukee, prosecutors accused an officer of using Flock to track a woman he dated and her former partner; investigators identified nearly 200 unauthorized searches. The officer later pleaded guilty and received probation. The department said it changed its auditing after the case (Wisconsin Public Radio; CBS 58). Audit logs helped expose that conduct, but only after the searches had occurred.
The production-labelled Jose Cuervo artifact defines the search identifier requirement enum with four literal values: UNSPECIFIED, UNAVAILABLE, OPTIONAL, and REQUIRED
Only REQUIRED blocks a blank case number; the other three states let the search proceed. Figure 2: the requirement is an organization preference with four possible states.
OPTIONAL and UNAVAILABLE are literal enum values in the captured client. The client retrieves organization preferences and uses the selected state when validating search fields, so the software model anticipates configurations in which a case number is not mandatory.
An agency may investigate an urgent incident before its records system assigns a formal case number, or its workflow may use another identifier. The accountability question is what replaces the missing link at the moment information is requested and disclosed.
The visual-search rejection is conditional
The visual-search validator makes the preference operational. It reads separate organization values for searchReason and caseNumber, compares each value with REQUIRED, and rejects the corresponding blank field only when that comparison is true. A missing case number by itself therefore does not trigger this error under the other represented preference states
The blank-case error fires only when the organization preference equals REQUIRED. Figure 3: the highlighted branch ties the missing-case error to c === Qr.REQUIRED.
The client-side error is conditional because the validator evaluates organization preference state before deciding whether an empty searchCaseNumber blocks the visual-search form. A represented workflow can therefore reach its next validation stage without a formal case number when the relevant preference is not REQUIRED.
Standard search still demands a stated reason
The nearby standard-search path keeps a different control. Its request object includes a reason, and its validator checks whether searchReason is missing or blank after whitespace is removed. When blank, it returns the literal error Search Reason required to execute a search! before the request construction continues
Standard search always rejects a reason left blank after trim(). Visual search blocks a blank case number only when REQUIRED.
Figure 4. Standard search includes reason text and rejects an empty value in the captured client.
This standard-search branch requires nonblank text by testing whether a string exists and remains nonempty after trim(). The client therefore distinguishes a reason from a case number. It does not check whether the typed reason is meaningful or matches the actual query.
A typed reason cannot do a case number's job
A case number can make later review easier by linking a query to reports, assignments, approvals, evidence, and outcomes. A reason field can preserve useful context at the moment of search.
A typed reason preserves context, but only a case number links a query to institutional records, and reason, user, scope, exports, and later case linkage must all stay connected to reconstruct the why.
The privacy risk is greatest when a low-friction preliminary search becomes detached from later accountability. A vague reason could be difficult to audit. A missing case link could make it harder to determine which incident prompted a query, who reviewed it, whether the subject was ever connected to the incident, and whether resulting records or exports were later corrected or deleted.
What this interface exposes is the earlier governance choice: in at least one represented configuration, disclosure is not visibly conditioned on a preexisting case number.
That choice pushes the accountability elsewhere. The reason entered, the user, the search scope, the resulting exports, and any later case linkage all have to stay connected if an agency ever wants to reconstruct why the search happened.
In this captured client, a reason is not a case number, and a case number is not universally required by the visible validation. That distinction has consequential effects on when accountability begins.