One wall is measurement; the other is that no shortcut exists
2026-07-29 · Dynamics & Unpredictability
You probably assume forecasts miss because the instruments aren't good enough and the data isn't plentiful enough. Half the time that's right. The other half is something else entirely — some things cannot be computed, not because you know too little, but because there is no way to find out short of letting them happen at full length.
Tomorrow's weather comes out pretty well. Next weekend's is shakier. Two weeks out it is barely better than guessing. That boundary is not a boundary of technique — make the supercomputer a hundred times faster and it barely moves. It is a wall.
The counterintuitive part is that there is more than one such wall, and the two look nothing alike. The first is you can't measure well enough: the system is exquisitely sensitive to its initial state, your measurement error is amplified exponentially, and the forecast horizon is capped by how fast that error grows. Money prises this one open a crack. The second wall is a different animal. Suppose you knew the initial state exactly, and the rules were exact with no fuzziness anywhere. There may still be no way of learning the outcome faster than running the thing one step at a time. That wall does not open — it is not about how much you know, it is about whether a shortcut exists at all.
Three issues here deal with unpredictability, and they divide the work. Topic 8 is chaos itself (deterministic does not mean predictable); Topic 9 is how one parameter walks a system all the way into chaos. This issue asks one thing: given that you can't predict it, which kind of "can't" is this, and what is still available in each case. The two limits have to be read against each other, because their remedies are nearly opposite — misdiagnose the wall and every dollar goes to the wrong place.
In 1961 the meteorologist Edward Lorenz wanted to continue a forecast run he had already computed, so he typed an intermediate state back in off the printout → ref · Lorenz system. The printout carried three decimal places; the machine had been holding six. The number he typed differed from the original by less than one part in a thousand — and the weather that came out was an entirely different weather.
What matters is not the slogan "a tiny difference makes a big difference", but how much, and how fast. In systems like this, two trajectories starting almost on top of each other pull apart exponentially: the gap doubles every fixed interval. That interval is the error doubling time; the growth rate behind it is the Lyapunov exponent, and the time it takes for an error to grow from negligible to unignorable is the Lyapunov time.
Exponential growth has a brutal consequence that only shows up when you run it backwards: to buy one more doubling time of forecast horizon, you have to halve your initial error. To buy ten, you have to cut it to a thousandth (2 to the tenth is about 1000). Investment in precision is multiplicative; the horizon it returns is additive. That is why weather forecasting advances at roughly a day per decade rather than doubling whenever compute doubles.
In modern operational forecasting the doubling time for synoptic-scale error is about a day and a half. In 2019 a group (Zhang and colleagues) used 9 km and 3 km models to estimate the limit directly: today's skilful lead time is around 10 days, and cutting current initial-condition error by a full order of magnitude buys at most 5 more days — after which you hit a line at roughly two weeks. That line is the ceiling assuming a perfect model, not the current state of the art. Weather running out at two weeks is not meteorologists slacking.
Set your replanning cycle by the error doubling time, not by the calendar. How: pull your last 20 predictions (delivery dates, sales, capacity, recovery times), group them by how far ahead each was made, and find the lead time at which the miss goes out of control — that is the doubling time for this thing, and your review interval should be half of it. The action to stop: turning the estimation meeting into two hours in pursuit of getting it right the first time.
Having hit the first wall, meteorologists did not give up. They changed the deliverable — and that move is worth stealing by anyone who forecasts anything.
Since the 1990s the major centres no longer run the model once. They perturb the initial state a few dozen times — each perturbation within what observational error allows, so every perturbed version is equally "entitled" to be the true current state — and run the forecasts in parallel. The European Centre for Medium-Range Weather Forecasts (ECMWF) runs 51: one control forecast plus 50 perturbed members. The technique is called ensemble forecasting.
What it delivers is not a number but a crowd of numbers. And how widely that crowd spreads is itself the most important product: if all 51 say rain on Saturday, you can say rain with real confidence; if 30 say rain and 21 say no, the correct output is "about a 60% chance", not a forced pick. The "70% chance of rain tomorrow" on your phone comes from precisely this.
Note that this is not uncertainty repackaged as a disclaimer. Probability forecasts are testable: take every day in the year on which you said 70%, and it should have rained on close to seven-tenths of them. This is calibration, and it is a scorable quantity. Point forecasts have no such property — when a single "rain tomorrow" turns out wrong, you cannot separate a bad model from bad luck, so nobody has to answer for anything.
Change the deliverable from one number to an interval plus a probability, and then score the interval. Concretely: attach an 80% interval to every number you report; each quarter, count what fraction of outcomes landed inside. The target is 80% — far more than that means you widened the interval to protect yourself, far less means you are fooling yourself. What gets held to account shifts from "did you call it" to "how well calibrated are your intervals". This step needs no new model, only a new table.
The second thing matters more and gets dropped most often: predictability is not a property of the system, it is a property of the question.
The temperature in Beijing on 17 March next year: unanswerable. The mean temperature in Beijing next March, and roughly how many days will top 25 °C: answerable, and rather well. Same atmosphere, same equations, same pile of measurement error. The only difference is that the first asks about one point on the trajectory and the second asks where that trajectory tends to sit, and how often.
That is exactly the difference between weather and climate. Climate is not "weather much later"; climate is the statistics of weather. In the language of Topic 7: the trajectory wanders on an attractor, and which point it wanders to is unanswerable, but the shape of the attractor is stable — stable enough that if you recount over a different stretch of time, you get very nearly the same distribution. → ref · phase space & attractors
So "this system is chaotic, it can't be predicted" is an incomplete sentence, and often a lazy one. How high to build the levee, how much redundancy to hold, how large a position to take — every one of those asks for a statistic. Changing the question is far cheaper than changing the tooling, and it is often the only move that works.
When someone says "that can't be computed", ask one question back: do you want a trajectory (the state at a particular moment), an end state (where it finally settles), or a statistic (the long-run distribution, rate, or proportion)? Their computability is completely different. Rewrite every question that can be rewritten as a statistic — turn "which week next quarter will the outage happen" into "roughly how many outages next quarter, and how long is the longest" — the second is answerable, and it is the number your staffing and redundancy actually need.
Now demolish the first wall entirely and see what is left standing behind it.
Suppose your system is discrete: cells, integers, exact rules. No decimals, no measurement error, no rounding. You know the initial state to the last bit. What could possibly stop you now?
Try the plainest system there is: a one-dimensional cellular automaton. A row of cells, each black or white; at every step all cells update at once, and a cell's new colour depends only on its own old colour and those of its two neighbours. Three cells give eight possible neighbourhoods, each assigned an outcome, so there are 256 possible rules, numbered 0 to 255. → ref · Game of Life & cellular automata
Start from a single black cell in the middle. Rule 90 grows a Sierpiński triangle, as regular as woven cloth. How regular? Whether the cell in row n, column k is black has a closed form — it equals Pascal's triangle (the binomial coefficients) modulo 2, so you plug in n and k and compute it directly without running a single step. This is reducible: a shortcut exists.
Rule 30 is a few bits away and grows something like scattered sand: some striping on the left, and in the middle a broad region where nobody has found any pattern at all. Wolfram used it as a pseudorandom generator for decades; in 2019 he offered $30,000 for three fairly basic questions about it, one of them being whether the centre column ever becomes periodic. The prize is still unclaimed. To know the colour of the middle cell at step one million, the only known method is to run a million steps. The property is called computational irreducibility.
Be precise about how this differs from the first wall, because it is the sentence that matters most here: irreducibility is not because you measured badly (there is no measurement), not because the rule is complicated (eight lines), and not because noise was amplified (there is no noise). It says that the process is its own shortest description. To jump to the answer you would need a path shorter than the process, and for the overwhelming majority of such rules that path does not exist.
There is a harder layer still: Rule 110 has been proved Turing-complete (Matthew Cook, 2004) — it can simulate any computer. General questions about its long-run behaviour therefore sit at the level of the halting problem: not hard to compute, but undecidable, with no algorithm that answers for all inputs.
Once you have established that the process in front of you is irreducible, stop spending on "computing it more accurately" — that money buys nothing. Spend on three things instead: make one step cheaper (shorten the cycle of one real trial), make the result of a step reversible, and make the observation between steps denser. In a world without shortcuts the only available speed-up is trial throughput, not predictive precision. This is the real argument for small fast steps — not a cultural preference, a consequence of the wall.
The two walls have nearly opposite remedies, so the diagnosis is everything. Three questions do it.
First: would an order of magnitude more measurement precision lengthen the horizon? Yes → precision wall, and buying observations, data and sensors pays (only additively, but it pays). No → stop buying; that budget belongs somewhere else.
Second: would an order of magnitude more compute let you see further? Under the precision wall: yes, because compute is what makes bigger ensembles and finer grids affordable. Under the computation wall: compute only makes the same process run faster — a million steps is still a million steps, just in less time. It shrinks a constant, not the wall.
Third: do I want a trajectory, an end state, or a statistic? This one dissolves a great many laments about unpredictability, and it works against both walls at once: the shape of a chaotic system's attractor is stable, and the density of black cells in an irreducible automaton is usually stable and estimable too. Reword the question and the wall may no longer be on your route.
One combined case needs care: real systems often hit both walls at once. Economies, ecosystems and organisations are all unmeasurable and irreducible together. The order is then fixed — ask the third question first (can this become a statistic), then the first (is precision worth buying), and only then concede the second wall. Done the other way round, you spend the money first and discover afterwards that it went to the wrong wall.
In any meeting about "we need better forecasts", run the three questions and write the conclusion down: which wall we are hitting, and therefore what we will stop funding. Without that last clause, the forecasting budget grows forever along the "buy more data" path — and that path only pays in front of the first wall.
Now the other side. Every claim above has a place where it fails, and you should know them before using any of it.
First, the Lyapunov exponent is an average, and real predictability changes day to day. "Doubling every day and a half" is a long-run average along the trajectory. Some atmospheric situations are remarkably sturdy — error grows slowly and a ten-day forecast holds; others fall apart at a touch and collapse in three days. Forecasters call this flow-dependent predictability, and the ensemble spread is precisely how they measure it on the day. So do not treat "two weeks" as a hard line that holds every day; it is a ceiling in order of magnitude, not a schedule.
Second, model error and initial-condition error are different things, and this issue's framework only covers the latter. Ensembles perturb the initial state. If the model itself has the physics wrong, all fifty members err in the same direction while the spread still looks narrow — and you get a confident, wrong probability. Climate projection faces mainly this kind of error. It is not a chaos problem but a structural one: adding members does nothing, you have to change the model. A narrow interval is not reliability, and this is the most common misreading of ensembles.
Third, computational irreducibility is not currently a theorem. Wolfram hangs it on a larger conjecture he calls the principle of computational equivalence: that almost all non-trivial rules are equivalent in computational power. There are many supporting cases and no proof. Rule 110's Turing-completeness is a rigorous result; "therefore any specific question is unpredictable" is not — a Turing-complete system can still contain plenty of specific questions that are decidable or even have closed forms. Using "irreducible" as a general-purpose shield for "so it can't be computed" is the easiest mistake to make here, and one of the most criticised uses of complexity science.
Fourth, and most important: neither wall endorses "so don't decide". The limits of predictability constrain statements about a specific future state. They do not constrain changing the distribution. You can still thin the bad tail, speed up recovery, and size the bet so it survives the whole distribution. Giving up point prediction is not giving up intervention — it is what frees the budget for it.
Because predictable statistics rest on a precondition: the rules generating the data did not change over that stretch, and the attractor holds its shape. Climate change is exactly the case where the attractor itself is moving, and market structure moves too. The move offered here — estimate the future distribution from historical statistics — is what fails first. The test is plain: did the rules change over this period? If they did, the distribution in your hand belongs to the system that used to exist.
Yes, and these are the most useful findings of all. The whole trajectory may be out of reach while some conserved quantity, some mean density, or some yes/no question about eventual extinction has a closed form. The difference between Rule 90 and Rule 30 is the reminder: reducibility is a property of the question. So the work worth doing is hunting for the sub-questions that happen to be reducible, rather than complaining that the whole is unpredictable.
It can, and quite specifically: if the perturbations are chosen badly — only along unimportant degrees of freedom — the members stay bunched and hand you false confidence. Spread is meaningful only once the perturbation scheme itself has been validated. When you see a very narrow interval, the first question is not "what's the conclusion" but "how was this interval generated".
No, and merging them produces wrong conclusions. NP-hardness is about how solution cost grows with problem size, and usually comes with the property that an answer is easy to verify. Irreducibility says that even at fixed size there is no path faster than stepping through, and the answer is typically not easy to verify — you cannot check it without running it. Both can hold at once, but they are different walls with different remedies.
Three trainable things: judging which wall a problem sits behind, rewriting the question into an answerable form, and calibrating your own intervals. All three can be scored and all three improve with practice. Calling specific outcomes, in many domains, cannot be trained — its ceiling is set by the system, not by you.