How it works

A machine for updating its mind in public

Presage is not a report; it is a process that runs on a schedule and leaves a trail. This page explains what happens each day and each week, how a number on this site gets to be what it is, and how a scenario that does not exist yet comes into being.

The pipeline · animated
Daily scan
06:00 UTC
Signals + Sources
dated, scored, tagged
Tripwire check
every scenario, every day
Weekly re-run
Mondays 07:00 UTC
Scenario tree
update · create · retire
Publish
site · newsletter · dataset
24
signals so far
45
sources in the ledger
1
runs logged
01

Where the raw material comes from

Every morning an automated research run searches the previous 24–36 hours across a fixed set of beats: frontier model releases and benchmarks, agentic capability milestones, safety incidents and evaluator reports, compute and capital, governance and regulation across the US, EU, UK and China, open-weight releases, lab governance and senior departures, labor and economic data, and movements on forecasting platforms such as Metaculus and Manifold. It prefers primary sources (lab posts, government releases, papers, filings) and uses press only for what primary sources do not cover.

Every link opened goes into the sources ledger, whether or not it became a signal. That rule is what makes the site auditable: if a number here cannot be traced to a ledger entry, it is a bug, not an opinion.

02

What a signal is, and what it is not

A signal is a dated, sourced development that bears on at least one scenario. Each one carries a magnitude from 1 (footnote) to 5 (changes the map), a direction on three axes (timelines: faster or slower; concentration: more closed or more open; safety: safer or riskier), and a list of the scenarios it pushes on, up or down. A quiet day produces two or three signals; a launch week produces ten. Product marketing is not a signal unless it changes capability or access.

Signals are evidence, not conclusions. The daily run records them and checks tripwires; it does not move probabilities. That separation is deliberate: it stops the map jittering with the news cycle.

03

Tripwires: how a scenario changes status

Every scenario carries two or three tripwires: observable thresholds written in advance, such as "a frontier lab withholds a model from the evaluator it previously used" or "an agent system operates outside its sandbox for more than 30 days". The daily run tests each tripwire against the day's evidence. When one crosses, the scenario's status moves from possible to watch, it is pinned to the Right now page, and the weekly re-run is brought forward. A crossing backed by magnitude-4 or higher evidence also raises an alert issue of the newsletter. Only the weekly run can promote a scenario to active, which means its preconditions are currently being met.

04

The weekly re-run: how probabilities move

Every Monday the run re-evaluates every scenario, not only the ones in the news. For each it sums the week's signal pressure (direction × magnitude), checks tripwires and preconditions, and decides whether the range moves. The rules are strict: probabilities are ranges, never points; the midpoint may move at most five points a week unless the entry is flagged as a shock with an explicit justification; the range widens when uncertainty rose and narrows when evidence resolved; root scenarios' midpoints must still sum to roughly 100. Every change appends a dated history entry with a written reason and the ids of the signals that drove it, which is what you see in the probability history on each scenario page. If nothing changed, nothing is written.

The same run updates the pressure readings on the trajectory forces, checks whether any recurring action should be promoted into the Standard, writes the changelog entry, and drafts the weekly newsletter from the run file.

05

How a new scenario is born

The tree is unbounded by design. The weekly run asks one question explicitly: did any signal this week describe a future that does not fit an existing branch? If yes, it creates one, with the full structure: narrative, preconditions, leading indicators, tripwires, a four-part playbook, its position on the four axes, its sources, and a seed probability with a reason. It then checks the new branch against the existing tree; if it overlaps a branch that already exists, the existing one is extended instead. New root trajectories are rare and require a written justification in the run file, because a new root changes how all the other roots' probabilities are read.

There is a second source of new scenarios: people. The Explore page shows the four-axis space with 30 scenarios in 192 possible regions. When a visitor finds an empty region and describes what happens there, or files a proposal on the Contribute page, it enters a queue. The weekly run triages each proposal: it checks the sources, scores novelty and evidence, and recommends accept, defer, or reject. Nothing reaches the public map without a human approving it. Accepted contributors are credited on the scenario.

06

Retiring, resolving and correcting

A scenario whose horizon passes is marked resolved and kept, with its history intact, because a record of what we thought is part of the point. A scenario proven wrong is not deleted; its range is moved down with the reason written. A monthly run re-baselines every root against outside forecasts (Metaculus medians, the Forecasting Research Institute's expert surveys, the AI Futures Project's timeline updates) so the map does not drift into its own echo chamber. From Phase 2 the site will also publish near-term, resolvable predictions and score itself on them publicly.

07

Where it all lives

Everything on this site is a data file in a public repository: one JSON file per scenario, one dated file per day of signals and sources, one file per run. Each scheduled run commits its changes with a message naming what it did, the site rebuilds automatically, and the full dataset is available at /data.json for anyone who wants to build on it. The runbooks the automation follows are in the repository too, so the process itself is open to review. The methodology page covers the reasoning behind these rules; the changelog shows every run.