Brian Merchant, writ­ing for Blood in the Machine, re­ports that peo­ple across the United States are dis­man­tling and de­stroy­ing Flock sur­veil­lance cam­eras, amid ris­ing pub­lic anger that the li­cense plate read­ers aid U. S. im­mi­gra­tion au­thor­i­ties and de­por­ta­tions.

Flock is the Atlanta-based sur­veil­lance startup val­ued at $7.5 bil­lion a year ago and a maker of li­cense plate read­ers. It has faced crit­i­cism for al­low­ing fed­eral au­thor­i­ties ac­cess to its mas­sive net­work of na­tion­wide li­cense plate read­ers and data­bases at a time when U. S. Immigration and Customs Enforcement is in­creas­ingly re­ly­ing on data to raid com­mu­ni­ties as part of the Trump ad­min­is­tra­tion’s im­mi­gra­tion crack­down.

Flock cam­eras al­low au­thor­i­ties to track where peo­ple go and when by tak­ing pho­tos of their li­cense plates from thou­sands of cam­eras lo­cated across the United States. Flock claims it does­n’t share data with ICE di­rectly, but re­ports show that lo­cal po­lice have shared their own ac­cess to Flock cam­eras and its data­bases with fed­eral au­thor­i­ties.

While some com­mu­ni­ties are call­ing on their cities to end their con­tracts with Flock, oth­ers are tak­ing mat­ters into their own hands.

Merchant re­ports in­stances of bro­ken and smashed Flock cam­eras in La Mesa, California, just weeks af­ter the city coun­cil ap­proved the con­tin­u­a­tion of Flock cam­eras de­ployed in the city, de­spite a clear ma­jor­ity of at­ten­dees fa­vor­ing their shut­down. A lo­cal re­port cited strong op­po­si­tion to the sur­veil­lance tech­nol­ogy, with res­i­dents rais­ing pri­vacy con­cerns.

Other cases of van­dal­ism have stretched from California and Connecticut to Illinois and Virginia. In Oregon, six li­cense plate-scan­ning cam­eras on poles were cut down and at least one spray-painted. A note left at the base of the sev­ered poles said, “Hahaha get wrecked ya sur­veilling fucks,” re­ports Merchant.

According to DeFlock, a pro­ject aimed at map­ping li­cense plate read­ers, there are close to 80,000 cam­eras across the United States. Dozens of cities have so far re­jected the use of Flock’s cam­eras, and some po­lice de­part­ments have since blocked fed­eral au­thor­i­ties from us­ing their re­sources.

A Flock spokesper­son did not say, when reached by TechCrunch, if the com­pany keeps track of how many cam­eras have been de­stroyed since be­ing de­ployed.

In a pri­vate ex­change with priests of the Diocese of Rome on Thursday, Pope Leo XIV re­sponded to four ques­tions, ad­vis­ing them on prayer, study, and priestly fra­ter­nity.

The off-cam­era mo­ment took place af­ter Leo gave a pub­lic speech to the priests, invit­ing them to “rekindle the fire” of their min­istry.

“The first priest to speak was a young man who asked the pope how the Gospel can be em­bod­ied in the world of young peo­ple,” ac­cord­ing to a priest pre­sent at the Feb. 19 meet­ing in the Vatican’s Paul VI Hall.

The priest told ACI Stampa, the Italian-language sis­ter ser­vice of EWTN News, that Leo’s an­swer to this ques­tion was: “First of all, what is needed is the wit­ness of the priest; and then, when meet­ing young peo­ple, they must broaden their hori­zons to reach as many young peo­ple as pos­si­ble. For this, it is nec­es­sary to re­dis­cover the value of com­mu­nion.”

Responding to a sec­ond ques­tion, the pope rec­om­mended know­ing well “the com­mu­nity in which one lives and works. It is nec­es­sary to know the re­al­ity well. To love your com­mu­nity, you must know it. Therefore, a real shared ef­fort is needed to un­der­stand it bet­ter and thus face to­gether all the chal­lenges that arise.”

“The pope also in­vited us to use our brains more and not ar­ti­fi­cial in­tel­li­gence [AI] to pre­pare hom­i­lies, as he now sees and hears hap­pen­ing,” the priest said. “And here the pope made a strong rec­om­men­da­tion re­gard­ing prayer: We priests must pray — re­main with the Lord, that is — not re­duce every­thing to the bre­viary or to a few brief mo­ments of prayer, but truly learn again to lis­ten to the Lord.”

The third ques­tion was more re­flec­tive: Today, as priests, we are un­able to re­joice in the suc­cess of an­other fel­low priest.

The pope re­sponded that “we are all hu­man, but we should set a good ex­am­ple, es­pe­cially the ex­am­ple of priestly fra­ter­nity.”

He dwelt at length on how to cul­ti­vate priestly friend­ship. The pope also re­minded them to con­tinue study­ing. “It must be on­go­ing study; we must al­ways stay up to date. But the fun­da­men­tal thing is to cul­ti­vate priestly friend­ship, priestly fra­ter­nity,” the priest from Rome said.

The fi­nal ques­tion con­cerned el­derly priests and their lone­li­ness. According to the priest, Leo’s re­sponse “reaffirmed the need for fra­ter­nity, for the joy of be­ing to­gether. We must give thanks, truly live grat­i­tude for the fact of be­ing priests, from the day of our or­di­na­tion every sin­gle day, and thank God for this great gift, and live the priest­hood with grat­i­tude. And here, a great deal of hu­mil­ity is also re­quired.”

“Personally, I was happy,” the priest con­cluded. “We greatly ap­pre­ci­ated the pope for a very, very con­crete speech.”

This story was first pub­lished by ACI Stampa, the Italian-language sis­ter ser­vice of EWTN News. It has been trans­lated and adapted by EWTN News English.

The lat­est up­date of Firefox, ver­sion 148, in­tro­duces a much-an­tic­i­pated “AI kill switch” fea­ture, al­low­ing users to dis­able AI func­tion­al­i­ties such as chat­bot prompts and AI-generated link sum­maries. Mozilla em­pha­sizes that once AI fea­tures are turned off, fu­ture up­dates will not over­ride this choice. This de­ci­sion re­flects the com­pa­ny’s new rev­enue-fo­cused strat­egy re­gard­ing AI in­te­gra­tions.

To dis­able AI fea­tures, users can nav­i­gate to Settings > AI Controls and tog­gle the ‘Block AI Enhancements’ op­tion. This will pre­vent any in-app no­ti­fi­ca­tions en­cour­ag­ing users to try out AI fea­tures, as well as re­move any pre­vi­ously down­loaded AI mod­els from the de­vice. For those who wish to main­tain some AI func­tion­al­i­ties, a se­lec­tive block­ing op­tion is avail­able, en­abling users to re­tain use­ful fea­tures like on-de­vice trans­la­tions while avoid­ing cloud-based ser­vices.

Beyond the AI kill switch, Firefox 148 of­fers users more con­trol over re­mote up­dates, al­low­ing them to opt out while still min­i­miz­ing data col­lec­tion. Users can set these pref­er­ences un­der Settings > Privacy & Settings > Firefox Data Collection.

The up­date also fo­cuses on en­hanc­ing core web plat­form ca­pa­bil­i­ties, in­clud­ing the in­te­gra­tion of the Trusted Types API and Sanitizer API to com­bat cross-site script­ing (XSS) is­sues. Additionally, Firefox 148 now in­cludes im­proved screen reader com­pat­i­bil­ity for math­e­mat­i­cal for­mu­las in PDFs, avail­abil­ity of Firefox Backup on Windows 10, and trans­la­tion ca­pa­bil­i­ties for Vietnamese and Traditional Chinese. New tab wall­pa­pers will also be fea­tured in new con­tainer tabs, along­side the ad­di­tion of Service worker sup­port for WebGPU.

For more de­tailed in­for­ma­tion on the up­date, users can re­fer to the of­fi­cial re­lease notes.

My old 2016 MacBook Pro has been col­lect­ing dust in a cab­i­net for some time now. The lap­top suf­fers from a “flexgate” prob­lem, and I don’t have any prac­ti­cal use for it. For quite some time, I’ve been think­ing about re­pur­pos­ing it as a guinea pig, to play with FreeBSD — an OS that I’d as­pired to play with for a long while, but had never had a real rea­son to.

During the re­cent hol­i­day sea­son, right af­ter FreeBSD 15 re­lease, I’ve fi­nally found time to set the lap­top up. Doing that I did­n’t plan, or even think, this may turn into a story about AI cod­ing.

2016 MacBook Pro mod­els use Broadcom BCM4350 Wi-Fi chip and FreeBSD does­n’t sup­port it na­tively. To have a work­ing Wi-Fi, a typ­i­cal sug­ges­tion on FreeBSD fo­rums, is to run wifi­box — a tiny Linux VM, with the PCI Wi-Fi de­vice in pass through, that al­lows Linux to man­age the de­vice through its br­cmf­mac dri­ver.

Brcmfmac is a Linux dri­ver (ISC li­cence) for set of FullMAC chips from Broadcom. The dri­ver of­floads the pro­cess­ing jobs, like 802.11 frame move­ment, WPA en­cryp­tion and de­cryp­tion, etc, to the firmware, which is run­ning in­side the chip. Meanwhile, the dri­ver and the OS do high-level man­age­ment work (ref Broadcom br­cmf­mac(PCIe) in Linux Wireless doc­u­men­ta­tion).

Say we want to build a na­tive FreeBSD ker­nel mod­ule for BCM4350. In the­ory, the sep­a­ra­tion of jobs be­tween the firmware and the dri­ver sounds per­fect. The “management” part of work is what FreeBSD al­ready does for other Wi-Fi de­vices it sup­ports. What’s left is to port some amount of ex­ist­ing “glue code” from the specifics of Linux to FreeBSD. If we ig­nore a lot of de­tails, the prob­lem does­n’t sound too com­pli­cated, right?

A level-zero idea, when one hears about “porting a bunch of ex­ist­ing code from A to B”, in 2026 is, of course, to use AI. So that was what I tried.

I cloned the br­cmf­mac sub­tree from Linux, and asked Claude Code to make it work for FreeBSD. FreeBSD al­ready has dri­vers that work through LinuxKPI — com­pat­i­bil­ity layer for run­ning Linux ker­nel dri­vers. So I specif­i­cally pointed Claude at the iwl­wifi dri­ver (a soft­mac dri­ver for Intel wire­less net­work card), ask­ing “do as they did it”. And, at first, this even looked like this can work — Claude told me so.

The mod­ule, in­deed, com­piled, but it did­n’t do any­thing. Because, of course: the VM, where we tested the mod­ule, did­n’t even have the hard­ware. After I set the PCI de­vice into the VM, and at­tempted to load the dri­ver against the chip, the chal­lenges started to pop up im­me­di­ately. The ker­nel pan­iced, and af­ter Claude fixed the pan­ics, it dis­cov­ered that “module did­n’t do any­thing”. Claude hon­estly tried to sift through the code, adding more and more #ifdef __FreeBSD__ wrap­pers here and there. It com­plained about miss­ing fea­tures in LinuxKPI. The mod­ule kept caus­ing pan­ics, and the agent kept build­ing FreeBSD-specific shims and call­backs, while warn­ing me that this pro­ject will be very com­pli­cated and messy.

After a num­ber of ses­sions, the diff, pro­duced by the agent, stared to look sig­nif­i­cantly larger than what I’d hoped it will be. Even worse, the dri­ver did­n’t look even close to be work­ing. This was right around time when Armin Ronacher posted about his ex­pe­ri­ence build­ing a game from scratch with Claude Opus and PI agent.

Besides the part that work­ing in Pi cod­ing agent feels more pro­duc­tive, than in Claude Code, the video got me think­ing that my ap­proach to the task was too straight­for­ward. The code of br­cmf­mac dri­ver is mod­er­ately large. The dri­ver sup­ports sev­eral gen­er­a­tions of Wi-Fi adap­tors, dif­fer­ent ca­pa­bil­i­ties, etc. But my im­me­di­ate task was very nar­row: one chip, only PCI, only Wi-Fi client.

Instead of con­tin­u­ing with the code, I spawned a fresh Pi ses­sion, and asked the agent to write a de­tailed spec­i­fi­ca­tion of how the br­cmf­mac dri­ver works, with the fo­cus on BCM4350 Wi-Fi chip. I ex­plic­itly set the au­di­ence for the spec­i­fi­ca­tion to be read­ers, who are tasked with im­ple­ment­ing the spec­i­fi­ca­tion in a clean-room en­vi­ron­ment. I asked the agent to ex­plain how things work “to the bits”. I added some high-level de­tails for how I wanted the spec­i­fi­ca­tion to be laid out, and let the agent go br­rrr.

After a cou­ple of rounds, the agent pro­duced me a “book of 11 chap­ters”, that hon­estly looked like a fine spec­i­fi­ca­tion

% ls –tree spec/

spec

├── 00-overview.md

├── 01-data-structures.md

├── 02-bus-layer.md

├── 03-protocol-layer.md

├── 04-firmware-interface.md

├── 05-event-handling.md

├── 06-cfg80211-operations.md

├── 07-initialization.md

├── 08-data-path.md

├── 09-firmware-commands.md

└── 10-structures-reference.md

Of course, one can’t just trust what AI has writ­ten.

To proof­read the spec I spawned a clean Pi ses­sions, and — for fun — asked Codex model, to read the spec­i­fi­ca­tion, and flag any places, where the text is­n’t aligned with the dri­ver’s code (“Source code is the ground truth. The spec needs to be ver­i­fied, and up­dated with any miss­ing or wrong de­tails”). The agent fol­lowed through and found sev­eral places to fix, and also pro­posed mul­ti­ple im­prove­ments.

Of course, one can’t just trust what AI has writ­ten, even if this was in a proof­read­ing ses­sion.

To dou­ble-proof­read the fixes I spawned an­other clean Pi ses­sions, ask­ing Opus model to ver­ify if what was pro­posed was aligned with how it works in the code of the dri­ver.

As a pro­cras­ti­na­tion ex­er­cise, I tried this loop with a cou­ple of cod­ing mod­els: Opus 4.5, Opus 4.6, Codex 5.2, Gemini 3 Pro pre­view. So far my ex­pe­ri­ence was that Gemini hal­lu­ci­nated the most. This was quite sad, given that the model it­self is­n’t too bad for sim­ple cod­ing tasks, and it is free for a lim­ited use.

Having a writ­ten spec­i­fi­ca­tion should have (in the­ory) ex­plained how a dri­ver’s code in­ter­acts with the firmware.

I started a fresh pro­ject, with noth­ing but the men­tioned “spec”, and prompted the Pi agent, that we were build­ing a brand new FreeBSD dri­ver for BCM4350 chip. I pointed the agent to the spec­i­fi­ca­tion, and asked it to ask me back about any im­por­tant de­ci­sions we must make, and de­tails we must out­line, be­fore jump­ing into “slopping the code”. The agent came back with ques­tions and de­ci­sion points, like “Will the dri­ver live in the ker­nels source-tree?”, “Will we write the code in C?”, “Will we rely on LinuxKPI?”, “What are our high-level mile­stones?”, etc. One in­flu­en­tial bit, that turned fairly pro­duc­tive mov­ing for­ward, was that I asked the agent to doc­u­ment all these de­ci­sion points in the pro­jec­t’s docs, and to ex­plic­itly ref­er­enced to these de­ci­sion docs in the pro­jec­t’s AGENTS.md.

It’s worth say­ing that, just like in any real pro­ject, not all de­ci­sions stayed to the end. For ex­am­ple,

Initially I asked the agent to build the dri­ver us­ing lin­uxkpi and lin­uxkpi_wlan. My naive think­ing was that, given the spec was writ­ten af­ter look­ing at Linux dri­ver’s code, it might be sim­pler for the agent, than build­ing the on top of the na­tive prim­i­tives. After a cou­ple of ses­sions, it did­n’t look like this was the case. I asked the agent to drop LinuxKPI from the code, and to refac­tor every­thing. The agent did it in one go, and up­dated the de­ci­sion doc­u­ment.

With spec­i­fi­ca­tion, docs and a plan, the work­flow process turned into a “boring rou­tine”. The agent had SSH ac­cess to both the build host, and a test­ing VM, that had been run­ning with the Wi-Fi PCI de­vice passed from the host. It me­thod­i­cally crunched through the back­log of its own mile­stones, it­er­at­ing over the code, build­ing and test­ing the mod­ule. Every time a mile­stone or a por­tion was fin­ished, I asked the agent to record the progress to the docs. Occasionally, an it­er­a­tion of the code crashed or hanged the VM. When this hap­pened, be­fore fix­ing the prob­lem, I asked — in a forked Pi’s ses­sion — to sum­ma­rize, in­ves­ti­gate and record the prob­lem for agen­t’s fu­ture-self.

After many low-in­volved ses­sions, I got a work­ing FreeBSD ker­nel mod­ule for the BCM4350 Wi-Fi chip. The mod­ule sup­ports Wi-Fi net­work scan­ning, 2.4GHz/5GHz con­nec­tiv­ity, WPA/WPA2 au­then­ti­ca­tion.

The source code is in repos­i­tory github.com/​narqo/​freebsd-br­cmf­mac. I did­n’t write any piece of code there. There are sev­eral known is­sues, which I will task the agent to re­solve, even­tu­ally. Meanwhile, I ad­vise against us­ing it for any­thing be­yond a study­ing ex­er­cise.

There is an ex­is­ten­tial dis­cus­sion on Hacker News, where the com­ments are clus­ter­ing around a cou­ple of points:

Really, this is­n’t the bat­tle I choose to par­tic­i­pate in. If there is an ex­pla­na­tion for how to prop­erly li­cense this type of code arte­fact, I can fol­low through.

The agent did­n’t put any li­cense for me, by de­fault. Choosing a li­cense was yet an­other de­ci­sion, that is doc­u­mented for the agent to fol­low, in the fu­ture it­er­a­tions. Today, the code in freebsd-br­cmf­mac uses ISC li­cense, be­cause this is what the orig­i­nal code of br­cmf­mac Linux dri­ver uses (e.g. see tor­valds/​linux/../​br­cmf­mac/​com­mon.c).

