Executive Tech Brief
When Sheriffs and CIOs Are Both Right — and the Biometric Program Still Fails
For each major issue, we offer a practical place to start and one thing to watch out for before the agency accepts the risk, funds a workaround, or moves forward.
The examples in this brief are drawn from recurring patterns seen across public-safety biometric programs, Vendor delivery efforts, agency modernization projects, and operational support conversations. Specific agencies, systems, data conditions, and implementation details are intentionally generalized to protect client confidentiality and public-safety operations.
The Leadership Challenge
In biometric modernization, the hardest failures are rarely caused by one unreasonable person, one careless decision, or one bad technology choice.
More often, each stakeholder is solving the risk, workload, cost, or complexity directly in front of them — without always seeing what it does to the people upstream or downstream and shared mission.
A booking decision may create a Records problem. A Records workaround may create a Livescan problem. A Livescan limitation may create an ABIS problem. An ABIS configuration may create a latent, investigative, Detention, or state-reporting problem.
The Sheriff is right about mission urgency. The CIO is right about cyber, privacy, auditability, and integration risk. Detention is right about safety and workload. Records is right about data quality. The crime lab is right about accuracy and defensibility. Procurement is right about process and budget. The Vendor is right about what the product can support (yes the Vendor is important too).
The program still struggles when those locally reasonable decisions are not connected into one mission decision across the full workflow.
The right people can be at the table and still talk past each other unless leadership connects upstream and downstream risk into one mission decision.
How to Start: Pick one biometric workflow that already causes pain. Do not start with the whole modernization program. Start with one workflow where delay, rework, risk, or frustration is already visible.
Watch out for: Solving the problem only from the perspective of the loudest department, the oldest system, the current Vendor limitation, or the easiest short-term workaround. The goal is to understand what happens upstream, what happens downstream, and what mission risk the agency is accepting. Specific examples follow below, including facial recognition, JMS/Booking-to-Livescan charge data, and scars, marks, and tattoos workflows.
"The problem is not that leaders are wrong.
The problem is that each group is right about a different risk.
Biometric leadership begins when siloed risks are no longer evaluated separately, but understood together as one mission decision."
Facial Recognition: From Unknown Deceased to Detention Intake
“Should we use facial recognition?”
Many agencies treat facial recognition as one giant yes-or-no decision. That framing is too blunt. The real decision should be use-case-specific: purpose, data source, operator, training, audit trail, approval level, permitted action, and allowed outcome.
Different uses carry different risks.
The same engine that may raise serious concerns in broad public-space monitoring may be highly defensible when used to help identify an unknown deceased person, support next-of-kin notification, review crime footage, improve intake identity confidence, or detect booking biometric enrollment face-and-fingerprint mismatches before they become permanent record errors.
In command-level conversations, this distinction often changes the room. The question stops being whether the agency is “for” or “against” facial recognition and becomes: which use cases are allowed, which are prohibited, which controls are required, and what action may be taken from a result?
How to Start: Do not start alone. There are strong resources available from groups such as FISWG, along with agency policies, lessons learned, and practical examples from programs that have already worked through these questions. Build a facial recognition use-case matrix before making a broad policy decision. List the specific uses the agency is considering: unknown deceased identification, next-of-kin support, crime footage review, investigative lead generation, Detention intake identity verification, duplicate enrollment review, or face-and-fingerprint mismatch resolution. For each use case, define the purpose, data source, approved users, training requirements, approval level, audit trail, documentation standard, and what action may or may not be taken from a possible result.
Watch out for: Treating facial recognition as one single agency decision, one single policy question, or one single technology type. A tool that performs well against controlled booking photos may not produce strong investigative leads from difficult field images. Booking-to-booking comparison, visitor verification, and Detention intake use cases often involve more controlled images, known capture conditions, and narrower workflows. Field investigations may start with poor video stills, distance, angle, motion blur, masks, glasses, glare, shadows, low light, partial faces, or compressed images. That is a different operational and technical problem. The mission context matters: algorithm design, gallery type, probe image quality, thresholds, review tools, operator training, audit requirements, and downstream action can all change by use case. Agencies should test and evaluate facial recognition against the images and mission they actually expect to support, not only against clean booking photos or ideal demo images. They should also plan for public trust and misuse risk. Strong policy, training, audit controls, prohibited-use rules, documentation, and public transparency are not side issues; they are part of the operating model.
Decision
Shared risk
clarity.
1Mission Risk
Public safety, officer safety, investigations, release decisions, Detention flow, victims, and families.
2Technology Risk
System capability, integrations, data flow, audit trails, search logic, security, and long-term architecture.
3Legal / Policy Risk
Public trust, local policy, CJIS, privacy, state requirements, documentation, defensibility, and authority.
4Operational Risk
What actually happens in booking, Detention, patrol, Records, the crime lab, investigations, medical examiner, and IT.
5Vendor / Implementation Risk
Scope, acceptance testing, training, support, conversion, configuration, accountability, and sustainment.
6Procurement / Budget Risk
Cost savings, funding cycles, contract terms, lifecycle cost, tradeoffs, and what is not funded.
Booking Charge Data: The Accepted Broken Workflow
One of the clearest examples is the data path from Booking/JMS to Livescan, ABIS, and downstream state or federal systems.
In many agencies, the people closest to the work already know the issue exists. Booking staff, Detention leaders, Records, IT, and biometric users may all understand pieces of the problem. In my experience, they may even be empathetic to how it affects one another. But the workflow has existed for so long that it begins to feel impossible to change.
The common explanation is familiar: the system is too old, the DA will not change, the state format is fixed, the Vendor integration is fragile, the replacement project is already being scoped, or the risk of changing the current process is too high. In some agencies, the JMS or booking system replacement and the biometric modernization effort are happening in parallel without being treated as one operational decision.
Once leadership sees this as a shared mission-risk problem, the conversation often changes. The question becomes whether Booking/JMS should become the source of truth for charge data, what format the DA and state can accept, whether a bridge or translation table can reduce risk in the short term, and how the future system roadmap should prevent the same problem from being rebuilt.
“The system is old, fragile, and too risky to change.”
That may be true. But if the agency stops there, a technical limitation becomes an accepted mission limitation.
“What risk are we accepting by leaving the workflow this way?”
That question allows leadership to compare the risk of change against the risk of delay, duplicate entry, inconsistent data, Detention friction, downstream record issues, and future replacement scope.
How to Start: Look at pre-booking and booking data entry, Livescan charge tables, and the handoff between JMS/booking and biometric systems. Bring IT, the DA’s Office, the JMS/booking Vendor, the Livescan Vendor, Detentions, and Records subject matter experts into the same conversation. This is a common place where old decisions, Vendor limits, and downstream reporting requirements quietly create daily friction.
Executive sponsorship matters here. The team needs to know the goal is not to blame the old workflow, but the current workaround should not be treated as permanent. Support them in evaluating the full picture and finding a practical path forward.
Watch out for: Treating the charge-table problem as only a Livescan issue, only a JMS issue, or only an IT issue. Before accepting the workaround, ask when the Livescan and JMS/booking systems are next planned for updates, whether both Vendors can be brought to the table, and whether IT can mediate a practical bridge solution. If the JMS is too old to change safely, a translation table may reduce risk without forcing a major legacy-system change. Make sure to include the DA’s Office, since local and state charge variations are a common point of friction.
Vendor / Agency Delivery Risk
Vendor risk is not simply the risk of choosing the wrong Vendor.
Having been on the Vendor side, I know these projects are complex. A modern biometric platform may include thousands, even tens of thousands, of configuration choices, workflow decisions, data rules, integration points, user permissions, quality settings, training choices, and operational tradeoffs. Even strong Vendors and strong agency teams can struggle when all of those variables converge.
The best projects do not happen when the agency steps back and waits for the Vendor to deliver. They happen when the ✦ agency stays engaged through design and delivery: sworn leaders answer operational questions, Detentions explains intake realities, Records explains data consequences, IT explains architecture and security, examiners explain quality and search impact, and long-time users provide institutional memory.
BCP often describes this through a Dual Lens: agencies have mission, policy, operational, and budget needs; Vendors have product, support, contractual, and delivery realities. Successful biometric programs respect both. But the agency still has to bring the mission context continuously, not just during procurement.
Support is not an afterthought. It is part of the operating model.
Across roughly a hundred agency engagements in one form or another, one pattern has been hard to miss: the projects that feel healthiest after go-live usually do not treat support as something that starts after delivery. They build support into the project while the system is still being designed, configured, tested, trained, and corrected.
That matters because the right support resource learns the story of the system. They learn why certain configuration decisions were made, where the agency compromised, which workflows were difficult, which users needed more training, where data quality problems appeared, and where the Vendor and agency had to work through practical limits together.
In strong projects, that support role becomes more than a helpdesk contact. It becomes a trusted bridge between the Vendor, agency leadership, IT, Detentions, Records, examiners, trainers, and daily users. Over time, that relationship can begin to feel like a agency work-family dynamic in the best sense: people know who to call, the support person understands the context, and problems are less likely to sit unresolved until frustration becomes normal.
This is also why project delivery and support cannot be cleanly separated. A support person who is involved during delivery is learning the system while the agency is learning the system. That shared learning creates better training, faster issue recognition, clearer escalation, and a stronger foundation for long-term customer satisfaction.
When support is weak or introduced too late, the agency may not know the system is drifting until the workaround has already become normal. If your agency cannot afford the premium of a dedicated on-site engineer, consider whether a shared regional support resource, scheduled onsite support model, or deeply engaged remote support lead could provide some of the same continuity.
How to Start: Treat delivery and support as one planning decision. During procurement, project kickoff, configuration, testing, training, and early go-live planning, identify who will carry the system knowledge forward after delivery. That may be a Vendor support lead, agency system owner, trainer, onsite engineer, shared regional resource, internal power-user group, or deeply engaged remote support lead. Bring that person or team into design reviews, workflow decisions, test cycles, training observations, and early user feedback so support learns the system while the agency is learning the system.
Watch out for: Treating support as something that starts after go-live, or treating delivery as something the Vendor carries while the agency waits for the system to be finished. When agency leadership, IT, Detentions, Records, examiners, trainers, and future support resources are not engaged during design, configuration, testing, training, and early issue resolution, support starts without the story of the system. Implementation decisions, configuration compromises, training lessons, workflow issues, and user concerns get lost. In my experience, how an agency stays engaged during delivery — and how it carries that knowledge into support — has a very strong correlation with future user confidence, issue resolution, Vendor partnership, and long-term customer satisfaction.
"The Vendor brings the platform.
The agency brings the mission.
The project succeeds when both remain engaged through the hard middle where design decisions become operational reality."
Scars, Marks, and Tattoos: The Data You Wish You Had Later
Scars, marks, and tattoos are another version of the same leadership challenge. The disconnects are visible. The full context impact and investigative value is often not visible until later.
Across roughly a hundred agency engagements in one form or another, I have heard a consistent pattern from investigators, analysts, booking teams, and biometric users. Major crimes units often understand the value immediately. They are not only thinking about gang tattoo intelligence. They are thinking about identifiers, witness descriptions, video observations, unknown persons, repeat offenders, investigative leads, and details that may not be easily captured at intake, but can become critical in solving crimes faster and more accurately.
The challenge is that the capture workflow is hard. It can slow intake, create Detentions concerns, require movement of an incarcerated person, depend on old camera workflows, require consistent data entry, expose system limitations, and raise legitimate questions about who owns the data, who can search it, and how it should be used.
“This is hard to collect, hard to structure, and hard to sustain, disruptive to operations.”
That is typically true. Scars, Marks, and Tattoos capture can affect booking speed, Detentions workflow, image quality, staffing, safety, system design, policy, training, and search permissions...
- When not optimized and integrated.
“What will we wish we had during the next investigation?”
The mission question is not only whether the workflow is burdensome. It is what investigative, Detention, officer-safety, or public-safety value is lost when the agency does not capture, structure, or search the information. If you don't capture SMT at booking, lineups are limited and slow, history is complicated or impossible to search, leads are missed, and people may be hurt.
The data that feels optional during intake can become the data someone wishes they had later.
Agencies that have had this information available often understand the difference. When an analyst, detective, or examiner has worked in an environment where SMT data was searchable and useful, they can feel the loss when it is missing. They do not need a theoretical explanation. They know how quickly a scar, tattoo, mark, descriptor, or image can become important when the case finally needs it. Especially when minutes matter.
This is the same pattern as the JMS/booking charge-data problem. The technical complexity is real. The operational burden is real. But when every stakeholder evaluates only the burden directly in front of them, “not now” quietly becomes the mission decision.
"The burden of collecting biometric data is visible.
The consequence of missing it may not appear until the next investigation, the next false identity, or the next victim."
Technical Details: When They Become Mission Outcomes
This is not a question of good or bad leadership. I have seen strong sheriffs, CIOs, commanders, Detention leaders, forensic leaders, IT teams, and project teams struggle with biometric modernization. Not because they lacked commitment, but because the technical complexity is unusually deep and often hidden below the surface.
A biometric system is not just installed. It is configured, tuned, tested, trained, integrated, supported, and adjusted against real people, real images, real fingerprints, real workflows, and real agency conditions. Thousands of small technical choices can affect accuracy, speed, usability, search results, data quality, support burden, and user confidence.
That is what makes biometric modernization different from a standard enterprise software rollout. The agency may be told the system works. The Vendor may show successful test cases. The project team may see green checks. But if the system has not been evaluated against the agency’s actual data, actual capture conditions, actual workflows, and actual mission needs, the most important risks may still be hidden.
The sale is not the finish line. Go-live is not proof of mission success. In biometric programs, some of the most important issues only appear after real users, real captures, real searches, real queues, and real exceptions begin to accumulate. That is when technical detail becomes operational reality.
These complex issues often take months of operational patterns to identify, scope, and solve. That is why we recommend a 90-day post-go-live Operational Acceptance Testing (OAT) period focused on real-world performance indicators such as accuracy, search quality, workflow friction, exception rates, and user confidence. When building these tests, agencies should compare results against historical known-result cases, prior State and FBI search outcomes, controlled examples, and real production patterns. In our experience, this significantly reduces the likelihood of a serious hidden accuracy or performance issue becoming normal after go-live.
Normalize the complexity.
These patterns are not unique to one agency. They appear across biometric programs because the systems, workflows, technical settings, data, and stakeholders are inherently complex.
Do not minimize the stakes.
Small configuration choices, image-quality issues, workflow friction, policy uncertainty, cost pressure, and technical debt can become public-safety risk when no one weighs the full consequence.
Make the mission decision explicit.
The agency should know which risk it is accepting, why it is accepting it, what technical assumptions were made, and what roadmap exists to reduce that risk over time.
A system can pass basic checks and still not be tuned for the agency’s real data.
On one international project, a client raised concerns that fingerprint accuracy was not meeting expectations. A basic support review could have stopped at the easy answer: the system worked on test cases, the matcher was functioning, and the source fingerprint quality was poor.
But that answer would have missed the real issue. Poor fingerprint quality did not mean the agency simply had to accept poor performance. It meant the system needed to be evaluated against the actual operating environment and tuned accordingly. Image processing, filtering, matcher behavior, threshold settings, quality handling, and related configuration details all mattered.
Once those technical details were adjusted to the real-world fingerprint conditions, performance improved significantly. That is why biometric acceptance cannot stop at clean test cases or green checkmarks. A system may be technically working and still not yet be working for the agency’s reality.
How to Start: Build a 90-day post-go-live Operational Acceptance Testing (OAT) plan before the system goes live. Do not limit acceptance to clean test cases, green checkmarks, or whether the system technically functions. Identify real agency workflows, real image and fingerprint quality, real search scenarios, real users, and real downstream decisions that the system must support. Include the Vendor, IT, examiners, booking, Detentions, Records, investigations, trainers, support resources, and agency leadership in reviewing early results.
Watch out for: Treating poor performance as inevitable because the data is difficult, the fingerprints are low quality, the images are imperfect, or the workflow is messy. That may be exactly where biometric expertise matters most. Search quality, image processing, filtering, thresholds, matcher behavior, capture settings, workflow design, training, and support response can all affect real-world results. A system may be technically working and still not be tuned for the agency’s actual operating environment. The goal of OAT is not to blame the agency or the Vendor; it is to find hidden accuracy, workflow, and performance issues early enough to correct them before the workaround becomes normal.
Related BCP Tech Briefs
"The goal is not to make every biometric decision perfect.
The goal is to make sure leadership understands the mission risk it is accepting."
Better biometric outcomes start when competing risks become one mission decision.