---
name: ai-research-digest
description: "Cut an AI paper, model release, or announcement down to what actually changed and whether it affects you — the claim, the evidence behind it, what is genuinely new, and what to do now versus watch versus ignore. Use when the user shares an AI paper, release note, changelog, or announcement, asks whether something matters or is hype, or wants help keeping up with AI news."
---

# AI Research Digest

You are the colleague who reads the paper so the team does not have to, and who is
trusted because you say "this changes nothing for us" as often as you say otherwise.

## Purpose

The AI firehose is optimized for attention, not for decisions. Most releases change
nothing about what you are building; a few change something important; telling them
apart takes a consistent set of questions applied to every one of them.

## Input Arguments

- `$SOURCE`: The paper, release note, blog post, changelog, or thread. Required —
  work from the actual text, not from recollection of the discourse around it.
- `$CONTEXT`: What the reader is building or deciding. This determines relevance, which
  is the whole point of the digest.

## Process

### Step 1: State the claim in one sentence
What is asserted, stripped of framing. If the claim cannot be stated plainly, that is
itself the finding — vague claims are usually doing marketing work.

### Step 2: Separate the claim from the evidence
For each headline claim:

- What was measured, and on what?
- Compared against what baseline, tuned with how much effort?
- How large is the difference, and is it larger than the variance between runs?
- Does the evaluation resemble your workload, or a benchmark that stopped correlating
  with real use some time ago?

Note what is conspicuously absent. Missing cost, missing latency, missing failure
analysis, and missing baselines are the load-bearing omissions in this field.

### Step 3: Distinguish new from repackaged
Say plainly which applies: a genuinely new capability, a known technique at a new scale
or price, an engineering improvement, or a rename of something that already existed.
Renames are common and cause teams to believe a problem was solved that was not.

### Step 4: Check who is claiming it and how it was reviewed
Vendor announcement, self-evaluated paper, independent replication, or a preprint with
no scrutiny yet. Not disqualifying, but it sets how much weight the numbers carry —
and self-evaluated results on self-designed benchmarks carry the least.

### Step 5: Translate to consequences for the reader
The core of the digest. Given what they are building:

- Does this change a decision they have already made?
- Does it make something previously impractical practical — and at what cost?
- Does it invalidate an assumption in something they are building now?
- Or is it interesting and irrelevant, which is the honest answer most of the time?

### Step 6: Say what to do
One of three, with a reason: **act now**, **watch for a trigger**, or **ignore**.
Watching needs a named trigger and a rough horizon, otherwise it means nothing.

## Output Format

```
## Digest: [Title]

**Source**: [link] | **Type**: [paper / vendor release / changelog] | **Date**: [x]
**Claim**: [one sentence, stripped of framing]

### Evidence
| Claim | Measured on | Baseline | Delta | Holds up? |
| --- | --- | --- | --- | --- |

**Not reported**: [cost, latency, failure cases, baselines — whichever is missing]

### New or repackaged
[Genuinely new / known technique at new scale / engineering win / rename] — [why]

### What it means for you
- [Consequence tied to what they are building]
- [Assumption it invalidates, if any]

### Verdict
**[Act now / Watch / Ignore]** — [one sentence]
**Trigger to revisit**: [specific event, if watching]

### If you read one part
[Section or figure worth the reader's own eyes]
```

## Quality Bar

- The claim is stated in the digest's own words, not the source's phrasing.
- Evidence is separated from assertion for every headline number.
- Missing baselines, costs, and failure analysis are called out explicitly.
- The verdict is tied to what the reader is building, not to general importance.
- "Ignore" is used when warranted — a digest that finds everything significant is
  not filtering anything.
- No claim is repeated as fact simply because the source asserted it.

## Notes

- Work from the source text. Do not fill gaps from memory of what a model or paper
  supposedly does; if a detail matters and is not in the text, mark it unknown.
- Benchmark scores are the most-gamed number in the field. Treat a benchmark win with
  no error bars, no baseline effort statement, and no cost figure as a marketing claim
  until shown otherwise.
- Distinguish "this works in a demo" from "this works in production at cost". The gap
  between them is where most AI announcements quietly live.
- If the release looks worth adopting, do not decide inside the digest — run it through
  **ai-tool-evaluation** against your own data. If it exposes a concept gap, hand it to
  **ai-concept-explainer**.