Methodology, version 2

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 how the questions are written, how each forecast is produced, what is checked before a forecast is published, and how to read the results. It is the second version of the site's methodology; the first, used for the launch set on 14 September 2026, is kept unchanged.

The questions

Every question is a yes/no question with an opening date, the day it joined the set, and a forecast at every quarter-end for five years from that date. For the questions the set began with, the opening date is 16 September 2026 and the quarter-ends are the 21 from 30 September 2026 to 30 September 2031. The opening date never changes once set. 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.

The criteria for each question are drafted by a model, GPT-6 Astra, one run per question, working from the one-sentence question and two of the launch set's criteria as examples, with web search to verify that every source a question names exists and how it publishes. Each run also reports any problem it finds with the question it was given: that the question has already been met, that no source could settle it, that a fact the question rests on is wrong or out of date, or that it had to choose between two readings. Those reports are reviewed, and a question is reworded or dropped in response before it is forecast. A question added later goes through the same steps as the ones the set began with. Four questions carried over from the launch set keep their original criteria unchanged.

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 forecast from the next weekly round on; its page shows the date it opened. Questions can also be retired, and criteria are clarified when a real case exposes an ambiguity; those changes are listed in the changelog at the end of this page with their date and reason. A retired question keeps its page and its forecasts.

How a forecast is made

All forecasts are made by one model, GPT-6 Astra (OpenAI) at its high reasoning-effort setting, working 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. It does not see this site, which is excluded from its searches. Every question is treated the same way: one run of the model per question per week.

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 both 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.

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. A small weekly move on one question therefore means little, and the Updates page reports large moves and movements across groups of questions.

The forecast date is the day the runs are made. It is also the evidence cutoff: nothing published after that date could have been seen.

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 2031" if it does not get there within the five years. 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. 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.

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. Each week's run starts from nothing: it does not see the site's earlier forecasts, its own or any other question's, so the set is not checked for consistency with itself, and two linked questions can disagree.

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

• 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.