Last reviewed: September 19, 2026
Automated license plate readers are designed to identify vehicles quickly.
That can be useful.
A camera may read a plate, compare it with information associated with a stolen vehicle, stolen plate, wanted person, missing person or another law-enforcement alert and notify officers within seconds.
But automated systems can make mistakes.
Databases can contain outdated information.
Plates can be moved between vehicles.
A camera can misread a character.
And even a perfectly accurate plate read does not necessarily tell an officer who is driving.
That is why an automated alert should begin a process of verification.
Not end one.
What is an ALPR hit?
A hit generally means the system believes a vehicle observation matches information it has been configured to look for.
For example:
A camera reads:
ABC1234
and a database indicates:
ABC1234 - stolen vehicle
The system generates an alert.
That can be an important investigative lead.
But several separate things still need to be true:
Did the camera read the plate correctly?
Does the alert refer to the same vehicle?
Is the underlying database information still current?
Is the plate still attached to the vehicle described in the record?
What does the alert actually say?
Those questions matter before an automated match becomes a real-world police encounter.
Michigan requires confirmation for LEIN ALPR-file hits.
Michigan State Police makes an Automated License Plate Reader file available to authorized law-enforcement agencies using the Law Enforcement Information Network, or LEIN.
The file combines eligible Michigan LEIN information with records supplied through the FBI’s National Crime Information Center.
MSP states:
All extract hits must be confirmed through LEIN and/or NCIC in accordance with hit-confirmation policy.
Read Michigan State Police’s current LEIN access information ↗
That is an important rule.
The computer match is not supposed to stand alone.
What does “confirm the hit” mean?
At the simplest level:
check the underlying criminal-justice information before treating the alert as current and accurate.
An ALPR camera may be comparing its observation against data that changes over time.
A stolen vehicle may have been recovered.
A warrant may have changed.
A plate may no longer be associated with the circumstances that originally generated the record.
Hit confirmation helps prevent officers from acting on information that is no longer valid.
But there is another layer too:
the camera observation itself should be checked.
A database can be right while the camera is wrong.
Imagine the system reads:
ABC1234
The database correctly says:
ABC1234 is stolen.
But the vehicle actually passing the camera has plate:
ABC1284.
The database did nothing wrong.
The camera misread one character.
If nobody checks the image or physical plate, an innocent vehicle can become the subject of a stolen-car alert.
That is not hypothetical.
Sherwood, Arkansas — February 2026
- Source type: Independent reporting and incident compilation.
- Last verified: September 19, 2026.
- What the system reportedly did: A Flock camera misread the final character of a plate and generated a stolen-vehicle alert involving the wrong SUV.
- Human verification: The mismatch was not resolved before officers conducted a high-risk stop.
- Outcome: An innocent couple was ordered from the vehicle at gunpoint while their infant remained inside; they were released after the mismatch was discovered.
- What this demonstrates: A plate read is an investigative lead. Failure to verify the image, physical plate, vehicle and originating record can expose an innocent person to serious consequences.
Institute for Justice ALPR incident database and linked original reporting ↗
That does not mean:
Flock cameras are usually wrong.
It means:
when the system is wrong, the consequences can become serious very quickly.
Read the documented-harm page →
This problem existed before Flock.
A 2014 federal appellate case, Green v. City and County of San Francisco, involved an older ALPR system that mistakenly identified Denise Green’s Lexus as a stolen vehicle.
Officers conducted a high-risk stop before police determined that the ALPR had misread her plate.
The opinion described training that treated an ALPR hit as something to verify rather than automatic proof.
The case illustrates a problem that is technological rather than vendor-specific:
automated plate recognition can generate false matches, and verification matters.
The plate can match while the vehicle does not.
Imagine an ALPR-generated plate is associated with a stolen pickup truck while the observed vehicle is a sedan.
That mismatch should matter.
The question should not be only:
Did the computer return a stolen plate?
It should also be:
Does the vehicle in front of us actually match the underlying record?
Technology can produce the first clue.
Human judgment still matters.
Plate image + vehicle description + database confirmation is stronger than any one alone.
A careful verification process can compare:
The plate characters
Does the physical plate match what the ALPR read?
The vehicle
Does the make, model, type or color correspond with the wanted record?
The underlying database
Is the record current and confirmed?
The circumstances
Is there additional information supporting or contradicting the alert?
The exact police procedure depends on applicable law and department policy.
Conceptually, though:
more independent confirmation reduces the chance that one bad data point becomes a dangerous mistake.
Officers face risk too.
Imagine receiving an alert saying:
STOLEN VEHICLE
An officer may reasonably prepare for the possibility that someone in the vehicle stole it, is fleeing or poses another threat.
The officer’s stress level rises.
Additional officers may respond.
The entire encounter can begin from a much more dangerous posture.
If the alert was wrong:
the technology has placed both the innocent driver and the responding officers into an unnecessarily hazardous situation.
Verification protects both.
A wrong plate is not the only way an alert can mislead.
Several things can go wrong.
Character recognition error
The camera reads one character as another.
Similar plate
A different vehicle has a plate only one character away from the wanted plate.
Stale database information
The plate or vehicle status changed but the alert information has not caught up.
Plate transferred or stolen
The plate itself may be attached to a different vehicle.
Vehicle description mismatch
The plate record identifies one type of vehicle while the observed vehicle is obviously another.
Human entry error
Someone may enter a plate incorrectly when creating a local alert.
Context error
The plate is correct, but the person or circumstances investigators expected are not present.
Different failures require different safeguards.
A correct ALPR read does not identify the driver.
Suppose the system correctly records:
Michigan ABC1234 passed this camera at 6:17 PM.
That establishes an observation involving the vehicle.
It does not automatically establish who was driving, who was riding inside, why the vehicle was there or whether the registered owner was present at all.
Cars are shared, borrowed, rented, loaned, driven by family members and occasionally stolen.
Vehicle data is not automatically person data with perfect certainty.
Association is not guilt either.
Newer surveillance analysis can potentially identify vehicles that appear together, travel similar routes or occur around the same locations.
That can generate useful investigative leads.
But two vehicles might repeatedly appear near one another because their owners work at the same factory, live in the same apartment building, drop children at the same school or use the same commute.
Patterns require interpretation.
A relationship suggested by data is not automatically a criminal relationship.
Human verification is not an admission that the technology is bad.
All kinds of useful systems require verification.
Technology assists human decision-making precisely because humans can evaluate information in context.
Saying:
verify the ALPR hit
is not anti-technology.
It is good operational practice.
A false alert can escalate faster than the correction.
The technology operates quickly.
Camera sees plate.
Database returns match.
Alert appears.
Officer responds.
But correcting the mistake may require reading the physical plate, checking the image, calling dispatch, confirming the database, comparing the vehicle or contacting another agency.
That means:
the alert can travel faster than the correction.
Good procedures need to account for that.
Local policies should explain verification.
When researching a department’s ALPR program, look for language addressing:
hit confirmation
visual verification
database confirmation
vehicle-description comparison
and:
action based on alerts.
A strong policy should make clear that an automated hit is not treated as infallible.
If the policy does not answer that:
ask.
Read: How to Read an ALPR Policy →
Ask what happens before a high-risk stop.
This is a reasonable oversight question.
Residents and elected officials can ask:
What steps are officers trained to take between receiving an ALPR stolen-vehicle alert and conducting a felony or high-risk stop?
Possible questions include:
Does dispatch confirm the underlying record?
Does the officer compare the camera image with the plate?
Is the actual plate visually confirmed?
Is vehicle make, model or color compared?
Are discrepancies communicated before the stop?
The purpose is not to micromanage police tactics publicly.
The purpose is to understand whether automated errors are being accounted for before consequences escalate.
Training matters.
Departments should ensure officers understand:
how ALPR errors occur;
what a hit means;
what a hit does not mean;
how to verify database information;
how to recognize a vehicle mismatch;
and how the technology fits into the department’s broader legal and tactical procedures.
The camera should not become an authority figure.
Local hot-list entries deserve oversight too.
Not every alert necessarily originates with a statewide or national database.
Agencies may have processes for entering plates connected with active investigations or other authorized purposes.
That creates additional questions:
Who may create a local alert?
What justification is required?
Does a supervisor approve it?
How long does it remain active?
Who removes it when it is no longer needed?
Are local entries audited?
An incorrectly entered plate can create the same real-world consequences as a camera misread.
Alert expiration matters.
Imagine police are looking for a vehicle today.
The investigation changes next week.
Does the alert disappear automatically?
Does somebody have to remove it?
How does the department ensure old investigative alerts do not remain active indefinitely?
This is an ordinary data-quality question with potentially serious consequences.
Sharing can make correction harder.
Suppose Agency A enters information.
Agency B receives the resulting alert.
Now the officer responding to the vehicle may not be the person who created the record, understands the original case or knows that the information recently changed.
That makes clear sourcing, current records, hit confirmation and communication between agencies especially important.
Track errors, not only successes.
Departments often have strong incentives to record stolen cars recovered, arrests, successful alerts and cases helped.
They should also understand false reads, incorrect alerts, stale records, wrong-vehicle incidents and searches that created operational problems.
A genuine evaluation of technology needs both sides.
Read: Do ALPRs Work? What the Evidence Actually Says →
Error rates need context.
A vendor might report extremely high plate-reading accuracy.
That is useful information.
But imagine a system processing millions of observations.
Even a very small error percentage can produce real mistakes at scale.
That does not mean every error produces a police stop.
Most will not.
It means:
“99-point-something percent accurate” is not the same statement as “errors never matter.”
Scale matters.
Do not confuse system error with officer misconduct.
This distinction is important.
An officer may receive incorrect information and act according to their understanding of policy.
The root problem may be camera error, bad database information, poor training, unclear policy or inadequate verification.
That is different from deliberately misusing the system.
Our documented-harm work distinguishes technical error from policy violation, formal accusation and confirmed misconduct.
Different failures require different responses.
And do not excuse avoidable mistakes as “the computer’s fault.”
Technology does not make decisions in a vacuum.
Governments choose what systems to buy, what databases to connect, what alerts to create, how officers are trained, what verification is required and how failures are reviewed.
“Computer error” can describe what triggered an event.
It does not end the accountability discussion.
What should residents ask locally?
If your municipality uses ALPR, useful questions include:
Are ALPR hits independently confirmed before enforcement action?
What database-confirmation procedures apply?
Are officers trained to visually confirm plates?
Are vehicle descriptions checked for obvious mismatches?
How are locally entered hot-list vehicles approved?
How quickly are obsolete alerts removed?
Are false alerts documented?
Has the department experienced an incorrect ALPR stop?
Are errors reviewed for training or policy changes?
Does the department track the number of false or unverified alerts?
Those answers tell us something about how seriously the agency treats the technology’s limitations.
What should elected officials ask?
A council member or trustee evaluating renewal can ask:
Have any ALPR alerts involving our department been incorrect?
How many?
What caused them?
Did any result in a vehicle stop?
What verification does policy require?
Has that procedure changed after any incidents?
Does the department track false positives or misreads?
What does the vendor provide when an error occurs?
Those are ordinary oversight questions.
They do not require assuming the technology is generally unreliable.
What should drivers understand?
If you are stopped because of an ALPR alert:
do not try to litigate the database on the roadside.
Keep the encounter calm and follow lawful instructions.
If you believe the stop resulted from an error, document what happened afterward when it is safe to do so.
Depending on the seriousness of the incident, you may want to request relevant records, preserve available video, contact the department or seek qualified legal advice.
This page is not personal legal advice.
The right lesson is not “never trust a computer.”
Technology can be remarkably accurate and useful.
The better lesson is:
do not give automated information more certainty than the information deserves.
ALPR can tell investigators:
This system believes it saw a vehicle matching this record.
Then people should verify.
That small distinction can prevent a useful technology from becoming a dangerous assumption.
And this does not resolve the larger surveillance question.
Imagine every ALPR hit were verified perfectly.
Imagine false reads became extraordinarily rare.
Imagine every officer followed policy.
That would reduce an important category of harm.
We would welcome it.
Our larger objection would remain.
The system would still routinely record ordinary vehicles, attach time and location, store observations, make them searchable and create movement histories involving people who are not suspected of anything.
Accuracy is important.
Accuracy does not make mass tracking acceptable.
Our position
If an ALPR system exists:
hits should be verified;
officers should be well trained;
alerts should be current;
errors should be documented;
audit trails should be meaningful;
and false matches should be taken seriously.
Those safeguards protect drivers, officers, investigations and public trust.
But the safest false ALPR hit is still:
the one generated by a mass-tracking system the community chose not to operate.