Is there a value when the dri­ver “isn’t done” yet?

In soft­ware en­gi­neer­ing, there aren’t many things that are “done”. We pro­duce code. Others find bugs, se­cu­rity vul­ner­a­bil­i­ties, cor­ner cases, and so on. We it­er­ate. AI cod­ing has­n’t changed these fun­da­men­tals — not by 2026, at least. Agents speeded up the part of pro­duc­ing code, just like other tool­ings have been speed­ing up the process of col­lab­o­rat­ing, find­ing bugs, etc.

Is there “value” in the dri­ver to­day? Probably not. Is there “value” in my out­dated and bro­ken MacBook? Not much. Was it in­sight­ful for me to walk the jour­ney from “claude can’t just take the code and port it” to “agent needs to plan, record, it­er­ate in or­der to progress” (and do­ing that did­n’t mean that I had to write a ton of mark­down es­says my­self)? Yes.

This ar­ti­cle has been re­viewed ac­cord­ing to Science X’s editorial process

and poli­cies. Editors have high­lighted the fol­low­ing at­trib­utes while en­sur­ing the con­tent’s cred­i­bil­ity:

This ar­ti­cle has been re­viewed ac­cord­ing to Science X’s editorial process

and poli­cies. Editors have high­lighted the fol­low­ing at­trib­utes while en­sur­ing the con­tent’s cred­i­bil­ity:

A pro­tein lurk­ing around in the blood can help with the ac­cu­rate di­ag­no­sis of Alzheimer’s dis­ease. In a re­cent study, re­searchers from Spain in­ves­ti­gated how blood-based bio­mark­ers, such as a pro­tein called p-tau217, af­fect both the clin­i­cal di­ag­no­sis of Alzheimer’s and neu­rol­o­gists’ con­fi­dence in their di­ag­no­sis.

After fol­low­ing 200 con­sec­u­tive new pa­tients aged 50 and older who pre­sented with cog­ni­tive symp­toms, they found that a sim­ple blood test mea­sur­ing p-tau217 sig­nif­i­cantly im­proved di­ag­nos­tic ac­cu­racy in rou­tine clin­i­cal prac­tice.

When re­ly­ing solely on stan­dard clin­i­cal eval­u­a­tion, doc­tors cor­rectly di­ag­nosed Alzheimer’s in 75.5% of cases, but when in­cor­po­rat­ing blood test re­sults, di­ag­nos­tic ac­cu­racy in­creased to 94.5%. The find­ings are pub­lished in the Journal of Neurology.

Phosphorylated tau, or p-tau217, is a pro­tein that nat­u­rally oc­curs in the brain and helps keep neu­rons, the cells that carry sig­nals, sta­ble and healthy. The trou­ble be­gins when this pro­tein be­comes ab­nor­mally phos­pho­ry­lated and clumps to­gether, form­ing tan­gles that dis­rupt com­mu­ni­ca­tion be­tween brain cells. Over time, this dam­age can im­pact brain func­tion and lead to neu­rode­gen­er­a­tive con­di­tions such as Alzheimer’s dis­ease.

While p-tau217 is not con­sid­ered the di­rect cause of Alzheimer’s, el­e­vated lev­els in the blood are now rec­og­nized as one of the most ac­cu­rate early warn­ing signs of the dis­ease.

In many parts of the world, the pop­u­la­tion is rapidly ag­ing and so is the num­ber of age-re­lated dis­eases like Alzheimer’s and de­men­tia. However, most of the stan­dard ways to di­ag­nose Alzheimer’s to­day, like ex­pen­sive brain scans or in­va­sive spinal taps, are costly, un­com­fort­able, and of­ten hard for pa­tients to ac­cess.

Scientists have long known that p-tau217 is a re­li­able bio­marker for de­tect­ing early signs of Alzheimer’s, but most of these data come from highly con­trolled re­search labs. How well it works in every­day med­ical clin­ics and whether it truly boosts doc­tors’ con­fi­dence in their di­ag­noses re­main less ex­plored.

In this study, the re­searchers fo­cused on both these fac­tors in real-world med­ical set­tings. They fol­lowed pa­tients who came in for gen­eral neu­rol­ogy con­sul­ta­tions and to a spe­cial­ized cog­ni­tive neu­rol­ogy unit with cog­ni­tive symp­toms. Clinicians noted their ini­tial di­ag­no­sis and how con­fi­dent they felt about it, then re­viewed the p-tau217 blood test re­sults and recorded any changes.

The team found that af­ter re­view­ing the p-tau217 re­sults, di­ag­nos­tic ac­cu­racy jumped by 19%. For about one in four pa­tients, the blood test prompted doc­tors to change their di­ag­no­sis. Some peo­ple who were first be­lieved to have Alzheimer’s turned out to have a dif­fer­ent con­di­tion, while oth­ers who were thought to be ex­pe­ri­enc­ing nor­mal ag­ing were cor­rectly iden­ti­fied as hav­ing Alzheimer’s. Also, the doc­tors’ con­fi­dence in their di­ag­noses rose from an av­er­age of 6.90 to 8.49 on a 10-point scale.

The p-tau217 tests proved to be ef­fec­tive across every stage of cog­ni­tive de­cline, be it early mem­ory com­plaints or late-stage de­cline such as de­men­tia. The find­ings show that this blood test could pro­vide a more ac­cu­rate and less in­va­sive way to di­ag­nose Alzheimer’s, po­ten­tially im­prov­ing care for mil­lions of peo­ple.

Build, pro­gram, and sim­u­late hard­ware in the browser. Bring your work­shop to the web.

The car wash test is the sim­plest AI rea­son­ing bench­mark that nearly every model fails, in­clud­ing Claude Sonnet 4.5, GPT-5.1, Llama, and Mistral.

The ques­tion is sim­ple: “I want to wash my car. The car wash is 50 me­ters away. Should I walk or drive?”

Obviously, you need to drive. The car needs to be at the car wash.

The ques­tion has been mak­ing the rounds on­line as a sim­ple logic test, the kind any hu­man gets in­stantly, but most AI mod­els don’t. We de­cided to run it prop­erly: 53 mod­els through Opper’s LLM gate­way, no sys­tem prompt, forced choice be­tween “drive” or “walk” with a rea­son­ing field. First once per model, then 10 times each to test con­sis­tency.

On a sin­gle call, only 11 out of 53 mod­els got it right. 42 said walk.

The mod­els that passed the car wash test:

Across en­tire model fam­i­lies, only one model per provider got it right: Opus 4.6 for Anthropic, GPT-5 for OpenAI. All Llama and Mistral mod­els failed.

The wrong an­swers were all the same: “50 me­ters is a short dis­tance, walk­ing is more ef­fi­cient, saves fuel, bet­ter for the en­vi­ron­ment.” Correct rea­son­ing about the wrong prob­lem. The mod­els fix­ate on the dis­tance and com­pletely miss that the car it­self needs to get to the car wash.

The fun­ni­est part: Perplexity’s Sonar and Sonar Pro got the right an­swer for com­pletely wrong rea­sons. They cited EPA stud­ies and ar­gued that walk­ing burns calo­ries which re­quires food pro­duc­tion en­ergy, mak­ing walk­ing more pol­lut­ing than dri­ving 50 me­ters. Right an­swer, in­sane rea­son­ing.

Getting it right once is easy. But can they do it re­li­ably? We reran every model 10 times, 530 API calls to­tal.

The re­sults got worse. Of the 11 mod­els that passed the sin­gle-run test, only 5 could do it con­sis­tently.

These are the only mod­els that an­swered cor­rectly every sin­gle time across 10 runs.

Both get it right most of the time. But in pro­duc­tion, an 80% suc­cess rate on ba­sic rea­son­ing means 1 in 5 API calls re­turns the wrong an­swer.

OpenAI’s flag­ship model fails this 30% of the time. When it gets it right, the rea­son­ing is con­cise: “You need the car at the car wash to wash it, so drive the short 50 me­ters.” When it gets it wrong, it writes about fuel ef­fi­ciency.

All Claude mod­els ex­cept Opus 4.6, all Llama, all Mistral, GPT-4o, GPT-4.1, GPT-5-mini, GPT-5-nano, GPT-5.1, GPT-5.2, Grok-3, Grok-4-1 non-rea­son­ing, Sonar, Sonar Reasoning Pro, DeepSeek v3.1, Kimi K2 Instruct.

Some mod­els that looked cor­rect on the first try turned out to be flukes.

Sonar went from cor­rect to 0/10. It still writes the same 200-word es­say about food pro­duc­tion en­ergy chains and EPA stud­ies in every sin­gle run, it just flips the con­clu­sion to “walk” every time now. Same rea­son­ing, op­po­site an­swer.

Kimi K2.5 went from cor­rect to a per­fect 5/5 tie. Literally can­not de­cide.

Sonar Pro went from cor­rect to 4/10. When it says “drive,” it’s be­cause of calo­rie-emis­sion math, not be­cause the car needs to be there.

And one model went the other di­rec­tion: GLM-4.7 went from wrong on the sin­gle run to 6/10. It was un­lucky the first time. Still not re­li­able, but the ca­pa­bil­ity is clearly in the weights.

The most com­mon push­back on the car wash test: “Humans would fail this too.”

Fair point. We did­n’t have data ei­ther way. So we part­nered with Rapidata to find out. They ran the ex­act same ques­tion with the same forced choice be­tween “drive” and “walk,” no ad­di­tional con­text, past 10,000 real peo­ple through their hu­man feed­back plat­form.

Turns out GPT-5 (7/10) an­swered about as re­li­ably as the av­er­age hu­man (71.5%) in this test. Humans still out­per­form most AI mod­els with this ques­tion, but to be fair I ex­pected a far higher “drive” rate.

That 71.5% is still a higher suc­cess rate than 48 out of 53 mod­els tested. Only the five 10/10 mod­els and the two 8/10 mod­els out­per­form the av­er­age hu­man. Everything be­low GPT-5 per­forms worse than 10,000 peo­ple given two but­tons and no time to think.

Thanks to Jason Corkill and the Rapidata team for mak­ing this hap­pen on short no­tice.

GLM-4.7 Flash on one of its cor­rect runs: “Walking would re­quire phys­i­cally push­ing or car­ry­ing the car, which is im­prac­ti­cal and im­pos­si­ble.” Probably the best ar­tic­u­la­tion of the ac­tual prob­lem from any model.

Claude Sonnet 4.5 wrote: “The only sce­nario where dri­ving might make sense is if you need to drive the car into the car wash any­way for an au­to­matic wash” and then picked walk. It saw the an­swer and re­jected it.

Claude Opus 4.5 sug­gested you should “walk to the car wash, then drive your car through the wash.” The car is at home.

Gemini 2.5 Pro when it gets it right: “You want to wash your car. The car needs to be at the car wash for this to hap­pen. Therefore, you must drive it there, re­gard­less of the short dis­tance.” When it gets it wrong: “50 me­ters is a very short dis­tance that would take less than a minute to walk.” Same model, same prompt.

This is a triv­ial ques­tion. There’s one cor­rect an­swer and the rea­son­ing to get there takes one step: the car needs to be at the car wash, so you drive.

Out of 53 mod­els, only 5 can do this re­li­ably. 15 more can some­times get there but un­pre­dictably. The re­main­ing 33 never get it right.

The pat­tern across 530 API calls shows three tiers of fail­ure:

Models that never get it right (33/53): These mod­els have learned “short dis­tance = walk” as a heuris­tic and can’t over­ride it with con­tex­tual rea­son­ing. The cor­rect an­swer is­n’t ac­ces­si­ble to them.

Models that some­times get it right (15/53): The ca­pa­bil­ity ex­ists but com­petes with the dis­tance heuris­tic. On any given call, ei­ther path might win. This is the most dan­ger­ous cat­e­gory for pro­duc­tion AI. The model passes dur­ing eval­u­a­tion and then fails un­pre­dictably in de­ploy­ment. Picking the right model is­n’t enough on its own.

Models that al­ways get it right (5/53): The con­tex­tual rea­son­ing con­sis­tently over­rides the heuris­tic.

This is a toy prob­lem with one log­i­cal step. Real-world AI ap­pli­ca­tions in­volve chains of rea­son­ing far more com­plex than this. If 90% of mod­els can’t re­li­ably han­dle “the car needs to be at the car wash,” how do they han­dle ac­tual busi­ness logic, multi-step work­flows, or am­bigu­ous edge cases in pro­duc­tion?

The car wash test is a zero-con­text prob­lem by de­sign. No sys­tem prompt, no ex­am­ples, just a raw ques­tion. That’s what makes it use­ful as a bench­mark. But the fail­ure mode is telling: mod­els don’t fail be­cause they lack the ca­pa­bil­ity. They fail be­cause the heuris­tic (“short dis­tance = walk”) wins over the rea­son­ing (“the car needs to be there”).

Context en­gi­neer­ing is one way to shift that bal­ance. When you pro­vide a model with struc­tured ex­am­ples, do­main pat­terns, and rel­e­vant con­text at in­fer­ence time, you give it in­for­ma­tion that can help over­ride generic heuris­tics with task-spe­cific rea­son­ing.

We’ve seen this in prac­tice. In a sep­a­rate ex­per­i­ment, we took a small open-weight model that failed an agent-build­ing task and added cu­rated ex­am­ples through Opper’s con­text fea­tures. It matched the out­put qual­ity of a fron­tier model at 98.6% lower cost, with­out chang­ing the model it­self.

The car wash prob­lem is sim­ple enough that the top 5 mod­els solve it with­out help. But most pro­duc­tion tasks aren’t that clean. They in­volve am­bi­gu­ity, do­main knowl­edge, and con­straints that aren’t ob­vi­ous from the prompt alone. For those, the gap be­tween “sometimes gets it right” and “always gets it right” is of­ten a con­text prob­lem.

All 53 mod­els were tested through Opper’s LLM gate­way us­ing the same prompt: “I want to wash my car. The car wash is 50 me­ters away. Should I walk or drive?” No sys­tem prompt. Forced choice be­tween “drive” and “walk” with a rea­son­ing field. The sin­gle-run test was one call per model. The 10-run retest was 10 iden­ti­cal calls per model (530 to­tal), no cache / mem­ory. Every call was traced and logged through Opper, so we could in­spect each mod­el’s rea­son­ing.

The hu­man base­line was col­lected through Rapidata, us­ing the same ques­tion and forced choice for­mat across 10,000 par­tic­i­pants.

Full data from every run is avail­able for down­load:

About us Blog Join the wait­list

We are re­leas­ing Steerling-8B, the first in­ter­pretable model that can trace any to­ken it gen­er­ates to its in­put con­text, con­cepts a hu­man can un­der­stand, and its train­ing data. Trained on 1.35 tril­lion to­kens, the model achieves down­stream per­for­mance within range of mod­els trained on 2–7× more data. Steerling-8B un­locks sev­eral ca­pa­bil­i­ties which in­clude sup­press­ing or am­pli­fy­ing spe­cific con­cepts at in­fer­ence time with­out re­train­ing, train­ing data prove­nance for any gen­er­ated chunk, and in­fer­ence-time align­ment via con­cept con­trol, re­plac­ing thou­sands of safety train­ing ex­am­ples with ex­plicit con­cept-level steer­ing.

For the first time, a lan­guage model, at the 8-billion-parameter scale, can ex­plain every to­ken it pro­duces in three key ways. More specif­i­cally, for any group of out­put to­kens that Steerling gen­er­ates, we can trace these to­kens to:

[Concepts] hu­man-un­der­stand­able top­ics in the mod­el’s rep­re­sen­ta­tions, and

We are re­leas­ing the weights of a base model trained on 1.35T to­kens as well as com­pan­ion code to in­ter­act and play with the model.

Below we show Steerling-8B gen­er­at­ing text from a prompt across var­i­ous cat­e­gories. You can se­lect an ex­am­ple, then click on any high­lighted chunk of the out­put. The panel be­low will up­date to show:

Input Feature at­tri­bu­tion: which to­kens in the in­put prompt strongly in­flu­enced that chunk.

Concept at­tri­bu­tion: the ranked list of con­cepts, both tone (e.g. an­a­lyt­i­cal, clin­i­cal) and con­tent (e.g. Genetic al­ter­ation method­olo­gies), that the model routed through to pro­duce that chunk.

Training data at­tri­bu­tion: how the con­cepts in that chunk dis­trib­ute across train­ing sources (ArXiv, Wikipedia, FLAN, etc.), show­ing where in the train­ing data the mod­el’s knowl­edge orig­i­nates.

Steerling is built on a causal dis­crete dif­fu­sion model back­bone, which lets us steer gen­er­a­tion across multi-to­ken to­kens rather than only at the next-to­ken. The key de­sign choice is de­com­pos­ing the mod­el’s em­bed­dings into three ex­plicit path­ways: ~33K su­per­vised “known” con­cepts, ~100K “discovered” con­cepts the model learns on its own, and a resid­ual that cap­tures what­ever re­mains.

We then con­strain the model with train­ing loss func­tions that en­sure the model routes sig­nal through con­cepts with­out a fun­da­men­tal trade­off with per­for­mance. The con­cepts feed into log­its through a lin­ear path, every pre­dic­tion de­com­poses ex­actly into per-con­cept con­tri­bu­tions, and we can edit those con­tri­bu­tions at in­fer­ence time with­out re­train­ing. For the full ar­chi­tec­ture, train­ing ob­jec­tives, and scal­ing analy­sis, see Scaling Interpretable Models to 8B.

Despite be­ing trained on sig­nif­i­cantly fewer com­pute than com­pa­ra­ble mod­els, Steerling-8B achieves com­pet­i­tive per­for­mance across stan­dard bench­marks. The fig­ure be­low shows av­er­age per­for­mance (across 7 bench­marks) ver­sus ap­prox­i­mate train­ing FLOPs on a log scale, with ver­ti­cal lines mark­ing mul­ti­ples of Steerling’s com­pute bud­get.

