Author: Jonathan

  • AI Police Reports and the Audit Problem

    AI Police Reports and the Audit Problem

    Part 5 of the Bend Surveillance Oversight series.

    Police reports are not ordinary paperwork.

    They can shape criminal charges, court proceedings, plea negotiations, public records, insurance claims, disciplinary reviews, and a person’s ability to defend themselves.

    That is why AI-generated police reports deserve careful public oversight.

    The issue is not whether officers should use better tools.

    The issue is whether official police records remain accurate, reviewable, and auditable when artificial intelligence is involved.

    What AI police report tools do

    AI police report tools can use body-camera audio, transcripts, officer input, or other records to generate a draft narrative.

    That may sound helpful.

    Police officers spend a lot of time writing reports, and many departments are looking for tools that reduce paperwork.

    But a police report is not just a summary.

    It is an official law enforcement record.

    If AI helps write that record, the public should know:

    • what information the AI used,
    • what the AI produced,
    • what the officer changed,
    • whether the officer verified every factual statement,
    • whether the original AI draft was preserved,
    • whether errors can be reconstructed later, and
    • whether defense attorneys, prosecutors, judges, or oversight bodies can review the process.

    Without those safeguards, AI report-writing creates a serious audit problem.

    Why the original AI draft matters

    Imagine an AI tool creates a draft police report from body-camera audio.

    The officer reads it, edits it, and copies the final text into the official report system.

    Then the original AI draft disappears.

    Later, a defendant, attorney, judge, journalist, auditor, or oversight board wants to know whether a questionable sentence came from the officer, the transcript, or the AI system.

    If the original AI draft was not preserved, there may be no way to answer that question.

    That is the core problem.

    The concern is not only that AI can make mistakes.

    The concern is that AI mistakes may become embedded in official records without leaving a trace.

    What a basic audit trail should include

    A reasonable AI police report policy should require preservation of:

    • the original AI-generated draft,
    • the body-camera audio or transcript used to generate it,
    • the prompt or settings used,
    • timestamps,
    • the officer’s edits,
    • the final submitted report,
    • supervisor edits if any, and
    • a clear label showing that AI assisted in the drafting process.

    This should not be controversial.

    If AI saves time and improves accuracy, the audit trail should show that.

    If AI introduces errors, the audit trail should make those errors detectable.

    Either way, preserving the record protects the public, defendants, officers, prosecutors, and the City.

    Bend should set rules before using AI reports

    This post does not claim that Bend currently uses AI-assisted police report-writing.

    The point is that AI report-writing is already being marketed to law enforcement agencies, and cities should set rules before these tools become routine.

    Bend should not wait until after AI-generated police reports become common to decide how they should be governed.

    A strong local policy would say:

    1. No AI-generated police report may be submitted without officer review and certification.
    2. The original AI-generated draft must be preserved.
    3. All officer edits must be logged.
    4. The report must disclose that AI assisted in drafting.
    5. Prosecutors must be notified when AI was used.
    6. Defense attorneys must be able to obtain relevant AI drafting records through normal discovery.
    7. AI report tools may not be used for serious incidents unless additional safeguards are in place.
    8. The City must publish annual statistics on AI report use, error findings, officer adoption, and measured time savings.
    9. The vendor may not use Bend data to train AI models without explicit public approval.
    10. The City must independently audit the system before and after deployment.

    These rules would not ban AI.

    They would make AI accountable.

    No AI-generated police report without an audit trail

    Police reports are too important to become black boxes.

    If AI helps write an official record, the original AI output should not vanish.

    Bend residents should expect a simple rule:

    No AI-generated police report without an audit trail.

    Further reading

    Series links

  • What Happens to the Data?

    What Happens to the Data?

    Part 4 of the Bend Surveillance Oversight series.

    When people talk about police cameras, the conversation often focuses on the camera itself.

    But the camera is only the beginning.

    The more important question is what happens after data is collected.

    • Where does the video go?
    • Who stores it?
    • How long is it kept?
    • Who can search it?
    • Can it be shared?
    • Can vendors access it?
    • Can outside agencies access it?
    • Are searches logged?
    • Can the data be used later for a different purpose?

    These are the questions that turn a camera discussion into a public oversight discussion.

    Collection is only step one

    A body camera, vehicle camera, drone, traffic camera, or license plate reader may collect video, audio, images, license plate data, metadata, location information, timestamps, or other records.

    But collection is only the first step.

    After that, data may be uploaded to cloud storage, attached to case files, searched by officers, shared with prosecutors, retained for years, reviewed by supervisors, exported for court, or combined with other systems.

    A technology policy that says “we use cameras” is not enough.

    The real policy should explain what data is collected, where it is stored, how long it is retained, who can access it, when it can be searched, whether searches require a case number, whether searches are audited, whether vendors can access it, whether outside agencies can access it, whether data can be used for AI training or analytics, and whether new uses require public approval.

    Cloud storage changes the oversight question

    Many modern police technology systems rely on cloud storage and vendor-managed software.

    That can be useful.

    Cloud systems can make evidence easier to organize, share, redact, and preserve.

    But cloud storage also changes the oversight question.

    If public safety data is stored in a vendor-controlled system, residents should know what contractual rules apply.

    They should know whether the City owns the data, whether the vendor can access it, whether subcontractors are involved, whether data is encrypted, and whether the City can independently verify how the system is configured.

    This is why public policy should not rely only on verbal assurances.

    The City should publish the actual rules.

    Retention matters

    Retention is one of the most important privacy questions.

    A camera that records something and deletes it quickly is very different from a system that keeps searchable records for months or years.

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

    For Bend, a reasonable policy would be:

    Delete non-evidence data by default after a short period unless it is flagged for a specific, documented case.

    For ALPR data, I would support a default deletion period as short as 72 hours unless the scan is tied to a legitimate case, hit, warrant, stolen vehicle, or documented investigation.

    Search logs should be mandatory

    If a police technology system can be searched, the search should leave a record.

    That record should show 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.

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

    With search logs, the City can verify whether the system is being used properly.

    This protects the public.

    It also protects officers who are using the system appropriately.

    Sharing rules should be explicit

    Data-sharing rules should not be vague.

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

    A stronger policy would say that surveillance data may not be shared with federal agencies, out-of-state agencies, private companies, or other third parties unless there is a specific legal basis, a documented case number, written authorization, and an auditable record.

    The point is not to prevent legitimate case-specific cooperation.

    The point is to prevent broad, informal, or automatic access to local surveillance data without clear public rules.

    Vendor access should not be a black box

    Vendor access is also a form of third-party access.

    If a private company hosts police data, manages software, provides analytics, troubleshoots systems, stores video, or controls user permissions, the public should know what limits apply.

    Vendor access should be limited, logged, and auditable.

    Contracts should make clear that vendors cannot use local public safety data for unrelated purposes, product development, AI training, or secondary analysis without explicit public approval.

    Public reports build trust

    The City should publish annual transparency reports for police surveillance systems.

    Those reports should include:

    • what systems were used,
    • how many searches were conducted,
    • how many times data was shared,
    • how many outside-agency requests were received,
    • how many requests were approved or denied,
    • how many audits were conducted,
    • whether any misuse was found,
    • whether any new features were activated, and
    • whether any policies changed.

    These reports do not need to expose sensitive case details.

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

    The basic principle

    The goal is not to prevent every use of technology.

    The goal is to make sure powerful tools answer to public rules.

    A camera policy should not stop at collection.

    It should follow the data.

    Where it goes, how long it stays, who can search it, who can share it, and how the public can verify the rules are being followed.

    Further reading

    Series links

  • Why Vendor Lock-In Matters in Police Technology Contracts

    Why Vendor Lock-In Matters in Police Technology Contracts

    Part 3 of the Bend Surveillance Oversight series.

    In the last post, we looked at the range of police technology Bend has already considered, approved, or discussed: body-worn cameras, fleet cameras, digital evidence storage, Fusus real-time information software, Axon Air drone software, third-party video playback, investigation software, VR training, and automated traffic enforcement cameras.

    Looked at one at a time, each purchase can sound narrow.

    But when the same vendor ecosystem provides the cameras, storage, software, subscriptions, hardware refreshes, training tools, review tools, and add-on features, the City may gradually become dependent on one platform.

    That is called vendor lock-in.

    Vendor lock-in does not necessarily mean anyone did anything wrong.

    It means a city’s systems, data, workflows, training, contracts, and budgets become so tied to one vendor that switching later becomes expensive, disruptive, or politically difficult.

    That matters for public oversight.

    How lock-in happens

    A city might begin with a legitimate need: body cameras.

    Then it needs a place to store the video, so it adds cloud evidence storage.

    Then prosecutors need access, so the system becomes part of the criminal justice workflow.

    Then patrol vehicles need cameras, so fleet cameras are added.

    Then drone video needs to be managed, so drone software is added.

    Then the department wants video review tools, third-party video playback, investigation software, AI tools, or real-time information platforms.

    Over time, what began as a camera contract can become a broad public safety software ecosystem.

    The Electronic Frontier Foundation has warned about this pattern in its article “Beware the Bundle”, which describes how police technology companies can use bundled offerings to become a department’s default provider for more and more tools.

    Again, the issue is not whether any single tool is useful.

    The issue is whether the public understands how the tools fit together before the City becomes deeply dependent on the platform.

    Why bundled contracts are harder to oversee

    Bundled contracts can make public oversight harder for several reasons.

    First, bundles can obscure what is actually being purchased.

    Second, bundles can make costs harder to compare.

    Third, bundles can reduce practical competition.

    Fourth, bundles can normalize expansion through amendments.

    That is how surveillance systems can grow without residents ever seeing a single clear moment where the full policy question is debated.

    Vendor assurances are not the same as public policy

    Cities often rely on vendor statements about what a system does or does not do.

    That is not enough.

    • Vendors can change product features.
    • Software capabilities can be added later.
    • Terms can change.
    • Subprocessors can be involved.
    • Data can be stored in complex cloud systems.
    • Departments can expand use over time.
    • Future renewals can make earlier decisions harder to revisit.

    That is why public rules should not depend only on vendor assurances or internal department practices.

    Public policy should be clear enough that residents can understand the limits before the next expansion happens.

    Why this matters in Bend

    Bend has already considered or approved multiple related technology systems over time.

    That does not prove a problem by itself.

    But it does show why residents should ask how all of these systems connect, whether alternatives were seriously evaluated, and what would happen if the City later wanted different pricing, stronger privacy protections, or more independent technical control.

    Vendor lock-in is not only a procurement question.

    It is also a transparency and governance question.

    What better contract oversight would look like

    If Bend wants useful technology without becoming overly dependent on one vendor ecosystem, contracts should protect the public interest.

    That can include:

    • clear exit clauses,
    • data portability requirements,
    • limits on automatic renewals,
    • public review before major expansions,
    • independent audits of enabled features and system settings, and
    • Council approval before materially new capabilities are activated.

    Those are not anti-technology ideas.

    They are basic governance safeguards.

    The real question

    The question is not whether Bend should use one vendor or another.

    The question is whether Bend has enough public oversight before the technology ecosystem becomes too large, too expensive, and too embedded to easily change.

    Vendor lock-in is not just a budget issue.

    It is a democracy issue.

    When public safety technology becomes hard to leave, hard to audit, and hard for residents to understand, public oversight becomes weaker.

    That is why Bend should address vendor lock-in now, before future expansions become automatic.

    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.

  • Police-Tech Vendors Are Becoming Public-Safety Platforms

    Why platform contracts require ongoing oversight

    Body cameras, TASERs, evidence storage, drones, AI tools, analytics, and report-writing software are increasingly being bundled into long-term public-safety platforms. That changes what local oversight has to look like.

    Core issue: Public agencies are no longer just buying individual police tools. They are often entering long-term platform relationships where today’s contract can shape tomorrow’s data access, AI features, evidence workflows, analytics, storage, integrations, and switching costs.

    Axon is no longer just a TASER and body-camera vendor. Its own Q1 2026 financials show a public-safety platform business built around hardware, software, cloud evidence storage, AI tools, analytics, subscriptions, drones, real-time operations, and long-term agency relationships. Axon reported Q1 2026 revenue of $807 million, up 34% year over year.

    That platform model is showing up in public contracts. Baltimore approved a $153 million Axon agreement for body-worn cameras, TASERs, and other public-safety tools, while some city leaders questioned whether the agreement was the best deal for taxpayers. Savannah approved a 10-year, $27 million Axon agreement. Connecticut State Police rolled out upgraded TASERs, body-worn cameras, AI translation capabilities, VR training, drones, and evidence-management tools as part of a broader modernization package.

    Those examples matter because they show how police technology is becoming a bundle: hardware, cloud storage, evidence systems, report workflows, analytics, AI features, training tools, subscriptions, and future upgrades. The public may hear “body cameras” or “TASERs,” but the contract can also shape data access, retention, search tools, audit logs, and the agency’s ability to leave later.

    Investors have noticed the same shift. Business Insider reported that an Axon pitch at the Sohn conference emphasized AI tools such as automated police-report drafting from body-camera footage. That is a market signal: public-safety data, AI workflows, and subscription platforms are becoming part of the growth story.

    Why the platform model changes oversight

    When a city buys a single device, oversight can focus on that device: what it does, who uses it, and how it is maintained. But a platform is different. A platform can expand over time. New features can be added. Workflows can change. Data can be connected across systems. A contract that starts as a body-camera or TASER purchase can become a broader operational environment for evidence management, report writing, analytics, training, records, drones, and real-time response.

    That does not make every feature harmful. Some tools may improve officer safety, evidence handling, language access, disclosure, or administrative efficiency. But the public needs to understand the tradeoff: each added feature can create new questions about data collection, access permissions, audit logs, retention, vendor access, system dependencies, and whether elected officials will be asked to approve meaningful changes before they happen.

    The safeguard question is not simply “Should the agency buy the tool?” It is also: what future capabilities does this platform make possible, who can enable them, and what public process is required before they are used?

    What local officials should ask before approving or renewing a police-tech platform

    • Feature scope: Which tools are included now, which are disabled, and which can be enabled later without a new public vote?
    • AI and analytics: Are report-writing, transcription, translation, facial recognition, object recognition, predictive analytics, or other AI-assisted tools included or available as add-ons?
    • Data storage: What data enters the vendor’s cloud systems, where is it stored, and how long is it retained?
    • Access controls: Who has administrator access, who can search records, and can access be limited by role, case type, unit, or investigation status?
    • Audit logs: Are searches, views, exports, deletions, administrator changes, and vendor-support access logged in a way the agency can export and review?
    • Vendor access: Can vendor employees access agency data for support, product development, testing, demos, analytics, or AI model improvement?
    • Data sharing: Can outside agencies, task forces, prosecutors, federal agencies, or private partners access the platform or receive exports?
    • Exit rights: If the city leaves the platform, can it export complete evidence records, metadata, audit logs, retention schedules, and chain-of-custody information in a usable format?

    Why it matters for Bend

    Axon-style contracts should be reviewed as evolving governance systems, not static equipment purchases. Council and staff should know which features are enabled, who has administrator access, what data moves into vendor cloud systems, and whether new AI or analytics tools can be added without a fresh public discussion.

    That review should not stop at the purchase vote. A police-tech platform can change through software releases, configuration changes, integrations, add-on modules, and new agency workflows. For major public-safety platforms, the better oversight model is continuing review: regular reporting on enabled features, access settings, audit-log exports, retention changes, vendor access, and any new AI or analytics tools.

    Practical safeguard: Require a quarterly platform change log for major police-tech systems. The log should identify major software releases, enabled or deferred features, AI or analytics tools, search changes, evidence-workflow changes, access-control changes, administrator roles, vendor access, audit-log export capability, retention changes, and new sharing relationships.

    Bottom line

    For public officials, procurement is no longer simply “buying a tool.” It can mean entering a long-term platform relationship where today’s contract shapes tomorrow’s data access, integrations, AI features, analytics, storage, and switching costs. That does not mean cities should reject every new public-safety technology. It means the public rules need to be as durable and adaptable as the technology itself.

    Police technology should be judged not only by what it promises on day one, but by what it allows on day 500: who can search, who can share, who can change the settings, who can audit the system, and who can prove whether the public’s limits were actually followed.

    “No man is allowed to be a judge in his own cause, because his interest would certainly bias his judgment, and, not improbably, corrupt his integrity.”— James Madison, Federalist No. 10 (1787)

  • Signals & Safeguards: Issue 10 – ALPR Oversight, Police-Tech Platforms, and Practical Privacy Safeguards

    Issue 10 • Wednesday, May 20, 2026

    Signals & Safeguards newsletter masthead

    A concise weekly scan of surveillance, privacy, cybersecurity, and the safeguards public officials should keep in view.

    At a glance

    – ALPR oversight is becoming a democracy issue, not just a police-camera issue.

    – Local, private, and federal plate-reader access is turning ordinary movement into searchable infrastructure.

    – Axon’s financials, contracts, and release notes show police technology becoming a changing software-and-data platform.

    – The safeguard question is consistent: who gets access, under what limits, and who can prove misuse?

    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.

    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.

    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.

    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.

    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.

    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.

    The Fourth Amendment line is being tested at the border and at the front door

    Two legal fights point to the same question: when the government intrudes into highly private spaces, do old safeguards still have practical force?

    EFF is urging the Fourth Circuit to require warrants for electronic-device searches at the border. Phones and laptops are not ordinary containers. They hold messages, photos, location trails, health information, financial records, work files, source communications, family details, and years of private life. A border search of a phone can reveal far more than a search of luggage.

    The same principle appears in the home-entry context. Lawfare has criticized DHS’s defense of immigration home entries based on administrative warrants, arguing that an administrative document issued inside the enforcement system is not the same as a judicial warrant signed by a neutral judge. That distinction matters because the home has long received the strongest Fourth Amendment protection.

    The point is not that the government can never search a device, enter a home, or enforce immigration law. The point is that process matters most when the stakes are high. A real warrant requirement forces the government to state facts, define the scope, and persuade a neutral decision-maker before the intrusion happens.

    Why it matters for Bend: federal privacy norms shape the environment local governments operate in. If device searches, home entries, database queries, and surveillance partnerships become easier at the federal level, local officials should be more careful about importing low-friction access into city systems, vendor contracts, and data-sharing agreements.

    Immigration surveillance vendors need verification before deployment

    Immigration enforcement is increasingly tied to vendor systems, mobile access, and large searchable databases. That makes vendor verification a civil-liberties safeguard, not a procurement formality.

    The Lever reported on Edge Ops, an ICE surveillance vendor connected to a system described as mapping immigrants’ routines and locations. The reporting raised basic due-diligence questions about the company’s public claims, executives, clients, and marketing materials. Separately, 404 Media reported that ICE agents have access to a large list of people on their phones through Palantir-linked systems.

    The concern is not only what data exists. It is how easily that data becomes available in the field. Mobile access changes the meaning of a database. If agents can carry searchable identity, address, location, case, or association information on a phone, the public needs to know who can search it, what legal threshold applies, whether searches are logged, whether results can be shared, and how errors are corrected.

    This is the same access problem that appears in ALPR systems. Surveillance oversight is often less about the sensor and more about the database behind it. Who can search? Who can export? Who can share? Who audits? Who can prove misuse?

    Why it matters for Bend: Bend residents’ information may pass through city, county, state, vendor, and federal systems. A privacy rule or sanctuary policy only works if the database permissions behind it match the public promise.

    Shared pattern

    The strongest stories this week point to the same lesson: access is the real policy.

    A camera is not just a camera if its records can be searched by outside agencies. A body camera is not just a body camera if its footage feeds a cloud platform, AI report-writing tools, evidence workflows, and long-term data storage. A phone is not just a device if it contains years of private life. A database is not just a database if field agents can query it from an app. A data center is not just a building if it reshapes local power, water, land-use, and infrastructure decisions.

    The safeguard question is consistent across all of them: who gets access, under what authority, with what limits, with what logs, and with what public ability to review the answer?

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

    Police-tech vendors are becoming public-safety platforms

    Axon is no longer just a TASER and body-camera vendor. Its own Q1 2026 financials show a public-safety platform business built around hardware, software, cloud evidence storage, AI tools, analytics, subscriptions, drones, real-time operations, and long-term agency relationships. Axon reported Q1 2026 revenue of $807 million, up 34% year over year.

    That platform model is showing up in public contracts. Baltimore approved a $153 million Axon agreement for body-worn cameras, TASERs, and other public-safety tools, while some city leaders questioned whether the agreement was the best deal for taxpayers. Savannah approved a 10-year, $27 million Axon agreement. Connecticut State Police rolled out upgraded TASERs, body-worn cameras, AI translation capabilities, VR training, drones, and evidence-management tools as part of a broader modernization package.

    Those examples matter because they show how police technology is becoming a bundle: hardware, cloud storage, evidence systems, report workflows, analytics, AI features, training tools, subscriptions, and future upgrades. The public may hear “body cameras” or “TASERs,” but the contract can also shape data access, retention, search tools, audit logs, and the agency’s ability to leave later.

    Investors have noticed the same shift. Business Insider reported that an Axon pitch at the Sohn conference emphasized AI tools such as automated police-report drafting from body-camera footage. That is a market signal: public-safety data, AI workflows, and subscription platforms are becoming part of the growth story.

    For public officials, procurement is no longer simply “buying a tool.” It can mean entering a long-term platform relationship where today’s contract shapes tomorrow’s data access, integrations, AI features, analytics, storage, and switching costs. That does not make every feature harmful, but it does mean elected oversight has to continue after the purchase vote.

    Why it matters for Bend: Axon-style contracts should be reviewed as evolving governance systems, not static equipment purchases. Council and staff should know which features are enabled, who has administrator access, what data moves into vendor cloud systems, and whether new AI or analytics tools can be added without a fresh public discussion.

    Warning Signals

    These items point toward where surveillance systems, vendor platforms, identity infrastructure, and data governance may be heading next.

    Signals section header

    Platform Watch: Axon software updates show why oversight cannot stop at purchase

    Axon’s May 2026 Records and Standards release notes show how a police-technology platform can change after a contract is approved. The May 19 rollout touches report writing, embedded photos, Evidence links, search behavior, audit-log display, chain-of-custody records, property labels, mobile notes, and DataStore access controls.

    Some changes may improve clarity or accountability. Axon says users will be able to insert photos directly into report narrative text across both Records and Standards in training environments. The embedded photos appear as thumbnails and link back to the Evidence details page in Axon Evidence.

    The strongest accountability item is DataStore v2 row-level access control. Axon says agencies previously used custom views to share DataStore access while protecting sensitive records such as Internal Affairs files, juvenile records, ongoing investigations, and restricted content. The new preview feature lets administrators exclude rows a user is not authorized to see, but restriction enforcement is off by default and must be enabled by administrators.

    Oversight question: Does the agency provide Council with a quarterly platform change log showing major software releases, enabled features, administrator settings, audit-log exports, DataStore access, vendor access, and any new AI, analytics, evidence, search, or access-control tools?

    Movement data is escaping public categories

    ALPRs are moving from city streets into ordinary consumer spaces. Reporting on Lowe’s and Home Depot shows how retailers can use license plate readers in parking lots for theft prevention and safety. Connecticut lawmakers have moved to restrict some police ALPR sharing, but those rules do not cover private retailers.

    Connected cars raise the same concern from another direction. The Guardian reported that General Motors agreed to pay $12.75 million to settle California claims that it sold drivers’ location and driving-behavior data to data brokers without proper consent. The point is not that cars, stores, or cameras are identical systems. The point is that each can create movement records outside the categories people usually associate with government surveillance.

    Traffic cameras add a local wrinkle. Bend and Redmond are working through automated traffic enforcement. Traffic cameras are not the same as Flock or retail ALPRs, but the governance questions overlap: retention, access, vendor contracts, audit logs, public notice, error correction, and whether data collected for one purpose can later be repurposed.

    Data-center infrastructure is becoming a local consent fight

    Data centers are no longer an abstract technology story. They are becoming local governance questions about power, water, land use, jobs, taxes, infrastructure costs, emergency services, and public trust.

    La Pine residents have raised concerns about a proposed data-center project connected to BoxMiner, and the City of La Pine has published a release summarizing what has come before Council. Central Oregon coverage shows the concern is not only whether a project is legal. It is whether residents understand the long-term costs, commitments, and infrastructure consequences before decisions are effectively locked in.

    National polling suggests this concern is not unique to Central Oregon. Gallup reported broad public opposition to AI data centers in respondents’ local areas. The best framing is not “no data centers.” It is “public-infrastructure decisions need public-infrastructure scrutiny.”

    AI is shortening the distance between flaw and exploit

    Google says it disrupted a hacking operation that used AI to help discover and exploit a previously unknown vulnerability. AP, Reuters, Axios, and The Hacker News all covered versions of the same warning: AI can help attackers move faster from finding a weakness to testing and deploying an exploit.

    The week’s other cybersecurity stories reinforce the same practical lesson. Microsoft patched 138 vulnerabilities. CISA added a newly exploited vulnerability to its Known Exploited Vulnerabilities catalog. A WooCommerce Funnel Builder flaw was reportedly under active exploitation. Krebs reported that a CISA contractor exposed AWS GovCloud credentials in a public GitHub repository.

    The safeguard is boring but urgent: inventory exposed systems, patch actively exploited flaws first, remove unsupported devices, use phishing-resistant MFA, scan code repositories for secrets, rotate exposed credentials quickly, and require vendors to disclose patch and incident timelines.

    “In questions of power, then, let no more be heard of confidence in man, but bind him down from mischief by the chains of the Constitution.”— Thomas Jefferson, Kentucky Resolutions draft (1798)

    Safeguards

    Safeguards works best when they’re practical: less data, cleaner boundaries, stronger access controls, usable audit logs, and fewer shortcuts.

    Safeguards section header

    Require public rules before deployment or emergency continuation

    Camera systems, ALPR networks, drones, ShotSpotter-style tools, and police-tech platforms should not go live first and receive rules later.

    Public rules should answer basic questions before deployment: what data is collected, how long it is retained, who can search it, whether outside agencies can access it, whether federal or immigration-enforcement access is allowed, whether vendor employees can access it, whether searches require case numbers or documented purposes, whether audit logs are exportable, and how misuse is punished.

    Emergency authority deserves special care. If an emergency declaration is used to preserve or expand a surveillance system after ordinary political approval breaks down, the declaration should be narrow, time-limited, publicly justified, and subject to prompt council review.

    Treat police-tech contracts as governance documents

    A police-technology contract is not just a purchase order. It can define data access, AI features, evidence storage, audit logs, vendor permissions, integrations, renewal leverage, and exit costs for years.

    Before approving or renewing a platform contract, public officials should ask what the contract makes possible later. What AI tools can be added? Where is the data stored? Who can access it? Can the vendor use agency data for training, product development, support, demos, or analytics? What outside agencies can search the system? What records are retained after termination? Can the agency export complete audit logs and evidence records if it leaves?

    Require quarterly platform change logs

    For major police-tech and public-data systems, agencies should provide Council with a short quarterly change log covering major software releases, enabled or deferred features, AI or analytics tools, search changes, evidence-workflow changes, access-control changes, administrator roles, vendor access, DataStore or reporting access, audit-log export capability, retention changes, and new sharing relationships.

    This is not anti-technology. It is basic oversight for systems that do not stay frozen after purchase.

    Make warrants and notice real

    A warrant requirement only works if the warrant process is real. Courts need specific facts, narrow scope, and neutral review before high-intrusion searches. That matters for border-device searches, home entries, geofence searches, cloud records, account data, and sensitive databases.

    Notice also matters. H.R.6048, the NDO Fairness Act, is worth tracking because people cannot challenge improper electronic searches if they never learn the search happened. Delayed notice may be justified in some investigations, but secrecy should be narrow, time-limited, and based on specific facts.

    Treat movement and biometric data as high-risk data

    Vehicle telematics, retail ALPRs, hotel reservations, phone location, connected devices, school platforms, and traffic-camera systems can reveal where people live, work, worship, seek care, shop, protest, attend school, or travel. Biometric data raises even greater stakes because faces, fingerprints, and palm prints cannot be reset like passwords.

    The NYC Health + Hospitals breach is a reminder that biometric and medical data create permanent risk when exposed. Public agencies and vendors should collect less biometric data, store it separately when collection is necessary, encrypt it, limit access, shorten retention, document every search, and provide clear breach notice and deletion rules.

    Judge privacy bills by what they prevent, not what they promise

    A weak privacy bill can give people familiar rights – access, correction, deletion, portability, or opt-outs – while still allowing broad data collection, weak default protections, preemption of stronger state laws, limited enforcement, or loopholes for data brokers and sensitive data. A serious privacy law should reduce unnecessary collection, preserve stronger state protections, regulate data brokers, protect sensitive data by default, create usable deletion and correction processes, and provide real enforcement.

    Bottom line

    The best safeguards this week are not exotic. They are the boring controls that make powerful systems governable: public rules before deployment, narrow access, clear warrants, meaningful notice, exportable audit logs, short retention, vendor verification, platform change logs, data minimization, and fast patching. Surveillance oversight works best when restraint is built into the system before the data becomes too useful to give up.

    “No man is allowed to be a judge in his own cause, because his interest would certainly bias his judgment, and, not improbably, corrupt his integrity.”— James Madison, Federalist No. 10 (1787)

  • What Happens Next: Stopping the Boxminer Data Center Deal

    Advocate Road Map · La Pine, Oregon · Issued May 14, 2026

    The process that must occur before any sale is final, the community’s intervention points, and actions to take this week.

    ⚠ Important: The May 13, 2026 public comments were not a legal public hearing. Oregon law requires a formal public hearing before this sale can close.

    Nearly three hours of public opposition were delivered at the May 13, 2026 La Pine City Council meeting. That is significant — but the fight is far from over, and the community has more legal leverage than it may realize.

    Oregon law mandates a formal public hearing before any city-owned land can be sold. That has not happened yet. Every step below must occur before Boxminer can legally take ownership of this property. Each one is an intervention point.

    The Foundational Law: ORS 221.725

    Oregon law is unambiguous: before a city council can sell city-owned real property, it must publish advance notice of the proposed sale in a newspaper of general circulation and hold a formal public hearing prior to the sale.

    At that hearing, the full nature and terms of the sale — including an independent appraisal or other evidence of market value — must be fully disclosed. Any city resident has the right to submit written or oral testimony.

    The May 13 public comment period does not satisfy this requirement. The March 25 vote to begin the purchase-and-sale process does not satisfy this requirement.

    The ORS 221.725 public hearing has not been held. The sale cannot legally close until it is.

    Part One: The Process Map — What Must Happen Before the Sale Can Close

    1. ORS 221.725 Public Hearing — Legally Required, Has Not Occurred

    Legal basis: Oregon Revised Statutes § 221.725 · City of La Pine

    Primary intervention point · Legally mandatory

    The city must publish a formal notice of the proposed sale in the Bend Bulletin, the newspaper of general circulation for La Pine. The notice must state the time and place of the hearing, a full description of the property, the proposed uses, and the reasons for the sale.

    Not earlier than five days after that publication, the council must hold the public hearing. At the hearing, the full sale terms — including an independent appraisal or other evidence of market value — must be publicly disclosed. Any city resident must be given the opportunity to submit written or oral testimony.

    What advocates can do: Demand in writing that the city confirm it will comply with ORS 221.725 and provide the date of the required publication. This is not a request — it is a statement that the community knows its rights.

    2. Full Contract Disclosure at Public Hearing

    Legal basis: Oregon Revised Statutes § 221.725 · Appraisal requirement

    Intervention point · Legally mandatory

    At the ORS 221.725 hearing, the city is legally required to fully disclose the nature and terms of the proposed sale, including an independent appraisal or equivalent evidence of market value. This means the full purchase and sale agreement — including any growth or expansion provisions — must be on the public record before the council votes.

    What advocates can do: File a Public Records Request now, before the hearing, for the full PSA text, all communications between city staff or council members and Boxminer, any appraisal commissioned, and any MidState Electric correspondence. The city has five business days to respond or provide a timeline under ORS 192.311.

    3. City Council Vote to Approve the Purchase and Sale Agreement

    Public body: La Pine City Council · Public agenda item

    Intervention point

    This is a separate vote from the March 25 vote to begin the process. The council must vote to formally approve the finalized PSA. This vote must appear on a public agenda with advance notice, giving advocates another opportunity to submit written testimony and speak during public comment.

    What advocates can do: Monitor the city’s meetings page at lapineoregon.gov/meetings for agenda postings. The next regular meeting is May 27, 2026. Any PSA approval vote must be listed as a new business item with supporting documents in the packet. If it appears without prior public notice of the ORS 221.725 hearing, challenge it immediately in writing.

    4. Deschutes County Deed Transfer — County Publication Required

    Legal basis: Oregon Revised Statutes § 275.120 · Deschutes County Board of Commissioners

    County action required · Intervention point

    The land is currently owned by Deschutes County. Before the county can transfer title, Oregon law requires the county sheriff to publish a notice of the sale in a local newspaper of general circulation once per week for four consecutive weeks prior to the sale. This is a parallel, independent publication requirement that creates another four-week public notice window.

    What advocates can do: Contact the Deschutes County Board of Commissioners now and put them on record. As the current titleholder, the county is a party to this transaction. Submit written testimony to the BOCC and request that the county independently verify the city has completed its ORS 221.725 obligations before proceeding.

    5. Formal Land Use Application and Site Plan Review — Planning Commission

    Legal basis: La Pine Development Code · City Planning Commission · ORS 227.178

    Second major intervention point

    Even after the land sells, Boxminer cannot break ground without submitting a formal land use application for site plan review. This triggers La Pine’s Planning Commission process, which has its own public notice, comment period, and hearing requirements completely independent of the land sale process.

    This is where the zoning question must be formally resolved in writing by city staff: La Pine Development Code Sec. 15.24.300 states that in the Light Industrial zone, “Energy and power generation uses are prohibited.” City staff must publish a written legal determination explaining how a 20MW Bitcoin mining facility is classified under that code before any permit can issue.

    What advocates can do: Central Oregon LandWatch can formally intervene in the land use process when the application is filed and can refer legal counsel to challenge the zoning classification if needed. File a written request with city Community Development now asking staff to confirm in writing the zoning classification that would apply to this use before an application is filed.

    6. Building Permits Issued — Final Gate

    Public bodies: La Pine Building Services · Deschutes County Community Development

    Final gate

    Building permits cannot be issued until after land use approval. Each permit is a public record. If the zoning determination or site plan review is contested, a Land Use Board of Appeals appeal can be filed, which can put a hold on permit issuance while the appeal is heard.

    The Oregon Department of Land Conservation and Development also has oversight authority over local land use decisions that conflict with acknowledged comprehensive plans.

    Part Two: What Advocates Should Do This Week

    🔥 Send a Written ORS 221.725 Demand Letter to City Hall

    Timing: Do within 48 hours.

    Write to City Manager Geoff Wullschlager and the City Recorder demanding:

    • Written confirmation that the city will comply with ORS 221.725 before finalizing any sale.
    • The anticipated date of the required newspaper publication.
    • Confirmation that the ORS 221.725 public hearing will be separately noticed and held before any PSA vote.

    Send by email and certified mail. Keep a copy. This letter creates a paper trail that the city received formal notice of its obligations.

    City Manager: Geoff Wullschlager
    Email: info@lapineoregon.gov
    Phone: (541) 536-1432
    Address: 16345 Sixth Street, La Pine, OR 97739

    🔥 File a Public Records Request for the Full Contract and All Communications

    Timing: Do within 48 hours.

    Under ORS 192.311, the city has five business days to provide the records or give a timeline. Request:

    • The full text of any purchase and sale agreement, letter of intent, or MOU with Boxminer Co. or any related entity.
    • All written communications between city staff or council members and Boxminer Co., Frontier Mining, or Jeff Keller from January 2025 to present.
    • Any appraisal of the subject property.
    • Any MidState Electric correspondence regarding power supply.
    • Any legal opinion on the Light Industrial zoning classification of this use.

    File online: La Pine Public Records Request Form

    🔥 Call Central Oregon LandWatch

    Timing: Do within 48 hours.

    Rory Isbell at Central Oregon LandWatch was previously unaware of this proposal. He now is, but he needs to hear that nearly three hours of public opposition materialized at the May 13 council meeting and that the ORS 221.725 hearing has not been scheduled.

    Share this key fact from the March 11 minutes: Jeff Keller told the council he had been working with MidState Electric and SLED Director Patricia Lucas since 2022 — three years of negotiations before the public heard a word. That timeline is material to any legal challenge about adequate public process.

    LandWatch can provide or refer an attorney to formally intervene at both the public hearing and the Planning Commission site plan review stage.

    Contact: Rory Isbell, Staff Attorney and Rural Lands Program Director
    Email: rory@colw.org
    Phone: (541) 647-2930 x804

    📋 Document the May 13 Comments While They Are Fresh

    Timing: Do within 72 hours.

    The nearly three hours of public comments are part of the official record, but advocates should independently document them. Track the names and addresses of speakers, the specific concerns raised, and any commitments or statements made by council members or city staff in response.

    This record will be essential at the ORS 221.725 formal hearing and any future LUBA appeal. If anyone recorded the meeting, secure those recordings now. The city should also produce audio or video if it exists; request it via public records if needed.

    📋 Write to the Deschutes County Board of Commissioners

    Timing: Do this week.

    The county is the current landowner and must execute the deed transfer. The city itself has publicly confirmed that Deschutes County must sign off on the final land sale and that a county building review is also required before construction.

    This means the BOCC has real authority here — not just a rubber stamp role. Write to the BOCC formally:

    • Notify them that significant organized community opposition exists.
    • Request that the county independently confirm the city has completed its ORS 221.725 obligations before proceeding with any transfer.
    • Ask the BOCC to place the matter on a public agenda for discussion.

    Deschutes County Board of Commissioners:
    deschutes.org
    1300 NW Wall Street, Bend, OR 97703

    🔥 Request a Speaking Slot at the May 29 Oregon Data Center Advisory Committee Meeting</h3

  • Surveillance • Privacy • Local Oversight

    Bend’s Flock Data Shows Why Surveillance Oversight Must Be Built Into the System

    Recent reporting about Bend’s Flock Safety cameras and Oregon’s sanctuary-law lawsuit point to the same lesson: privacy rules only work when the databases enforce them.

    The most important surveillance story in Bend this week is not hypothetical. According to The Source Weekly, federal immigration officials made 279 queries into Bend’s Flock Safety data in the first three weeks after the cameras went live. Bend Police reportedly did not authorize those searches, and it remained unclear what, if any, data may have been retrieved.

    That should concern anyone who cares about local control, public accountability, or civil liberties.

    The issue is not simply whether a particular search was improper. The larger problem is governance. When a surveillance system is installed for one stated purpose, it can quickly become useful to other agencies, vendors, or outside users who were not central to the original public debate.

    If city officials cannot later answer basic questions — who searched the system, why they searched it, what they saw, whether the search was tied to a case number or documented purpose, and whether any result was shared — then the public is being asked to trust a system that cannot be independently verified.

    That is not meaningful oversight. That is a blind spot.

    Audit logs are not a technical detail. They are the oversight system.

    Surveillance oversight often gets discussed as if it is mainly a policy question: Should the city approve the tool? What is the stated purpose? What does the vendor promise? What does the agency say it intends to do?

    Those questions matter, but they are not enough.

    Once a system is live, the real questions become operational:

    • Who can access the system?
    • Can outside agencies search it?
    • Can federal agencies search it?
    • Can vendors access camera feeds, search tools, dashboards, support logs, or stored data?
    • Does every search leave a usable record?
    • Can elected officials or independent reviewers verify how the system was used?
    • Are searches tied to a case number, warrant, emergency, or documented purpose?
    • Are improper searches detectable?

    Without those controls, the public has no practical way to know whether the system is being used as promised.

    This does not require assuming bad faith by local officials. In fact, it shows why good-faith intentions are not enough. A system can be approved by people with narrow intentions and later become available to people with very different priorities. That is why access controls, audit logs, outside-agency limits, vendor-access limits, and public reporting must exist before a system goes live.

    “You must first enable the government to control the governed; and in the next place oblige it to control itself.”
    — James Madison, The Federalist No. 51 (1788)

    Oregon’s sanctuary-law lawsuit is also about database access

    The Bend Flock story now sits inside a larger Oregon data-sharing dispute.

    OPB reported that a lawsuit filed in Multnomah County Circuit Court alleges Oregon State Police allowed federal immigration authorities to access Oregonians’ data through shared law-enforcement databases for years, despite Oregon’s sanctuary laws. Oregon State Police denies wrongdoing.

    The Source Weekly also reported that the complaint alleges federal immigration authorities queried state-run data about Oregonians 1.4 million times between February 2025 and February 2026, an average of 3,835 queries each day.

    The practical lesson is straightforward: a sanctuary policy is only as strong as the database permissions behind it.

    If an agency is legally barred from using data for immigration enforcement, the system should not rely on informal restraint. It should include technical controls that prevent improper access, audit logs that expose improper use, and consequences when policy and practice diverge.

    A privacy rule that lives only on paper is fragile. A privacy rule built into permissions, logging, retention limits, and reporting is much harder to ignore.

    Why this matters for Bend

    Bend residents’ information may pass through city, county, state, vendor, and law-enforcement systems. That information can include license plate scans, police records, driver information, public records, utility records, permits, emergency-service data, and other civic information collected for ordinary public purposes.

    The danger is that data collected for one purpose can become useful for another.

    A license plate reader approved for local public-safety purposes can become searchable by outside agencies. A state database can become an immigration-enforcement tool. A vendor platform can create access points that city officials did not fully understand when the contract was approved. A policy promise can fail if the technology underneath it does not actually enforce the rule.

    That is why surveillance oversight cannot stop at approval. Local officials need to know who can search local systems, what outside agencies can access, what vendors can see, how long data is retained, and whether every search leaves a record that can be reviewed.

    The safeguard standard should be simple

    Before Bend approves, renews, or expands any surveillance or sensitive data system, the city should be able to answer:

    • Who can access the data?
    • Who can search the system?
    • Can outside agencies access it?
    • Can federal agencies access it?
    • Can vendors access it?
    • Is every search logged?
    • Are searches tied to a documented purpose?
    • How long is data retained?
    • Can improper access be detected?
    • Can elected officials and the public receive meaningful reports about system use?

    If those questions cannot be answered clearly, the system is not ready.

    This is not about being anti-technology. It is about making sure public technology remains accountable to the public. Tools that collect sensitive information should not depend on trust alone. They should be designed so that misuse is difficult, detectable, and provable.

    Bottom line

    The Bend Flock story and the Oregon sanctuary-law lawsuit point to the same conclusion: access is the story.

    Who can search the data? Who can receive it? Who can share it? Who can buy it? Who can combine it with other systems? Who can turn an ordinary resident’s movement, record, or routine interaction with government into an investigative lead?

    Privacy safeguards fail when access is undefined, unlogged, or routed through systems the public cannot see.

    The best safeguards are practical and boring by design: collect less data, connect fewer systems, limit outside access, require documented purposes, log every search, review the logs, shorten retention, make vendor access visible, and make misuse provable.

    Surveillance oversight works best when restraint is built into the system before the data becomes too useful to give up.

    Related reading: