I am currently using Perplexity for https://veruscite.com/. Verify citations actually exist -- so get in a list of 100, half I can check with crossref, but the other half I need to do a web search and fetch to make sure they exist.

So I need higher rate limits to not make the tool come to a crawl. I probably will not consider DeepSeek API here (I have tried DeepSeek hosted at US providers, like Perplexity). The other search/fetch tools I try do not have great web coverage of Asian journals, but the fact DeepSeek API is not zero data retention I cannot get over.

I am confused by this as well, shouldn't it be all white listed sites at the start?

So I wish I could use Google for https://veruscite.com/, but the number of Google searches are a hard cap on the account! So yes that is fine for agentic coding, but for an app that relies on web-search is not sufficient.

I am currently using Perplexity fast search and fetch, and I am happy with that. I would try our Ceramic.ai, but I need to be able to fetch the pages as well (I do not want summaries).

(I work at Linkup.) We do both: search returns raw results, no summaries, and there's a separate fetch endpoint that returns the full page as markdown, with optional JS rendering. You should compare us against your Perplexity setup - you might some value in switching

Put in the todo list to check out. If you cut web search costs even further for flash/fast search (similar to Perplexity, which is $1 per 1000 for fast search) would make it more competitive (at least for my app!)

While this is true, it is still possible to take the probabilities and make determinations of recall and false positives using conformal sets, https://crimede-coder.com/blogposts/2026/ConfClassification

(Or just use a model to re-calibrate the probabilities, I like the conformal approach though as those rates are what I often care about.)

You just need some labelled data to generate the "corrected" probabilities (or thresholds to meet the specified error rates).

They are relevant and courts have considered the whole of a persons movements standard in terms of whether querying ALPR data constitutes a search, https://andrewpwheeler.com/2026/08/12/license-plate-reader-s...

Under current case law (Carpenter and recently affirmed in Chatrie) it will definitely be a search, IMO it is just when the sensors become dense enough according to the court (absent states do not make regulation themselves to require a warrant for historical data).

This is what the majority of mine look like as well. Just simple instructions for things I need to do repeatedly.

I have not even really needed a formal memory system. If I see an error happen more than once, I just say "hey add a note on this to agents.md". Tends to be verbose but overall works quite well for the projects I am doing.

This is another riff on not embedding a full document, but doing a summarization of the document and embedding the summary for RAG. Nice usecase for high cardinality data!

I did not know about this when I wrote https://andrewpwheeler.com/2026/08/12/license-plate-reader-s... the day prior, but one of the things I did state was deleting data (except in the extreme case, like New Hampshire's 3 minute retention), will not prevent abuse. People just do illegal queries over and over again.

Part of the reason I wrote that post is it is better to retain the data indefinitely and have a warrant standard than continue to reduce the time period in which the data is retained.

This is already the current status quo on paper. I bet the majority of the cases IJ identified of mis-use the PDs already had this policy. (That is the same standard when you do a background criminal history check in New York, need to put in a case number, FYI.)

I did not want to go into too many technical details on the post -- I think you could do an AI audit at the point in time of the search query to prevent people putting in junk cases. That said I believe there will always need to be third party audits at a minimum.

Part of the issue is policies on paper are not effectively enforced. So people saying "just have policy X to prevent abuse" is a non-answer.

I wrote the post mainly because people arguing for limited data retention I think is bad for both sides -- it neither protects civil liberties and simultaneously makes it harder for long term criminal investigations.

It isn't at all the current status quo. There may be some kind of departmental guideline in some cases, but it's neither required by the software, nor mentioned in the Lexipol Media Group policy template that commonly gets purchased by police departments once the public starts asking them what their ALPR policy is. A quick spot-check of eyesonflock.com finds that, of those audit logs that are still available to the public, case or CAD IDs are still not commonly required.

The thing about CAD/case IDs is that it makes the use of junk cases in audit trails more detectable vs. the current situation.

Third-party audits would be great, but I haven't been able to find an ideal third party to do the auditing. Locally, police commission groups quickly got co-opted through political processes into being both toothless and extremely deferential towards the police department. I wouldn't trust state auditors any more than local auditors. That's why we pushed to force audit logs to be made publicly accessible in SB1516 6(3)(a): https://olis.oregonlegislature.gov/liz/2026R1/Downloads/Meas...

> Part of the issue is policies on paper are not effectively enforced. So people saying "just have policy X to prevent abuse" is a non-answer.

Policies on paper are where you start. I wholeheartedly agree that they are not by themselves sufficient, but they have to exist, and to that end, you want the strictest possible policies that are politically achievable. I don't believe that a warrant requirement is politically achievable.

We had several deep conversations with ACLU on data retention limits. Data retention limits were one of the things they fought hardest for in this state. We supported that, but focused more of our energy on a different aspect (which we didn't succeed at, unfortunately). ACLU's point of view is that longer data retention makes it easier to profile the movements and activities of politically sensitive groups. It's true that it does, but ALPR vendors' ability to directly access and control the data means that there are numerous trivial workarounds for targeting any demographic or political group, regardless of data retention limits.

I remain of the opinion that these systems simply don't need to exist at all, which makes the answers to a lot of these questions a lot easier. Violent crime has overall been trending downward for a long time, we live in one of the most peaceful societies in human history, we already know how to reduce property crime and crime directly related to poverty, and roving armed gangs are not a sensible immigration policy. We're twisting ourselves in knots trying to figure out how to make an inherently unsafe technology safe to meet a need that we don't have.

Flock exists because YCombinator and subsequent investors saw an opportunity to use public grant money to pay to bootstrap the collection of an enormous amount of really valuable data on Americans.

I cannot read this article, but this may be partly confused what this function by Carbyne does. If there is a flood of critical systems, it just plays an auto message "If this is about X, thank you and we know about it" if you called from the same area.

I don't remember from prior articles if at that point you just stay on the line, or if you need to press a button. It is not going through an AI voice call tree.

It says its main function is to recognize if the call is related to a previous incident already registered. If it is, then the AI provides an update on the matter, otherwise it directs the caller to a human