In the pre­vi­ous up­date, we shared sev­eral ways that as­sess how in­ter­pretable a mod­el’s rep­re­sen­ta­tions are. Here we pro­vide an­other met­ric that gives in­sight into the mod­el’s use of its con­cepts. On a held-out val­i­da­tion set, over 84% of to­ken-level con­tri­bu­tion comes from the con­cept mod­ule: the model is not just us­ing the resid­ual to make its pre­dic­tions. This mat­ters for con­trol: if the mod­el’s pre­dic­tions gen­uinely flow through con­cepts, then edit­ing those con­cepts at in­fer­ence time ac­tu­ally changes what the model does rather than nudg­ing a side chan­nel while the real work hap­pens else­where.

A use­ful check is what hap­pens when we re­move the resid­ual path­way. On sev­eral LM Harness tasks, drop­ping the resid­ual has only a small ef­fect, which sug­gests the mod­el’s pre­dic­tive sig­nal is largely routed through con­cepts rather than hid­den “everything-else” chan­nels.

Finally, Steerling can de­tect known con­cepts in text with 96.2% AUC on a held-out val­i­da­tion dataset.

In the com­ing weeks, we’ll be re­leas­ing deep dives on each of these ca­pa­bil­i­ties:

* Concept dis­cov­ery: what did Steerling learn that we did­n’t teach it? We’ll open up the dis­cov­ered con­cept space and show struc­ture that sur­prised us.

* Alignment with­out fine-tun­ing: re­place thou­sands of safety train­ing ex­am­ples with a hand­ful of con­cept-level in­ter­ven­tions.

* Memorization & train­ing data val­u­a­tion: trace any gen­er­a­tion back to the train­ing data that pro­duced it, and as­sign value to in­di­vid­ual data sources.

* The case for in­her­ent in­ter­pretabil­ity: what do you gain when in­ter­pretabil­ity is de­signed in from the start, and what do you miss when it’s bolted on af­ter the fact?

We’ll cover each of these in de­tail in up­com­ing posts, with quan­ti­ta­tive eval­u­a­tions and de­ploy­ment-ori­ented case stud­ies.

LLMs don’t—and can’t—do every­thing. What they do is very im­pres­sive—and use­ful. It’s broad. And in many ways it’s hu­man-like. But it’s not pre­cise. And in the end it’s not about deep com­pu­ta­tion.

So how can we sup­ple­ment LLM foun­da­tion mod­els? We need a foun­da­tion tool: a tool that’s broad and gen­eral and does what LLMs them­selves don’t: pro­vides deep com­pu­ta­tion and pre­cise knowl­edge.

And, con­ve­niently enough, that’s ex­actly what I’ve been build­ing for the past 40 years! My goal with Wolfram Language has al­ways been to make every­thing we can about the world com­putable. To bring to­gether in a co­her­ent and uni­fied way the al­go­rithms, the meth­ods and the data to do pre­cise com­pu­ta­tion when­ever it’s pos­si­ble. It’s been a huge un­der­tak­ing, but I think it’s fair to say it’s been a hugely suc­cess­ful one—that’s fu­eled count­less dis­cov­er­ies and in­ven­tions (including my own) across a re­mark­able range of ar­eas of sci­ence, tech­nol­ogy and be­yond.

But now it’s not just hu­mans who can take ad­van­tage of this tech­nol­ogy; it’s AIs—and in par­tic­u­lar LLMs—as well. LLM foun­da­tion mod­els are pow­er­ful. But LLM foun­da­tion mod­els with our foun­da­tion tool are even more so. And with the ma­tur­ing of LLMs we’re fi­nally now in a po­si­tion to pro­vide to LLMs ac­cess to Wolfram tech in a stan­dard, gen­eral way.

It is, I be­lieve, an im­por­tant mo­ment of con­ver­gence. My con­cept over the decades has been to build very broad and gen­eral tech­nol­ogy—which is now a per­fect fit for the breadth of LLM foun­da­tion mod­els. LLMs can call spe­cific spe­cial­ized tools, and that will be use­ful for plenty of spe­cific spe­cial­ized pur­poses. But what Wolfram Language uniquely rep­re­sents is a gen­eral tool—with gen­eral ac­cess to the great power that pre­cise com­pu­ta­tion and knowl­edge bring.

But there’s ac­tu­ally also much more. I de­signed Wolfram Language from the be­gin­ning to be a pow­er­ful medium not only for do­ing com­pu­ta­tion but also for rep­re­sent­ing and think­ing about things com­pu­ta­tion­ally. I’d al­ways as­sumed I was do­ing this for hu­mans. But it now turns out that AIs need the same things—and that Wolfram Language pro­vides the per­fect medium for AIs to “think” and “reason” com­pu­ta­tion­ally.

There’s an­other point as well. In its ef­fort to make as much as pos­si­ble com­putable, Wolfram Language not only has an im­mense amount in­side, but also pro­vides a uniquely uni­fied hub for con­nect­ing to other sys­tems and ser­vices. And that’s part of why it’s now pos­si­ble to make such an ef­fec­tive con­nec­tion be­tween LLM foun­da­tion mod­els and the foun­da­tion tool that is the Wolfram Language.

On January 9, 2023, just weeks af­ter ChatGPT burst onto the scene, I posted a piece en­ti­tled “Wolfram|Alpha as the Way to Bring Computational Knowledge Superpowers to ChatGPT”. Two months later we re­leased the first Wolfram plu­gin for ChatGPT (and in be­tween I wrote what quickly be­came a rather pop­u­lar lit­tle book en­ti­tled What Is ChatGPT Doing … and Why Does It Work?). The plu­gin was a mod­est but good start. But at the time LLMs and the ecosys­tem around them weren’t re­ally ready for the big­ger story.

Would LLMs even in the end need tools at all? Or—despite the fun­da­men­tal is­sues that seemed at least to me sci­en­tif­i­cally rather clear right from the start—would LLMs some­how mag­i­cally find a way to do deep com­pu­ta­tion them­selves? Or to guar­an­tee to get pre­cise, re­li­able re­sults? And even if LLMs were go­ing to use tools, how would that process be en­gi­neered, and what would the de­ploy­ment model for it be?

Three years have now passed, and much has clar­i­fied. The core ca­pa­bil­i­ties of LLMs have come into bet­ter fo­cus (even though there’s a lot we still don’t know sci­en­tif­i­cally about them). And it’s be­come much clearer that—at least for the modal­i­ties LLMs cur­rently ad­dress—most of the growth in their prac­ti­cal value is go­ing to have to do with how they are har­nessed and con­nected. And this un­der­stand­ing high­lights more than ever the broad im­por­tance of pro­vid­ing LLMs with the foun­da­tion tool that our tech­nol­ogy rep­re­sents.

And the good news is that there are now stream­lined ways to do this—us­ing pro­to­cols and meth­ods that have emerged around LLMs, and us­ing new tech­nol­ogy that we’ve de­vel­oped. The tighter the in­te­gra­tion be­tween foun­da­tion mod­els and our foun­da­tion tool, the more pow­er­ful the com­bi­na­tion will be. Ultimately it’ll be a story of align­ing the pre-train­ing and core en­gi­neer­ing of LLMs with our foun­da­tion tool. But an ap­proach that’s im­me­di­ately and broadly ap­plic­a­ble to­day—and for which we’re re­leas­ing sev­eral new prod­ucts—is based on what we call com­pu­ta­tion-aug­mented gen­er­a­tion, or CAG.

The key idea of CAG is to in­ject in real time ca­pa­bil­i­ties from our foun­da­tion tool into the stream of con­tent that LLMs gen­er­ate. In tra­di­tional re­trieval-aug­mented gen­er­a­tion, or RAG, one is in­ject­ing con­tent that has been re­trieved from ex­ist­ing doc­u­ments. CAG is like an in­fi­nite ex­ten­sion of RAG, in which an in­fi­nite amount of con­tent can be gen­er­ated on the fly—us­ing com­pu­ta­tion—to feed to an LLM. Internally, CAG is a some­what com­plex piece of tech­nol­ogy that has taken a long time for us to de­velop. But in its de­ploy­ment it’s some­thing that we’ve made easy to in­te­grate into ex­ist­ing LLM-related sys­tems and work­flows. And to­day we’re launch­ing it, so that go­ing for­ward any LLM sys­tem—and LLM foun­da­tion model—can count on be­ing able to ac­cess our Foundation Tool, and be­ing able to sup­ple­ment their ca­pa­bil­i­ties with the su­per­power of pre­cise, deep com­pu­ta­tion and knowl­edge.

Today we’re launch­ing three pri­mary meth­ods for ac­cess­ing our Foundation Tool, all based on com­pu­ta­tion-aug­mented gen­er­a­tion (CAG), and all lever­ag­ing our rather huge soft­ware en­gi­neer­ing tech­nol­ogy stack.

Immediately call our Foundation Tool from within any MCP-compatible LLM-based sys­tem. Most con­sumer LLM-based sys­tems now sup­port MCP, mak­ing this ex­tremely easy to set up. Our main MCP Service is a web API, but there’s also a ver­sion that can use a lo­cal Wolfram Engine.

A one-stop-shop “universal agent” com­bin­ing an LLM foun­da­tion model with our Foundation Tool. Set up as a drop-in re­place­ment for tra­di­tional LLM APIs.

