Digest and delivery
Which items make it into a digest, how they are grouped and judged, and how the digest reaches you
Which items go in
A digest run starts by fetching all sources once more, so nothing published since the last scheduled fetch is missed. Then it collects the candidate items:
- published in the last 30 days, and
- not already part of an earlier digest, and
- if there is a previous digest, anything from 48 hours before that digest onward, so items that arrived just as the last digest was being made are not lost.
If there are more than 300 candidates, each source gets a share proportional to how much it published, keeping its most recent items, so a prolific source cannot crowd out the rest. Items that have not been summarised yet still go in, with their title and link only.
How items are grouped
Sources belong to a category (called a topic in the cloud app). The digest has one section per
category; sources without one land in Uncategorized. The model writes each section as a short
newsletter piece rather than a list: the narrative replaces the items, roughly 40 to 60 words per
item and at most about 500 words per section.
What the model returns
For every section the model returns the narrative and, for every item, a verdict and a one-line reason of at most 15 words:
| Verdict | Meaning |
|---|---|
must_read | Rare, and reserved for items squarely in your interests |
worth_it | Solid, worth your time |
skip | An honest skip, even for a well-made item outside your interests |
Verdicts are recommendations for you, based on your reader profile
and recent feedback, not general quality marks. Every candidate item must appear exactly once;
anything the model leaves out is added as a skip, and any id it invents is dropped.
The whole answer has to be valid JSON. A digest that fails after the retry is stored with status
failed together with the raw model output, so you can see what went wrong instead of getting
nothing.
When there is nothing new
If no candidate items exist, an empty digest is recorded and the run stops: no model call, no
email. The cloud app shows it as a quiet week; the self-hosted app shows an empty badge on the
Digests page.
Delivery
The digest is always readable in the app. Email is on top of that:
- Self-hosted, email is sent only when an email provider is fully configured, using the core's own template. See Configuration.
- In the cloud, the digest is mailed to your account's email address.
In both cases skip items are left out of the email; the app shows them. A failed send never fails
the run: the digest stays ready in the app and the error is logged.
| Status | Meaning |
|---|---|
ready | Generated; not mailed (email off, or the send failed) |
sent | Generated and mailed |
failed | The model call failed or returned invalid JSON, even after a retry |
empty | Nothing new in the window; no model call, no email |