Name Resolution Methodology
How we match obfuscated operator identities to full names from public employment records
This is a technical description of the current (December 2025) name resolution and matching algorithm. It explains how matches happen, and, most importantly, it explains the limitations in that process. The algorithm is subject to change.
tl;dr: For matters requiring certainty, we recommend submitting public records requests to the relevant agency. The information provided here is intended to assist such efforts, not replace them.
Overview
Flock obscures operator identities in its audit logs. Regular audit logs truncate names (e.g., "Bernard Barker" becomes "B. Bar"), while up until December 2025, transparency portal logs replace names entirely with UUIDs (coded identifiers like 550e8400-e29b-41d4...). As of December 2025, transparency portal logs no longer even contain this information. This makes it difficult or impossible to identify who conducted a search and audit a search.
Where possible, our name resolution system attempts to match these obfuscated identities to full names from public police employment records, to assist with research and audits.
The system uses pattern matching and assigns a confidence score to each match, indicating how certain we are about the identification.
The Problem
Flock's audit logs contain names in several abbreviated or obfuscated formats:
| Format | Example | Possible Matches | Found in ... |
|---|---|---|---|
| UUID | 550e8400-e29b-41d4… | Anyone | Transparency Portals |
| Partial | J. Smi | John Smith, Jane Smith, James Smithson | Network logs |
| Partial (first) | J. | John Smith, Jack Hughes, Jim Flanders | Network logs |
| Partial (last) | . Smi | John Smith, Carl Smithson, Bob Smithers | Network logs |
| Full name | John Smith | John Smith, John A. Smith | Organization logs |
| Partial name | J Smith | John Smith, Jane Smith, James Smithson | Organization logs |
| Partial (reversed) | Smith, J | John Smith, Jane Smith, James Smithson | Organization logs |
The challenge is that abbreviated names like "J. Smi" could match multiple people in a police roster. Our system needs to find likely matches while indicating when the match is ambiguous.
UUID Resolution
Transparency portal audit logs present an additional challenge: instead of showing even truncated names, they replace operator identities with UUIDs (Universally Unique Identifiers)—random-looking strings like:
These UUIDs appear to be consistent within an agency, and may reflect a Flock internal database id—the same operator appears to always gets the same UUID—but they provide no information about the person's identity.
Correlating UUIDs to Names
To resolve UUIDs, we attempt to find corresponding records in other audit logs (such as network logs) that contain actual names. The correlation process:
- We look for audit records from other sources with similar search characteristics (time, reason, organization) that include a name.
- Based on how well the records align, we assign a confidence score. Factors include matching search times, identical reasons, and consistent metadata.
- Only correlations with at least 60% confidence are displayed. Lower-confidence matches are hidden to reduce incorrect associations.
- If we find a correlated name (even truncated like "J. Smi"), we then apply the standard name resolution process described below to match it to employment records.
Placeholder Names
When a UUID cannot be correlated to a name with sufficient confidence, we display a placeholder name instead of the raw UUID. These are deterministically generated from the UUID itself. The names tend to be vaguely Cyberpunk-sounding names like "Apex Node," "Garnet Meridian," or "Cobalt Cipher." They are displayed in a muted font in the search results to distinguish them further from real names.
// Same UUID always generates same placeholder
550e8400-e29b-41d4-a716-446655440000 → "Apex Node"
This makes audit logs more readable while preserving the ability to track patterns—if you see "Apex Node" conducting many searches, it is likely the same (unidentified) operator. Note that different UUIDs can occasionally generate the same placeholder name.
The Placeholder Name Birthday Problem
There are only 506 possible placeholder names. As a classic Birthday Problem, this gives us a 50% of duplicate names in organizations with ~27 users.
Placeholder names, in their current form, should be considered to be visual aids, not analytical tools.
Note: UUID correlation is separate from name resolution. Even when we successfully correlate a UUID to a name, that name may still be truncated (like "J. Smi") and require further resolution to identify the full name and employment records.
Finding Full Names
We use a multi-step matching algorithm with confidence scoring:
Step 0: Organization Audit Logs
For a handful of agencies, we have Organization Audit Logs available. For results from these logs, full names are present in the source data and are displayed directly.
Step 1: Organization Mapping
First, we determine which police agency corresponds to each Flock organization. This narrows down the search space significantly—we only look for matches within the relevant agency's roster.
Step 2: Name Format Detection
The system analyzes each audit name to determine its format (partial, reversed, compact, or full). This determines which matching rules to apply.
Step 3: Find Potential Matches
For each person in the agency's roster, we calculate a base score based on how well the audit name matches. Only matches above a minimum threshold (50%) are considered.
Step 4: Apply Ambiguity Penalty
If multiple people match, the confidence score is divided by the number of matches. This reflects the uncertainty: "J. Smi" matching two John Smiths gets half the confidence of a unique match.
Step 5: Employment Verification
Finally, when looking up information for a specific search, we use the available employment records to verify that matched officers were employed at the agency when that specific search occurred.
Understanding Confidence Scores
Confidence scores range from 0% to 100% and reflect how certain we are about a match. Higher scores indicate more reliable identifications.
Base Scores
Before applying the ambiguity penalty, matches receive a base score depending on the match quality:
| Match Type | Example | Base Score |
|---|---|---|
| Full name exact match | "John Smith" → John Smith | 100% |
| Partial with full last name | "J. Smith" → John Smith | 95% |
| Partial with name fragment | "J. Smi" → John Smith | 90% |
| Full name fuzzy match | "Jon Smith" → John Smith | 80% |
| Compact exact match | "JSMITH" → John Smith | 75% |
| Compact fuzzy match | "JSMTH" → John Smith | 65% |
Ambiguity Penalty
When multiple people match, the base score is divided by the number of matches:
// Unique match
"J. Smi" → 1 match (John Smith) = 90% ÷ 1 = 90%
// Ambiguous match
"J. Smi" → 2 matches (John Smith, Jane Smith) = 90% ÷ 2 = 45%
// Highly ambiguous
"J. Smi" → 3 matches = 90% ÷ 3 = 30%
Interpreting Results
High (70%+)
Likely correct. Usually a unique or near-unique match.
Medium (40-70%)
Possible match. May have some ambiguity or partial matching.
Low (<40%)
Uncertain. Multiple candidates or weak pattern match.
Technical Details
Name Format Detection
The system identifies name formats using pattern matching:
| Format | Pattern | Parsed As |
|---|---|---|
| Partial | Single letter + period + space + fragment | {initial: "j", last_frag: "smi"} |
| Partial Reversed | Fragment + comma + space + letter | {initial: "j", last_frag: "smith"} |
| Full | Two or more space-separated words | {first: "john", last: "smith"} |
| Compact | Single word, no spaces or periods | {value: "jsmith"} |
Matching Heuristics
Different rules apply depending on the detected format:
- Partial names: Initial must match first letter of first name; last fragment must be a prefix of last name
- Full names: First and last names compared directly; fuzzy matching allows for minor typos (90%+ similarity)
- Compact names: Compared against concatenated first initial + last name; fuzzy matching applied
Data Sources
Police employment records are sourced from the National Police Index and Open Oversight Virginia . See the Police Employment Information page for coverage details.
Limitations
While our name resolution system attempts to provide valuable context, it has inherent limitations:
- Not all states publish police employment data, and some published data is incomplete or outdated.
- Flock appears to have no requirement that accounts have complete names. Some agencies appear to enter only a first or last name (resulting in a truncated name like "B." or "H."), or use titles ("Detective Jones" → "D. Jon").
- Flock accounts are often assigned to non-police staff (analysts, administrators, dispatchers) who won't appear in police rosters.
- Names like "J. Smith" may match many people in larger agencies.
- Officers may use nicknames, middle names, or different spellings in Flock versus official records.
- Some Flock organization names cannot be definitively matched to specific agencies, preventing name resolution entirely.
- For UUIDs, the process is complicated by various inconsistencies across audit logs. Searches are not guaranteed to show up with the same characteristics in different audit logs. See the Irregular records reports for examples.
- UUID correlation is further complicated by low-entropy data: if there are twenty nationwide, unfiltered searches for the reason "inv" around the same time, it's difficult to find the correct one.
These limitations are not specific to HaveIBeenFlocked.com. Your local police agency will see the same thing during their audits: searches of local ALPR data are being conducted by "H." in a large police or sheriff's department several states away.
For matters requiring certainty, we recommend submitting public records requests to the relevant agency. The information provided here is intended to assist such efforts, not replace them.