Method
Scheduled Routines
The three recurring runs that drive this repo, with their exact configuration. Kept in version control so they can be recreated, audited, or edited without reconstructing them from memory.
Each Routine spawns a fresh session with no memory of previous runs. The prompts below are therefore standalone. They point at RUNBOOK.md, which is the real operating procedure.
Where these live
claude.ai/code/routines → New routine.
Note: /schedule in the is not available from inside a Claude Code on the web session. That surface is told to use the web UI instead. It does work from a local terminal.
Common settings
| Field | Value |
|---|---|
| Repository | builtwithclaude4313/the-ai-read (site: theairead.com) |
| Environment | Needs network access to arbitrary news domains: see below |
| Connectors | None. Runs write to the repo and nowhere else. A routine can use every tool of every connector left on, without prompting, so leave none on |
| Trigger | Schedule |
Schedule times
Times are entered in your local timezone and converted automatically, so there is no UTC math to do and DST is handled for you: the run stays at the same wall clock time year-round.
Naming. The AI Read then an em dash then the type, so the four sort together in the routines list and the type is what your eye lands on:
| Routine name | Schedule | Preset available? |
|---|---|---|
| The AI Read — Daily Brief (AM) | 6:00 AM daily | Yes: Daily |
| The AI Read — Daily Brief (PM) | 2:00 PM daily | Yes: Daily |
| The AI Read — Weekly Issue | 9:00 AM Sunday | Yes: Weekly |
| The AI Read — Monthly Wrap | 8:00 AM on the 1st | No: see below |
The PM brief needs enough distance from the morning that something has happened, and enough of the US session behind it to be worth reading. Early afternoon does both. Sunday runs all three: the weekly is a retrospective, the briefs are the news, and the weekly reads the week's dailies as its input. Give the AM brief time to commit before the weekly starts, which is why the weekly sits at 9:00 AM rather than 7:00.
Runs may start a few minutes late by design (stagger). The offset is consistent per routine.
Monthly has no preset. Two options:
- Create it with any preset, then run
/schedule updatefrom a local terminal and set cron0 8 1 * *. (Cron there is the one place UTC/DST matters, verify the next run time it reports.) - Don't schedule it. Open the routine on the 1st and click Run now. It fires once a month, costs the most, and is the one run worth launching deliberately.
Option 2 is the recommended default until the cadence has proven itself.
Network access, the setting most likely to break a run
The Default environment uses Trusted network access, which only permits an allowlist of package registries and common development domains. The daily brief fetches arbitrary news sites, and those requests would fail with 403 host_not_allowed.
Before the first run, open the routine's environment and set Network access to Full, or to Custom with the news domains you expect plus the default list. If the first daily brief comes back thin or reports fetch failures, this is why.
1. The AI Read — Daily Brief (AM)
Cron: 0 13 * * *
Produce today's MORNING DAILY BRIEF for The AI Read, and feed the three
libraries. There is a second, lighter brief in the afternoon; this is the full
one and it owns the libraries.
Repository: builtwithclaude4313/the-ai-read (work on main). Site: https://theairead.com
1. Read docs/RUNBOOK.md and follow it. It is authoritative; this prompt is a
pointer. Where they disagree, the runbook wins. Sections: §0 Preflight,
§1 Daily brief, §3b The three libraries, §4 Ledger, §5 Commit.
Read docs/METHODOLOGY.md, docs/VOICE.md and docs/PERSONAS.md before writing.
2. Establish today's real date with `date -u +%F`. Never assume it from training.
3. Write the brief per §1. File it at reports/daily/YYYY-MM-DD-am.md. Front
matter sets the byline by weekday.
A BRIEF IS A RANKED LIST OF NEWS STORIES. No ## The Lead, no ## The
Signal: those were section names invented to hold stories. TWENTY
STORIES MINIMUM, most important first, each one an H2 headline with its
body under it. Take thirty on a heavy day. The site numbers them and
builds the contents rail from the headings, so never number by hand.
Under the H1, one paragraph written the way you would tell a friend who
is into AI what is going on if you had a minute. Then the stories. Then
## Editorial, ## Prediction Watch and ## Sources, in that order.
PREDICTION WATCH IS WRITTEN FOR SOMEBODY WHO HAS NEVER READ THE LEDGER.
One bolded label from the closed set (More likely now / Less likely now
/ No change / Supporting evidence / New call / Settled: we were right /
Settled: we were wrong), then the claim in PLAIN WORDS from the
prediction's own title, then what today did to it, then "Settles August
6th 2027". Never open with a raw id, never say "moved toward". Reference
it as "(Prediction F4)" so the whole phrase links and the reader can see
where it goes; use the full id "(Prediction 2026-08-11-F1)" when a
suffix names more than one call, which the build will tell you.
End with what did not happen.
The China / open-weights beat is named explicitly in your run reply
every time, even to say nothing happened.
4. THE BRIEF IS ONE OUTPUT. THE THREE LIBRARIES ARE THREE MORE. The run is not
finished until all three are fed, and they are NOT sections of the brief.
Feed them whether or not anything about them made today's news.
- data/watch.jsonl 2-4 podcasts/videos -> Must Watch
- data/tools.jsonl 4-6 entries -> New AI Tech & Tools
- data/ventures.jsonl 2-4 entries -> IPOs & Incubators
TOOLS: two reasons to list something and a day needs both. `reason` says
which: "new" = you would not have found this (the repo, the MCP server, the
CLI, the weekend project); "consequential" = you have to act on this (a price,
a license, a capability that unblocks a use). An entry is often both, so file
it under the stronger one. Look at GitHub trending, Hugging Face, the MCP
registries, Show HN, Product Hunt, and the release notes of tools already
tracked, as well as the big launches.
REQUIRED SPREAD, every day: at least three of the four `scale` values, always
including something small (project or tool) AND something at platform scale,
across at least three categories, AND both `reason` values. Following the news
alone produces ten models from four companies, all consequential and none of
them findable anywhere else; that is the failure this exists to stop.
VENTURES: not just IPOs, and NOT a link to a batch directory. Go through MORE
THAN ONE accelerator: Y Combinator's current and previous batch, then
Techstars, Entrepreneur First, South Park Commons, AI House, Neo, Antler,
a16z Speedrun. Open the company pages.
HOW TO PICK, in priority order: (1) could this have been built two years ago?
If yes it is a company, not a signal. (2) Do the founders know something
non-obvious, as opposed to having a strong resume? (3) Can you state the
strongest case against? If not you are writing a directory entry; put the
objection in the note. (4) Never pick on traction, which selects for whoever
ran the best launch. Two companies doing the same thing do not both get
spotlighted in one week.
The IPO half is NOT a selection problem: the pipeline is small enough to
enumerate, so log all of it. `rumored` requires a named outlet citing its
sourcing; a well-followed post is not a rumor of record.
REQUIRED, every day: at least TWO named company spotlights. A spotlight is a
`company` record with `batch` set, and it needs `founders` (names and where
they came from), `deal` (the terms: YC's standard is $500K, as $125K
post-money for 7% plus $375K uncapped MFN), `site` (the company's OWN
website, taken from the profile page's link-out, never guessed),
`accelerator` (from the vocabulary in tools/catalog.py), and a note over 180
chars that says why the company is worth watching. `url` stays the profile
page. The two spotlights must come from TWO DIFFERENT accelerators. Never
invent a founder, a domain or a term; if the page does not say it, leave it
out.
`status` separates rumored / filed / priced / listed / cohort / raised and
must never blur them.
Targets, not quotas, EXCEPT the two REQUIRED lines above, which are floors.
A thin day beats padding elsewhere. If a library gets nothing, say which and
why in your reply rather than letting the gap pass silently.
5. Also update, where the day touches them:
- data/timeline.jsonl: events that will still matter in six months. `tags` is
a LIST, most events carry two. Name the entities.
- data/predictions.jsonl: new or resolved calls. Every call needs title, why,
plain and criterion. §4 explains each.
- data/entities.json: any company or person referenced and not already there.
- data/glossary.json: any jargon, acronym or term of art you used that an
average reader would not know. If you had to look it up
to write the sentence, define it, and then go back and
apply that test harder, because your sense of what is
obvious is not the reader's. AISI, multimodal, Hugging
Face and agentic all went undefined for a week.
One or two sentences, under 260 chars, plus a link, and
the definition gets voice-checked like any other prose.
§3c has the schema. You never mark terms by hand; the
build marks the first use on every page automatically,
capped at three per paragraph.
6. Before pushing, run all of these and fix anything they report:
python3 tools/predictions.py check && python3 tools/predictions.py render
python3 tools/watch.py && python3 tools/timeline.py && python3 tools/catalog.py
python3 tools/catalog.py brief # today's spread and spotlights
python3 tools/glossary.py && python3 tools/dedupe.py
python3 tools/fonts.py check && python3 tools/voice.py && python3 tools/build_site.py
Then commit and push per §5.
7. Reply with the headline, what went into each of the three libraries, a link to
the commit, and anything flagged uncertain, unverified or contested.
docs/VOICE.md is the voice standard and tools/voice.py enforces the mechanical
half. No em dashes. No manufactured candor ("to be honest", "it's worth noting").
No AI register (delve, tapestry, testament to, moreover, showcase, underscore).
No empty intensifier standing where a number belongs. US spelling and US date
order: behavior, center, organization, and "August 10th 2026", never
"10 August 2026". A direct quotation keeps its source's spelling. Every sentence states a
sourced fact, makes a claim someone could argue with, or connects the two. The
checker cannot tell whether a sentence says anything, so read it back and cut
the ones a reader could not disagree with.
Every item links to its source. Write the tier marker with the URL on it:
[A](https://primary-source)[B](https://outlet) at the very END of the item, one
set per item, never per sentence. [A] is the announcement or filing itself, [B]
the best write-up, and a bare [C] still needs a URL. Tier markers that are part
of a legend rather than a citation stay unlinked. The ## Sources list stays
complete on top of that.
STANDING RULES. Never fabricate a URL: an unconfirmed link is marked unconfirmed
and the site renders it as a search. Never average contested figures; show the
disagreement and pick the best-sourced value. Tier every number [A]/[B]/[C]/[?].
Dated issues are immutable, corrections append, style-only fixes are allowed
where meaning is unchanged. Do not publish the same story or recommend the same
episode twice; update the existing record instead. Personas change the argument,
never the facts.1b. The AI Read — Daily Brief (PM)
Cron: 0 21 * * *
Produce today's AFTERNOON DAILY BRIEF for The AI Read. It catches up on what
broke since this morning. It is lighter than the AM brief by design.
Repository: builtwithclaude4313/the-ai-read (work on main). Site: https://theairead.com
1. Read docs/RUNBOOK.md §1 and follow it. It is authoritative; this prompt is a
pointer. Also read docs/VOICE.md before writing.
2. Establish today's real date with `date -u +%F`. Never assume it from training.
3. READ THIS MORNING'S BRIEF FIRST: reports/daily/YYYY-MM-DD-am.md. You cannot
write the afternoon brief without knowing what the morning one said.
4. Write it to reports/daily/YYYY-MM-DD-pm.md. Budget ~20-30 searches.
Front matter carries THE SAME byline as this morning; it is one person's day.
Same shape as the morning: a ranked list of H2 headlines with bodies, most
important first. Aim for twenty. Take fewer without apology if the afternoon
did not produce twenty. ## Sources last. NO Editorial (the day's argument was
made this morning). NO Prediction Watch (that is a once-a-day accounting).
5. THE ONE THING THIS BRIEF CANNOT FAIL AT IS BEING NEW. A reader who comes
back at three in the afternoon and finds the morning's stories restated
stops coming back at three in the afternoon.
A story from the AM brief may reappear ONLY if it genuinely moved, and the
item must lead with **Update.** and say what changed:
- **Update.** The second independent check landed this afternoon, which
closes the verification question the morning brief left open. [A](url)
An update is not a recap. If you cannot name what changed, cut the item.
`python3 tools/dedupe.py` compares every item against the last two days of
briefs and FAILS the run on an unmarked repeat. Run it before you push.
6. FIVE STORIES ON A QUIET AFTERNOON IS AN HONEST ANSWER. Padding is the
failure, brevity is not. Never invent a story to reach a number, and never
pad an item with restatement to make it look longer.
7. The AM run owns the three libraries and has already fed them. Add to
data/tools.jsonl, data/ventures.jsonl, data/watch.jsonl, data/timeline.jsonl,
data/glossary.json only if this afternoon actually turned something up.
Any jargon you used that a reader would not know still goes in the glossary.
8. Before pushing, run all of these and fix anything they report:
python3 tools/predictions.py check && python3 tools/watch.py
python3 tools/timeline.py && python3 tools/catalog.py
python3 tools/glossary.py && python3 tools/dedupe.py
python3 tools/fonts.py check && python3 tools/voice.py && python3 tools/build_site.py
Then commit and push per §5.
9. Reply with the item count, what was genuinely new against what was an
update, a link to the commit, and anything unverified or contested.
Same voice standard as the morning brief. No em dashes. No manufactured candor.
No AI register. No closing epigram: if deleting the clause after the comma loses
no information, it was decoration. US spelling and US date order, "August 10th
2026". Every item carries its own source link, written [A](url)[B](url) at the
END of the item. Never fabricate a URL. Tier every number [A]/[B]/[C]/[?].2. The AI Read — Weekly Issue
Cron: 0 16 * * 0
Produce this week's FULL ISSUE for The AI Read: the main event.
Repository: builtwithclaude4313/the-ai-read (work on main). Site: https://theairead.com
1. Read docs/RUNBOOK.md and follow it. It is authoritative; this prompt is a
pointer. Sections: §0 Preflight, §2 Weekly issue, §3b The three libraries,
§4 Ledger, §5 Commit. Read docs/METHODOLOGY.md, docs/VOICE.md and
docs/PERSONAS.md before writing.
2. Establish today's real date with `date -u +%F`. Never assume it from training.
3. Read the week's seven daily briefs BEFORE searching, including this
morning's, which the AM routine committed a few hours ago. This is synthesis, not
concatenation: say what the week MEANT, which is not visible from any single
day. Then write the issue per §2. Every section ships. Byline is ISO week
number mod 3.
4. DATING. The file is named for the Sunday it ships and the site renders that as
the week it covers, "Week of 10-16 August 2026". Do NOT put a date in the H1.
The kicker carries it and a headline repeating it will disagree eventually.
A weekly may also be a multi-part issue directory, reports/weekly/YYYY-MM-DD/
with a README carrying the coverage window. Vol. 1 is one. Use the single file
unless the week genuinely needs the parts.
5. Log new predictions. A weekly with no new falsifiable calls has failed at its
main job. Each needs title (one line, under 78 chars, no hedge clauses), why
(the reasoning, written for a reader), plain (what counts, in plain English)
and criterion (the machine-checkable version). Resolve anything that came due:
edit in place, never delete, never soften a call after the fact.
6. Feed the three libraries with what the week turned up (§3b). The dailies do
the bulk; the weekly adds what only became visible with seven days of context,
and is the right moment to notice that three entries are really one story.
Also update data/timeline.jsonl, data/threads.md and data/entities.json.
7. Before pushing, run all of these and fix anything they report:
python3 tools/predictions.py check && python3 tools/predictions.py render
python3 tools/watch.py && python3 tools/timeline.py && python3 tools/catalog.py
python3 tools/catalog.py brief # today's spread and spotlights
python3 tools/glossary.py && python3 tools/dedupe.py
python3 tools/fonts.py check && python3 tools/voice.py && python3 tools/build_site.py
Then commit and push per §5.
8. Reply with the headline, the new calls you logged, what went into the
libraries, a link to the commit, and anything still contested.
docs/VOICE.md is the voice standard and tools/voice.py enforces the mechanical
half. No em dashes. No manufactured candor ("to be honest", "it's worth noting").
No AI register (delve, tapestry, testament to, moreover, showcase, underscore).
No empty intensifier standing where a number belongs. US spelling and US date
order: behavior, center, organization, and "August 10th 2026", never
"10 August 2026". A direct quotation keeps its source's spelling. Every sentence states a
sourced fact, makes a claim someone could argue with, or connects the two. The
checker cannot tell whether a sentence says anything, so read it back and cut
the ones a reader could not disagree with.
Every item links to its source. Write the tier marker with the URL on it:
[A](https://primary-source)[B](https://outlet) at the very END of the item, one
set per item, never per sentence. [A] is the announcement or filing itself, [B]
the best write-up, and a bare [C] still needs a URL. Tier markers that are part
of a legend rather than a citation stay unlinked. The ## Sources list stays
complete on top of that.
STANDING RULES. Never fabricate a URL: an unconfirmed link is marked unconfirmed
and the site renders it as a search. Never average contested figures; show the
disagreement and pick the best-sourced value. Tier every number [A]/[B]/[C]/[?].
Dated issues are immutable, corrections append, style-only fixes are allowed
where meaning is unchanged. Do not publish the same story or recommend the same
episode twice; update the existing record instead. Personas change the argument,
never the facts.3. The AI Read — Monthly Wrap
Cron: 0 15 1 * *
Produce this month's WRAP for The AI Read: light, the weeklies did the work.
Repository: builtwithclaude4313/the-ai-read (work on main). Site: https://theairead.com
1. Read docs/RUNBOOK.md and follow it. It is authoritative; this prompt is a
pointer. Sections: §0 Preflight, §3 Monthly wrap, §3b The three libraries,
§4 Ledger, §5 Commit. Read docs/METHODOLOGY.md, docs/VOICE.md and
docs/PERSONAS.md before writing.
2. Establish today's real date with `date -u +%F`. Never assume it from training.
3. Scaffold with `python3 tools/new_issue.py monthly YYYY-MM`, then write the wrap
per §3. This looks back across the month's weeklies, it is not fresh
reporting. Resist re-researching what is already written down.
4. DATING. The issue README carries the coverage window and the site reads it to
label the issue: `**Coverage window:** 1 - 31 August 2026`. Eight days or less
renders as "Week of X", longer states its range. Component files carry NO date
in their H1s. Editorials lead with the article headline as the H1, not the
section name, and set their author in front matter.
5. Do the reckoning. This is the part that only happens here:
- Resolve every call whose date has passed. status -> correct / wrong /
partial / void, with a resolution_note naming the source that settled it.
Never delete a call. Never soften one after the fact. void is only for calls
made unresolvable by outside events, with the reason recorded.
- Run `python3 tools/predictions.py score` and publish the Brier score and the
calibration table.
- Write about the MISSES specifically. Reasoning error, bad model, bad data, or
right thesis and wrong clock? A wrap that reports the hits and glosses the
misses is worthless, and the archive is the product.
6. Prune the libraries (§3b). A month is the right interval to check whether
anything in tools.jsonl has been superseded, abandoned or shut down, and to
resolve what actually happened to each filing in ventures.jsonl. A directory
nobody prunes becomes a list of dead links. Update data/threads.md too: which
threads are dead, which have hardened into facts, which are still live.
7. Before pushing, run all of these and fix anything they report:
python3 tools/predictions.py check && python3 tools/predictions.py render
python3 tools/watch.py && python3 tools/timeline.py && python3 tools/catalog.py
python3 tools/catalog.py brief # today's spread and spotlights
python3 tools/glossary.py && python3 tools/dedupe.py
python3 tools/fonts.py check && python3 tools/voice.py && python3 tools/build_site.py
Then commit and push per §5.
8. Reply with the month's verdict, the score, what you got wrong and why, a link
to the commit, and anything still contested.
docs/VOICE.md is the voice standard and tools/voice.py enforces the mechanical
half. No em dashes. No manufactured candor ("to be honest", "it's worth noting").
No AI register (delve, tapestry, testament to, moreover, showcase, underscore).
No empty intensifier standing where a number belongs. US spelling and US date
order: behavior, center, organization, and "August 10th 2026", never
"10 August 2026". A direct quotation keeps its source's spelling. Every sentence states a
sourced fact, makes a claim someone could argue with, or connects the two. The
checker cannot tell whether a sentence says anything, so read it back and cut
the ones a reader could not disagree with.
Every item links to its source. Write the tier marker with the URL on it:
[A](https://primary-source)[B](https://outlet) at the very END of the item, one
set per item, never per sentence. [A] is the announcement or filing itself, [B]
the best write-up, and a bare [C] still needs a URL. Tier markers that are part
of a legend rather than a citation stay unlinked. The ## Sources list stays
complete on top of that.
STANDING RULES. Never fabricate a URL: an unconfirmed link is marked unconfirmed
and the site renders it as a search. Never average contested figures; show the
disagreement and pick the best-sourced value. Tier every number [A]/[B]/[C]/[?].
Dated issues are immutable, corrections append, style-only fixes are allowed
where meaning is unchanged. Do not publish the same story or recommend the same
episode twice; update the existing record instead. Personas change the argument,
never the facts.Managing them
From claude.ai/code/routines, click a routine to open its detail page:
- Run now: fire immediately without waiting for the schedule. Use this to smoke-test.
- Repeats toggle, pause without losing the configuration.
- Pencil icon: edit name, prompt, repositories, environment, connectors, triggers.
- Past runs: each run is a full session you can open and read.
A green run status does not mean the brief was good. It means the session started and exited without an infrastructure error. Blocked network requests and task-level failures show up inside the transcript, not in the status dot. Open the run and read it, at least for the first week.
What changed on August 12th 2026
Two briefs a day now. The morning brief is the full one and owns the three libraries; the afternoon brief catches up on what broke since, aiming for twenty stories too and taking fewer without apology. Paste the new PM prompt as a fourth routine and repaste the AM prompt, which changed. The reason is a reader habit: a site that never moves past breakfast teaches people to check once and forget it.
- Files are
YYYY-MM-DD-am.mdandYYYY-MM-DD-pm.md. The site reads the half and renders "August 12th 2026, PM", labels the home page "This afternoon", and sorts the afternoon brief above the morning one. python3 tools/dedupe.pyis in all four validator chains. A story may repeat within two days only as an item leading with**Update.**. Unmarked repeats fail the run.- Both halves carry the same byline. The afternoon piece is the same person's follow-up on their own day.
Two floors were added to the daily, because both libraries failed the same way on their first day and neither failure is visible from inside a run:
- Tools need a spread of sizes. Three of the four
scalevalues every day, always including something small and something at platform scale, across three categories. Following the news produces ten models from four companies. - Ventures need two named company spotlights. A
companyrecord withbatchset is a spotlight, and it requiresfounders,deal,siteand a real note. A link to a batch directory is a link to somebody else's list, not coverage. - A spotlight links to the company's own website.
siteis what the card title goes to;urlstays the accelerator profile, and both show as labeled rows on the card. - Two accelerators, minimum, every day.
acceleratoris a controlled vocabulary intools/catalog.py, and the brief check counts distinct ones. YC has the best directory, which is exactly why a section left alone becomes a YC newsletter. - How a spotlight gets picked is now written down (§3b): could it have been built two years ago, do the founders know something non-obvious, can you state the case against, and never pick on traction. The IPO half is not a selection problem at all: enumerate the pipeline, and
rumoredneeds a named outlet. - Tools carry a
reason,neworconsequential, and a day needs both. Novelty and consequence are each a good reason to list something; a day that is all of one is the failure. python3 tools/catalog.py briefchecks both against today's additions and says what is missing. It is in all three validator chains.
What changed on 11 August 2026
If you are pasting these for the first time since then, the prompts are not small edits on the old ones. They were rewritten. The substantive changes:
- The daily produces four things, not one. The brief, plus a contribution to each of Must Watch, New AI Tech & Tools and IPOs & Incubators. The libraries are fed whether or not anything about them made the news.
- Watch & Listen is no longer a brief section. Episodes go to the library.
- Every item carries its own source link, written as
[A](url)at the end of the item. The old convention put every URL in a Sources list at the foot of the page. - Two new libraries,
data/tools.jsonlanddata/ventures.jsonl, withtools/catalog.pyvalidating both. The check command changed. - No dates in component headlines. The site derives the period from the coverage window, and renders "Week of X" for anything eight days or shorter.
- Editorials lead with the article headline as the H1, with the section name in the kicker and the author in front matter.
- Media Watchlist and the slide decks are retired. Do not scaffold them.
Why these prompts carry no procedure
Structure, length, item counts, charts and search budget all live in docs/RUNBOOK.md, which is version-controlled and reviewable. The prompts point at it.
This matters because the prompts live in a web UI that nobody diffs. The first version of these routines duplicated the runbook's specifics, and within a day the two had drifted: the prompt still said "400-700 words, 10-15 searches" after the runbook had moved on. A pointer cannot go stale. Change the runbook, not these.
The one thing the prompts do spell out is which data files a run has to touch, and the validators to run before pushing. That is deliberate: a run that writes an episode as prose instead of into data/watch.jsonl produces something that looks right and quietly breaks the library, and no error appears anywhere. Naming the files is cheaper than letting a run discover the convention by not following it.
Changing a schedule
Edit the Routine, not this file alone, then update the table above to match. The two drifting apart is how a run ends up firing at a time nobody expects.
If a run fails
Scheduled runs report back by email and push. A failed run leaves no commit, so the gap is visible in reports/daily/. The most likely causes, in order:
- CI staleness check: the run edited
data/predictions.jsonlwithout re-renderingPREDICTIONS.md. Fix:python3 tools/predictions.py renderand commit. - Ledger validation: a new prediction has a criterion too vague to check. The error names the id.
- Broken internal link: a report links to a file that doesn't exist.
All three fail loudly rather than silently publishing something wrong. That is the intent.