Methodology, version 3.1

takeoff.watch aims to give a clear view of what the coming years will look like with AI. It follows a large and growing set of concrete yes/no questions, chosen to span the whole range of what the next five years might hold: from where things stand now, through AI systems doing most of the research that improves them, through capability beyond the best human experts, through robots and AI systems moving into the physical world and into government, to a world where most consequential decisions are made by AI, and including the outcomes where progress stalls or is stopped. Each question has precise resolution criteria, so it can be settled against the public record, and each is forecast at every quarter-end for five years. New questions are added as they become worth tracking, and the whole set is re-forecast every week.

This page explains what the questions are, how each forecast is produced, what is checked before a forecast is published, and how to read the results. It is version 3.1 of the site's methodology. Forecasts are made as under version 3, in which each run can read the forecasts made before it; what is new is how questions are resolved. When a forecast suggests that a question may already have resolved, a separate run of the model checks it against the qualifying sources and rules on it, the ruling is published on the question's page, and later forecasts follow it. Version 3, version 2.1, version 2 and the first version, used for the launch set on 14 September 2026, are kept as they were.

The questions

Every question is a yes/no question with an opening date, the day it joined the set, which never changes once set. For the questions the set began with, it is 16 September 2026. Each forecast covers the five years ahead of the day it is made: 21 quarter-ends, from the end of the quarter the forecast is made in through the same quarter-end five years later. The window moves forward a quarter at a time: a forecast made on 3 October 2026 covers 31 December 2026 through 31 December 2031. Forecasts made before 3 October 2026 cover the launch window, 30 September 2026 through 30 September 2031. The forecast for a quarter-end is the probability that the question has resolved YES on or before that date. Because the question is cumulative, the probability can only rise from one quarter-end to the next.

Each question is a single sentence, such as "Will the US unemployment rate exceed 7% in any month?" or "Will a covered developer state that no human researcher makes a material contribution to its frontier model research?", backed by resolution criteria in a fixed form: definitions for every term that could be read two ways, what resolves YES and what resolves NO, the exact publications or data series that can settle it, and the site-wide conventions on publication dates and confirmation that apply. The criteria are written so that the question turns on a published statement or figure, not on whether something has quietly happened.

Many questions ask about events that look remote today, and are meant to. A question that sits near zero now is worth asking if it would be the clearest sign that a particular kind of future had arrived. Where a question concerns a quantity that already exists, such as economic growth, unemployment, robot production, or a share of electricity, the set usually asks about it at several levels, so that one curve shows a familiar change and another shows a change without precedent. To keep such questions answerable, they turn either on a figure that a statistical agency, index, or regulator would still publish, or on a formal act by a government, court, lab, or international body.

Questions are grouped into areas for browsing and tagged with the topics they touch, and each carries the stage of the arc above that it is meant to mark. The set is not fixed. Questions are added whenever one seems worth tracking, and a new question is first forecast on its opening date, then weekly on its own day; its page shows the date it opened. Questions can also be retired; retirements are listed in the changelog at the end of this page with their date and reason. Criteria are not changed after a question opens: when a real case exposes an ambiguity, a ruling settles it, as described under "How questions resolve". A retired question keeps its page and its forecasts.

How a forecast is made

All forecasts are made by one model, Claude Opus 5.5 (Anthropic) at its maximum reasoning-effort setting. It runs inside Claude Code, Anthropic's agent harness, with Claude Code's own tools switched off, and works as an agent with tools to search the web, open pages and PDFs, and search recent news, and with a Linux container of its own in which it can run code. Its web searches exclude this site; what it knows of the site's forecasts comes from the archive described below. Every question is treated the same way: one run of the model per question per week, on that question's own day, until the question resolves.

The run is given the question, its criteria, and the required quarter-ends. It researches the question on its own: the current status of everything the question names, checked against primary sources; comparable past cases; and the calendar and incentives of whoever would have to publish the resolving statement. It is told that its training data is out of date and to search rather than remember, and it is not given a budget of searches or a time target. It then builds its forecast from a hazard rate, the chance that the resolving publication first appears in each quarter given that it has not yet, and accumulates that into the cumulative series. It submits its reasoning and its probabilities, and a short summary in plain language for a general reader: the main reason for its forecast and what would most change it. All three are published as they are.

Many of these questions turn on a number: a rate a statistical agency publishes, a count, a share of some total, a level that a trend either reaches or does not. For those, the run is expected to work with the figures rather than estimate them. The container gives it a shell, Python with the usual data libraries, and its own internet access, so it can download a published series, compute a base rate over the whole history the source provides, check the arithmetic behind any claim it is about to make, and calculate the cumulative series from the quarterly hazards it chose instead of writing them out by hand. It is told that this is for arithmetic on evidence it has gathered and not a substitute for gathering it: a calculation of its own is not a source, and the write-up has to rest on published figures with their URLs. What it computed, and from which file or series, belongs in the reasoning so a reader can repeat it. The container is scratch space, discarded when the run ends; nothing in it is published.