Direct fine-grained ac­cess to Wolfram tech for LLM sys­tems, sup­port­ing op­ti­mized, cus­tom in­te­gra­tion into LLM sys­tems of any scale. (All Wolfram tech is avail­able in both hosted and on-premise form.)

For fur­ther in­for­ma­tion on ac­cess and in­te­gra­tion op­tions, con­tact our Partnerships group »

A minute-by-minute re­con­struc­tion of the mas­sacre by Earshot and Forensic Architecture found Israeli sol­diers fired over 900 bul­lets at the aid work­ers, killing 15. Drop Site is a reader-funded, in­de­pen­dent news out­let. Without your sup­port, we can’t op­er­ate. Please con­sider be­com­ing a paid sub­scriber or mak­ing a 501(c)(3) tax-de­ductible do­na­tion to­day.Fu­ner­als held at Nasser Hospital in Khan Yunis, in south­ern Gaza, for aid work­ers from the Palestinian Red Crescent who were killed in an Israeli at­tack in Tel al-Sul­tan. March 31, 2025. Photo by Hani Alshaer/Anadolu via Getty Images.Israeli sol­diers fired nearly a thou­sand bul­lets dur­ing the mas­sacre of 15 Palestinian aid work­ers in south­ern Gaza on March 23, 2025—with at least eight shots fired at point blank range—ac­cord­ing to a joint in­ves­ti­ga­tion by the in­de­pen­dent re­search groups Earshot and Forensic Architecture. The re­port, based on eye­wit­ness tes­ti­mony and au­dio and vi­sual analy­sis, shows that a num­ber of aid work­ers were ex­e­cuted and that at least one was shot from as close as one me­ter away.In Tel al-Sul­tan that day, Israel killed eight aid work­ers with the Palestine Red Crescent Society (PRCS), six from Palestinian Civil Defense, and a UN re­lief agency staffer. It im­me­di­ately trig­gered in­ter­na­tional con­dem­na­tion and was de­scribed as “one of the dark­est mo­ments” of the war by PRCS.The Israeli mil­i­tary was forced to change its story about the am­bush sev­eral times, fol­low­ing the dis­cov­ery of the bod­ies in a mass grave, along with their flat­tened ve­hi­cles, and the emer­gence of video and au­dio record­ings taken by the aid work­ers. An in­ter­nal mil­i­tary in­quiry ul­ti­mately did not rec­om­mend any crim­i­nal ac­tion against the army units re­spon­si­ble for the in­ci­dent.The re­port by Earshot and Forensic Architecture re­con­structs, minute by minute, how the mas­sacre un­folded. Using video and au­dio record­ings from the in­ci­dent, open-source im­ages and videos, satel­lite im­agery, so­cial me­dia posts, and other ma­te­ri­als, as well as in-depth in­ter­views with two sur­vivors of the at­tack, the groups were able to dig­i­tally re­con­struct the scene and events sur­round­ing the mas­sacre.Is­raeli sol­diers am­bushed and sub­jected Palestinian aid work­ers to a near con­tin­u­ous as­sault for over two hours even though the sol­diers never came un­der fire.At least 910 gun­shots were doc­u­mented across three video and au­dio record­ings of the at­tack. The vast ma­jor­ity of these gun­shots, at least 844, were fired over just five min­utes and 30 sec­onds.At least 93% of the gun­shots recorded in the first min­utes of the at­tack were fired di­rectly to­wards the emer­gency ve­hi­cles and aid work­ers by Israeli sol­diers. During this time, at least five shoot­ers fired si­mul­ta­ne­ously. Witness tes­ti­monies sug­gest as many as 30 sol­diers were pre­sent in the area.Is­raeli sol­diers were ini­tially po­si­tioned on an el­e­vated sand­bank by the road, with no ob­struc­tions lim­it­ing their line of sight. The emer­gency lights and mark­ings of the vic­tims’ ve­hi­cles would have been clearly vis­i­ble to the sol­diers at the time of the at­tacks.Is­raeli sol­diers first main­tained fixed fir­ing po­si­tions from the el­e­vated sand­bank, then walked to­ward the aid work­ers while con­tin­u­ing to shoot. Upon reach­ing the aid work­ers, the sol­diers moved be­tween them and the ve­hi­cles and ex­e­cuted some of the aid work­ers at point blank range, as close as one me­ter away.In the im­me­di­ate af­ter­math of the at­tack, the Israeli mil­i­tary con­ducted ex­ten­sive earth­works at the site. In the days and weeks that fol­lowed, the area was fur­ther trans­formed by the Israeli mil­i­tary’s con­struc­tion of the “Morag Corridor,” a se­cu­rity zone split­ting the south­ern Gaza Strip, and the erec­tion of an aid dis­tri­b­u­tion site op­er­ated by the Israeli- and U.S.-backed Gaza Humanitarian Foundation.“This seems to be a very well doc­u­mented case us­ing a num­ber of forms of cred­i­ble ev­i­dence that are cross ref­er­enced,” Katherine Gallagher, a se­nior staff at­tor­ney at the Center for Constitutional Rights, told Drop Site af­ter re­view­ing a de­tailed sum­mary of the in­ves­ti­ga­tion. “It pre­sents a very com­pelling case, and hon­estly, a very dev­as­tat­ing one.”The Israeli mil­i­tary did not re­spond to spe­cific in­quiries from Drop Site and in­stead pointed to the find­ings of an in­ter­nal in­ves­ti­ga­tion pub­lished on April 20 that found “the in­ci­dent oc­curred in a hos­tile and dan­ger­ous com­bat zone, un­der a wide­spread threat to the op­er­at­ing troops.” It also “found no ev­i­dence to sup­port claims of ex­e­cu­tion,” which it called “blood li­bels and false ac­cu­sa­tions against IDF sol­diers.”The joint re­port will be re­leased February 24 at a gath­er­ing at British par­lia­ment in Westminster hosted by the British Palestinian Committee with Earshot, Forensic Architecture, and the in­ter­na­tional hu­man­i­tar­ian law co­or­di­na­tor for PRCS, Dana Abu Koash. The full re­port is avail­able here.On March 23, 2025 at 3:52 a.m., PRCS dis­patched two am­bu­lances from two dif­fer­ent ar­eas to the scene of an Israeli airstrike in Al-Hashashin, an area near Rafah. Israel had re­sumed its scorched earth bomb­ing cam­paign on Gaza a few days ear­lier af­ter aban­don­ing the January 2025 cease­fire agree­ment.The at­tack on the aid work­ers be­gan at ap­prox­i­mately 4:00 a.m. when one of the am­bu­lances dri­ving along Gush Katif road in Al-Hashashin came un­der Israeli fire. The ve­hi­cle had its emer­gency lights turned on at the time. Mustafa Khafaja, who was dri­ving, lost con­trol of the ve­hi­cle, which veered left off the road and stopped near an elec­tric­ity pole. Khafaja and his col­league, Ezz El-Din Shaat, who was in the pas­sen­ger seat, were both killed. A third PRCS worker, Munther Abed, who was in the back of the ve­hi­cle, threw him­self to the floor of the van and sur­vived.Af­ter the shoot­ing stopped, Israeli sol­diers ap­proached the am­bu­lance and dragged Abed out of the car, beat him, and de­tained him at a nearby pit. Sometime later, two Palestinian civil­ians—a fa­ther and son from the Bardawil fam­ily—were also de­tained and brought to the pit. The Israeli sol­diers then took the three de­tainees to an el­e­vated area be­hind a tall con­crete struc­ture some 38 to 48 me­ters south­east of the am­bu­lance, where an ad­di­tional group of Israeli sol­diers were po­si­tioned.Still from the sit­u­ated tes­ti­mony with Munther Abed re­count­ing the lo­ca­tion of the pit and the area be­hind the tall con­crete struc­ture where he was taken when de­tained by Israeli sol­diers. (Forensic Architecture, 2026).By 4:35 a.m., the sec­ond am­bu­lance, hav­ing com­pleted its mis­sion in Al-Hashashin, was dis­patched to search for the first am­bu­lance, which had lost con­tact with PRCS head­quar­ters at 3:55 a.m. The sec­ond am­bu­lance was joined by two more PRCS am­bu­lances, one be­long­ing to Civil Defense, and a Civil Defense fire truck. The five-ve­hi­cle res­cue con­voy ar­rived at the scene of the at­tack of the first am­bu­lance shortly af­ter 5:00 a.m. All ve­hi­cles were clearly marked and had their emer­gency lights turned on.The po­si­tion of each am­bu­lance as the shoot­ing be­gan. (Forensic Architecture, 2026)A PRCS worker in one of the am­bu­lances, Refaat Radwan, be­gan film­ing on his phone as they drove to the site. His re­cov­ered videos as well as record­ings of phone calls by two other aid work­ers at the scene to PRCS dis­patch pro­vided cru­cial ev­i­dence of the mas­sacre. Forensic Architecture and Earshot’s analy­sis of the record­ings cor­rob­o­rated eye­wit­ness tes­ti­mony on the po­si­tions and move­ments of the Israeli sol­diers through­out the at­tack.At 5:09 a.m., as the aid work­ers parked and ap­proached the first am­bu­lance by foot, Israeli sol­diers po­si­tioned on the el­e­vated sand­bank opened fire. A dig­i­tal re­con­struc­tion of the scene shows that the sol­diers would have had an un­in­ter­rupted view of the ar­rival of the con­voy. Abed, who was be­ing de­tained at gun­point on the el­e­vated sand­bank, tes­ti­fied that the sol­diers were kneel­ing and aim­ing their weapons at the con­voy as it ap­proached.Lo­ca­tions of all emer­gency ve­hi­cles at the in­ci­dent site at 5:10 a.m. rel­a­tive to Munther Abed and the Israeli sol­diers who de­tained him. From their po­si­tion, the sol­diers would have been able to clearly see the con­voy’s ar­rival with their emer­gency lights on. (Forensic Architecture, 2026).

