What I Learned Investigating Flock in Pflugerville: A Field Guide for Elected Officials

What follows is the process I went through as an elected official: the questions I asked, the records I requested, the people I listened to, the changes we made along the way, and what I would tell another local elected official to do if they are evaluating Flock, or any other high-risk technology their city is considering.

I would move faster through some of this if I started today, because I know more now than I did in December 2025. That is part of the lesson, too. Your own conclusion is one vote. You still need to understand what your community is worried about, what your colleagues need to see before they can vote, what staff can fix without a Council vote, what the vendor will actually put in writing, and what risk remains once every fixable problem has been fixed.

This is a long post because the process was long. The list below is the short version. Everything after it is the detail, organized so you can jump to the part you need.

Start by understanding what you are actually buying

One of the first problems in these discussions is that people use "Flock" to mean several different things. An automated license plate reader is not a conventional security camera. A fixed video camera is not video analytics. A vehicle-search tool is not facial recognition. A database your officers can query is not the same as a network that lets information move between agencies. Those distinctions matter because each carries different risks.

When this started, I wanted basic public information Pflugerville didn't yet have in one place: how many cameras we had, what kind they were, what they captured, what systems ran them, what policy governed them, and what the public could actually see about their use. Digging in, I found that individual departments had been buying Flock's Condor cameras for ordinary security purposes instead of plain, non-networked cameras, without realizing what that connected them to. We had also, at some point, purchased a Flock Wing Gateway without Council approval because the cost was below the threshold where our previous City Manager had to notify Council. It piped every old security camera in places like the library and other city buildings into FlockOS, so police could monitor city facilities from a single dashboard in their cars. The intent was reasonable. The staff who set it up believed the data stayed ours alone and did not understand they were routing that footage into a much larger system. Flock did not clearly explain what its hardware connected to.

On December 15, 2025, I convened a dedicated Council Lunch and Learn with Flock representatives, after giving staff advance notice of the concerns residents were likely to raise so nobody was caught off guard in the room. Flock's practice in these meetings is to send an account executive, essentially a salesperson, and a PR representative, not a product manager or engineer who can actually answer technical questions.

That was useful, but a vendor presentation is the start of an investigation, not the end. A company can tell you what a product is designed to do, and most people trust what even the salesperson is saying. An elected official still has to determine what it can actually do, what the contract permits, how it is being used today, where the data goes, who else can reach it, and how the product is changing under the vendor's own roadmap.

My first follow-up question, in January, was jurisdictional rather than technical: was the Texas Department of Public Safety's access to Pflugerville's data legally required, or had the city simply enabled it. Context matters here: our governor has said state DPS officers are also deputized as ICE agents. So even if we had a policy against immigration-related searches, DPS, who did have access, could in theory run them. Whether a data flow is mandated or optional determines which bucket a problem falls into: fixable locally or not. The answer, once we checked: we had to sign an MOU to access the state's Flock system, but the state needed no such agreement to access ours.

Fix the things your own city can fix

Several of the earliest improvements did not require an ordinance or even a Council vote. They came out of direct conversations with the City Manager, Police Chief, and staff about what residents were raising and what we could fix immediately: expanding the information on the city website about what systems Pflugerville was running and how many cameras were in place, improving the public transparency portal, turning on the Flock-hosted public audit feature, publishing the Police Department's General Order governing ALPR use, and changing internal procedure so every search required a case number and a plain-language explanation of why it was conducted. None of these needed a fight. Staff implemented them without pushback. By January 10, 2026, the department had made the search-entry changes, and the city was proactively publishing its policy and audit information.

If the problem was weak transparency, we improved transparency. If the problem was thin search documentation, we strengthened it. If residents could not see the rules governing officers, we published the rules. At the time, I was still testing whether there was a responsible way to run the system, and if there was any chance of getting there, we needed to close the gaps within the city's control first. That also makes the eventual decision cleaner: once you have fixed everything a policy change can fix and serious concerns remain, you are no longer debating problems a memo could have solved. You are down to the actual issue.

Get the records

