jonathanwestmoreland.com

Tag: ALPR

  • Questions Bend Residents Can Ask Council

    Questions Bend Residents Can Ask Council

    Part 10 of the Bend Surveillance Oversight series.

    You do not need to be a surveillance expert to ask reasonable questions about public technology.

    If a city uses tools that collect, store, search, analyze, or share public data, residents have a right to understand how those tools are governed.

    That applies to body cameras, fleet cameras, automated license plate readers, drones, traffic enforcement cameras, digital evidence systems, AI tools, real-time information platforms, and any other technology that affects public privacy, public records, or public accountability.

    The goal is not to attack City staff or police.

    The goal is simple:

    Public safety technology should answer to public rules.

    1. What systems exist?

    • What surveillance technologies does Bend Police currently use?
    • What systems are being considered for future use?
    • Which systems are active now?
    • Which systems are approved but not yet active?
    • Which systems are optional add-ons or future capabilities?
    • Which vendors are involved?
    • Are there third-party vendors, subcontractors, cloud providers, or software modules the public should know about?
    • Is there a plain-language public inventory residents can read?

    2. What data is collected?

    • Does the system collect video?
    • Does it collect audio?
    • Does it collect license plate data?
    • Does it collect location data?
    • Does it collect metadata?
    • Does it collect biometric data?
    • Does it analyze faces, vehicles, objects, movement, behavior, or patterns?
    • Is any data analyzed by AI or automated tools?
    • Are any features disabled but technically available?

    3. Where does the data go?

    • Where is the data stored?
    • Is it stored on City systems or vendor-controlled cloud systems?
    • Does the City own and control the data?
    • Can vendors access the data?
    • Can vendors process, export, or analyze the data?
    • Are cloud providers or subprocessors involved?
    • Can data be stored outside Oregon?
    • Can data be stored outside the United States?
    • What happens to the data when the contract ends?

    4. How long is the data kept?

    • What is the default retention period for each system?
    • Is non-evidence data automatically deleted?
    • Is non-hit ALPR data deleted quickly?
    • Who can extend retention?
    • What justification is required to extend retention?
    • Are retention changes logged?
    • Are retention settings audited?
    • Does the City publish retention rules publicly?

    5. Who can search the data?

    • Who has access to each system?
    • Are users limited by role?
    • Can every officer search the system?
    • Can supervisors search it?
    • Can dispatch search it?
    • Can prosecutors access it directly?
    • Can vendors access it?
    • Can outside agencies access it?
    • Are searches required to include a case number or incident number?
    • Are searches required to include a purpose?
    • Are all searches logged?
    • Are search logs audited?
    • What happens if someone searches improperly?

    6. Can outside agencies access it?

    • Can federal agencies access Bend surveillance data?
    • Can out-of-state agencies access it?
    • Can regional law enforcement systems access it?
    • Can fusion centers access it?
    • Can private companies access it?
    • Can vendors respond directly to outside requests?
    • Does the City require case-specific legal process before sharing?
    • Does the City require written authorization before sharing?
    • Does the City publish annual data-sharing statistics?
    • Can the City deny outside requests?
    • Can the City audit outside access?

    7. Can vendors activate new features?

    • Can vendors activate new AI features?
    • Can vendors activate analytics features?
    • Can vendors activate biometric tools?
    • Can vendors activate ALPR features?
    • Can vendors activate real-time monitoring?
    • Can vendors change retention settings?
    • Can vendors change data-sharing settings?
    • Does Council approval happen before new capabilities are enabled?
    • Does the public receive notice before major feature changes?
    • Are disabled features independently verified?

    8. What about facial recognition and biometrics?

    • Does Bend use facial recognition?
    • Does Bend plan to use facial recognition?
    • Do any current systems have facial recognition capability?
    • Are biometric features disabled?
    • Who verifies that they are disabled?
    • Would Council approval be required before biometric features are activated?
    • Would the public receive notice?
    • Would there be legal review and technical review first?

    A simple local rule would be:

    No facial recognition or biometric identification without explicit public approval.

    9. What about AI police reports?

    • Does Bend use AI-assisted police reports?
    • Does Bend plan to use AI-assisted police reports?
    • If AI is used, are original AI drafts preserved?
    • Are officer edits logged?
    • Does the final report disclose AI assistance?
    • Are prosecutors notified when AI was used?
    • Can defense attorneys obtain AI drafting records through normal discovery?
    • Can the vendor use Bend data to train AI models?
    • Has the system been independently audited?
    • Are serious incidents excluded or subject to extra safeguards?

    A simple local rule would be:

    No AI-generated police report without an audit trail.

    10. What oversight exists?

    • Has the City conducted an independent technical audit?
    • Does each system have a public use policy?
    • Does each system have a public retention policy?
    • Does each system have a public sharing policy?
    • Are complaints tracked?
    • Are violations reported publicly in aggregate?
    • Does Council review surveillance systems before renewal?
    • Does the City publish annual transparency reports?
    • Are total annual costs publicly reported?
    • Are future renewals and expansions clearly identified?

    11. What safeguards will Bend adopt?

    • Will Bend adopt a surveillance technology ordinance?
    • Will Bend require Council approval before acquisition or expansion?
    • Will Bend publish a public inventory of all surveillance technologies?
    • Will Bend require public use policies before deployment?
    • Will Bend set short retention limits?
    • Will Bend require logged searches with case numbers?
    • Will Bend restrict federal and third-party sharing?
    • Will Bend prohibit facial recognition without explicit public approval?
    • Will Bend require independent technical audits?
    • Will Bend require annual public transparency reports?
    • Will Bend prohibit vendors from activating new capabilities without City approval?
    • Will Bend require public review before contract renewal?

    A short version residents can send

    Residents who want to keep it simple can ask Council this:

    Before Bend expands police surveillance technology, will the City publish a plain-language inventory of all systems, identify what data each system collects, explain where the data is stored, disclose retention periods, require logged searches with case numbers, restrict federal and third-party sharing, prohibit facial recognition without explicit public approval, and require annual public transparency reports?

    These are not anti-police questions.

    They are public governance questions.

    If a technology is powerful enough to collect, search, store, analyze, or share public data, it is powerful enough to deserve public rules.

    Bend residents deserve clear answers before police surveillance systems expand.

    Further reading

    Series links

  • What Reasonable Safeguards Would Look Like in Bend

    What Reasonable Safeguards Would Look Like in Bend

    Part 9 of the Bend Surveillance Oversight series.

    This does not have to be a yes-or-no fight over police technology.

    Bend can support legitimate public safety tools while still requiring strong public oversight.

    The real question is not whether technology should ever be used.

    The real question is whether powerful systems are governed by clear public rules before they expand.

    Body cameras, fleet cameras, ALPRs, drones, traffic enforcement cameras, digital evidence systems, AI tools, and real-time information platforms all raise different questions.

    But they also share a common issue:

    They collect, store, search, analyze, or share public data.

    That means Bend should have a citywide surveillance technology policy.

    Not a vague promise.

    Not vendor assurances.

    Not scattered contract language.

    Not internal rules that residents cannot easily find.

    A clear public framework.

    1. Public inventory of surveillance technologies

    Bend should publish a plain-language inventory of all police surveillance technologies.

    That inventory should identify:

    • the technology name,
    • the vendor,
    • the department using it,
    • the purpose of the system,
    • what data it collects,
    • where the data is stored,
    • how long the data is retained,
    • who can access it,
    • whether outside agencies can access it,
    • whether vendors or subcontractors can access it, and
    • whether any AI, biometric, analytics, or automated decision features are enabled or available.

    Residents should not need to search scattered agendas, contracts, staff reports, and vendor documents to understand what systems exist.

    2. Council approval before acquisition or expansion

    Bend should require Council approval before any department acquires, renews, expands, or materially changes surveillance technology.

    That should include new tools, new vendors, major software modules, AI features, biometric capabilities, data-sharing expansions, and contract amendments that materially change what a system can do.

    Public approval should happen before deployment, not after the system is already operating.

    3. Public use policy before deployment

    Every surveillance technology should have a public use policy before it is deployed.

    That policy should explain:

    • the approved purpose,
    • allowed uses,
    • prohibited uses,
    • data collection rules,
    • retention rules,
    • access rules,
    • sharing rules,
    • audit procedures,
    • disciplinary consequences for misuse, and
    • how residents can find annual reports.

    The public should be able to read the rules before the technology is used.

    4. Short retention for non-evidence data

    Data retention should be limited.

    For non-evidence data, the default should be deletion after a short period unless the data is tied to a specific, documented case.

    For ALPR data, I would support a default rule like this:

    Non-hit ALPR data should automatically delete within 72 hours unless it is tied to a documented case, warrant, stolen vehicle, active investigation, or legally valid evidentiary need.

    Short retention allows legitimate use while reducing the risk that ordinary residents’ movements become long-term searchable records.

    5. Logged searches with case numbers

    If a system can be searched, every search should be logged.

    The log should identify:

    • who searched,
    • when they searched,
    • what they searched,
    • why they searched,
    • the case number or incident number,
    • whether the search produced a result, and
    • whether the result was shared.

    Search logs protect the public from misuse.

    They also protect officers who use the system properly.

    6. Limits on federal, out-of-state, private, and vendor access

    Local surveillance data should not become outside-agency data by default.

    Bend should limit access by federal agencies, out-of-state agencies, private companies, vendors, subcontractors, fusion centers, and other third parties.

    Access should require a documented purpose, legal authority, written authorization, and an auditable record.

    Broad sharing, informal access, and bulk access should be prohibited unless explicitly approved through a public process and consistent with law.

    7. No facial recognition or biometric identification without explicit approval

    Bend should prohibit facial recognition, biometric identification, biometric analytics, or similar identity-matching tools unless Council explicitly approves them after public notice, public debate, legal review, and technical assessment.

    If a system is technically capable of biometric analysis but the City says the feature is disabled, that should be independently verified.

    Disabled features should not become active through a quiet software update or vendor configuration change.

    8. AI report-writing rules

    If Bend ever uses AI to help draft police reports, the City should require strict auditability.

    The basic rule is simple:

    No AI-generated police report without an audit trail.

    That means preserving original AI drafts, officer edits, source transcripts, timestamps, final reports, supervisor edits, and disclosure that AI was used.

    Prosecutors and defense attorneys should be able to obtain relevant records through normal legal processes.

    9. Independent technical audits

    Bend should not rely only on vendor assurances.

    The City should require independent technical audits of surveillance systems.

    Audits should verify:

    • enabled features,
    • disabled features,
    • retention settings,
    • sharing settings,
    • access controls,
    • security controls,
    • vendor access,
    • subprocessor access, and
    • compliance with City policy.

    Trust is strongest when systems can be independently checked.

    10. Annual public transparency reports

    Bend should publish annual surveillance transparency reports.

    Those reports should include:

    • what systems were used,
    • what new systems were acquired,
    • how many searches occurred,
    • how many outside requests were received,
    • how many requests were approved or denied,
    • how many audits were performed,
    • whether misuse was found,
    • whether any new features were activated,
    • whether policies changed, and
    • what the total annual costs were.

    Transparency reports do not need to reveal sensitive case details.

    They should provide enough aggregate information for residents and elected officials to know whether the rules are working.

    11. Contract terms that match public policy

    Contracts should not undermine policy.

    If Bend adopts public rules, vendor contracts should match those rules.

    Contracts should prohibit vendors from changing settings, enabling features, expanding sharing, using data for product development, or using local public safety data for AI training unless the City explicitly approves it through the required public process.

    Good policy should be backed by enforceable contract language.

    12. Public review before renewal

    Surveillance technology should not renew automatically without public review.

    Before renewal, the City should publish a report explaining how the system was used, whether it met its stated purpose, what it cost, whether misuse occurred, whether audits were completed, and whether stronger safeguards are needed.

    Renewal should be a public decision, not an automatic default.

    The basic framework

    A reasonable Bend surveillance policy could be summarized like this:

    • Tell the public what systems exist.
    • Require approval before expansion.
    • Limit retention.
    • Log searches.
    • Restrict sharing.
    • Control vendor access.
    • Ban biometric use without explicit approval.
    • Audit AI tools.
    • Verify systems independently.
    • Report to the public every year.

    That is not anti-police.

    That is responsible governance.

    Powerful public safety tools should answer to public rules.

    Further reading

    Series links

  • Other Cities Are Already Asking Better Questions

    Other Cities Are Already Asking Better Questions

    Part 8 of the Bend Surveillance Oversight series.

    Bend does not need to invent police surveillance oversight from scratch.

    Other cities are already asking the same basic questions:

    • Who approves surveillance technology before it is used?
    • What data is collected?
    • How long is it kept?
    • Who can search it?
    • Can outside agencies access it?
    • Can vendors change settings or activate new features?
    • Does the public receive annual reports?
    • Can elected officials review the system before it expands?

    That is the important lesson.

    The issue is not whether every city has reached the same conclusion.

    They have not.

    The issue is that communities across the country are realizing that police technology should not expand faster than public oversight.

    Austin: surveillance technology should require public rules

    Austin offers one useful model.

    In February 2026, the Austin City Council passed a resolution called the Transparent and Responsible Use of Surveillance Technology Act, or TRUST Act.

    The resolution directed the City Manager to return with an ordinance regulating the adoption, acquisition, deployment, use, and review of surveillance technology by city departments.

    That matters because it shifts the question from one contract at a time to a broader public framework.

    Bend could take the same approach.

    The public question should not only be whether a single contract sounds reasonable.

    The broader question should be what rules apply before surveillance technology is acquired, expanded, renewed, or materially changed.

    Mountain View: vendor assurances were not enough

    Mountain View, California offers another useful lesson.

    In January 2026, the City publicly stated that it had discovered unauthorized queries and potential access to Mountain View ALPR data.

    The City said Police Department staff had met with Flock Safety leadership about “the security and control of our data,” and said it was “upset and disappointed with how our data was accessed.”

    That example matters because it shows why vendor assurances are not enough.

    The lesson for Bend is simple:

    Do not wait for a data-sharing problem before creating data-sharing rules.

    Pima County: cost and AI concerns can cross political lines

    Pima County, Arizona offers another example.

    Reporting in early 2026 described the Pima County Board of Supervisors rejecting a proposed $45 million contract expansion involving Axon technology and AI tools.

    Reported concerns included cost, AI expansion, and whether the investment made sense for the Sheriff’s Department.

    That example matters because surveillance oversight is not only a privacy issue.

    It is also a budget issue.

    Public safety dollars are limited.

    Every dollar spent on bundled technology, AI tools, cloud subscriptions, hardware refreshes, and add-on features is a dollar not spent somewhere else.

    That does not mean technology is never worth funding.

    It means elected officials should ask hard questions before long-term commitments become automatic.

    Ferndale: public pressure can lead to stronger oversight

    Ferndale, Michigan offers another useful example based on reporting about local ALPR oversight discussions.

    Reporting described residents raising concerns about license plate reader expansion and city officials discussing stronger policies.

    That is important because public oversight often improves when residents ask specific, grounded questions.

    Community engagement does not have to stop technology.

    It can improve the rules that govern technology.

    The pattern is bigger than one vendor

    This is not only about Axon.

    It is not only about Flock.

    It is not only about ALPRs.

    It is not only about body cameras.

    It is not only about AI.

    The larger issue is how cities govern powerful surveillance systems once cameras, cloud storage, software subscriptions, data-sharing, analytics, and vendor platforms become part of public safety operations.

    A city can support public safety and still insist on public oversight.

    Those goals are not opposites.

    What Bend can learn

    Bend can learn at least five things from other cities.

    1. Oversight should happen before deployment or expansion, not after controversy.
    2. Citywide rules are better than one-off contract debates.
    3. Data-sharing limits should be explicit and enforceable.
    4. Vendors should not be the only source of truth about how systems work.
    5. Annual public reporting builds trust without exposing sensitive case details.

    These examples do not prove that Bend has the same problems.

    They show why Bend should adopt safeguards before problems occur.

    Bend can ask better questions now

    Police technology can be useful.

    But useful tools still need rules.

    If other cities are asking stronger questions about surveillance technology, Bend can too.

    The question is not whether Bend should copy another city word for word.

    The question is whether Bend should create its own public framework before future expansions become harder to unwind.

    Better questions today can prevent harder problems tomorrow.

    Further reading

    Series links

  • Why Federal and Third-Party Sharing Matters

    Why Federal and Third-Party Sharing Matters

    Part 7 of the Bend Surveillance Oversight series.

    In the last post, I wrote about why ALPR scans are location records.

    A license plate reader does not just capture a plate number.

    It creates a record that a specific vehicle was seen at a specific place at a specific time.

    But there is a second question that matters just as much:

    Once a city collects surveillance data, does that data stay local?

    That question applies to ALPRs, body cameras, fleet cameras, drone video, real-time information platforms, traffic cameras, evidence systems, and other police technology.

    The concern is not only what Bend collects.

    The concern is who else can access it.

    Local data can become outside-agency data

    A resident may feel differently about local police using a tool for a specific local purpose than they do about that same data becoming available to state agencies, federal agencies, out-of-state agencies, fusion centers, private vendors, or other third parties.

    Public consent for one local use should not be treated as consent for every future use.

    That is why data-sharing rules should be explicit before technology expands.

    Local data should not become outside-agency data by default.

    The policy should be explicit

    Data-sharing rules should not be vague.

    A policy that says information may be shared “for law enforcement purposes” may sound reasonable, but it can be extremely broad.

    A stronger policy should say exactly:

    • who may access the data,
    • for what purpose,
    • under what legal authority,
    • with whose approval,
    • with what documentation,
    • for how long,
    • whether access is logged,
    • whether the public will receive aggregate reporting, and
    • whether the request can be denied.

    If the policy does not clearly prohibit broad sharing, residents cannot know where local surveillance data may eventually go.

    That uncertainty is the problem.

    Federal access requires special caution

    Federal access deserves special attention because federal priorities can change quickly.

    Local residents may support local public safety uses while objecting to unrelated federal uses, especially if those uses involve immigration enforcement, political activity, protests, reproductive health travel, religious activity, or other sensitive areas.

    A strong policy would say:

    Bend surveillance data may not be shared with federal agencies unless there is case-specific legal process, written City authorization, a documented local purpose, and an auditable record.

    That rule would not prevent lawful cooperation in a serious case.

    It would prevent broad, informal, or routine access.

    Vendor access is also third-party access

    Third-party sharing is not only about government agencies.

    Vendors are third parties too.

    If a private company hosts police data, maintains the software, provides analytics, troubleshoots systems, stores video, processes license plate reads, or manages user access, that company may have some level of technical access to the system.

    That access should be limited, logged, and auditable.

    Vendor access should never be a black box.

    Contracts should clearly define when a vendor can access data, what the vendor can do with it, whether subcontractors are involved, whether data can be used for product development or AI training, and how the City verifies compliance.

    Outside sharing can create long-term consequences

    Once data leaves a local system, it may be harder to control.

    It may be copied, retained, searched again, combined with other databases, or used for purposes residents never debated locally.

    That is why sharing limits need to be set before sharing occurs.

    The point is not to block legitimate, case-specific cooperation.

    The point is to prevent broad access, informal access, bulk sharing, or secondary uses that bypass local democratic oversight.

    What a stronger local rule could require

    A stronger Bend policy would require:

    • case-specific legal process for outside-agency access,
    • written City authorization before sharing,
    • a documented purpose for every request,
    • a case number or incident number when applicable,
    • logs showing what was shared and with whom,
    • limits on vendor access and subcontractor access,
    • prohibitions on bulk or informal sharing,
    • clear retention limits after data is shared, and
    • annual public reporting in aggregate form.

    These safeguards would not prevent legitimate public safety work.

    They would make sure powerful data-sharing systems answer to public rules.

    The basic principle

    Local surveillance data should not become outside-agency data by default.

    If Bend collects police technology data, the City should clearly define who can access it, when it can be shared, how sharing is approved, how access is logged, and how the public can verify that the rules are being followed.

    The solution is not complicated:

    No broad sharing. No informal access. No vendor black boxes. No federal access without case-specific process. Public reporting every year.

    That is how local control becomes real.

    Further reading

    Series links

  • ALPRs: License Plate Scans Are Location Records

    ALPRs: License Plate Scans Are Location Records

    Part 6 of the Bend Surveillance Oversight series.

    An automated license plate reader does not just capture a plate number.

    It creates a time-and-place record.

    And when many scans are collected over time, those records can reveal patterns about where a vehicle has been, when it was there, and how often it appeared in certain places.

    That is why ALPR data should be treated as location data.

    It is not “just a plate.”

    It is a record of movement.

    What an ALPR scan actually records

    An ALPR system typically captures:

    • the license plate number,
    • the date and time of the scan,
    • the location of the camera,
    • an image of the plate or vehicle, and sometimes
    • additional metadata about the scan.

    One scan by itself may not say much.

    But multiple scans over time can create a much richer picture.

    If a vehicle is scanned near a home, workplace, school, clinic, place of worship, political event, protest, or support meeting, the scans may reveal sensitive patterns about a person’s life.

    That is why ALPR data deserves careful limits.

    Patterns matter more than single scans

    The privacy issue is not only the plate number.

    The privacy issue is the pattern.

    A series of scans can show where a vehicle travels, how often it visits certain places, what route it takes, when it leaves, when it returns, and whether those movements change over time.

    That is a form of location tracking.

    Even if each individual scan appears routine, the system as a whole can become highly revealing.

    That is why retention periods, search rules, and sharing rules matter so much.

    This post does not claim Bend currently uses fixed ALPR technology

    This post does not claim that Bend currently uses fixed automated license plate reader technology.

    The point is broader: if Bend adopts fixed ALPRs in the future, or if related systems create similar location records, the City should have clear rules in place before deployment.

    Oversight should come first, not later.

    Short retention should be the default

    If ALPR data is retained for long periods, it becomes easier to reconstruct a person’s travel history.

    The longer the data is kept, the more it can be searched, shared, or misused later.

    A reasonable rule would be:

    Delete ALPR scans quickly unless they are tied to a legitimate, documented case.

    I would support a default retention period as short as 72 hours unless the scan is associated with a specific investigative need such as a stolen vehicle, warrant hit, active case, or clearly documented law enforcement purpose.

    That kind of rule allows legitimate use while reducing unnecessary long-term accumulation.

    Every search should be logged

    If ALPR data can be searched, every search should leave a record.

    That record should show:

    • who conducted the search,
    • when it was conducted,
    • what plate or data was searched,
    • the case number or incident number,
    • the reason for the search, and
    • whether the results were shared.

    Without logs, the public has to trust that the system is being used properly.

    With logs, the City can verify that the rules are being followed.

    Sharing should be limited and documented

    ALPR data should not flow freely to outside agencies, vendors, private companies, or federal systems without clear public rules.

    A strong policy would require:

    • a specific legal basis for sharing,
    • a documented case-related purpose,
    • written authorization,
    • an auditable record of what was shared and with whom, and
    • clear limits on bulk or informal access.

    The issue is not whether legitimate case-specific sharing can occur.

    The issue is whether local location data becomes broadly accessible by default.

    Public reports build trust

    If Bend ever uses ALPRs, the City should publish annual public reports showing:

    • how many cameras or systems were used,
    • how many scans were collected,
    • how long data was retained,
    • how many searches were conducted,
    • how many shares occurred,
    • how many outside-agency requests were received,
    • how many requests were granted or denied, and
    • whether any misuse or policy violations were found.

    These reports do not need to expose sensitive investigative details.

    They should provide enough information for residents and elected officials to understand how the system is working.

    The basic principle

    An ALPR scan is not just a plate number.

    It is a location record.

    And location records deserve strong safeguards.

    Short retention. Logged searches. Clear sharing limits. Public oversight.

    Those are not extreme demands.

    They are basic rules for a powerful system.

    Further reading

    Series links

  • What Police Technology Has Bend Already Considered or Purchased?

    What Police Technology Has Bend Already Considered or Purchased?

    Part 2 of the Bend Surveillance Oversight series.

    Before Bend residents can have a useful conversation about police surveillance oversight, we need to understand what technology the City has already approved, discussed, or bundled into larger contracts.

    This is not about assuming bad intent.

    It is about making the public record easier to understand.

    Over the past several years, Bend has moved from body-worn cameras into a broader police technology ecosystem involving vehicle cameras, cloud evidence storage, drone software, real-time information tools, third-party video playback, investigation software, and bundled Axon subscriptions.

    That is why this conversation should not be reduced to a simple question like, “Should police have cameras?”

    The better question is:

    What systems has Bend adopted, and what public rules govern the data those systems create?

    Body-worn cameras and Evidence.com

    In April 2021, Bend City Council considered a five-year agreement with Axon for body-worn cameras, associated hardware, analytical software, training, and digital evidence storage, with a contract amount not to exceed $1,038,996.

    The City’s issue summary said full implementation would mean every officer would be equipped with a body-worn camera during their shift, video recordings would be stored, and the Deschutes County District Attorney’s Office would have the ability to receive the information.

    That matters because body cameras are not only recording devices. They also create records that must be stored, accessed, shared, retained, and governed.

    Fleet cameras in police vehicles

    In July 2022, Bend City Council approved a five-year, $679,500 contract with Axon for fleet cameras in Bend Police vehicles.

    The City described the contract as covering purchase and installation of cameras, software, and video storage.

    This is important because fleet cameras can be more than dashboard video. Depending on the hardware, software, and enabled features, vehicle camera systems can interact with evidence storage, metadata, automated review tools, and potentially other software capabilities.

    That is exactly why public policy should focus on capabilities, retention, access, and auditing — not just the word “camera.”

    Fusus real-time information software

    In March 2023, Bend City Council considered a three-year agreement with Fusus Inc. for software and associated hardware to view public and community video sources for incident situational awareness and investigations, with a contract amount not to exceed $230,000.

    The City’s issue summary described Fusus as a real-time crime center platform designed to consolidate video and other information sources.

    It said Fusus could bring together public and private video systems, community tips, community text notifications, Computer Aided Dispatch, unmanned aircraft video, Live 911 information, body-worn cameras, in-car cameras, a community camera registry, a CJIS-compliant video evidence vault, and video live links for 911 callers.

    That is a much broader system than a single camera.

    It is a platform for gathering, viewing, and coordinating multiple information sources in one place.

    Axon Air and drone software

    In February 2024, Bend considered additional Axon Air software licenses for its drone program.

    The issue summary said Bend Police had been using Axon Air software since 2022 for drone support and remote viewing capabilities, and that the department wanted additional pilot and drone licenses.

    It also stated that Bend Police had been using Axon services since 2021 as a unified platform to better track deployment, usage, and results of police actions.

    That phrase — unified platform — is important.

    It shows the direction of travel: not isolated tools, but integration of multiple police technologies into one vendor ecosystem.

    2024 Axon bundled contract

    In October 2024, Bend City Council considered a five-year Axon Officer Safety Plan 10 Premium subscription.

    The meeting minutes state that Council authorized a five-year contract with Axon for Taser hardware, virtual reality hardware and software, digital video recorder playback support, and investigation support software, for a total amount not to exceed $2,555,786.51.

    The minutes also identify the new bundled products and services as Investigate Pro, Third-Party Video Playback, and Virtual Reality training.

    This is the clearest example of why residents need a public inventory.

    Once products are bundled together, it becomes harder for the public to understand which tools are active, which are planned, which are optional, and which could be expanded later.

    Automated traffic enforcement cameras

    Separate from the Axon materials, Bend has also moved forward with automated traffic enforcement.

    The City says the program uses cameras to detect red-light running and speeding at various intersections.

    This is a different type of camera program, but it belongs in the same public conversation because it raises the same basic governance questions:

    • What data is collected?
    • Who operates the system?
    • How long is the data retained?
    • Who can access it?
    • What rules prevent secondary use?

    Why this matters

    Looked at separately, each item may sound narrow:

    • A body camera contract.
    • A fleet camera contract.
    • A drone software license.
    • A real-time information platform.
    • A video playback tool.
    • An investigation software tool.
    • A traffic enforcement camera program.

    But viewed together, they show a larger pattern: Bend is building a police technology environment made of cameras, cloud storage, software subscriptions, vendor platforms, and integrated data systems.

    That does not mean the City should abandon useful tools.

    It does mean residents deserve a clear, public inventory.

    The first step toward meaningful oversight is simple:

    Tell residents what systems exist.

    Selected source documents

    Series links

  • This Is Not Just About Cameras

    This Is Not Just About Cameras

    Part 1 of the Bend Surveillance Oversight series.

    Most people hear “police cameras” and imagine a simple device: a body camera on an officer, a camera in a patrol car, or a license plate reader mounted near a road.

    Cameras are a tool of modern policing, but modern policing was never just about cameras.

    They are often part of a much larger technology ecosystem involving cloud storage, evidence management software, artificial intelligence tools, automated license plate readers, vehicle cameras, drones, real-time crime center platforms, third-party vendors, and future software features that may be added after the original purchase.

    That distinction matters.

    A camera records what happens in front of it. A connected surveillance system can collect data, store it, search it, analyze it, share it, and combine it with other systems. Once that happens, the public policy question changes.

    The question is no longer only:

    Should police have cameras?

    The better question is:

    What rules govern the data those cameras create?

    For example:

    • Where is the data stored?
    • How long is it kept?
    • Who can search it?
    • Are searches logged?
    • Can outside agencies access it?
    • Can vendors access it?
    • Can new AI or biometric features be activated later?
    • Does the City Council have to approve expansions?
    • Are residents told when capabilities change?

    These are not anti-police questions.

    They are basic public oversight questions.

    Body cameras, patrol vehicle cameras, and evidence systems can serve legitimate public safety and accountability purposes. But when those systems are connected to vendor-controlled cloud platforms, AI tools, automated license plate readers, and broader data-sharing networks, the public deserves clear rules before the technology expands.

    This is especially important because cities often start with one tool and later add more tools from the same vendor.

    A city may begin with body cameras, then add fleet cameras, then cloud evidence storage, then license plate readers, then drones, then AI report-writing tools, then real-time crime center software.

    Each step may be presented as a small upgrade.

    But together, those upgrades can create a powerful surveillance infrastructure.

    That is why the issue is not just the camera.

    It is the ecosystem.

    Bend residents should not have to dig through dense procurement packets, legal agreements, and technical appendices to understand what surveillance tools are being used or considered.

    The City should provide a plain-language public inventory of police technology systems, including hardware, software, cloud storage, AI tools, third-party vendors, data retention rules, data-sharing rules, audit procedures, and any future capabilities that can be activated through software.

    This does not require the City to abandon useful technology.

    It simply requires public oversight to keep pace with the technology being purchased.

    Before Bend expands police surveillance systems, residents should be able to answer a simple question:

    Are these tools governed by clear public rules, or are we relying mostly on vendor assurances and internal department policies?

    That is the conversation Bend should have now, before the system becomes larger, more expensive, and harder to change.

    Further reading

    Series links

  • ALPR Oversight Is a Democracy Issue

    Signals & Safeguards — A standalone civic-oversight post on license plate readers, public consent, federal access, and the safeguards local governments should require before surveillance networks become hard to unwind.

    ALPR oversight is becoming a democracy issue

    The strongest surveillance story this week is not one camera system by itself. It is the fight over who gets to approve, search, share, and shut down a network once it is already in place.

    Automatic license plate readers, often called ALPRs, are usually introduced as practical public-safety tools. Police agencies point to stolen-vehicle recovery, suspect identification, Amber Alerts, and serious investigations. Those uses can be real. But the democratic problem begins when a system that looks like a set of cameras turns into a searchable movement database shared across agencies, jurisdictions, vendors, and sometimes federal systems.

    That is why the key question is no longer simply, “Do these cameras help police?” The better question is: who controls the system once it exists?

    When public consent breaks down

    In Troy, New York, a dispute over Flock license plate readers escalated after residents objected to cameras installed without meaningful public input, the City Council voted to end the program, and the mayor declared a state of emergency to keep the cameras operating. The fight became larger than Flock: it became a dispute over emergency authority, public consent, and whether elected bodies can still control surveillance systems once public-safety claims are used to preserve them.

    That should concern any community considering ALPRs or similar systems. If ordinary approval channels can be bypassed, delayed, or overridden after cameras are installed, then the public debate happens too late. The technology gains institutional momentum before the rules are settled.

    The democracy issue: surveillance systems should not go live first and receive public rules later.

    Once a camera network is installed, agencies, vendors, and outside partners may develop expectations around continued access. That makes it politically and operationally harder for elected officials to narrow, pause, or end the system.

    The pattern is spreading

    The pattern is appearing elsewhere. In Cleveland and nearby communities, residents and advocates are challenging Flock deployments over privacy, immigration-enforcement access, and uncertainty about who can search the system. In Bend, The Source Weekly reported that federal immigration officials made 279 queries into Bend’s Flock Safety data in the first three weeks after the cameras went live, and Bend Police reportedly did not authorize those searches.

    That Bend example matters because it shows how quickly the debate can move from “Should we install cameras?” to “Who searched the data, why, under what authority, and what did they see?” A local system may be approved for local purposes, but the practical risk is that local vehicle-location data becomes useful to agencies far beyond the community that generated it.

    The federal layer changes the stakes

    The federal layer makes the issue sharper. Reporting from 404 Media says the FBI wants to buy nationwide access to license plate reader data. If local and private cameras can become part of a national movement-search network, then approving a few cameras is not only a local equipment decision. It is a decision about whether local vehicle-location data can become searchable far beyond the community that generated it.

    That does not mean every ALPR deployment is the same, or that every agency intends to misuse the system. It means the rules must be written for the system’s real capabilities, not only for its best-case sales pitch.

    Public safety and public oversight are not opposites

    The public-safety case should not be dismissed. ALPRs can help find stolen vehicles, locate suspects, and respond to serious threats. But that is exactly why governance has to come first. A system useful enough to solve crimes is also useful enough to misuse, over-share, or repurpose.

    Good oversight does not require pretending the technology has no value. It requires acknowledging that useful tools can still create serious risks when access is broad, retention is long, audit logs are weak, vendor permissions are unclear, or outside-agency sharing is treated as a default instead of an exception.

    Why it matters for Bend

    Why it matters for Bend: Bend has already seen how quickly the question can move from “Should we install cameras?” to “Who searched the data, why, and what did they see?” Bend and Redmond are also working through automated traffic-enforcement systems, which are not the same as ALPRs but raise overlapping questions about vendors, retention, access, audit logs, public notice, error correction, and repurposing.

    Traffic cameras, retail ALPRs, police ALPRs, and connected-vehicle data are not identical systems. But they all point toward the same local-governance challenge: ordinary movement is becoming easier to capture, store, search, and share. Communities need clear rules before those records become too convenient to give up.

    “The liberty of every man is at the mercy of every petty officer.”— James Otis, arguing against writs of assistance (1761)

    Safeguards local officials should require

    Before approving, renewing, expanding, or continuing an ALPR program, public officials should require written rules that answer the basic governance questions up front:

    • Purpose limits: define exactly what the system may and may not be used for.
    • Access limits: identify who can search the system and whether outside agencies can access it.
    • Federal-access rules: state whether federal or immigration-enforcement searches are allowed, blocked, or require a specific legal process.
    • Short retention: automatically delete plate data quickly unless it is tied to a documented investigation.
    • Search documentation: require a case number, purpose, user identity, and timestamp for every search.
    • Exportable audit logs: make logs available for independent review, public reporting, and investigation of misuse.
    • Vendor restrictions: define vendor access, support access, data use, training use, subcontractors, and breach obligations.
    • Public reporting: publish regular transparency reports showing searches, outside-agency access, hits, false positives, retention, and policy violations.
    • Democratic review: require council approval before expansion, new integrations, new sharing relationships, or emergency continuation.

    Bottom line: ALPR oversight is becoming a democracy issue because the most important decision is not only whether cameras exist. It is whether the public, through elected officials and enforceable rules, still controls how movement data is searched, shared, retained, audited, and shut down.