The Israeli sol­diers re­mained on the sand­bank while fir­ing con­tin­u­ously at the aid work­ers for four min­utes. The sol­diers then ad­vanced to­wards the aid work­ers at a walk­ing pace of ap­prox­i­mately one me­ter per sec­ond while con­tin­u­ously shoot­ing.Echolo­ca­tion of Israeli sol­diers ap­proach­ing the aid work­ers dur­ing the fi­nal 1 minute and 30 sec­onds. (Earshot, 2026).

Upon reach­ing the ve­hi­cles, the Israeli sol­diers con­tin­ued to fire as they walked in be­tween the am­bu­lances and the fire truck, shoot­ing the aid work­ers at close range in ex­e­cu­tion-style killings.At ap­prox­i­mately 5:13 a.m., PRCS aid worker Ashraf Abu Libda called the group’s head­quar­ters. The record­ing, which over­laps Radwan’s video, pro­vided ad­di­tional de­tails. In this record­ing, Earshot found that at least eight gun­shots were fired from po­si­tions be­tween the emer­gency ve­hi­cles. One of the gun­shots cap­tured on Abu Libda’s phone call was fired from a range of one to four me­ters from him. The gun­shots co­in­cide with the last time Abu Libda’s voice is heard on the call, sug­gest­ing these are the gun­shots that killed him.Echolo­ca­tion of Israeli sol­diers as close as 1 to 4 me­ters from aid work­ers and most likely close-range ex­e­cu­tion. (Earshot, 2026).