This is where the investigation widened. On June 9, 2026, I requested the underlying emails, agreements, inventories, technical details, and draft renewal documents: the complete camera and device inventory, the distinction between ALPR units and video cameras, which existing city cameras fed into Flock, gateway and server details, the AI, search, and analytics capabilities that were actually enabled, the latest draft renewal, proposed order forms and pricing, and the internal staff-vendor correspondence about the renewal. The City Secretary acknowledged the request the next day. I followed up two weeks later and offered to take the response in batches rather than hold up the whole production.

Staff produced the response on June 29: roughly 95 megabytes of emails and documents, including the Police Department's investigative-technology policy, the existing agreement and MOU, the privacy policy, camera inventories, a draft redlined renewal master services agreement, and prior open-records material. Buried in the technical answers was the fact that 38 existing city cameras, well beyond the 28 automated license plate readers most residents thought of as "Flock," were feeding live video into the system through a separate gateway integration. That detail illustrates why the initial public camera count, and what is listed on the Flock Transparency Portal, understated what was actually in the system.

Do not ask for "the Flock contract." Technology contracts are usually a stack: an order form, a master services agreement, terms incorporated by reference online, a privacy policy, data-processing terms, product-specific terms, and amendments. You need to know which document controls when they conflict, and whether the vendor can update any of them without your city's sign-off. The same logic applies to the emails. Staff-vendor communications show what capabilities were being discussed before the contract was final, what concerns staff raised at the time, how the company described its own product, and what it would not agree to change. For example, I found evidence of our police department requesting quotes for Flock’s 911-transcription software and for their drones. Those plans never materialized, but the fact that someone on staff inquired told me something.

Audit actual use

I would do this earlier if I started over. Do not rely on the aggregate numbers a vendor or your own department hands you: arrests assisted, or vehicles recovered. Pull the individual search records instead, and look at who ran each search, the stated reason, whether that reason is actually meaningful, patterns over time, unusual searches, and any external access or sharing. Ask about outcomes specifically. I never got a straight answer on how many solved cases actually required Flock versus cases where Flock contributed but wasn't the reason the case closed. I’m still curious; it will matter if we ever end up discussing a “replacement.”

Flock's own auditing reports misuse after it happens. It does nothing to stop an officer from picking a different, technically legal reason code instead of the real one. That is why the plain-language explanation requirement matters more than the drop-down category ever did. I trusted Pflugerville's commissioned officers. I did not trust every outside agency with access to our data. The final access records showed why that distinction mattered.

Residents were doing some of this work independently, and it fed directly back into mine. A resident also spent significant time reviewing the audit records on their own and surfaced patterns I had not caught in the aggregate numbers. Separately, on July 9, 2026, another resident flagged that the camera count had quietly disappeared from Flock's transparency portal. I asked staff the same day whether that was intentional. The answer was that the vendor's portal only counted Flock-branded units and had never included the Axon vehicle-mounted and other license plate readers already in use, which is exactly the kind of undercount you only catch if someone outside City Hall is watching the public-facing numbers as closely as staff watches the internal ones.

Listen to the people who understand the risks

If activists, organizers, civil-liberties groups, or residents raise concerns, listen. Do not assume someone raising privacy concerns is exaggerating because they identify as an activist, and do not assume someone defending the department is dismissing those concerns because they support police. Different people are working from different information. Residents from communities that have historically carried a disproportionate share of surveillance, over-policing, or immigration enforcement risk can see harms in a system that someone without that history does not immediately register.

In January 2026, several residents told me they wanted to organize around privacy and surveillance concerns but did not know where to start, so I connected them with each other. By mid-month, that group was meeting on its own.

I also met directly with the local police association and talked with the officers who use these tools day to day. I wanted to understand what Flock did for their casework, what they would lose if it went away, and which safeguards would interfere with legitimate investigative work. I went on a ride-along earlier this year and saw Flock used in real time to try to locate a suspect. I also saw how easily the system could show where someone likely lives, works, or drops their children off at school. You need input from the people who use the system and the people most likely to carry its risks. Do not outsource your judgment to either one. My prepared remarks explain how I weighed that public-safety value against the contract, the company, and resident concerns.

