The Case Number Gap in FlockNova
FlockNova, Flock Safety's person-search tool, can run an ordinary search with no case number attached to the visible request. That matters when a name, phone, vehicle, address, or association becomes an investigative dossier: a later reviewer needs the authority, purpose, scope, sources, and result, not merely proof that somebody clicked Search. A case number helps only when the system requires it and carries it with the exact query.
In the captured frontend, the case number is not a universal precondition for every search, and it is not visibly attached to the ordinary search request.
A case-number feature exists. That fact can create a reassuring impression if the surrounding control flow is not inspected. The code shows something more fragile: a conditional prompt, a single browser-stored value, an ordinary executor that never consumes that value, and an older history record that omits it.
The prompt is conditional
The readable header opens the case modal only when three conditions align: the current route starts with /search, user.RequiresCaseNumber is truthy, and the browser has no case value. The same header exposes Quick Search when the current path starts with /investigation. Its menu visibility also checks userDetails.requiresCaseNumber, which uses another user object and different capitalization.
All three conditions must hold, or the case prompt never appears. Figure 2: the automatic prompt watches /search while Quick Search is exposed on /investigation routes, and the two controls read differently shaped user properties.
The prompt is conditional, and its control signals drift in this captured generation. Its behavior depends on route, object, property spelling, and browser state.
A visible modal is often treated as proof of enforcement. Here, the modal is one entrance to a browser value.
A browser label, not a scoped authority object
The case provider initializes one caseNumber value from localStorage. When it mounts, it reads the same storage key and either sets or clears that single value.
The stored value is not keyed to an investigation, organization, target, legal process, or expiration, and it carries no case status, assignment, jurisdiction, date range, approved source, search geography, or link-depth limit. Those are the properties an authorization decision would need to describe its scope.
Figure 3: the captured context loads one caseNumber value from browser local storage. The stored value is a single string, but a real authorization would describe scope.
The problem is treating the existence of that label as proof that a query was validated, properly scoped, or tied to the matter displayed in the browser.
The ordinary request path omits it
The ordinary search screen validates three categories before execution: a search type, a nonempty term, and at least one selected data source. It then writes history and invokes the execution hook. The execution hook adds an optional route investigation ID to search parameters, but it does not read CaseContext or attach a case number or user-entered purpose.
The ordinary request carries type, term, source, and an optional investigation ID, but not the case value. Figure 4: the ordinary path checks type, term, and source, then builds parameters with an optional investigation ID and no case context. Sources: SearchAppMain.js and useSearchExecution.js.
An investigation ID is not interchangeable with a case number. In this application, the investigation ID is a workspace identifier used in routing and result organization. The case value is separate browser metadata. Neither value, standing alone, establishes why a particular source may be queried, which target is authorized, or what time and geographic limits apply.
The gap matters most on high-sensitivity paths. A header can display a plausible case number while the downstream request never receives it. That makes the label weak evidence for attributing a particular lookup to the matter shown on screen.
History is not an authorization record
The older readable history helper creates a record with four fields: user ID, search term, search type, and investigation ID. It does not include the case number, purpose, selected source list, result count, outcome, export, or linked-record pivots. If the history request fails, the catch block reports the failure and returns control; the search workflow is not made conditional on a successful audit write.
Recent-search history can help users resume work. It is not the same thing as an immutable compliance audit.
Figure 5: the history entry stores only user, term, type, and investigation ID, then catches a failed write. A four-field history row cannot reconstruct what an audit would need.
A meaningful audit would need to reconstruct the attempted source, normalized selector, organization, scope, result status, later reveal, link expansion, sharing, and export. It would also need to survive a client failure.
What stronger accountability requires
The problem is the client's inability to distinguish legitimate from improper lookups through a reliable request-bound control.
Without that binding, several forms of harm become harder to detect:
- personal-interest browsing can resemble authorized investigation activity;
- a stale browser value can create false matter attribution;
- a query can outgrow the target or source scope that justified its first step;
- a recent-history row can be mistaken for a complete audit;
- review teams may not be able to reconstruct which purpose governed a sensitive result.
A server-validated authority record would bind the query before any source is touched.
The product-level remedy is not simply "require any case string." A stronger design would use a server-validated authority record scoped to user, organization, target, source, time, geography, and permitted downstream actions. The browser would pass an opaque identifier, and the server would reject out-of-scope requests before touching an upstream source.
That is the precise gap: the ordinary client path shown here neither requires nor consumes the case value. It is a more defensible and more useful finding than the broader claim that "FlockNova requires no case number."