Earlier forecasts

Each run is given a read-only archive of the forecasts made before it: every forecast published on this site, with its write-up, and the forecasts the same forecaster has made for the site's bots on Metaculus and Manifold, each labelled with the model and methodology version that produced it. For runs from 19 October 2026 on, the archive also keeps the run's full working record and the pages it fetched.

The run may use the archive in two ways. For its own question, it may start from its last forecast instead of from nothing: read the earlier write-up, not only its numbers; re-read the criteria; check whether the evidence that forecast rested on still holds; look for what has been published since, and dig where it thinks the earlier work fell short; and say in the write-up what changed and why the numbers moved or did not. It is not required to keep the last forecast, and it is told that an earlier forecast is a starting point to test, not a source, and that differences of a few points between runs are normal. For related questions, such as the rungs of a ladder or two questions about the same event, it may read their latest forecasts and keep its own consistent with them, or say why it does not. Forecasts made under earlier methodology versions, including those by GPT-6 Astra, are in the archive with their labels and can be read the same way. The run is told that forecasts made before 19 October 2026 were single runs without the archive: none saw an earlier forecast or was checked against related questions, and re-running a question a week later typically moved its five-year figure by about 4 points, mostly with no news behind it.

The site uses one model and one run per question so that its capacity goes to covering more questions. The cost is run-to-run variation: two runs on the same question in the same week would usually differ by a few points, and nothing averages that out. Starting from the last forecast should make week-to-week changes follow evidence more closely than under earlier versions, but a small weekly move on one question still means little, and the weekly briefing reports large moves and movements across groups of questions.

The questions are not all forecast on one day. Each question has a fixed day of the week and is re-forecast once a week on that day, so about a seventh of the set is forecast each day. A forecast's date is the day of its own run, and it is also the evidence cutoff: nothing published after that date could have been seen. Forecasts on different questions can therefore be up to six days apart, and each question's page shows its own date.

Until 29 September 2026 the forecasts were made by GPT-6 Astra (OpenAI), all on one day each week, and until 19 October 2026 each run started without seeing any earlier forecast; those forecasts stay in each question's history. A change of model or method can move a question's forecast when nothing in the world has changed, so the weekly briefing compares a question's forecasts only when both were made under the same methodology.

Checks before a forecast is accepted

A submission is rejected, and the run is asked to fix and resubmit, if a probability is outside 0–100%, if the probability for a later quarter-end is lower than for an earlier one, or if any required quarter-end is missing. A run gets three submissions. A run that fails for technical reasons, such as a tool error or a time limit, is rerun from the start. Only a run that ends in an accepted forecast is used, and nothing is edited by hand.

The site applies the same checks every time it is built, so a forecast that fails them cannot be published.

The model sometimes declines to forecast a question. So far this has happened on questions that turn on an election result or on a specific political decision: it researches the question and then says it will not put probabilities on the outcome. The site does not press it, reword the question to get around it, or substitute a number from anywhere else. The question stays in the set, its page says that the model declined and quotes what it said, and it is asked again every week.

Reading the site

The overview shows, for each question, the forecast at three points: one, three, and five years out. The figure is the probability that the question has resolved YES by that date; the blue tint deepens as the probability rises. A second view, "Date by chance", turns the same forecast around: for each question it shows the first quarter-end at which the probability reaches 10%, 50%, and 90%, or "after" the last quarter-end if it does not get there within the five years. The three points are counted from the end of the current quarter. When the window moves forward into a new quarter, a question not yet re-forecast does not reach the new five-year point, so for up to a week it shows its own last quarter-end there instead. Selecting a column heading sorts every question by that column. The topic menu narrows the table to one topic; a question can belong to several.

Each question page shows the full curve, the probability at every quarter-end, with the model's reasoning below it, opened by its plain summary. Hover over, or press and drag on, the chart to read the forecast at any quarter. Every date on the site is one the model actually forecast; the site does not interpolate between dates or smooth the curves.

For questions about a monthly or quarterly statistic, the first quarter-end after a question opens is often close to zero by construction: the first observation that can count is for a period ending after the opening date, and it may not be published until the following quarter.

Every question page links to a JSON download containing every published forecast for that question, along with the question's metadata and any resolution data.

How questions resolve

These conventions apply to every question.

Covered developers. A fixed list: OpenAI, Anthropic, Google DeepMind, xAI, Meta, DeepSeek, Alibaba (Qwen), Moonshot AI, ByteDance Seed, and Zhipu AI. Inclusion is a scoping choice for this question set, not a claim about which developers are at the capability frontier. Developers added later count only from the date they are added. The list applies only where a question says "covered developer"; questions that name specific developers, or that apply to any developer, are not limited by it.

What counts as public confirmation. Either:

• a statement on the developer's own website or in a document the developer wrote (such as a system card, risk report, safety-framework disclosure, or incident report); or
• a report by a third-party evaluator (such as METR), a government AI safety institute (UK AISI, US CAISI, or a Chinese government equivalent), or an affected third party, if the developer does not publicly dispute it within 14 days.

Executive interviews, employee social-media posts, leaks, and press reports based on anonymous sources do not count. Many questions name their own, narrower set of resolving sources; the question page says which.

Resolution date. A question resolves on the date the qualifying document or statement is published (UTC), not the date of the event, measurement, or coverage.

Resolution window. Only publications dated on or after the question's opening date count. A publication from before the opening date does not count, even if it describes the same thing.

Observation period. For a question about a published statistic, the observation must be for a period that ends after the question's opening date. A publication that only repeats or revises figures for earlier periods does not count.

Once yes, always yes. When a question resolves YES, it stays that way for every later quarter-end. Later retractions, lapses, or repeals are noted but do not undo the resolution. A resolved question is no longer forecast; its page keeps the forecasts made before it resolved.

Who decides. Each night, after the forecasts, any question whose new forecast puts at least a 25% chance on its current quarter is checked by the resolver: a separate run of the same model, Claude Opus 5.5 at its maximum setting, with the same tools. It starts fresh, with the question, its criteria, these conventions and any earlier rulings on the question, and is given the forecast's write-up only as a pointer to what to check. It opens every document itself, quotes the passage that establishes each element of the criteria, and rules YES, with the resolution date and source, or NOT YET, saying what is missing. There is no NO ruling: a question that has not resolved stays open. The ruling is published with that night's forecasts: a YES resolves the question, and a NOT YET is shown on the question's page with the date it was checked.

The resolver reads the criteria by three rules. The criteria are the rules: when their text settles a case, it is followed, even where the result seems to miss the question's point; the criteria are not rewritten after the fact, and a question that resolves on a case it was not written to capture may be followed by a new question. When a criterion the case turns on can reasonably be read two ways, the resolver adopts the reading that better fits what the question is trying to detect, judged from its wording, its stage in the set and the cases its criteria include and exclude, and states that reading as a general rule. And earlier rulings bind later ones: a reading once adopted decides later cases the same way. Each forecasting run is told these rules and given any rulings on its question, so that it forecasts the question as it will be resolved.

Limitations

These are model-generated forecasts about questions with little historical precedent, and the site has no track record yet.

The forecasts come from one model and, each week, one run per question. A run can miss a document or misread a question, and nothing averages that out within the week; the resolution criteria and the checks above limit it but do not remove it. Letting the run compute rather than estimate removes a class of arithmetic error, but a calculation is only as good as the series it was run on and the reference class it was chosen for, and a confident number is easier to believe than a rough one; the write-ups name what was computed and from where so that a reader can check both. One model also lacks the different perspectives that models from different developers would bring. The model's training data predates the run, sometimes by many months; it is told to search rather than remember, but a stale belief can still shape what it looks for. Reading earlier forecasts brings its own risk: a run that starts from last week's forecast can carry forward last week's mistake, and a forecast can drift less than the evidence warrants. Consistency between related questions is left to each run; the site does not enforce it, and two linked questions can still disagree.

The resolver is one run of the same model, and a ruling can be wrong in the same ways a forecast can: a missed document, or a misread criterion. Each ruling quotes its sources so that it can be checked.

The forecasts are meant to make assumptions explicit and to show how the outlook moves as evidence comes in, not to make confident predictions. Nothing on this site is financial, investment, or policy advice.

Changelog

• 30 October 2026. Methodology v3.1 takes effect: questions are resolved by the resolver described under "How questions resolve", and each forecasting run is told how it reads the criteria and given any rulings on its question. The model, its tools and the schedule of version 3 are unchanged.
• 19 October 2026. Methodology v3 takes effect: each run can read every earlier forecast and write-up, from this site and from the site's bots on Metaculus and Manifold, build on its own last forecast for the question, and check related questions' latest forecasts. The model, its tools and the schedule of version 2.1 are unchanged.
• 29 September 2026. Methodology v2.1 takes effect: forecasts move from GPT-6 Astra to Claude Opus 5.5, and from one weekly round to a rolling schedule in which each question is re-forecast weekly on its own day. Everything else in version 2 is unchanged.
• 21 September 2026. Methodology v2 takes effect. The site's strategy has shifted from forecasting a small set of questions in depth to forecasting many, and the methodology has changed with it so that a large set can be processed every week: a large set of yes/no questions, each forecast by one model in one run, in place of ten questions in three formats forecast by a weighted ensemble of nine models under Methodology v1. Four of the ten launch questions were yes/no questions; they continue in this set with their wording and criteria unchanged, and their 14 September forecast is the first entry in their history. The other six (AI-executed cyber incidents, biological and chemical weapons, US–China frontier AI agreement, US federal frontier-AI regulation, US real GDP growth, US labor share) are retired: they are kept on the site for the record, are no longer forecast, and their pages point to the questions in this set that cover the same ground.