At least 844 gun­shots were fired over a pe­riod of five min­utes and 30 sec­onds, with at least 93% of the shots fired to­ward the emer­gency ve­hi­cles. The au­dio bal­lis­tics analy­sis con­firms the pres­ence of at least five shoot­ers—and pos­si­bly many more—fir­ing si­mul­ta­ne­ously. The two sur­viv­ing PRCS aid work­ers, Munther Abed and Asaad Al-Nasasra, tes­ti­fied that be­tween 12 and 30 sol­diers were at the scene.“The re­con­struc­tion was jointly achieved with the two sur­vivors of the in­ci­dent, with an im­mer­sive spa­tial model they could walk through and amend. Together with spa­tial and au­dio analy­sis we es­tab­lished the po­si­tion of the sol­diers on an el­e­vated ground with an un­ob­structed line of sight to the emer­gency ve­hi­cles. The sol­diers could clearly see the aid work­ers, shot at them con­tin­u­ously and de­lib­er­ately from this po­si­tion and then ap­proached to ex­e­cute them one by one at close range,” Samaneh Moafi, as­sis­tant di­rec­tor of re­search at Forensic Architecture, told Drop Site. “Locating the mas­sacre within the evo­lu­tion of Israel’s cam­paign in Gaza shows that it was not an iso­lated in­ci­dent but part of the geno­cide.”Earshot used echolo­ca­tion to an­a­lyze the au­dio on the record­ings in or­der to ar­rive at pre­cise es­ti­mates of the shoot­ers’ lo­ca­tions. Echolocation is the process of lo­cat­ing the source of a sound based on an analy­sis of the sound’s echoes and the en­vi­ron­ment in which the sound trav­els. The Israeli mil­i­tary de­stroyed and cleared so many build­ings in the Tel Al-Sultan area where the am­bush of the aid work­ers took place that very few struc­tures re­mained. This de­struc­tion ac­tu­ally strength­ened Earshot’s abil­ity to de­ter­mine the po­si­tions and move­ments of Israeli sol­diers, based on iden­ti­fy­ing the sur­faces re­spon­si­ble for clearly dis­tin­guish­able gun­shot echoes. Rather than hav­ing mul­ti­ple build­ings re­flect­ing the sound waves, there were only a few stand­ing walls and the emer­gency ve­hi­cles them­selves.The analy­sis of the video and au­dio cor­rob­o­rated Al-Nasasra’s eye­wit­ness tes­ti­mony that Israeli sol­diers “came down [from the sand­bank], got close to [the aid work­ers] and shot them from close range,” and “were walk­ing be­tween [the aid work­ers] and shoot­ing.”Map show­ing the Israeli sol­dier’s po­si­tions de­rived from an au­dio analy­sis of gun­shot echoes from Refaat Radwan’s video. (Earshot, 2026).“Earshot foren­si­cally an­a­lyzed over 900 gun­shots fired at aid work­ers. It took one whole year of care­ful lis­ten­ing to re­con­struct an au­di­tory pic­ture of what hap­pened that dark night,” Lawrence Abu Hamdan, the di­rec­tor of Earshot, told Drop Site. “I am so proud that our work has cor­rob­o­rated the sur­vivors’ tes­ti­mony, es­tab­lish­ing their brave ac­counts as ac­cu­rate and re­li­able doc­u­men­ta­tion of what oc­curred that day. Yet, it is the echoes of this event that con­tinue to haunt us: the de­struc­tion and clear­ing of Tel al-Sul­tan left only three struc­tures stand­ing at this crime scene. While the few echoes re­flect­ing off these build­ings brought light to this crime, they have also re­vealed a scale of era­sure of life be­yond this one event.”Ac­cord­ing to au­topsy re­ports first re­ported by the Guardian, the aid worker who filmed the video—Rad­wan—was shot in the head, while Abu Libda and an­other aid worker, Muhammad Bahloul, were shot in the chest. A doc­tor who ex­am­ined the bod­ies re­port­edly de­scribed the “specific and in­ten­tional lo­ca­tion of shots at close range” as in­dica­tive of an “execution-style” shoot­ing.More than two hours af­ter the ini­tial at­tack, a clearly marked UN ve­hi­cle, a Toyota Hilux, passed by the site. Israeli sol­diers fired on the ve­hi­cle, killing the dri­ver. The UN lost con­tact with the ve­hi­cle at 6:00 a.m. A sec­ond UN ve­hi­cle, a minibus, ar­rived in the area min­utes later and was brought to a stop by gun­fire a lit­tle over 200 me­ters away. The dri­ver was able to es­cape.Left: Photograph of the UN Toyota Hilux taken on the 30 March 2025, when the bod­ies of the vic­tims were re­cov­ered. (OCHA, 2025). Right: Still from the sit­u­ated tes­ti­mony with Asaad re­count­ing the lo­ca­tion of the UN Toyota Hilux when brought to a stop. (Forensic Architecture, 2026). Annotated 3D model show­ing the po­si­tion of two UN ve­hi­cles in re­la­tion to the miss­ing am­bu­lance and the con­voy of emer­gency ve­hi­cles. (Forensic Architecture, 2026).Between 6:55 and 7:13 a.m., Al-Nasasra made a phone call to PRCS head­quar­ters that cap­tured at least 42 ad­di­tional gun­shots and the sound of ve­hi­cle move­ment. The record­ing also cap­tured the sound of an ex­plo­sion the in­ves­ti­ga­tion iden­ti­fied as the fir­ing of an Israeli-made Spike LR guided mis­sile.Fol­low­ing the am­bush, Israeli forces crushed all eight ve­hi­cles us­ing heavy ma­chin­ery and at­tempted to bury them un­der the sand.The body of Anwar al-At­tar was found near the am­bush site on March 27, and the bod­ies of the other 14 aid work­ers, all wear­ing iden­ti­fy­ing uni­forms or vol­un­teer vests of their re­spec­tive or­ga­ni­za­tions, were found in a mass grave near the site on March 30.The 15 aid work­ers killed were: Mustafa Khafaja, Ezz El-Din Shaat, Saleh Muammar, Refaat Radwan, Muhammad Bahloul, Ashraf Abu Libda, Muhammad al-Hila, and Raed al-Sharif with PRCS. Zuhair Abdul Hamid al-Farra, Samir Yahya al-Ba­hapsa, Ibrahim Nabil al-Maghari, Fouad Ibrahim al-Ja­mal, Youssef Rassem Khalifa, and Anwar al-At­tar with Civil Defense. Kamal Mohammed Shahtout with UNRWA.Annotated still from the 3D model show­ing the lo­ca­tion of the bod­ies of aid work­ers and their ve­hi­cles be­fore the mass bur­ial. (Forensic Architecture, 2026).One of the sur­vivors, Abed, was re­leased hours af­ter the am­bush. The other sur­vivor, Asaad, was held in Israeli cus­tody with­out charge for 37 days, tor­tured, and in­ter­ro­gated in re­la­tion to the in­ci­dent at the Sde Teiman de­ten­tion camp, a no­to­ri­ous Israeli prison camp in the Negev desert, be­fore be­ing re­leased on April 29.Jonathan Whittall, a se­nior UN of­fi­cial in Palestine be­tween 2022 and 2025, was one of team mem­bers on the ground when the mass grave was dis­cov­ered on March 30 and pro­vided ev­i­dence to Forensic Architecture and Earshot for their in­ves­ti­ga­tion. “Following our dis­cov­ery of the mass grave, the nar­ra­tive from Israeli forces shifted mul­ti­ple times; we were fed sev­eral ver­sions of a bla­tant lie,” Whittall told Drop Site. “The men we re­trieved on Eid last year were medics. We found them in their uni­forms, ready to save lives, only to be killed by Israeli forces fully aware of their pro­tected sta­tus.” Whittall, who is now ex­ec­u­tive Director of KEYS Initiative, a po­lit­i­cal af­fairs and strate­gic ad­vi­sory or­ga­ni­za­tion, has also con­tributed re­port­ing to Drop Site News. “This il­lus­trates an ab­hor­rent dis­re­gard for in­ter­na­tional law,” he con­tin­ued, “where any Palestinian in an Israeli-designated evac­u­a­tion zone is tar­geted re­gard­less of their civil­ian sta­tus. It high­lights the to­tal lack of ac­count­abil­ity un­der which these forces op­er­ate. International gov­ern­ments con­tinue to arm and trade with a lead­er­ship ac­cused of geno­cide, whose sol­diers mas­sa­cred medics and buried them in a grave marked by the siren light of the am­bu­lance they de­stroyed.”Pales­tin­ian Red Crescent aid work­ers mourn the killing of their col­leagues by the Israeli mil­i­tary in Tel al-Sul­tan as their bod­ies are brought to Nasser Hospital in Khan Yunis, in south­ern Gaza. March 30, 2025. (Photo by Abdallah F.s. Alattar/Anadolu via Getty Images).In the af­ter­math of the mas­sacre, the Israeli mil­i­tary pro­vided sev­eral con­flict­ing ver­sions of events to jus­tify the killings. On March 28, af­ter the dis­cov­ery of al-At­tar’s body, the Israeli mil­i­tary ad­mit­ted that its sol­diers had fired on “ambulances and fire trucks.” Three days later, af­ter the re­main­ing bod­ies were dis­cov­ered in a mass grave, the Israeli mil­i­tary claimed that “several un­co­or­di­nated ve­hi­cles were iden­ti­fied ad­vanc­ing sus­pi­ciously to­ward IDF troops with­out head­lights or emer­gency sig­nals.”Af­ter footage from Radwan’s phone was first pub­lished by the New York Times a few days later, the Israeli mil­i­tary back­tracked on its claims that the ve­hi­cles did not have emer­gency sig­nals on when Israeli troops opened fire, say­ing the state­ment was in­ac­cu­rate.The Israeli mil­i­tary then an­nounced on April 20 that an in­ter­nal in­quiry into the in­ci­dent had found the killings were caused by “several pro­fes­sional fail­ures, breaches of or­ders, and a fail­ure to fully re­port the in­ci­dent.”The Israeli mil­i­tary said troops from the Golani re­con­nais­sance bat­tal­ion were in­volved in the at­tack. However, it said sol­diers did not en­gage in “indiscriminate fire” dur­ing the in­ci­dent, but that they opened fire on what they be­lieved to be a “tangible threat” amid what the mil­i­tary called an “operational mis­un­der­stand­ing.” It blamed the at­tacks on “poor night vis­i­bil­ity” and main­tained the in­ci­dent had un­folded in a “hostile and dan­ger­ous com­bat zone, un­der a wide­spread threat to the op­er­at­ing troops.” Six of the fif­teen Palestinians killed, the mil­i­tary said, “were iden­ti­fied in a ret­ro­spec­tive ex­am­i­na­tion as Hamas ter­ror­ists,” but pro­vided no ev­i­dence to sup­port the claim.“On the spe­cific ques­tion of Israel jus­ti­fy­ing the at­tack on clearly marked med­ical per­son­nel be­cause of sus­pi­cions of mem­ber­ship in groups or links to groups or ter­ror­ism—be­cause there is an af­fir­ma­tive duty to re­spect and pro­tect med­ical per­son­nel, you don’t shoot first, you pro­tect first,” Gallagher told Drop Site. “But what this in­ves­ti­ga­tion re­veals is that there was a shoot first pol­icy, and that is un­law­ful un­der in­ter­na­tional law.”As for the bur­ial of the bod­ies in a mass grave, the Israeli mil­i­tary said in its re­port “it was de­cided to gather and cover the bod­ies to pre­vent fur­ther harm and clear the ve­hi­cles from the route in prepa­ra­tion for civil­ian evac­u­a­tion. The body re­moval and ve­hi­cle crush­ing were car­ried out by field com­man­ders.” It con­cluded, “removing the bod­ies was rea­son­able un­der the cir­cum­stances, but the de­ci­sion to crush the ve­hi­cles was wrong. In gen­eral, there was no at­tempt to con­ceal the event.”As a re­sult of the in­ves­ti­ga­tion, the com­mand­ing of­fi­cer of the 14th Brigade re­ceived a let­ter of rep­ri­mand for “his over­all re­spon­si­bil­ity for the in­ci­dent,” while the deputy com­man­der of the Golani re­con­nais­sance bat­tal­ion in­volved in the in­ci­dent was “dismissed from his po­si­tion due to his re­spon­si­bil­i­ties as the field com­man­der and for pro­vid­ing an in­com­plete and in­ac­cu­rate re­port dur­ing the de­brief.”The in­quiry did not rec­om­mend any crim­i­nal ac­tion be taken against the mil­i­tary units re­spon­si­ble for the in­ci­dent. The Palestine Red Crescent Society, Civil Defense, and the UN hu­man­i­tar­ian agency in Gaza all re­jected the Israeli mil­i­tary re­port.“At­tacks on med­ical per­son­nel and those who are iden­ti­fied as med­ical per­son­nel are patently un­law­ful un­der in­ter­na­tional law, and there is an af­fir­ma­tive oblig­a­tion to pro­tect med­ical per­son­nel in the con­text of armed con­flict. So the very first thing is that there’s a breach of that very clear and time hon­ored prin­ci­ple of in­ter­na­tional hu­man­i­tar­ian law,” Gallagher said. “When you zoom out and look at this in the con­text of the way the Israeli as­sault has been car­ried out over many months and years in Gaza and we see that there is a pat­tern and prac­tice of at­tacks on med­ical per­son­nel—sim­i­lar to jour­nal­ists and other groups that are ex­plic­itly and uniquely pro­tected as classes of civil­ians in in­ter­na­tional hu­man­i­tar­ian law—it raises even more ques­tions and deep con­cern about the lack of ac­count­abil­ity, be­cause what we know is that im­punity breeds rep­e­ti­tion.”Gal­lagher, who pre­vi­ously worked at the UN’s International Criminal Court for the for­mer Yugoslavia, said that a le­gal analy­sis of the mas­sacre would find se­ri­ous vi­o­la­tions of the Rome Statute of the International Criminal Court. “When you’re talk­ing about grave breaches of the Geneva Conventions, in par­tic­u­lar war crimes, you have oblig­a­tions, not just the pos­si­bil­ity, but oblig­a­tions, to open in­ves­ti­ga­tions,” Gallagher said.Trans­form­ing the Site of the Massacre into a GHF HubSatellite im­agery from the morn­ing of the am­bush shows that ex­ten­sive earth­works were car­ried out at the in­ci­dent site. The im­ages re­veal the con­struc­tion of an earth berm ap­prox­i­mately 220 me­ters north of the am­bush lo­ca­tion and an­other roughly 410 me­ters to the south. These two po­si­tions later func­tioned as check­points, re­strict­ing ac­cess and con­trol­ling pas­sage along an evac­u­a­tion route es­tab­lished that morn­ing by the Israeli mil­i­tary lead­ing to­ward the coastal Al-Mawasi area.The earth­works that be­gan shortly af­ter the at­tack were used in the con­struc­tion of a Gaza Humanitarian Foundation “aid dis­tri­b­u­tion” site, at which civil­ians were tar­geted and shot at. (Foren­sic Architecture, 2026).

In the days and weeks that fol­lowed, the area sur­round­ing the in­ci­dent site was fur­ther trans­formed by the Israeli mil­i­tary’s con­struc­tion of the “Morag Corridor” se­cu­rity zone and the erec­tion of an aid dis­tri­b­u­tion site op­er­ated by the Gaza Humanitarian Foundation.“On that same site of the mass grave, the Gaza Humanitarian Foundation es­tab­lished a dis­tri­b­u­tion point where des­per­ate peo­ple were gunned down try­ing to ac­cess food,” Whittall told Drop Site. “Now, the U.S, un­der the so-called Board of Peace, plans to build a ‘New Rafah’ over this crime scene. Without mean­ing­ful ac­count­abil­ity, ‘New Rafah’ will be a mon­u­ment to im­punity.”