More than one elected official from another city, who had already been through a fight like this on the same and different issues, told me the same thing: you need many stories describing different kinds of risk, not one. A single account of harm, however real, is easy for a skeptical colleague to file away as an outlier. Multiple accounts spanning misidentification, immigration enforcement exposure, and routine over-policing are harder to dismiss as one person's bad experience, and that range is what actually moves a body of seven people who started from seven different priors.

Understand the politics without letting the politics decide the question

This part is harder to explain publicly. There were stretches of this process where my private level of concern was ahead of what I was saying in public. That was not an attempt to mislead residents. What I said publicly during that period was accurate: I was investigating, I had not reached a final conclusion, and I would share it when I had one. What I held back was the strength of my private view, because an unsupported position from one council member closes colleagues' minds faster than it opens them, and I had not yet built the record to back it up.

I serve on a seven-member Council. My own conclusion is one vote. Part of the job in a deliberative body is figuring out what each colleague actually needs to see before they can reach a decision themselves, and you get most of that from watching how they've voted and spoken on other issues over time, not from lobbying them one-on-one, which risks turning into an unlawful walking quorum outside a posted meeting. One colleague weighs data above everything else: outcome numbers, and whether contract language actually matches the risk being managed. Another was always going to raise the likelihood that our crime rate ticks up without the tool, because being seen as strong on crime matters to how they govern. Neither of those reads came from a private conversation. Both were visible from how each had approached similar issues before, and building a public record that answered the data question directly and took the crime-rate concern seriously instead of dismissing it, mattered more than persuading either one directly ever could have. If you believe the body should move in a particular direction, your job is to build the factual record and create the space for colleagues to get there on their own, not to assign them to a side before they finish reviewing the evidence.

Give the vendor a chance to solve the problems

As the investigation progressed, I got more involved in the contract-renewal process itself, though negotiating the contract is staff's and the City Attorney's job, not a council member's. As early as February 2026, I gave the City Attorney the existing Flock agreement as a working test case while he reviewed a separate technology-governance resolution I was drafting, so the two efforts could inform each other from the start. Once staff produced the redlined master services agreement in early July, I reviewed it and sent the City Attorney proposed contract protections and negotiation points on July 6, then circulated my own redline and recommendations on July 14. On August 7, I flagged a scope problem directly: the proposed agreement was written almost entirely around ALPR use, even though the June records already showed ordinary video-surveillance feeds flowing into Flock's system. I treated video and audio protections as part of the same negotiation, not a separate issue to raise later. On August 11, Council postponed the scheduled vote on the renewal, giving staff more time to negotiate the open items before a final decision.

On August 18, working with the City Attorney during that postponement, I put together a prioritized list of the agreement's remaining deficiencies and flagged which ones mattered most to me. I was fortunate to enlist the help of an attorney who lived in Pflugerville and specialized in AI, data protection, and cybersecurity to review the drafts and offer suggestions pro bono.

That specificity also tests the vendor. If a company says publicly it does not intend to use your data a certain way, ask it to put that in writing. If it says a safeguard is fundamental to how it operates, ask for the safeguard in the contract. If it says a use case falls outside the system's purpose, ask whether the agreement can prohibit it outright. What a company says it plans to do and what it reserves the legal right to do are two different documents, and that gap became one of the more important parts of my own evaluation. I am covering the specific contractual deficiencies we found in the next post in this series, because they deserve their own treatment.

Separate the problems you can fix from the ones you cannot

This was the most consequential part of my own decision. Some risks were within Pflugerville's control: department policy, search documentation, what gets published, what gets audited, who has local access, and what terms we could negotiate into the contract. Other risks were tied to the company itself, the broader sharing network, the product's changing capabilities, and contractual rights the vendor was unwilling to give up. A City Council can hold its own Police Chief accountable, change city policy, and cut an employee's access. It cannot govern a national technology company's product strategy. The contract review identifies which protections Flock accepted and which risks remained with Pflugerville.

I started this process asking whether enough safeguards could get Pflugerville to a responsible yes. The question that mattered by the end was different: could I tell residents, honestly, that the safeguards I believed were necessary were enforceable, durable, and actually within the city's control. My answer was no.

What that answer meant in Pflugerville

Staff were still negotiating the unresolved provisions from the August 18 list when, on Monday, August 24, Sam Aly, a Pflugerville resident who ran against me for this seat last November, got back the results of a Texas Public Information Act request he'd filed and spent that afternoon analyzing it: 459 outside agencies had access to Pflugerville's Flock data, only 80 of which were ever supposed to be authorized, and the data showed almost 1.6 million searches run against Pflugerville's system. Sam posted his analysis publicly as soon as he finished and sent me the raw data directly. I passed it immediately to the City Manager, the City Attorney, and the Police Chief. All three went into action that night, including contacting Flock directly to learn how this happened and double-checking every setting in our own system. They confirmed that we had National and State-wide sharing turned off. The records showed that data was still being shared.

By around noon on Tuesday, August 25, city crews were bagging every ALPR camera in Pflugerville, ahead of that evening's Council meeting. Council voted unanimously that night to decline the agreement and direct staff to terminate it. Chevonne Lorigo-Johst, president of the Pflugerville ISD school board, was in the room for the resident testimony and the Council discussion, and PfISD's superintendent moved to cancel the district's own Flock contract as soon as the vote was final. By Wednesday morning, August 26, PfISD had shut off its own Flock ALPRs and taken them down from their mounts. District leaders had followed the resident and Council discussion for months and were prepared to act. Building the record publicly gave them the information and time to do it.

These outcomes are the direct result of the process in this post. The transparency fixes, the records requests, the audit review, and the contract engagement did not resolve the underlying problem. They revealed how far outside the city's control it actually was. What closed it out in the end was a former political opponent doing the analysis staff hadn't yet done, and my understanding is that they could not do so without Flock’s assistance, on a Monday evening, and a city willing to act on it within 24 hours regardless of who brought it forward.

Timeline at a glance

• December 15, 2025: Council Lunch and Learn with Flock executives.
• By January 10, 2026: Search-entry documentation and public policy and audit publication changes in place.
• June 9, 2026: Formal records request for the full inventory, technical detail, and draft renewal.
• June 29, 2026: Staff produces the records; disclosure that additional city cameras feed video into the system.
• July 6 and July 14, 2026: Proposed contract protections and a full redline sent to the City Attorney.
• August 7, 2026: Scope problem flagged: the agreement covers ALPR but not the video feeds already in the system.
• August 11, 2026: Council postpones the renewal vote to give staff more time to negotiate.
• August 18, 2026: Prioritized list of remaining contract deficiencies finalized with the City Attorney.
• August 24, 2026: Sam Aly's records request comes back showing 459 outside agencies with access and almost 1.6 million searches against Pflugerville's data, only 80 of which were ever authorized, a number that was already too permissive. Sam posts it publicly and sends it to me that evening; I notify the City Manager, City Attorney, and Police Chief, who contact Flock the same night.
• August 25, 2026: Cameras bagged by noon; Council votes unanimously that evening to terminate the agreement.
• August 26, 2026: PfISD shuts off and removes its own Flock ALPRs following the district superintendent's cancellation.

What I would do faster next time

I would request the contracts, communications, audit logs, sharing arrangements, and data terms immediately rather than building up to them. I would define the contractual red lines earlier, and I would ask harder questions about the vendor's product roadmap sooner. I would still talk to officers, residents, and advocates, make the local fixes immediately, and give the vendor a real chance to address the concerns before reaching a conclusion. A faster review still requires each of those steps unless you have already found evidence of abuse.

The broader lesson

The investigation focused on Flock. The same questions apply to facial recognition, generative AI, drones, automated permitting tools, video analytics, predictive systems, or whatever comes next: what data does it collect, what can it infer, who has access, where does the data go, what decisions can it influence, what happens when it is wrong, what protections exist in policy versus in the contract, what can the city actually audit, what can residents see, and which of those protections remain within the city's control when the vendor changes the product later.

Pflugerville spent nine months answering most of those questions after the system had already been in place for several years. Cities should not have to run this process from scratch every time a new high-risk technology shows up at a Council meeting, and that is the argument I am making in the next two posts in this series. Governance, oversight, and Council-level policy are critical in this fast-changing space.