Download the Book (PDF): Introduction Shortly after three in the afternoon on 14 August 2003, a high-voltage transmission line in northern Ohio sagged into a tree and tripped. That was not unusual; lines trip all the time, and the grid is designed to route around them. What made the day historic was that the alarm system in the control room of the local utility had silently stalled nearly an hour earlier, so the operators watching their screens saw a calm system while the real one was coming apart. Over the next hour, more lines overloaded, sagged and tripped, each failure pushing load onto neighbours that were themselves near their limits. Shortly after four o'clock the cascade became uncontrollable, and within minutes roughly fifty million people across the north-eastern United States and Ontario were without power. The joint US–Canada task force that investigated the event did not conclude that nobody had the data. The data existed, in sensor readings flowing every few seconds from substations across the region. What failed was the machinery for turning those streams into a timely, believable warning. That gap between having temporal data and acting on it is the subject of this book. Almost every system that matters to modern life produces a continuous record of itself: the frequency and phase angle of an electrical grid sampled dozens of times a second, the order book of an exchange updating thousands of times a second, the vibration of a turbine bearing captured at tens of thousands of samples a second, the temperature, pressure and flow readings from every pump in a refinery. These records are time series, and the two questions most often asked of them are deceptively simple. What will happen next? And is what is happening now normal? The first question is forecasting. The second is anomaly detection. They are usually taught as separate disciplines, with separate methods and separate literatures, but in practice they are one problem seen from two sides. An anomaly is, very often, an observation a good forecaster would not have predicted. A failure warning is a forecast of an anomaly that has not yet arrived. Any system that does one well has most of what it needs to do the other. Why this moment is different For most of the twentieth century, the best tools for both questions were statistical models built by hand for one series at a time: exponential smoothing, autoregressive integrated moving average models, seasonal decomposition procedures developed by government statistical agencies to adjust employment and retail figures. These methods are still excellent, and a recurring theme of this book is that they remain the baseline any new method has to beat. But they share a limitation. Each model learns from one series, or a handful of related ones, and starts from nothing when it meets a new one. Deep learning promised something different: models that learn general patterns across thousands or millions of series, so that what is learned about the daily cycle of electricity demand in one city can sharpen the forecast for another. The first serious evidence that this worked came from retail and logistics forecasting in the late 2010s, where global neural models trained across huge product catalogues began to beat per-series statistics. The second wave came from the transformer, the architecture that had transformed language processing, and a run of papers between 2020 and 2022 adapted it to long-horizon forecasting with growing claims of success. Then, in 2022, a short paper showed that a single linear layer could outperform most of those transformers on their own benchmarks. That result forced the field to ask what the transformers had actually been learning, and the answers reshaped the architecture of everything that followed. The models that emerged after the reckoning, beginning with the patch-based transformers of 2023, look very different from their predecessors, and they became the foundation for something genuinely new: pretrained time-series foundation models, trained on tens or hundreds of billions of observations, that can produce a reasonable forecast for a series they have never seen without any training at all. By 2025 there were dozens of them, from Amazon, Google, Salesforce, IBM, Datadog, research laboratories and universities, and leaderboards tracking their progress month by month. At the same time, a second architectural line matured. State-space models, which descend from control theory rather than language, offered a way to process long sequences in linear time and to update a forecast one observation at a time with constant memory. Recurrent architectures, written off a few years earlier, came back in modernised form. For streaming applications, where a model must digest each new reading as it arrives and decide within milliseconds whether to raise an alarm, these designs have properties that transformers do not. The argument This book makes one argument and follows it through. Time-series foundation models work, where earlier adaptations of language architectures struggled, because of a small number of representational choices that make temporal data learnable: grouping observations into patches rather than treating each one as a token, normalising each series so that scale and level do not swamp shape, decomposing signals into trend and seasonal parts at several resolutions, and, for streaming use, carrying a compact state forward through time. None of these ideas is new in isolation. What is new is that, combined and trained at scale, they produce models that generalise across domains far better than anyone expected in 2022. But the second half of the argument matters as much as the first. In the settings where failure prediction has real consequences, which in this book means power grids, financial exchanges and industrial plants, these models earn their place only when they are embedded in an evaluation and decision discipline that most published benchmarks have lacked. Anomaly detection research in particular has been distorted for years by evaluation protocols that rewarded noise. Forecasting leaderboards have been distorted by test data leaking into pretraining corpora. The cost of running a large model is often a thousand times the cost of a gradient-boosted tree that is nearly as accurate. And the events that matter most, the blackout, the flash crash, the bearing seizure, are by definition rare and unlike the bulk of the training data. A foundation model is a powerful prior. It is not a substitute for knowing what a wrong answer costs. The ground covered The book opens by establishing what makes temporal data different from text, and why the classical statistical baselines remain so hard to beat. It then follows the transformer's encounter with forecasting, including the linear-model result that exposed its early weaknesses, and examines in detail the three ideas that rescued it: patch-based tokenisation, multiscale trend–seasonal decomposition, and the state-space and recurrent alternatives that handle long streams efficiently. With those foundations in place, it surveys the pretrained foundation models themselves, how they are built, what data they learn from, and how to read the evaluations that rank them. The second half turns from forecasting to detection and from methods to domains. A chapter on anomaly detection examines how the field's evaluation practices went wrong and what has replaced them. Three chapters then take the methods into the field: power grids, where forecasting errors cost money and detection failures cost blackouts; financial exchanges, where the signal is faint, the data adversarial and the timescales measured in microseconds; and industrial sensors, where labelled failures are scarce and models must often run on hardware bolted to the machine. A final chapter assembles the pieces into the design of a real-time failure prediction system, and the conclusion considers what remains unsettled. The reader is assumed to be intelligent and curious but not necessarily a specialist in machine learning. Technical terms are defined when they first appear, and a glossary collects the most important. There is no mathematics beyond what can be stated in a sentence, though the ideas are not simplified to the point of being wrong. Where the evidence is mixed, the book says so. The field is moving quickly, and some of the specific models named here will be superseded within a year or two. The representational ideas that make them work, and the discipline required to deploy them safely, are likely to last much longer. Chapter 1. Why Time Is Not Text The success of large language models made it tempting to believe that any sequence is, in the end, just a sequence. Words follow words, readings follow readings; train a big enough network on enough of them and it will learn whatever structure is there. That intuition is not entirely wrong, and the later chapters of this book describe how far it has been vindicated. But it hides a set of differences between text and temporal measurements that shaped every architectural decision in the field. Understanding them is the starting point for understanding why some methods work and others fail. The unit of meaning A word carries meaning on its own. The token "turbine" means something before you see the sentence around it, and a language model's vocabulary of a few tens of thousands of such tokens covers almost everything a person might write. A single reading from a sensor carries almost no meaning on its own. The number 49.97, read from a frequency meter, tells you nothing until you know it is measured in hertz, that the nominal value is 50, that it was 50.01 a second ago and 49.93 a second later, and that the grid is in continental Europe, where a sustained deviation of that size triggers automatic reserve activation. The meaning of a time-series observation lives almost entirely in its relationship to its neighbours: its level relative to the recent past, its slope, its position in a daily or weekly cycle, its deviation from what was expected. This has an immediate consequence for any architecture that processes sequences one element at a time. If each element is a single scalar reading, the model's attention or memory must do all the work of assembling local context before any higher-level pattern can be recognised. In language, by contrast, the tokeniser has already done much of that work by grouping characters into meaningful units. Chapter 3 shows that the single most important step in making transformers work on time series was to give them an equivalent of words: short windows of consecutive readings, called patches, treated as the basic unit. Scale, level and the problem of the absolute number The second difference is that numbers have magnitudes, and magnitudes vary enormously. The hourly electricity demand of a national grid is measured in tens of gigawatts; that of a single household in hundreds of watts. A stock might trade at four dollars or four thousand. Two series with identical shapes, one a scaled copy of the other, should be forecast in the same way, but a neural network that sees raw values will treat them as completely different inputs. Worse, the level of a single series often drifts. A sensor's baseline shifts after recalibration. Demand grows as a city expands. Prices wander with no tendency to return to any particular value. A model trained on one range of values may be asked to forecast in another range it has never seen. In statistical language, most real time series are nonstationary: their mean, variance and correlation structure change over time. Classical forecasting handled this by differencing (modelling changes rather than levels) or by explicit trend terms. Deep learning, after some years of painful experience, settled on a simpler and surprisingly powerful device: normalise each input window by its own mean and standard deviation before it enters the model, then reverse the normalisation on the output. The technique was formalised in 2022 as reversible instance normalisation, usually abbreviated RevIN, and a version of it sits at the front of nearly every modern forecasting model. It does not solve nonstationarity, but it removes the most damaging form of it, the shift in level and scale between training and use, and lets the network concentrate on shape. The pretrained foundation models of Chapter 6 go further, with scaling schemes chosen so that a series from any domain, at any magnitude, arrives at the model looking roughly comparable. Frequency, seasonality and multiple clocks Language has no clock. A sentence takes as long to read as the reader needs. Time series are indexed by time, and the sampling interval matters enormously. The same physical system observed every second, every hour and every day produces three series with different statistical character. Hourly electricity load has a pronounced daily cycle, a weekly cycle, and an annual cycle superimposed; the same load recorded daily shows only the weekly and annual cycles; recorded every few seconds it is dominated by noise and small fluctuations around a smooth curve. Seasonality, meaning patterns that repeat at fixed periods, is the most valuable structure in most real series, and it often comes in several overlapping periods at once. Retail sales have weekly and annual seasonality plus holiday effects that move from year to year. Traffic has rush-hour peaks that differ between weekdays and weekends. A model that must discover each period from scratch, with no notion of calendar time, is at a disadvantage against one that is told where in the day and week each observation falls. Many forecasting systems therefore add calendar features, and the trend–seasonal decomposition methods of Chapter 4 make the separation of these clocks an explicit architectural principle. The variety of sampling frequencies also poses a problem for any model meant to work across domains. A pretrained model that has learned what a daily cycle looks like in hourly data, a pattern repeating every twenty-four steps, must recognise the same cycle in fifteen-minute data, where it repeats every ninety-six steps. Some foundation models handle this by being told the frequency; others use different patch sizes for different frequencies; others simply learn from enough mixed data that they infer it. Many series at once A fourth difference is that real systems produce many series together. A substation reports voltage, current and phase angle on each of several lines. A jet engine reports temperatures and pressures at a dozen stations along its gas path. An exchange publishes prices and quantities at each level of the order book for each of thousands of instruments. These multivariate series are related, sometimes tightly and physically, as when current and power on the same line are linked by voltage, sometimes loosely and changeably, as when the correlation between two stocks rises in a crisis. It seems obvious that a model should exploit these relationships. In practice, as Chapter 3 explains, one of the surprising findings of recent years is that forecasting each channel independently with a shared model often works better than modelling the channels jointly, because joint models overfit to correlations that do not persist. The question of when to model cross-channel dependence, and how, has not been fully settled, and it matters especially for anomaly detection, where many of the most important failures show up not in any single channel but in a break in the usual relationship between them. Irregularity, gaps and the messiness of the real stream Benchmark datasets are clean. Real streams are not. Sensors drop out and come back. Communications links buffer data and deliver it late. Clocks drift, so that two series nominally sampled at the same instant are offset by a fraction of a second. Some systems report only on change, producing irregular timestamps. A meter may be replaced, producing a step change in level that reflects nothing about the system being measured. These problems are often dismissed as data engineering, outside the scope of modelling. In failure prediction they are central. A sensor that drops out may be the first sign of the failure itself. A step change after maintenance is not an anomaly in the physical process but will look like one to any naive detector. Missing data must be distinguished from zero, and late data from absent data. The streaming architectures of Chapter 5 and the system design of Chapter 12 return to these issues, because a model that is accurate on clean benchmarks but brittle under real stream conditions is of little practical use. The baselines that refuse to die Before any deep learning method is taken seriously, it must beat the classical baselines, and the history of forecasting is littered with sophisticated methods that did not. The clearest evidence comes from a series of open forecasting competitions organised by Spyros Makridakis and colleagues, beginning in 1982 and known as the M competitions. The early competitions repeatedly found that simple methods, especially exponential smoothing, matched or beat more elaborate statistical models on large collections of real business and economic series. Exponential smoothing deserves a short explanation, because its logic recurs throughout this book. In its simplest form it forecasts the next value as a weighted average of past values, with weights that decay geometrically into the past, so recent observations count most. Extensions add a smoothed trend term and smoothed seasonal terms, giving a family of models (often called ETS, for error, trend and seasonality) that can be fitted quickly, are hard to break, and capture the main structure of most business series. The autoregressive integrated moving average family, ARIMA, takes a different route, modelling each value as a linear combination of past values and past errors after differencing to remove trend. The fourth competition, M4, run in 2018 with 100,000 series, marked a turning point. The winning entry, by Slawek Smyl of Uber, was a hybrid that combined exponential smoothing with a recurrent neural network trained across many series at once. It was the first time a method involving neural networks had won an M competition, and it won by a substantial margin. But the organisers also noted that most pure machine-learning entries performed poorly, and that combinations of simple statistical methods remained among the strongest performers. The fifth competition, M5, in 2020, used Walmart retail data, and there the winners were dominated by gradient-boosted decision trees, particularly the LightGBM library, trained across thousands of related series with carefully engineered features. Two lessons from this history shape the rest of the book. First, global models, trained across many series rather than one at a time, can beat local statistical models when there is enough related data. That idea, scaled up enormously, is what a foundation model is. Second, the baselines are strong, and any claim of progress must be measured against them on fair terms. A seasonal naive forecast, which simply predicts that each value will equal the value one season ago, is a remarkably tough opponent for daily or weekly series with strong seasonality. Gradient-boosted trees remain the default choice in many industrial forecasting teams because they are fast, robust and accurate. A deep model that cannot beat them, at comparable cost, has not earned deployment. Error measures and what they reward Comparing forecasts requires a measure of error, and the choice of measure is not neutral. The mean absolute error and mean squared error are simple but depend on the scale of the series, so they cannot be averaged across series of different magnitudes. The mean absolute percentage error divides by the actual value, which makes it scale-free but explodes when actual values approach zero, a serious problem for intermittent demand or for any quantity that can cross zero. The measure most widely used in serious forecasting evaluation is the mean absolute scaled error, MASE, proposed by Rob Hyndman and Anne Koehler in 2006. It divides a forecast's absolute error by the in-sample error of a naive or seasonal naive forecast on the same series. A MASE below one means the forecast beats the naive benchmark; above one means it does worse. Because it is scaled by the series' own difficulty, it can be averaged across series, and it carries a built-in comparison against the simplest possible method. Point forecasts, a single number for each future step, are increasingly seen as insufficient. A grid operator scheduling reserves needs to know not only the expected demand but the range within which demand will fall with high probability. A risk manager needs the tail of the return distribution, not its mean. Probabilistic forecasts, which give a full predictive distribution or a set of quantiles, are evaluated by proper scoring rules such as the continuous ranked probability score, CRPS, which rewards both accuracy and appropriate sharpness and penalises overconfidence and underconfidence alike. A closely related measure, the weighted quantile loss, averages the pinball loss across a set of quantile levels. Nearly all the modern foundation models produce probabilistic forecasts, and nearly all serious benchmarks now evaluate them with CRPS or a quantile loss alongside MASE. For anomaly detection, as Chapter 8 explains at length, the choice of evaluation measure turned out to matter even more, and a widely used protocol rewarded methods for behaviour that had nothing to do with detecting anomalies. That story is one of the cautionary tales of the field. What a good architecture must respect Pulling these observations together gives a set of requirements that a deep learning architecture for time series must meet. It must build meaningful local units from individual readings, because a single reading means little. It must be insensitive to the absolute scale and level of the input, because these vary wildly across series and drift within them. It must capture structure at several time scales at once, from short-term fluctuations to long seasonal cycles. It must decide carefully how much to model relationships between channels, because those relationships are both valuable and unstable. It must tolerate missing, late and irregular data. For streaming use, it must update cheaply as each new reading arrives. And it must beat simple, fast, robust baselines by a margin that justifies its cost. The first generation of transformer forecasters, described next, met few of these requirements. Their failure, and the diagnosis that followed it, is what made the later successes possible. Chapter 2. The Transformer's First Encounter with Time The transformer was introduced in 2017 in a paper on machine translation titled "Attention Is All You Need." Its central mechanism, self-attention, lets every element of a sequence look directly at every other element and decide how much each one matters. In a recurrent network, information from the start of a long sentence must pass through every intermediate step to reach the end, and much of it is lost along the way. In a transformer, the first word and the last are one step apart. That directness, combined with the fact that attention can be computed in parallel across the whole sequence on modern hardware, made transformers dramatically easier to train at scale than the recurrent networks they replaced. For forecasting, the appeal was obvious. Long-horizon forecasting requires a model to relate the distant past to the distant future. Electricity demand next Tuesday depends on demand last Tuesday, and on the same week last year. A model that could attend directly across long windows seemed ideally suited. Between 2019 and 2022, a succession of papers adapted the transformer to long-sequence time-series forecasting, each claiming large improvements over its predecessors. Then the whole line was called into question. The cost of attention and the first adaptations The first obstacle was computational. Self-attention compares every element with every other, so its cost grows with the square of the sequence length. For a language model processing a few thousand tokens, that is manageable. For a forecaster looking back over several weeks of hourly data, or several days of minute-level data, with every reading treated as a token, the input easily reaches several thousand elements, and quadratic cost becomes prohibitive. The early papers therefore concentrated on making attention cheaper. LogTrans, in 2019, used sparse attention patterns that let each point attend to a logarithmically growing set of predecessors. Informer, published at the AAAI conference in 2021 and given one of its best paper awards, introduced what its authors called ProbSparse attention, which identified the small number of query positions whose attention distributions were far from uniform and computed full attention only for those. Informer also introduced a generative-style decoder that produced the whole forecast horizon in one forward pass rather than one step at a time, avoiding the accumulation of errors that plagues step-by-step autoregressive generation over long horizons. Informer's lasting influence, however, came from its benchmark. Its authors released a dataset of electricity transformer temperature readings, oil temperature and load measurements from two substations in China recorded over two years at hourly and fifteen-minute resolutions, known as ETT. Together with a handful of other public datasets covering electricity consumption, road traffic occupancy, weather, currency exchange rates and influenza-like illness, ETT became the standard test bed for long-horizon forecasting. For the next several years, almost every new architecture reported its results on the same small set of tables, forecasting horizons of 96, 192, 336 and 720 steps. Building decomposition into the transformer The next major step came from a group at Tsinghua University. Autoformer, presented at the NeurIPS conference in 2021, made two changes. First, it built series decomposition directly into the architecture. At several points inside the network, a moving-average filter split the signal into a smooth trend component and a seasonal remainder, and the two were processed along separate paths. The idea came from classical time-series analysis, where separating trend from seasonality has been standard practice for decades, but embedding it as a repeated internal operation rather than a one-off preprocessing step was new. Second, Autoformer replaced the dot-product attention between individual time points with what it called an auto-correlation mechanism. Instead of asking which past points resemble the current point, it asked which time lags produce the strongest self-similarity in the series, computed efficiently using the fast Fourier transform, and then aggregated whole sub-series aligned at those lags. In effect, the model looked for periods and compared the present with the corresponding moments in previous cycles. That is much closer to how a human analyst reasons about a seasonal series than point-to-point attention is. FEDformer, from Alibaba researchers at ICML in 2022, pushed further in the frequency domain. It argued that most real series have sparse representations in a Fourier or wavelet basis, meaning a handful of frequency components capture most of their structure, and it performed attention-like operations on a randomly selected subset of frequency modes. That reduced computational cost to linear in sequence length and, the authors argued, made the model more robust to noise. FEDformer also used a mixture of moving-average filters of different widths for decomposition, an early form of the multiscale decomposition that Chapter 4 examines. Other variants followed. Pyraformer built a pyramidal attention structure that summarised the series at multiple resolutions. Crossformer attempted to model dependencies across channels as well as across time. Each paper reported substantial error reductions on the standard benchmarks, often twenty or thirty percent relative to the previous state of the art. The cumulative impression was of a field making rapid progress. The linear shock In May 2022, a team from the Chinese University of Hong Kong and the International Digital Economy Academy posted a paper with a pointed title: "Are Transformers Effective for Time Series Forecasting?" Published at AAAI in 2023, it compared the leading transformer forecasters against a set of almost embarrassingly simple models. The simplest, which the authors called Linear, was a single linear layer mapping the input window directly to the output horizon, with one set of weights shared across all channels. A variant called NLinear subtracted the last value of the input window before the linear layer and added it back afterwards, a crude form of normalisation. A third, DLinear, first split the input into trend and remainder with a moving average, as Autoformer did, and then applied a separate linear layer to each before summing. On the standard long-horizon benchmarks, these linear models outperformed the transformers on most datasets and horizons, often by wide margins. On several datasets, the improvement over the best transformer exceeded twenty percent. The paper went further than a comparison. It probed what the transformers were actually doing. One experiment showed that increasing the look-back window, giving the model more history, should help a model that genuinely extracts long-range dependencies, yet the transformers' accuracy often failed to improve or even worsened as the window grew, while the linear models improved steadily. Another experiment shuffled the order of the input time points before feeding them to the transformers. A model that understands temporal order should be devastated by this. Several of the transformers were barely affected. The authors' diagnosis was that self-attention is, by construction, permutation-invariant: it treats its input as a set, not a sequence, and relies on added positional encodings to recover order. Those encodings, borrowed from language models, were a weak signal compared with the attention mechanism's tendency to compare values. On time-series data, where the most important information is in the precise ordering and spacing of observations, the transformers had been losing much of what mattered. The gains reported on the benchmarks, the paper suggested, came largely from other components, such as decomposition and the direct multi-step output, which the linear models also had. What the reckoning taught The reaction to the linear-model paper was not, in the end, to abandon transformers. It was to work out what they had been doing wrong. Several distinct lessons emerged, and each became a design principle for the next generation. The first lesson concerned the unit of attention. Attending between individual time points is a poor use of the mechanism. A single scalar reading carries almost no information about local shape, so the attention scores between two points are dominated by noise and by coincidental similarity of values. The fix, as Chapter 3 describes, was to attend between patches, short windows of consecutive readings that each carry a meaningful local pattern. The second lesson concerned channel mixing. The early transformers mixed all the channels of a multivariate series together at the input, embedding the vector of simultaneous readings as a single token. The linear models that beat them treated each channel independently, with shared weights. That independence turned out to be a strength, reducing overfitting to spurious cross-channel correlations and effectively multiplying the amount of training data, since every channel became a separate training example. The third lesson concerned normalisation. The NLinear trick of subtracting the last value, and the more principled reversible instance normalisation that appeared around the same time, made a large difference on datasets with distribution shift between training and test periods. Several of the transformers' failures were failures to cope with level changes, not failures of temporal modelling. The fourth lesson concerned benchmarks themselves. The standard datasets were few and small. ETT consists of just seven channels from two transformers. The exchange-rate dataset contains daily rates for eight currencies, and exchange rates are close to random walks, for which the best possible forecast is approximately the last observed value. A model that reported a large improvement on the exchange-rate data was likely exploiting some quirk of the split rather than predicting currencies. The influenza-like illness data is weekly and short. Results on such data have high variance and are easy to overfit through hyperparameter choice. Later analyses found that results on these benchmarks were sensitive to details such as whether the final incomplete batch of test data was dropped, a choice that had been inconsistently implemented across codebases. The fifth lesson was about humility. A model that does well because of its architecture should continue to do well when its components are ablated one at a time, when its input is perturbed, and when it is compared fairly against strong simple baselines with the same preprocessing. Many of the published transformer gains had not been subjected to those tests. The forecasting community had been through this before, in the M competitions, which had repeatedly shown that complexity does not guarantee accuracy. The linear-model paper was a reminder that the lesson needed relearning with each new architecture. Beyond the benchmarks It is worth asking why the transformers' weaknesses had gone unnoticed. Part of the answer is that the benchmark ecosystem was self-referential. Each new model compared itself against the previous transformers, on the same datasets, using code inherited from the same repositories. The question "does this beat a well-tuned linear model, or exponential smoothing, or a gradient-boosted tree?" was rarely asked, because the baselines in the tables were other transformers. Another part of the answer is that the long-horizon setting itself was somewhat artificial. Forecasting 720 hourly steps ahead, a month, from a fixed window of 96 steps, four days, is not a task most practitioners face in that form. Real forecasting systems typically use much longer histories, exogenous inputs such as weather forecasts and calendars, and hierarchical structure, and they care about calibrated uncertainty, not just mean squared error. The benchmark task tested something, but not obviously the thing that matters in deployment. None of this means the transformer was the wrong architecture. What it showed was that a powerful general-purpose mechanism, applied to a domain without regard for the domain's structure, can underperform a simple mechanism that respects that structure. The next generation of models kept the transformer but changed what it attended to, how it handled channels, and how it normalised its inputs. They also kept the decomposition and frequency-domain insights from Autoformer and FEDformer, which had been genuine contributions even if the attention mechanisms around them were not. The result, within a year, was a family of transformer forecasters that consistently beat the linear baselines, and a foundation for pretraining at scale. A note on what linear models can and cannot do Before moving on, it is worth being clear about the limits of the linear-model result, because it is sometimes cited as proof that deep learning is unnecessary for forecasting. A linear map from input window to output horizon can represent any fixed linear filter, which includes the seasonal naive forecast, linear trend extrapolation, moving averages and, to a good approximation, the forecasts of many classical statistical models. On data whose structure is predominantly linear and stationary after normalisation, such as the smooth seasonal patterns of electricity load or traffic occupancy, that is a great deal of power. What a linear model cannot do is change its behaviour depending on the input. It applies the same weights to a calm period and a volatile one, to a series in a rising regime and one in a falling regime, to the hour before a holiday and an ordinary hour. It cannot recognise that a particular shape in the recent past signals an imminent change. It cannot learn from one domain and transfer to another with different periods. And it cannot model interactions between channels except through a fixed linear combination. These are exactly the capabilities needed for the hardest forecasting problems and for anomaly detection, where the question is precisely whether the current behaviour is unusual given its context. The linear-model result showed that the early transformers were not delivering those capabilities. It did not show that they were not worth having. Chapter 3. Patches as Words In late 2022, a team from Princeton University and IBM Research published a paper whose title made a deliberate echo. A few years earlier, the vision transformer had been introduced under the title "An Image Is Worth 16x16 Words," describing the idea of cutting an image into small square patches and treating each patch as a token. The new paper was called "A Time Series Is Worth 64 Words," and its model, PatchTST, applied the same idea to temporal data. It was presented at the ICLR conference that year, and it became the template on which most subsequent forecasting transformers, and most of the foundation models, were built. The patch The mechanism is simple. Take an input window of, say, 512 consecutive readings from one channel. Slide a window of length 16 along it with a step of 8, so that consecutive patches overlap by half. That produces 64 patches, each containing 16 readings. Each patch is mapped by a small learned linear layer into a vector of the transformer's working dimension, a positional encoding is added to mark its place in the sequence, and the resulting 64 vectors are fed to a standard transformer encoder. At the output, the encoder's final representations are flattened and mapped by another linear layer to the forecast horizon. That is the whole idea, and its effects are large. Consider first the computational cost. Attention grows with the square of the number of tokens. Treating each of 512 readings as a token gives 512 squared, roughly a quarter of a million, pairwise comparisons per attention layer. Treating each of 64 patches as a token gives 64 squared, about four thousand. Patching with a stride of 8 reduces the attention cost by a factor of roughly 64. That saving can be spent on a much longer look-back window, which is exactly what long-horizon forecasting needs. More important than the saving is what each token now means. A patch of sixteen consecutive readings carries local shape: whether the series is rising or falling over that stretch, how curved it is, how noisy, whether it contains a peak. Attention between two patches compares two local shapes, which is a meaningful operation. Attention between two individual readings compares two numbers, which is mostly noise. Patching gives the transformer something like words, and the attention mechanism, which was designed to find relationships between meaningful units, can do what it does best. There is also a subtler benefit. Because each token now summarises a stretch of time, the positional encoding problem identified in the previous chapter becomes much less severe. Shuffling the order of patches still destroys information the model needs, but the information inside each patch is ordered by construction, since the linear embedding of a patch is not permutation-invariant. The model can no longer ignore temporal order within a patch, and the coarser order between patches is easier to encode. Channel independence PatchTST's second design decision was to treat each channel of a multivariate series independently. A dataset with seven channels became seven separate univariate series, each passed through the same transformer with the same weights. The model never sees two channels together, so it cannot learn cross-channel relationships directly. It learns a single, general mapping from the past shape of a series to its future shape, and applies it to every channel. This seems wasteful, and the authors were explicit that it was a choice made for empirical rather than theoretical reasons. When they compared channel-independent and channel-mixing versions of the model, independence won on most benchmarks. Several explanations have been offered. Independence multiplies the effective training set, because each channel becomes a separate example. It prevents the model from overfitting to cross-channel correlations that hold in the training period but not the test period. And it makes the model robust to the number and order of channels, so the same model can be applied to a dataset with seven channels or seven hundred. Later work refined the picture. When cross-channel dependence is strong, stable and physically grounded, as in a set of temperature sensors arranged along a pipe, modelling it helps. When it is weak or changeable, as in a basket of unrelated retail products, modelling it hurts. Most real datasets are a mixture. The practical consequence was a family of hybrid designs that process each channel independently through most of the network and then apply a limited, carefully regularised mechanism for sharing information across channels. Chronos-2, released by Amazon in October 2025, is a recent example: its transformer alternates between attention along time, within each series, and what its authors call group attention, across the series in a defined group at each patch position. Group membership is supplied by the user, so the same model can be run as a pure univariate forecaster, as a multivariate model across a set of related series, or as a model that forecasts one target using others as covariates. Inverting the problem A different and equally influential response came from Tsinghua University in late 2023. The iTransformer, presented at ICLR in 2024, inverted the usual arrangement. Instead of making each time step or patch a token and attending across time, it made each entire channel a token. The whole look-back window of one channel, perhaps 96 or 512 readings, was embedded as a single vector, and attention operated across channels. Temporal patterns within each channel were captured by the embedding and by feed-forward layers applied to each token independently. The logic was that, in the standard arrangement, a single token mixed readings from different channels that might measure entirely different physical quantities at different scales, making its embedding hard to interpret. In the inverted arrangement, each token represents one coherent physical variable, and attention learns which variables inform which. On datasets with many channels and meaningful cross-channel structure, such as traffic sensor networks with hundreds of detectors, iTransformer performed especially well. On datasets with few channels, the advantage was smaller. The comparison between PatchTST and iTransformer illustrates a broader point. There is no single right way to tokenise a time series, because the right unit depends on where the important structure lies. If it lies mainly in temporal shape within each channel, patch tokens are best. If it lies mainly in relationships between channels, variate tokens may be better. Many subsequent designs combine both. Quantisation: treating values as vocabulary A third approach, taken by the first version of Amazon's Chronos model in 2024, went further in borrowing from language modelling. Rather than embedding continuous values, Chronos converted them into discrete tokens. Each series was first scaled by its mean absolute value, so that series of different magnitudes became comparable. The scaled values were then quantised into a fixed number of bins, 4,096 in the published models, each bin becoming a token in a vocabulary. The resulting token sequence was fed to an unmodified T5 language model architecture, trained with the standard cross-entropy loss used in language models, and forecasts were produced by sampling tokens autoregressively and converting them back to values. The attraction of this design was that it required no architectural innovation at all. Every tool developed for language models could be used unchanged. Because the model outputs a probability distribution over bins at each step, it naturally produces probabilistic forecasts, and because the distribution is categorical rather than parametric, it can represent any shape, including multimodal distributions. The original Chronos paper showed that this simple approach, trained on a large corpus of public data supplemented by synthetic series, produced zero-shot forecasts competitive with models trained on the target datasets. The drawbacks are also clear. Quantisation discards fine resolution, which matters for some applications. The model has no built-in notion that bin 1,000 is close to bin 1,001; it must learn the ordering of its vocabulary from data. And generating one token per time step, autoregressively, is slow for long horizons. Amazon's own successor, Chronos-Bolt, abandoned quantisation in favour of patch-based inputs and direct multi-step quantile outputs, and was reported to be up to 250 times faster than the original with better accuracy. Chronos-2 continued in that direction. The quantisation idea has not disappeared; it survives in models such as Kronos, a foundation model for financial price data published in 2025, which uses a learned tokeniser to convert multi-dimensional price and volume records into discrete tokens. But for general forecasting, continuous patch embeddings have become the dominant choice. Choosing patch length If patches are words, patch length is vocabulary granularity, and it involves a real trade-off. Short patches preserve fine detail and allow the model to resolve sharp local events, but produce many tokens, raising cost and reducing the information each token carries. Long patches are cheap and informative but smear out short events and may straddle the boundaries of important features. The right length depends on the sampling frequency and the time scales of the structure in the data. For hourly data with a daily cycle, a patch of 16 or 24 readings covers most of a day, so each token represents roughly one daily cycle. For minute-level data, the same patch covers a quarter of an hour, which may be too short to capture the main structure. For data sampled at kilohertz rates, as in vibration monitoring, patches of hundreds or thousands of samples may be appropriate. Different foundation models resolve this differently. Google's TimesFM, first described in 2023 and published at ICML in 2024, used a fixed input patch of 32 readings and an output patch of 128, meaning each step of autoregressive generation produced 128 future values at once. Salesforce's Moirai, also published at ICML in 2024, used multiple patch sizes, choosing larger patches for higher-frequency data, with a separate input projection for each size. Its successor, Moirai 2.0, published in November 2025, abandoned this in favour of a single patch size, reporting that the simpler design worked at least as well. TiRex, a recurrent foundation model discussed in Chapter 5, uses non-overlapping patches of 32. The convergence on patches of a few dozen readings for general-purpose models reflects the mix of frequencies in their training data, most of which is hourly, daily or sub-hourly. Table 1 sets out the main tokenisation strategies, the unit each token represents, and their principal strengths and weaknesses, as discussed in this chapter. Table 1. Strategies for turning a time series into tokens. Strategy What one token represents Representative models Main strength Main weakness Point tokens One reading, or one vector of simultaneous readings Informer, Autoformer, FEDformer Full temporal resolution Tokens carry little meaning; quadratic cost Patch tokens A short window of consecutive readings from one channel PatchTST, TimesFM, Moirai, Chronos-Bolt, TiRex Meaningful local shape; far fewer tokens Patch length must suit the data's time scales Variate tokens The whole look-back window of one channel iTransformer Captures cross-channel structure directly Temporal detail compressed into one embedding Quantised value tokens One reading mapped to a discrete bin Chronos (original), Kronos Reuses language-model machinery unchanged; flexible distributions Loses resolution; slow autoregressive generation Self-supervised pretraining on patches Patching also opened the door to self-supervised pretraining, which is the mechanism by which foundation models learn from unlabelled data. In language, models learn by predicting masked or next words. With patches, the analogous tasks are predicting masked patches from their surroundings, or predicting the next patch from the preceding ones. The PatchTST paper itself included a self-supervised variant: randomly mask a fraction of the input patches, train the transformer to reconstruct them, then fine-tune the pretrained model on the forecasting task. The pretrained version outperformed the supervised one on several benchmarks, and a model pretrained on one dataset transferred usefully to others. That result, modest in scale, was an early indication that patch-based transformers could learn general representations of temporal shape, and it pointed directly toward the foundation models of Chapter 6. Masked reconstruction and next-patch prediction encourage different capabilities. Masked reconstruction, used in the self-supervised PatchTST and by Carnegie Mellon's MOMENT model, trains the model to understand a patch in context from both sides, which is useful for imputation of missing values and for anomaly detection, where the question is whether an observed patch matches what its context would predict. Next-patch prediction, used by decoder-only models such as TimesFM, trains the model to extrapolate, which is what forecasting requires. Some recent models combine both, or use masking strategies designed to mimic the conditions of multi-step forecasting. TiRex's contiguous patch masking, for example, hides runs of consecutive patches during training so that the model learns to forecast across gaps of the same kind it will face when producing long horizons. Normalisation inside and around the patch Patching interacts closely with normalisation. In PatchTST and most of its successors, the input window is normalised by its mean and standard deviation before patching, using reversible instance normalisation, and the forecast is denormalised afterwards. That handles differences in level and scale across series and over time. But normalising the whole window by a single mean and standard deviation has a weakness. If the window contains a regime change, such as a step change in level halfway through, the statistics are a blend of two regimes, and the normalised series has an artificial shape. If the window contains an outlier, the standard deviation is inflated and the rest of the series is compressed toward zero. Several refinements have been proposed: normalising each patch separately, using robust statistics such as the median and interquartile range, or applying nonlinear transforms that compress large values. Chronos-2, for instance, standardises its input and then applies an inverse hyperbolic sine transform, which behaves like a logarithm for large values and like the identity near zero, before patching. For anomaly detection, where the input may contain exactly the outliers one is trying to detect, the choice of normalisation can determine whether the anomaly is visible to the model at all. Why patches mattered It is now clear, looking back, that patching was the single most important change in the transition from the first generation of time-series transformers to the second. It addressed the unit-of-meaning problem directly, gave each token a local shape to represent, made attention computationally affordable over long windows, and created a natural target for self-supervised learning. Combined with channel independence and instance normalisation, it produced a transformer that reliably beat the linear baselines that had embarrassed its predecessors. Patching did not, on its own, address the multiscale nature of temporal structure. A patch of fixed length captures structure at one scale; the trend over months and the fluctuation within minutes require different treatment. Nor did it make the transformer efficient for streaming, where each new reading arrives one at a time and the model must update without recomputing attention over the whole window. Those two problems, multiscale structure and streaming efficiency, are the subjects of the next two chapters. Chapter 4. Trend, Season and Residual at Many Scales Every analyst who has looked at a plot of monthly retail sales or hourly electricity demand has performed a decomposition in their head. There is a slow drift, upward or downward, over months and years. There is a pattern that repeats, every day or every week or every year. And there is what is left over: the irregular wiggle, the surprise, the part that neither the drift nor the cycle explains. Separating a series into these three components, trend, seasonality and residual, is one of the oldest ideas in time-series analysis, and it turns out to be one of the most useful ideas in deep forecasting too. The reasons are specific, and the best modern architectures build decomposition into their structure at several scales at once. The classical inheritance The formal decomposition of economic time series developed largely in government statistical agencies, which needed to publish seasonally adjusted figures for employment, retail sales and industrial production so that a rise in December shopping would not be mistaken for an economic boom. The United States Census Bureau's X-11 method, introduced in the 1960s, used a sequence of moving averages to estimate trend and seasonal factors, and its descendant, X-13ARIMA-SEATS, remains in official use. These methods were designed for monthly and quarterly data with a single seasonal period. In 1990 Robert Cleveland and colleagues published STL, short for seasonal-trend decomposition using LOESS, where LOESS is a method for fitting smooth curves through local weighted regression. STL alternates between estimating the seasonal component, by smoothing the values at each position in the cycle across successive cycles, and estimating the trend, by smoothing the series after the seasonal component is removed. It is robust to outliers, handles any seasonal period, and allows the seasonal pattern to change slowly over time. Later extensions, such as MSTL, applied it repeatedly to handle multiple seasonal periods, a daily cycle and a weekly cycle in hourly data, for example. The value of decomposition for forecasting is that each component is easier to forecast than the whole. A trend is smooth and can be extrapolated with a line or a gentle curve. A seasonal pattern repeats and can be projected forward by copying the most recent cycle, perhaps adjusted for slow change. The residual, if the decomposition has done its job, is close to random noise, and its best forecast is near zero. Forecasting the components separately and adding them back together often beats forecasting the raw series directly, because each sub-problem matches a simple model well. The value of decomposition for anomaly detection is equally direct. If the trend and seasonality are removed, what remains is the residual, and an anomaly is a residual that is unusually large. Twitter's open-source anomaly detection package, released in 2015, used exactly this idea: an STL-style decomposition followed by a robust statistical test for outliers in the residual, an approach its authors called seasonal hybrid extreme studentised deviate. It detected spikes in tweet volume and server metrics without being fooled by the regular daily cycle of user activity. Many industrial monitoring systems still rely on residual-based detection of this kind. Decomposition as architecture: N-BEATS The first deep learning model to make decomposition central to its architecture, and to demonstrate that it worked at scale, was N-BEATS, introduced by researchers at Element AI in 2019 and published at ICLR in 2020. N-BEATS is not a transformer. It is built from stacks of fully connected blocks, each of which takes the input window, passes it through several layers, and produces two outputs: a backcast, the block's reconstruction of the input, and a forecast, its contribution to the future. The backcast is subtracted from the input before it passes to the next block, so each block sees only what the previous blocks failed to explain. The forecasts from all blocks are summed. This doubly residual design means that each block acts like a stage in a decomposition, peeling off one layer of structure and passing the remainder on. In its interpretable configuration, N-BEATS constrained the blocks in the first stack to produce outputs that were low-degree polynomials, capturing trend, and the blocks in the second stack to produce outputs that were sums of sines and cosines, capturing seasonality. The result was a forecast that could be split into a trend part and a seasonal part, each visible and checkable by an analyst. On the M4 competition data, N-BEATS outperformed the winning hybrid of exponential smoothing and recurrent networks that had won the competition the previous year, and did so with a pure deep learning model. That was a significant moment: it showed that a neural network with the right inductive bias could beat the best statistical hybrids on a large, varied collection of real series. The interpretable configuration performed nearly as well as the unconstrained one, suggesting that the trend–seasonality structure was not a handicap but a helpful prior. N-HiTS, a successor published at AAAI in 2023 by researchers at Carnegie Mellon and Nixtla, added an explicitly multiscale dimension. Each stack in N-HiTS sees the input at a different resolution, through pooling layers that downsample it by different factors, and produces a forecast at a correspondingly coarse resolution that is then interpolated to the full horizon. The stacks that see heavily downsampled input capture slow, long-horizon structure cheaply; those that see full resolution capture fast fluctuations. The forecast is assembled hierarchically, from coarse to fine. On long-horizon benchmarks, N-HiTS matched or beat the transformers of its day at a fraction of the computational cost. Decomposition inside the transformer Autoformer, described in Chapter 2, brought decomposition inside the transformer, using a moving average at several points in the network to split hidden representations into trend and seasonal parts. Its decomposition was the component that the linear-model paper borrowed for DLinear, and arguably the component that did much of the work. FEDformer extended it by using a mixture of moving averages with different window widths, weighted by learned coefficients, so that the network could choose the appropriate smoothing scale. These internal decompositions have a known weakness. A moving average of width k needs k values centred on each point, so at the end of the input window, which is exactly where the forecast begins, it must pad the series, usually by repeating the last value. The trend estimate at the most recent points is therefore biased toward flatness, and any genuine change in trend at the end of the window is underestimated. STL handles this better, with locally weighted regression that adapts at the boundaries, but it is harder to embed in a differentiable network. Some later designs use learnable decomposition, in which the network learns its own filters for separating slow and fast components, while others use frequency-domain methods that do not suffer the same boundary issue in the same form. Periods as a second dimension: TimesNet TimesNet, published at ICLR in 2023 by the Tsinghua group behind Autoformer, took a different approach to seasonality. It begins by computing the Fourier transform of the input window to identify its dominant periods, say 24 and 168 for hourly data with daily and weekly cycles. For each dominant period, it reshapes the one-dimensional series into a two-dimensional array, with one row per cycle and one column per position within the cycle. A series of 720 hourly readings with a period of 24 becomes an array of 30 rows and 24 columns. In this arrangement, two kinds of variation become two spatial directions. Reading along a row shows how the series changes within one cycle: the shape of a single day. Reading down a column shows how the same moment in the cycle changes from one cycle to the next: how demand at 6 p.m. evolves over a month. TimesNet then applies two-dimensional convolutional filters, borrowed from image processing, which capture both kinds of variation together. The outputs for each period are reshaped back to one dimension and combined with weights proportional to the strength of each period in the Fourier spectrum. TimesNet was designed as a general-purpose backbone and reported strong results not only on forecasting but on imputation, classification and anomaly detection. Its central insight, that a seasonal series has a natural two-dimensional structure and that variation within a cycle and variation across cycles are different things, is a decomposition in a deeper sense. It does not subtract seasonality; it reorganises the data so that seasonal structure becomes geometrically explicit. Mixing scales: TimeMixer TimeMixer, published at ICLR in 2024 by researchers at Ant Group and Tsinghua, combined decomposition with multiscale processing in an architecture built entirely from simple fully connected layers, without attention. It begins by producing several versions of the input at progressively coarser resolutions through average pooling: the original hourly series, a two-hourly version, a four-hourly version, and so on. Each version is decomposed into seasonal and trend parts. Its key observation is that seasonal and trend information should flow between scales in opposite directions. Seasonal patterns are best understood at fine scales, where individual cycles are resolved, and the fine-scale seasonal information should be aggregated upward to inform the coarser scales. Trend patterns are best understood at coarse scales, where noise is averaged away and slow movements are clear, and coarse-scale trend information should be propagated downward to inform finer scales. TimeMixer implements this with a bottom-up mixing of seasonal components and a top-down mixing of trend components, followed by a set of predictors, one per scale, whose outputs are combined into the final forecast. The design embodies a principle that an experienced forecaster would recognise: to forecast the trend, look at the smoothed data; to forecast the cycle, look at the detail; and let each inform the other. On the standard long-horizon benchmarks, TimeMixer outperformed PatchTST and iTransformer on many datasets, with lower computational cost. Why decomposition helps a neural network It might be thought that a sufficiently large neural network would learn to decompose its input without being told. In principle it could. In practice, building decomposition into the architecture helps for several reasons. First, it reduces the effective complexity of the function to be learned. A network that must map raw input directly to forecast must simultaneously learn to extrapolate trends, to project seasonal patterns forward, and to ignore noise. A network that receives trend and seasonal components separately can learn each mapping with fewer parameters and less data. Second, it improves extrapolation. Neural networks are notoriously poor at extrapolating beyond the range of their training data. A trend component that is extrapolated by a simple linear or polynomial head, as in N-BEATS or DLinear, can continue a rising trend into values the network has never seen, where an unconstrained network might flatten out or behave erratically. Third, it improves robustness to distribution shift. When the level of a series changes, the trend component absorbs most of the change, and the seasonal and residual components, which carry most of the shape information, remain comparable to what the network saw in training. Fourth, it supports interpretability. An operator who can see that a forecast consists of a rising trend plus a familiar daily cycle plus a small residual can judge whether the forecast is plausible. An operator presented with an unexplained number has no such check. In high-stakes settings such as grid operation, interpretability is not a luxury, because the operator must decide whether to trust the forecast before committing reserves. Multiple clocks in the field The importance of multiscale decomposition becomes clearest in the domains examined later in this book. Electricity demand has a daily cycle driven by human activity, a weekly cycle driven by the working week, an annual cycle driven by heating and cooling, and holiday effects that occur on different dates in different years. Superimposed on these are weather-driven fluctuations at the scale of hours to days, and a slow trend driven by economic growth, electrification and efficiency. A forecaster that handles only one scale well will make systematic errors at the others. Industrial sensors present a different multiscale structure. A rotating machine produces vibration at its rotational frequency and its harmonics, at frequencies of tens to thousands of hertz, modulated by load changes over seconds to minutes, and slowly altered by wear over weeks to months. A failing bearing typically first appears as a faint high-frequency component, often detectable only after demodulation of the signal, that grows over days or weeks before any change is visible in the overall vibration level. Detecting it requires separating the slow degradation trend from the fast operational fluctuations, which is a decomposition problem at widely separated scales. Financial series have yet another structure. Intraday trading volume and volatility follow a characteristic U-shaped pattern, high at the open and close and lower at midday. Volatility clusters, with turbulent periods following turbulent periods, over days to weeks. Price levels have essentially no predictable trend over short horizons. Here decomposition helps less with forecasting the level, which is close to unpredictable, than with forecasting volatility and volume, and with recognising when the normal intraday pattern has broken down. The limits of decomposition Decomposition is a strong prior, and like all strong priors it can mislead when its assumptions fail. A series without stable seasonality, such as intermittent demand for spare parts, gains little from a seasonal component and may be harmed by a model that hallucinates one. A series whose seasonal period changes, such as the shift in daily demand patterns during the COVID-19 lockdowns of 2020, will be poorly served by a seasonal component estimated from the previous year. And the separation between trend and seasonality is not unique: a slow seasonal cycle can be absorbed into the trend if the smoothing window is long enough, and a fast trend change can leak into the seasonal component. For anomaly detection, decomposition raises a specific hazard. If an anomaly occurs during the period from which the seasonal component is estimated, it may be absorbed into the seasonal pattern and then subtracted from future observations, creating a spurious anomaly one cycle later, a phantom echo. Robust decomposition methods, which downweight outliers when estimating components, reduce this risk but do not eliminate it. The foundation models of Chapter 6 do not, for the most part, impose explicit decomposition. They rely instead on normalisation, patching and very large training sets from which the network learns to recognise trend and seasonality implicitly. Whether explicit decomposition still helps such models, or whether scale makes it redundant, is an open question. The evidence so far suggests that for the largest models trained on the most varied data, explicit decomposition adds little to average benchmark accuracy, but that in specific domains with strong and well-understood seasonal structure, such as electricity demand, decomposition-based features and architectures remain competitive and considerably cheaper to run. Chapter 5. State, Memory and the Streaming Problem A transformer reads a window. It takes a fixed stretch of history, processes all of it at once, and produces an output. When a new reading arrives, the window shifts by one step and, in the simplest implementation, the whole computation starts again. For offline forecasting, where a model produces tomorrow's demand forecast once a night, this is perfectly acceptable. For monitoring a live stream, where thousands of sensors report every second and a model must decide after each reading whether something is going wrong, it is wasteful at best and infeasible at worst. The natural architecture for a stream is one that carries a compact summary of the past forward in time and updates it cheaply as each new observation arrives. Engineers have built such systems for decades. The Kalman filter, developed around 1960 and used ever since in navigation, tracking and control, maintains an estimate of a system's hidden state and its uncertainty, updating both with each new measurement in a fixed amount of computation. Recurrent neural networks did the same thing with learned rather than hand-specified dynamics. That idea, a learned state updated through time, has returned to the forefront of sequence modelling through state-space models and modernised recurrent networks, and it matters especially for real-time failure prediction. The rise and fall of the recurrent network Recurrent neural networks process a sequence one element at a time, maintaining a hidden state vector that is updated at each step as a function of the previous state and the current input. The long short-term memory network, LSTM, introduced by Sepp Hochreiter and Jürgen Schmidhuber in 1997, added gating mechanisms that let the network learn when to retain information and when to discard it, which made it possible to learn dependencies over hundreds of steps rather than a handful. Through the 2010s, LSTMs and the closely related gated recurrent units were the dominant architecture for sequence modelling, including time-series forecasting. Amazon's DeepAR, published in 2020, used an LSTM to produce probabilistic forecasts across large catalogues of related products, and it became one of the most widely deployed deep forecasting methods in industry. NASA's Jet Propulsion Laboratory used LSTMs to detect anomalies in spacecraft telemetry, in work published in 2018 that Chapter 11 returns to. Recurrent networks had two weaknesses. First, training them is inherently sequential: the state at step 1,000 depends on the state at step 999, which depends on step 998, and so on, so the computation cannot be parallelised across time. On modern hardware, which achieves its speed through massive parallelism, this made recurrent networks slow to train on long sequences. Second, despite gating, they still struggled to retain information over thousands of steps. The transformer, which could be trained in parallel and could relate any two positions directly, displaced them almost entirely by the early 2020s. What was lost in that displacement was the recurrent network's natural fit to streaming. A trained recurrent network processes each new input in constant time and constant memory, regardless of how long it has been running. A transformer's cost per new input grows with the length of the context it attends to. For a monitoring system running indefinitely on a high-rate stream, that difference is fundamental. Structured state spaces The modern revival of state-based models began not in time-series forecasting but in a line of research at Stanford University led by Albert Gu and Christopher Ré on how to build sequence models that could handle very long dependencies efficiently. The starting point was the continuous-time linear state-space model from control theory, in which a hidden state evolves according to a linear differential equation driven by the input, and the output is a linear function of the state. This is the same mathematical object that underlies the Kalman filter and much of classical signal processing. A linear state-space model has a remarkable property: it can be computed in two equivalent ways. Run as a recurrence, it updates its state one step at a time, in constant time per step, which is ideal for streaming inference. Unrolled over a whole sequence, the same model is equivalent to a convolution of the input with a fixed kernel, which can be computed for the whole sequence in parallel using the fast Fourier transform, which is ideal for training. A model with this dual form can be trained like a convolutional network and deployed like a recurrent one. The difficulty was in choosing the state dynamics so that the model could remember information over long ranges without the state exploding or vanishing. A 2020 paper by Gu and colleagues, introducing a framework called HiPPO, derived specific state matrices that cause the hidden state to maintain an optimal compressed summary of the input history, in the sense of projecting the history onto a set of polynomial basis functions. The structured state-space sequence model, S4, published at ICLR in 2022, combined these principled dynamics with an efficient algorithm for computing the convolution kernel. On the Long Range Arena, a benchmark of tasks requiring dependencies over thousands of steps, S4 dramatically outperformed transformers, and it was the first model to solve the benchmark's hardest task, which required reasoning over sequences of 16,000 elements. S4 and its successors were applied to time-series forecasting with some success, but they had a limitation for the hardest forecasting and detection problems. Their dynamics were linear and time-invariant: the same transformation was applied at every step, whatever the input. Such a model cannot decide, based on what it is currently seeing, to remember one thing and forget another. It applies the same fixed filter to a calm period and to a crisis. Selection: Mamba In December 2023, Gu, now at Carnegie Mellon, and Tri Dao of Princeton introduced Mamba, which removed that limitation. Mamba's key innovation was to make the state-space parameters functions of the input, so that at each step the model could choose how much of the new input to absorb into its state and how much of the existing state to retain. The authors called this selection. A selective state-space model can, in principle, ignore irrelevant inputs entirely and preserve important information indefinitely, or reset its state when it detects a change of context. Selection breaks the convolutional equivalence, because the dynamics now change from step to step. Mamba compensated with a hardware-aware parallel scan algorithm that computes the recurrence efficiently on graphics processors, keeping the state in fast on-chip memory. The result was a model whose training cost grows linearly with sequence length, rather than quadratically as in a transformer, and whose inference cost per new element is constant. On language modelling, Mamba matched transformers of similar size at the scales tested and generated text several times faster. A follow-up, Mamba-2, published in 2024, showed a formal connection between selective state-space models and a restricted form of attention, and used it to achieve further speed improvements. For time series, Mamba prompted a wave of adaptations. TimeMachine, published in 2024, used four Mamba modules arranged to capture both channel-mixing and channel-independent structure at two resolutions. S-Mamba, presented in a paper titled "Is Mamba Effective for Time Series Forecasting?", applied a bidirectional Mamba across channels, in the inverted arrangement introduced by iTransformer, with a simpler feed-forward treatment of time. These models generally matched or modestly exceeded the best transformers on the standard long-horizon benchmarks while using less memory and computation, especially at long look-back windows. The gains on benchmarks were not as dramatic as the gains on language or on synthetic long-range tasks, and the reason is instructive. Most of the standard forecasting benchmarks do not require dependencies over thousands of steps; a look-back of a few hundred steps captures their main structure, and at that length, transformers with patching are already efficient. Where state-space models show their real advantage is at much longer contexts, at high sampling rates, and in streaming deployment, which are exactly the conditions that the standard benchmarks underrepresent and that real-time failure prediction requires. The return of the LSTM A parallel revival came from the original inventors of the LSTM. In 2024, a team led by Hochreiter at the Johannes Kepler University in Linz and the company NXAI introduced xLSTM, an extended LSTM with two new cell types. One, the mLSTM, uses a matrix-valued memory and can be trained in parallel, much like a linear attention mechanism. The other, the sLSTM, retains a genuinely recurrent scalar memory with new exponential gating and normalisation, which cannot be fully parallelised across time but can, in principle, track state in ways the parallel architectures cannot. That distinction matters for an argument that has gained attention in sequence modelling theory. Some tasks require a model to track state through a long sequence of updates, such as following the parity of a stream of bits, or counting how many times a condition has been met. Theoretical analyses have suggested that transformers and parallelisable state-space models, because their computation over a sequence can be expressed in a limited number of parallel steps, cannot solve certain state-tracking problems of this kind at arbitrary length, whereas a true nonlinear recurrence can. TiRex, a time-series foundation model released by NXAI in 2025 and presented at NeurIPS that year, built on this argument. It is a decoder-only model using sLSTM blocks exclusively, with patches of 32 values and a quantile output head. With only 35 million parameters, an order of magnitude fewer than several competitors, it reported the best zero-shot probabilistic accuracy on the GIFT-Eval benchmark at the time of its publication, and strong results on Amazon's Chronos benchmark. Its authors attributed the advantage, particularly on long-horizon forecasts, to the sLSTM's state-tracking ability, which lets the model carry both predicted state and uncertainty forward across patches as it generates a long forecast. In their ablations, the variant using only sLSTM blocks performed best, and the variant using only the parallelisable mLSTM performed worst. Whether state tracking in this formal sense is what really drives TiRex's accuracy, or whether other design choices matter more, is not yet settled. But the result was a striking demonstration that a recurrent architecture could compete at the top of a foundation-model leaderboard dominated by transformers, at a fraction of the size. What streaming really requires The comparison between architecture families comes down to how they behave in four respects: the cost of training on long sequences, the cost of processing one new observation during deployment, the memory required to keep running indefinitely, and the capacity to track state. Table 2 summarises these for the main families discussed in this book. The entries describe the architectures in their standard forms; specific implementations may differ. Table 2. How the main architecture families behave on long sequences and live streams. Family Training cost as context grows Cost per new reading in deployment Memory while streaming Representative time-series models Patch transformer Quadratic in number of patches Grows with context length Grows with context, or fixed window PatchTST, TimesFM, Moirai, Chronos-2 Linear or MLP mixer Linear in window length Recompute fixed window; very cheap Fixed window DLinear, TimeMixer, Tiny Time Mixers Structured or selective state space Linear, parallel scan or convolution Constant Constant state S4 variants, TimeMachine, S-Mamba Recurrent (sLSTM) Linear but sequential Constant Constant state TiRex, DeepAR (LSTM) The table understates one practical point. A transformer with a key-value cache, the technique used in language models to avoid recomputing attention over previous tokens, can process each new token at a cost that grows linearly rather than quadratically with context, and with patching, the number of tokens is modest. For many monitoring applications, a patch transformer that reprocesses a window of a few thousand readings every second is entirely affordable on modern hardware. The constant-cost advantage of state-based models becomes decisive only when the number of streams is very large, the sampling rate is very high, the context needed is very long, or the hardware is very constrained, as on an embedded controller bolted to a pump. State as a detector There is a deeper reason why state-based models suit anomaly detection. A model that carries a learned summary of the past is, in effect, carrying an expectation about what comes next. When the next observation arrives, the model can compare it with that expectation, and the size of the mismatch is a natural anomaly score. This is precisely how the Kalman filter has long been used for fault detection in aerospace and process control: the innovation, the difference between the predicted and observed measurement, is monitored, and a persistent or large innovation signals a fault. A learned state-space or recurrent model generalises this to complex, nonlinear systems whose dynamics no engineer has written down. It can be trained on normal operation only, which matters because failures are rare and labelled examples scarce, and it produces a prediction error at every step, which can be monitored in real time. The selective mechanism in Mamba-style models adds the possibility that the model learns to reset or reweight its state when the context changes, such as at the start of a new operating mode, which reduces false alarms caused by legitimate transitions. The same property creates a hazard. A model with long memory that has absorbed an anomaly into its state may treat subsequent anomalous behaviour as normal, because its expectation has adapted. A sensor that drifts slowly upward over weeks may never produce a large prediction error, because the model's state drifts with it. This is the classic problem of adaptive detectors, and it has no purely architectural solution. It requires monitoring at several time scales, comparing the model's state against a reference from known-good operation, and periodically checking whether the system's baseline has moved. Chapter 12 returns to these design choices. Hybrid designs The boundaries between families are increasingly blurred. Several recent language-model architectures interleave attention layers with state-space or recurrent layers, using attention for precise retrieval over a moderate window and state-space layers for efficient long-range summarisation. The same pattern is appearing in time-series models. A plausible design for a streaming monitor uses a state-space or recurrent layer to maintain a running summary over hours or days, and a patch transformer over the most recent minutes, combining the cheap long memory of the first with the precise local pattern-matching of the second. There is also a growing recognition that the right architecture depends on the deployment conditions as much as on the data. A model that will run once a night on a cloud server to produce day-ahead forecasts can be large, attention-based and expensive. A model that must score every reading from ten thousand sensors within a hundred milliseconds, on hardware at a substation or a factory, must be small and state-based. The foundation models described in the next chapter were mostly developed for the first setting. Adapting them to the second, through distillation into smaller models, quantisation to lower numerical precision, or architectural choices like TiRex's, is one of the most active areas of practical work. Chapter 6. Pretraining at Scale: The Foundation Models A foundation model, in the sense the term has acquired since about 2021, is a large model trained on a broad body of data that can be adapted to many downstream tasks, often with little or no task-specific training. Language models are the canonical example: a model trained to predict the next word across a large fraction of the written internet can then translate, summarise, answer questions and write code. The question that animated time-series research from 2023 onward was whether the same could be done for temporal data. Could a single model, trained on a large and varied collection of time series, produce good forecasts for a series it had never seen, from a domain it had never encountered, without any training on that series at all? By 2025 the answer was clearly yes, with qualifications that the next chapter examines. How these models are built, what they are trained on, how their architectures differ and what they output determine where that answer holds. Zero-shot forecasting and why it is surprising A conventional forecasting model, statistical or neural, is fitted to the history of the series it will forecast, or to a collection of closely related series. A zero-shot model is not. It receives a context window, the recent history of a new series, and produces a forecast directly, using only what it learned during pretraining on other data. In the language of large language models, the context window plays the role of the prompt, and the model performs in-context learning: it infers the relevant patterns, such as the period of the seasonality, the direction of the trend and the level of noise, from the context alone. That this works at all is not obvious. Time series from different domains have very different statistical character. The daily sales of a shop, the hourly temperature in a city, the minute-by-minute CPU load on a server and the weekly count of influenza cases share little in surface terms. What they share, the foundation-model results suggest, is a vocabulary of temporal shapes: trends of various curvatures, cycles of various periods and shapes, level shifts, spikes, decays, noise of various colours. A model that has seen enough examples of these shapes, in enough combinations and at enough scales, can recognise them in a new series and extrapolate them sensibly. The practical appeal is large. Many organisations have thousands or millions of series, many of them short, new or sparsely observed, and cannot afford to build and maintain a separate model for each. A zero-shot model that produces a reasonable forecast for any of them, immediately, is valuable even if specialised models would be slightly more accurate. For anomaly detection, a pretrained model that already knows what normal temporal behaviour looks like across many domains offers a starting point for systems where labelled failures are scarce. The first generation The first models marketed as time-series foundation models appeared in 2023. TimeGPT-1, from the forecasting software company Nixtla, was described in a technical report in October of that year as a transformer trained on over 100 billion data points from public sources across finance, economics, demographics, healthcare, weather, energy, web traffic and other domains. It was offered as a commercial service accessed through an application programming interface rather than as downloadable weights. Lag-Llama, from a group of academic and industrial researchers, was an open decoder-only transformer modelled on the LLaMA language-model architecture, which used lagged values of the series, the value one day ago, one week ago and so on, as input features, and produced probabilistic forecasts through a parametric output distribution. These early models established the concept but left open how far it could be pushed. The decisive contributions came in 2024, from several large industrial laboratories working in parallel. Four designs from 2024 Amazon's Chronos, described in Chapter 3, took the most literal route from language modelling: scale each series by its mean absolute value, quantise it into 4,096 bins, and train an unmodified T5 language-model architecture on the resulting token sequences. The models ranged from about 8 million to 710 million parameters. The training corpus combined a large collection of public datasets with two kinds of augmentation. One, called TSMixup, created new training series by taking random convex combinations of existing ones, blending, say, a retail series with an energy series to produce a plausible new shape. The other, called KernelSynth, generated entirely synthetic series by sampling from Gaussian processes, statistical models that produce random smooth functions, using randomly composed combinations of kernels representing trends, periodicities and noise. The use of synthetic data turned out to be important, and it has become standard practice. Google's TimesFM, described in a paper presented at ICML in 2024, was a decoder-only transformer with 200 million parameters, trained on about 100 billion time points. Its training corpus drew heavily on Google Trends search-interest data and Wikipedia page-view counts, which provide millions of real series at hourly, daily, weekly and monthly granularities, supplemented by synthetic and public data. It used input patches of 32 readings and output patches of 128, so that each step of generation produced a long stretch of forecast, reducing the number of autoregressive steps and the accumulation of errors over long horizons. A model of 200 million parameters is small by the standards of language models, and the authors emphasised that TimesFM was designed to be practical to run. Salesforce's Moirai, also presented at ICML in 2024, addressed two problems the others had sidestepped. The first was multivariate data with an arbitrary number of channels. Moirai flattened all the channels of a multivariate series into a single sequence of patches and used a form of attention, which its authors called any-variate attention, that distinguished patches from the same channel from patches from different channels through learned biases, so the same model could handle one channel or hundreds. The second was frequency. Moirai used several patch sizes, assigning larger patches to higher-frequency data. It was trained on LOTSA, a curated archive of open time-series data comprising about 27 billion observations across nine domains, and it produced probabilistic forecasts through a mixture of parametric distributions. MOMENT, from Carnegie Mellon University, was presented at ICML in 2024 with a different emphasis. Rather than focusing on forecasting alone, it was designed as a general-purpose representation model for time series, trained by masked patch reconstruction on a compilation of public data its authors called the Time Series Pile. MOMENT was evaluated on forecasting, classification, anomaly detection and imputation, and its masked-reconstruction objective made it particularly suited to detection, since a model that reconstructs a masked patch well from its context has learned what the patch should look like, and a large reconstruction error signals that the observed patch is unusual. Smaller, larger, and different The models of 2024 prompted two opposite responses. One pushed toward much larger models. Time-MoE, published at ICLR in 2025, scaled a decoder-only time-series transformer to 2.4 billion parameters using a mixture-of-experts design, in which each input is routed to a small subset of specialised sub-networks so that only a fraction of the parameters are active for any prediction. It was trained on a corpus its authors assembled, Time-300B, containing more than 300 billion time points across nine domains. Sundial, from Tsinghua University and presented at ICML in 2025, was trained on a corpus its authors put at about a trillion time points, and replaced the usual quantile or parametric output with a generative objective based on flow matching, a technique from image generation that learns to transform random noise into samples from the predictive distribution. The other response pushed toward much smaller models. IBM's Tiny Time Mixers, published at NeurIPS in 2024, used an architecture built from simple mixing layers, without attention, with as few as about one million parameters, and reported zero-shot accuracy competitive with models hundreds of times larger on several benchmarks. TiRex, described in the previous chapter, used 35 million parameters. Moirai 2.0, released by Salesforce in November 2025, was explicitly framed around the theme that less is more: it replaced Moirai's masked encoder with a decoder-only design, dropped the multiple patch sizes in favour of one, replaced the mixture-distribution output with a quantile loss, and added multi-token prediction. Its smallest variant, at about 11 million parameters, outperformed its own larger variants of 87 and 305 million parameters on the GIFT-Eval benchmark. The paper reported it as roughly thirty times smaller and twice as fast as the largest version of the original Moirai. That finding, that larger variants did not improve and sometimes slightly worsened accuracy, is one of several pieces of evidence that the scaling behaviour of time-series models differs from that of language models. In language, larger models trained on more data improve predictably over many orders of magnitude. In time series, the gains from scale appear to saturate much earlier, perhaps because the vocabulary of temporal shapes is smaller than the vocabulary of language, perhaps because the available real data is less diverse, perhaps because the noise inherent in many series puts a ceiling on achievable accuracy. The question is not settled, but practitioners no longer assume that the largest model is the best. A third response came from domain-specialised pretraining. Datadog's Toto, published in 2025 with 151 million parameters, was trained on a corpus dominated by observability data, the metrics that monitoring systems collect from servers, containers and applications, alongside public and synthetic data. Its authors released a benchmark, BOOM, of 350 million observations across 2,807 series drawn from Datadog's own telemetry, arguing that observability data has characteristics, such as high frequency, heavy tails, sparse spikes and strong cross-series structure, that general-purpose benchmarks underrepresent. Kronos, mentioned in Chapter 3, was pretrained on more than 12 billion candlestick records from 45 exchanges, the open, high, low and close prices and volumes summarising trading over each interval. These specialised models trade breadth for depth: they give up some generality in exchange for a better prior on the specific kinds of series their users care about. Covariates and context The most important limitation of the first-generation foundation models was that most of them were univariate in practice. They forecast one series from its own past. Real forecasting problems almost always involve covariates: other information that helps predict the target. Electricity demand depends on temperature, so a demand forecast should use the weather forecast. Retail sales depend on promotions and prices, which are known in advance. A forecast that ignores these is handicapped no matter how good its model of temporal shape. Chronos-2, released by Amazon in October 2025, was designed specifically to address this. Its group attention mechanism, described in Chapter 3, lets the target series attend to covariate series at each patch position, and it supports past-only covariates, covariates whose future values are known (such as calendar features or scheduled prices), and categorical covariates. Strikingly, the authors trained its multivariate and covariate capabilities entirely on synthetic data, generated by taking univariate synthetic series and imposing dependencies between them, both simultaneous and lagged. The base model has 120 million parameters, with a 28-million-parameter variant that trailed it by about one point of skill score on GIFT-Eval. On the authors' fev-bench benchmark of 100 forecasting tasks, Chronos-2 reported the highest average win rate and skill score of any model tested, and its largest margins over other models came on the subset of tasks involving covariates, including case studies in energy and retail. The ability to use covariates changes what a foundation model can be used for. A univariate zero-shot forecaster is a useful default for large catalogues of series. A covariate-aware zero-shot forecaster can, in principle, replace a substantial fraction of the bespoke forecasting models that organisations currently build and maintain, provided it is accurate enough and cheap enough for the application. Context length has expanded alongside. Early models used contexts of 512 readings, which for hourly data is about three weeks. Chronos-2 was trained with contexts of 2,048 and then post-trained to 8,192. Longer context helps most with series that have long seasonal periods or slow structural changes, and it matters for anomaly detection, where a longer reference window gives a better picture of what normal looks like. Table 3 summarises a selection of the models discussed in this chapter. Parameter counts are as reported by the developers; several models are available in multiple sizes. Table 3. Selected time-series foundation models. Sources: the developers' published papers and model documentation. Model Developer and year Architecture Parameters Notable design choice Chronos Amazon, 2024 Encoder-decoder transformer (T5) About 8M to 710M Quantised value tokens; synthetic Gaussian-process data TimesFM Google, 2024 Decoder-only patch transformer 200M Long output patches; web-derived training data Moirai Salesforce, 2024 Masked encoder transformer About 14M to 311M Any-variate attention; multiple patch sizes Time-MoE Academic and industry team, 2025 Decoder-only mixture of experts Up to 2.4B Sparse expert routing at billion scale TiRex NXAI, 2025 Recurrent (sLSTM) 35M State-tracking recurrence; contiguous patch masking Toto Datadog, 2025 Decoder-only transformer 151M Observability-dominated pretraining corpus Chronos-2 Amazon, 2025 Encoder-only transformer with group attention 120M (and 28M) Covariates and multivariate input learned from synthetic data Moirai 2.0 Salesforce, 2025 Decoder-only transformer About 11M to 305M Simplified design; smallest variant most accurate Synthetic data as a training principle The repeated success of synthetic data in time-series pretraining is one of the most interesting findings of this period, and it distinguishes the field from language modelling, where synthetic text plays a supporting role at most. Chronos used Gaussian-process series. Chronos-2 learned its multivariate behaviour from synthetic dependencies. ForecastPFN, published at NeurIPS in 2023, and TabPFN-TS, a 2025 adaptation of a tabular foundation model to forecasting, were trained entirely or largely on synthetic data and achieved competitive zero-shot accuracy on real benchmarks. Chronos-2's authors reported that a variant trained only on synthetic data performed only slightly below the full model on all three benchmarks they used. The likely explanation is that the space of plausible temporal shapes can be described generatively more completely than the space of plausible sentences. A modest number of building blocks, trends of various forms, periodicities, autoregressive noise, level shifts, spikes and their combinations, can generate a very large fraction of the shapes that real series exhibit. Synthetic data also has two practical advantages. It is free of licensing restrictions, and it is free of contamination: a model trained on synthetic data cannot have memorised the test set of a public benchmark, a problem the next chapter discusses at length. Synthetic data has a limitation that matters for failure prediction. Synthetic generators produce the shapes their designers thought to include. The rare and idiosyncratic behaviours that precede real failures, the specific signature of a cracking turbine blade or the cascading pattern of a grid disturbance, are unlikely to appear in a generic synthetic corpus. For forecasting normal behaviour, synthetic data is a powerful complement to real data. For learning what abnormal behaviour looks like, it is no substitute for domain data, though domain-specific simulators, such as the physics-based turbofan simulation used to create NASA's engine degradation datasets, can partly fill the gap. Zero-shot, fine-tuned, or neither A foundation model can be used in three ways. Zero-shot, it receives a context and produces a forecast with no adaptation. Fine-tuned, its weights are updated by further training on data from the target domain, which typically improves accuracy at the cost of compute and the need for training data. And as a component, its internal representations can be extracted and used as features for another model, such as a classifier for failure modes or a detector for anomalies. The evidence on fine-tuning is mixed but generally favourable when enough domain data is available. Fine-tuning on a few thousand series from a target domain often improves accuracy measurably over zero-shot use. On very small target datasets, fine-tuning risks overfitting and may degrade the general knowledge the model acquired in pretraining. Parameter-efficient fine-tuning methods, which update only a small number of added parameters, offer a middle path and have been applied to several of the models described here. There is also a case for using neither. A well-tuned gradient-boosted tree or exponential smoothing model, fitted to a domain where abundant history is available and the structure is stable, may match a foundation model's accuracy at a tiny fraction of the cost. The foundation model's comparative advantage is greatest where history is short, series are numerous and diverse, maintenance resources are limited, and a good default is more valuable than an optimised specialist. Its comparative advantage is smallest where a single important series has decades of clean history and a team of analysts who understand it. Deciding which situation one is in requires evaluation, and evaluation, as the next chapter shows, is harder than the leaderboards suggest. Chapter 7. Reading the Leaderboards By the end of 2025, anyone choosing a time-series foundation model could consult public leaderboards that ranked dozens of models on hundreds of forecasting tasks, updated as new models were released. These leaderboards were a major improvement on the situation of three years earlier, when new architectures were compared on a handful of small datasets against other transformers. But they measure something specific, and the thing they measure is not always the thing a practitioner needs to know. Knowing how modern forecasting evaluation works, and where it misleads, is the precondition for a responsible deployment decision. The benchmark ecosystem Three benchmarks dominated the evaluation of foundation models by late 2025. GIFT-Eval, released by Salesforce researchers in 2024, comprises 23 datasets containing about 144,000 series and 177 million data points, spanning seven domains and ten sampling frequencies from seconds to years. Combining datasets with different forecast horizons produces nearly a hundred distinct task configurations, which are grouped by horizon into short, medium and long. Crucially, GIFT-Eval was released together with a separate pretraining corpus that its authors had checked for overlap with the test data, so that model developers could pretrain without contaminating the evaluation. Amazon's Chronos benchmarks, introduced with the original Chronos paper, divided a collection of public datasets into those used in training (an in-domain benchmark) and those held out entirely (a zero-shot benchmark of 27 datasets in its second version). Amazon's fev-bench, published in 2025, contains 100 forecasting tasks with a particular emphasis on realistic settings involving covariates, and was designed to address the scarcity of covariate tasks in other benchmarks. These benchmarks aggregate results across many tasks using two kinds of summary. A win rate records, for each pair of models, the fraction of tasks on which one beats the other, averaged over all opponents. A skill score expresses each model's error relative to a simple baseline, typically the seasonal naive forecast, so that a skill score of 40 percent means the model's error is 40 percent lower than the baseline's, aggregated across tasks with a geometric mean. Both summaries are computed separately for a point accuracy measure, usually MASE, and a probabilistic measure, usually CRPS or the weighted quantile loss. The differences between top models on these leaderboards are often small. In the Chronos-2 paper, for example, Chronos-2 reported a GIFT-Eval skill score of 51.4 percent on the weighted quantile loss against 51.0 percent for Google's TimesFM-2.5, the next strongest model on that measure, and a MASE skill score of 30.2 percent against 29.5 percent. Differences of that size are real in the sense that they are consistent across many tasks, but they are small in the sense that a practitioner would rarely notice them in a single application. A difference of less than a percentage point in aggregate skill score says little about which model will perform better on a particular dataset. Contamination The most serious threat to the validity of foundation-model benchmarks is contamination: test data, or data closely related to it, appearing in the pretraining corpus. A model that has seen the test period of a benchmark during pretraining can recall rather than forecast, and its score will overstate its ability on genuinely new data. Contamination is harder to avoid in time series than it might seem. The standard public datasets, the electricity consumption data, the traffic sensor data, the ETT transformer data, the M4 competition series, are included in many public archives, and a model trained on a broad scrape of public time series is likely to have seen them. Even if the exact test windows are excluded, the same series at earlier dates may be included, and for highly regular series, such as traffic occupancy with its stable weekly pattern, having seen the series' history is almost as good as having seen its future. Related series pose a subtler problem: a model trained on electricity data from one set of households may have learned patterns that make another set of households from the same utility unusually easy to forecast. The benchmark designers have responded. GIFT-Eval's leakage-checked pretraining corpus, and the separation of in-domain and zero-shot datasets in the Chronos benchmarks, are both attempts to keep training and test data apart. Leaderboards now often mark models whose training data is known to overlap with the test data, or whose training data is undisclosed. But many models, particularly commercial ones, do not disclose their full training corpus, and some benchmark datasets are so widely redistributed that their absence from any large scrape is hard to guarantee. A 2026 study by Google researchers comparing foundation models with supervised specialists on four public datasets, discussed further below, explicitly flagged that three of the four datasets it used, M4, Traffic and ETTh1, might appear in foundation-model pretraining data, so strong foundation-model results on them might partly reflect recall. That caveat applies, to varying degrees, to most published comparisons on public data. The only fully reliable defence is evaluation on private data that no model could have seen, ideally from the deployment domain itself and from a period after the model's training cut-off. This is one reason why domain-specific benchmarks built from proprietary data, such as Datadog's BOOM benchmark of observability metrics, are valuable even though they are narrower than the general benchmarks. It is also the reason why any organisation considering a foundation model for an important application should evaluate it on its own recent data before trusting any leaderboard. What aggregate scores hide Even a perfectly uncontaminated leaderboard averages across tasks, and averages hide structure. A model that ranks first overall may rank tenth on the subset of tasks most like a particular application. GIFT-Eval's own breakdowns by horizon illustrate this: Moirai 2.0's smallest model, for example, ranked fourth among foundation models on short horizons but eighth on long horizons in its developers' report. Breakdowns by domain, frequency and series characteristics often show larger variation still. The same Google study provides a clear illustration. Its authors compared three foundation models, TimesFM 2.0 at 500 million parameters, TimesFM 2.5 at 200 million and the original Chronos T5-Base, against four supervised models trained on each dataset: gradient-boosted trees using the XGBoost library, an LSTM, PatchTST and DLinear. On the highly periodic traffic data, TimesFM 2.0 had the lowest MASE of all seven models. On the ETTh1 energy data, which the authors characterised as physically constrained, XGBoost was clearly best, with a MASE of 0.573 against 1.046 for the best foundation model. On the exchange-rate data, close to a random walk, TimesFM 2.0 failed badly, with a MASE above 12, while TimesFM 2.5 had the best MASE of any model. On the M4 daily data, DLinear, a single linear layer, narrowly had the lowest MASE. No paradigm dominated. The authors drew a useful conclusion: the right choice depends on the character of the series. They built a simple router that used four statistical features of each series, its spectral entropy, coefficient of variation, seasonal autocorrelation and trend strength, to decide whether it should be sent to a foundation model or to a specialist. The study's thresholds were tuned on the same series it evaluated, so the router's reported gains should be treated with caution, but the principle, that series characteristics predict which method will do best, is sound and consistent with long experience in forecasting competitions. The cost dimension Leaderboards rank by accuracy. Deployments must also consider cost, latency and operational complexity, and on these dimensions the differences between methods are not small but enormous. The Google study measured inference latency and throughput for each model under representative conditions. Table 4 reproduces its figures. The foundation models ran on graphics processors; the specialists ran on an ordinary server processor. Table 4. Inference latency and throughput for foundation models and supervised specialists. Source: Soni, Das and Guduguntla, "Assessing the Operational Viability of Foundation Models for Time Series Forecasting," arXiv 2605.24381 (2026). Model Hardware 95th-percentile latency Throughput (forecasts per second) TimesFM 2.0 V100 GPU 200 ms 5 TimesFM 2.5 T4 GPU 283 ms 3.5 Chronos (T5-Base) T4 GPU 1,764 ms 0.6 PatchTST Xeon CPU 9.03 ms 111 XGBoost Xeon CPU 0.18 ms 9,300 DLinear Xeon CPU 0.13 ms 7,870 The authors estimated that foundation-model inference cost roughly a thousand times as much as a supervised specialist. Those figures depend heavily on batching, hardware and implementation, and newer models such as Chronos-Bolt and Chronos-2 are much faster than the original Chronos measured here; Amazon reported Chronos-2 processing about 300 series per second on a single GPU when run in large batches. But the order-of-magnitude gap between a large neural model and a gradient-boosted tree or linear model is real, and it matters for applications that must forecast or score millions of series, or must respond within milliseconds. The specialists carry costs of their own, however. A supervised model must be trained, which requires historical data for each series or group of series, a training pipeline, validation, and periodic retraining as the data drifts. For an organisation with millions of short-lived series, such as a retailer whose product catalogue turns over every season, the engineering cost of maintaining specialists may exceed the compute cost of a foundation model. For a new series with no history, the cold-start problem, a specialist cannot be trained at all, while a foundation model can forecast from whatever context is available. The Google study gave an example of exactly this, in which TimesFM produced a reasonable forecast from 48 hours of history while XGBoost could not, though it was a single qualitative case rather than a systematic test. Probabilistic calibration For decisions under uncertainty, the accuracy of the central forecast matters less than the reliability of the uncertainty around it. A forecast that says demand will be between 40 and 45 gigawatts with 90 percent probability is useful only if, over many such forecasts, the actual value falls within the stated range about 90 percent of the time. A model whose 90 percent intervals contain the actual value only 70 percent of the time is overconfident, and a decision-maker relying on it will be surprised far more often than they expect. CRPS and quantile losses reward calibration, but aggregate scores can conceal miscalibration in specific conditions. A 2026 benchmark of foundation models on Texas grid load data, discussed in Chapter 9, found that Chronos-2 produced well-calibrated intervals while Moirai 2.0 and the widely used Prophet forecasting library were overconfident, with roughly 70 percent coverage at a nominal 90 percent level. Calibration also tends to degrade precisely when it matters most: during unusual events, regime changes and extreme conditions, which are underrepresented in training data and in benchmarks. Methods exist to correct miscalibration after the fact. Conformal prediction, a family of techniques that uses recent forecast errors to adjust the width of prediction intervals so that they achieve their nominal coverage, has been adapted to time series in several forms. Adaptive conformal inference, introduced by Isaac Gibbs and Emmanuel Candès in 2021, adjusts interval widths online in response to observed coverage, providing long-run coverage guarantees even under distribution shift. These methods can be wrapped around any forecaster, including a foundation model, and they are an important tool for anyone deploying probabilistic forecasts in a high-stakes setting. A deployment evaluation What, then, should an organisation do before deploying a foundation model for forecasting or detection? The leaderboards provide a useful shortlist. They do not provide a decision. A responsible evaluation for a specific application has several components. It uses the organisation's own data, from a period after the candidate models' training cut-offs, so that contamination is impossible. It uses rolling-origin evaluation, in which the model forecasts from many successive starting points across the test period, rather than a single split, so that results are not driven by the peculiarities of one period. It compares against the strongest simple baselines that are realistic for the application, typically seasonal naive, exponential smoothing and gradient-boosted trees with the features the organisation already uses, all given the same information, including covariates. It measures the accuracy that matters for the decision, which may be the error at a specific horizon, the accuracy of the peak rather than the average, or the calibration of the upper tail. It breaks down results by the conditions that matter, such as holidays, extreme weather or periods of high volatility, rather than reporting only averages. And it measures the full cost, including latency, hardware, engineering and maintenance, against the value of the accuracy gained. Such evaluations are more expensive than consulting a leaderboard, but they are what distinguish a deployment that works from one that disappoints. The chapters that follow show, domain by domain, what the conditions that matter are, and why they are so often exactly the conditions that benchmarks miss. Chapter 8. Detecting the Abnormal, and Measuring It Honestly An anomaly is an observation or pattern that does not conform to expected behaviour. The definition is easy to state and hard to apply, because everything depends on what is expected. A temperature of 38 degrees Celsius is normal for a summer afternoon in Seville and alarming for a server room. A sudden doubling of trading volume is normal at the market open and suspicious at two in the afternoon. A vibration reading that would be routine during start-up is a warning sign during steady operation. Anomaly detection in time series is the problem of learning what is expected, in context, and recognising departures from it. The main approaches are long established, and deep learning and foundation models slot into them rather than replacing them. The field also learned a painful lesson: for several years, the most widely used evaluation protocol in deep anomaly detection research rewarded methods for behaviour unrelated to detecting anomalies, and the apparent progress it recorded was largely illusory. Kinds of anomaly It is useful to distinguish three kinds of anomaly, following a classification popularised in a widely cited 2009 survey by Varun Chandola, Arindam Banerjee and Vipin Kumar. A point anomaly is a single observation far from the rest: a spike in a sensor reading caused by electrical interference, or a single erroneous trade at an absurd price. A contextual anomaly is an observation that would be normal in another context but is abnormal in this one: high electricity demand at three in the morning, or heating load during a heat wave. A collective anomaly is a sequence of observations that is abnormal as a whole even though no individual observation is: a heartbeat waveform with a subtly wrong shape, or a vibration pattern whose frequency content has shifted though its amplitude is unchanged. Point anomalies are the easiest to detect and often the least important. Many are measurement artefacts rather than events in the underlying system. Contextual and collective anomalies are harder and usually more consequential, because they are how real faults typically first appear: not as a dramatic spike but as a pattern that is subtly wrong for the circumstances. A related concept is the change point, a moment at which the statistical behaviour of a series shifts persistently, such as a step change in a pump's baseline power draw after a seal begins to leak. Change points are not anomalies in the sense of isolated departures, but detecting them is often the real goal of a monitoring system. Four families of method Most anomaly detection methods for time series fall into one of four families, distinguished by how they model normal behaviour. Prediction-based methods train a forecaster on normal data and flag observations that the forecaster did not predict. The anomaly score is the prediction error, perhaps normalised by the forecaster's own uncertainty. This is the approach taken by the NASA Jet Propulsion Laboratory system described in Chapter 11, which used LSTM forecasters on spacecraft telemetry, and it is the natural way to use a forecasting foundation model for detection: run the model, compare its forecast distribution with what actually happened, and flag observations in the far tails. The approach works well for contextual anomalies, since the forecaster conditions on context, and its quality is bounded by the quality of the forecaster. Reconstruction-based methods train a model to compress and reconstruct windows of normal data, typically using an autoencoder, a network with a narrow internal bottleneck that forces it to learn the essential structure of its input. A window that the model reconstructs poorly is unlike the normal data it was trained on. Many deep detection methods of the late 2010s and early 2020s took this form, including OmniAnomaly, published in 2019 with the Server Machine Dataset collected from a large internet company, and USAD, published in 2020, which used adversarially trained autoencoders. MOMENT's masked-patch reconstruction objective, described in Chapter 6, makes it a natural reconstruction-based detector. Distance- and density-based methods measure how far each window is from other windows, or how sparsely populated its neighbourhood is. The isolation forest, introduced in 2008, isolates observations by random partitioning and scores as anomalous those that are isolated in few steps. The matrix profile, developed by Eamonn Keogh's group at the University of California, Riverside from 2016 onward, efficiently computes for every subsequence of a long series the distance to its nearest neighbour elsewhere in the series; a subsequence whose nearest neighbour is far away, called a discord, is a strong candidate anomaly. These methods are often surprisingly hard to beat. Association-based methods look at relationships rather than values. The Anomaly Transformer, presented at ICLR in 2022 by the Tsinghua group behind Autoformer, observed that in a transformer's attention, normal points tend to attend broadly across the series, finding associations with many other points that share the series' regular patterns, whereas anomalous points, being rare, can associate only with their immediate neighbours. It measured the discrepancy between each point's learned attention pattern and a local prior and used it as the anomaly score. For multivariate data, a related idea monitors the relationships between channels and flags a break in their usual correlation, which is often how faults in physical systems first appear. The benchmarks were broken Through the late 2010s and early 2020s, deep anomaly detection research reported steady and often dramatic progress. Papers routinely reported F1 scores, the harmonic mean of precision and recall, above 0.9 on standard multivariate benchmarks such as the Server Machine Dataset, NASA's SMAP and MSL spacecraft telemetry datasets, and the SWaT dataset from a water treatment testbed in Singapore. Each new architecture claimed to beat the previous ones by a few points. In 2020, Renjie Wu and Eamonn Keogh posted a paper, later published in IEEE Transactions on Knowledge and Data Engineering, with the title "Current Time Series Anomaly Detection Benchmarks Are Flawed and Are Creating the Illusion of Progress." It identified four problems with the most widely used benchmark datasets. Many contained anomalies so obvious that they could be detected by a single line of code, such as a threshold on the raw value or on the first difference, making them useless for distinguishing sophisticated methods. Many had anomalies so dense, occupying large fractions of the test data, that the very notion of an anomaly as a rare departure was strained. Some contained labelling errors, points marked anomalous that looked normal and vice versa. And in several, anomalies were concentrated toward the end of the test data, so that a method biased toward flagging late observations would score well for reasons unrelated to detection. Wu and Keogh released a new archive of 250 series from varied domains, each with exactly one carefully verified anomaly that was not trivially detectable. A second, independent critique concerned the evaluation protocol. Most deep detection papers had used a procedure called point adjustment. Anomalies in these datasets are labelled as segments, contiguous stretches of time. Under point adjustment, if a detector flags any single point within a labelled anomalous segment, every point in that segment is counted as correctly detected. The rationale was that in practice an operator alerted at any point during an anomalous episode would investigate the whole episode. The effect, however, was to inflate scores enormously. A long anomalous segment of a thousand points could be credited as fully detected on the strength of one lucky flag. In a paper presented at the AAAI conference in 2022, Siwon Kim and colleagues at Seoul National University demonstrated the consequence starkly. Under point adjustment, anomaly scores generated at random, with no information about the data at all, achieved F1 scores that matched or exceeded many published state-of-the-art deep methods on the standard benchmarks. A detector that flagged points at random would, by chance, hit at least one point in most long anomalous segments, and point adjustment would then credit it with detecting the whole segment. When the same methods were evaluated without point adjustment, or with stricter protocols, much of the reported progress disappeared, and several deep methods performed no better than simple baselines. These two critiques together meant that a large part of the deep anomaly detection literature from the preceding five years could not be taken at face value. It was not that the methods were useless. Some of them genuinely learned useful representations. But the benchmarks could not tell the good methods from the bad, and the evaluation protocol could not tell either from chance. Better measures The response has been a combination of better datasets and better metrics. On metrics, several proposals address the specific weaknesses of point-wise F1 with and without point adjustment. Range-based precision and recall, introduced in 2018 by Nesime Tatbul and colleagues, credit a detection according to how much of an anomalous range it overlaps, whether it detects the range early, and whether it fragments a single range into many alerts. Affiliation metrics, introduced in 2022, measure how close each detection is to the nearest true anomaly and vice versa, giving partial credit for near misses. The volume under the surface, VUS, introduced by John Paparrizos and colleagues in 2022, extends the familiar area under the precision–recall curve by also integrating over a range of tolerances for how far a detection may be from a labelled anomaly, which removes the need to choose a single threshold or a single tolerance and makes the score robust to small labelling inaccuracies at segment boundaries. The most comprehensive recent benchmark, TSB-AD, published by Qinghua Liu and John Paparrizos at NeurIPS in 2024 under the title "The Elephant in the Room: Towards a Reliable Time-Series Anomaly Detection Benchmark," assembled 1,070 curated series from 40 source collections, removed or corrected problematic labels, and evaluated 40 detection algorithms ranging from simple statistical methods to recent foundation models. After analysing the behaviour of the candidate metrics, it recommended VUS-PR, the precision–recall form of the volume under the surface, as the most reliable. Its findings were sobering for deep learning. Simpler architectures and statistical methods often outperformed advanced neural networks. The authors found that neural methods did comparatively well on multivariate series and that foundation models did well on point anomalies, but that neither had yet established the clear superiority that the earlier literature had implied. The headline lesson was that time-series anomaly detection remained an open problem in which careful baselines were essential. How foundation models fit Foundation models enter anomaly detection in three ways. The first and most direct is as forecasters in a prediction-based detector. A pretrained probabilistic forecaster such as Chronos-2, TimesFM or TiRex can produce, for each future step, a predictive distribution conditioned on the recent past. An observation that falls far in the tail of that distribution is a candidate anomaly. Because the forecaster has learned general patterns of temporal behaviour, it can be applied to a new stream immediately, without collecting a training set of normal data, which addresses one of the most persistent obstacles in industrial monitoring. The second is as reconstruction models. MOMENT and other masked-reconstruction models can be asked to fill in a masked patch from its surroundings, and the difference between the reconstruction and the observed patch is an anomaly score. This is well suited to collective anomalies, where the issue is the shape of a whole window rather than a single value. The third is as feature extractors. The internal representations a foundation model computes for each patch encode the local shape and context of the series. These representations can be fed to a simpler detector, such as an isolation forest or a distance-based method, which can then operate in a space where similar temporal patterns are close together. This combines the general knowledge of the pretrained model with the robustness of classical detectors. Each approach inherits the foundation model's limitations. A forecaster that has learned to expect smooth seasonal behaviour may regard a legitimate but unusual operating mode as anomalous, producing false alarms. A forecaster with a long context that has absorbed a slowly developing fault into its context may stop regarding the fault as unusual. And the predictive distributions of foundation models are not always well calibrated, especially in their tails, which is exactly where an anomaly detector looks. A detector built on a miscalibrated forecaster will be either too sensitive or too lax in ways that are hard to predict. The threshold is the product Almost every method described here produces a continuous anomaly score. Turning that score into an alert requires a threshold, and the choice of threshold is where most of the practical difficulty lies. A threshold set too low floods operators with false alarms, which they learn to ignore. A threshold set too high misses the events that matter. The right threshold depends on the cost of a false alarm relative to the cost of a missed event, and on the rate at which operators can investigate alerts, which is a property of the organisation rather than the data. Several methods set thresholds adaptively. The NASA system used a nonparametric dynamic thresholding procedure that chose, within each window of recent errors, the threshold that best separated a small number of large errors from the bulk. Methods based on extreme value theory, such as the SPOT algorithm published in 2017 by Alban Siffer and colleagues, fit a statistical model to the tail of the score distribution and set thresholds to achieve a specified false-alarm probability, updating as new data arrives. Conformal methods, described in the previous chapter, can provide guarantees on the long-run false-alarm rate under weak assumptions. But the most important design decision is often not statistical. It is the decision about how many alerts a human team can usefully handle, and what information each alert must carry for that team to act on it. A detector that achieves excellent VUS-PR on a benchmark but produces fifty alerts an hour for a two-person control-room team has failed. A detector that produces two alerts a day, each with a clear indication of which sensors are involved and how the current pattern differs from normal, may be far more valuable even if its benchmark score is lower. The domain chapters that follow return to this point repeatedly, because it is where most deployed systems succeed or fail. Anomaly is not failure A final distinction matters for everything that follows. An anomaly is a statistical property: an observation unlike the expected pattern. A failure is a physical or operational event: a component breaking, a line tripping, a trading system malfunctioning. The two are related but not identical. Many anomalies are harmless: a sensor glitch, a planned maintenance operation, an unusual but legitimate operating condition. Some failures produce no detectable anomaly in the monitored signals until it is too late, because the relevant signal is not measured or the failure develops faster than the sampling rate. Failure prediction, the subject of the domain chapters, therefore requires more than anomaly detection. It requires knowing which anomalies are precursors of which failures, how much warning they provide, and what can be done with that warning. That knowledge comes from the physics of the system, the history of its failures, and the experience of its operators, combined with the statistical machinery described here. The power grid, the exchange and the factory each combine these elements differently. Chapter 9. Power Grids: Balancing in Real Time An alternating-current power grid is a machine the size of a continent that must keep supply and demand in balance at every instant. Electricity cannot be stored in the wires; every watt consumed must be generated at the same moment. When demand exceeds supply, the rotating generators connected to the grid slow down slightly, and the grid's frequency, nominally 50 hertz in Europe and most of the world, 60 hertz in North America, falls. When supply exceeds demand, frequency rises. Grid operators watch frequency continuously, and automatic control systems adjust generation within seconds to correct deviations. If frequency moves too far, protective systems disconnect generators or shed load to prevent equipment damage, and if those actions cascade, the grid can collapse. Time-series forecasting and anomaly detection are therefore not peripheral to grid operation. They are its core. Every decision an operator makes, from which power stations to schedule for tomorrow to whether to trip a line in the next second, depends on a forecast of what the system will do and a judgement about whether what it is doing now is normal. Deep learning and foundation models are now being applied across that whole range of decisions, and their limitations bite in different places at each timescale. The forecasting horizons of a grid Grid operation involves forecasts on several distinct horizons, each tied to a different decision. Long-term forecasts, years to decades ahead, inform investment in generation and transmission. Medium-term forecasts, weeks to months ahead, inform maintenance scheduling and fuel procurement. Day-ahead forecasts inform unit commitment, the decision about which generating units to start up and run tomorrow, and the clearing of day-ahead electricity markets. Intraday and hour-ahead forecasts inform adjustments as conditions evolve. And very short-term forecasts, seconds to minutes ahead, inform the automatic and manual balancing that keeps frequency stable. The quantities forecast include demand, or load, at every level from the whole system down to individual substations and feeders; generation from wind and solar plants, which depends on the weather; prices in electricity markets; and flows on transmission lines, which determine whether any line is at risk of overloading. Day-ahead system load forecasting is among the most mature forecasting problems in any industry. Load is driven by temperature, through heating and cooling, by daylight, through lighting, by the calendar, through the working week and holidays, and by economic activity. These drivers are well understood, and a good day-ahead forecast for a large system typically achieves errors of a few percent. The Global Energy Forecasting Competitions organised by Tao Hong and colleagues in 2012, 2014 and 2017 established reference datasets and showed that the best methods combined careful use of weather forecasts with regression or machine-learning models; gradient-boosted trees and ensembles of simpler models performed strongly. Forecasting at lower levels of aggregation is harder. A single substation's load is noisier than the system total, more affected by individual large customers, and increasingly affected by rooftop solar generation behind the meter, which reduces apparent demand on sunny days in ways the utility cannot observe directly. Forecasting renewable generation is harder still, because it depends on the weather at specific locations and times, and weather forecasts themselves have errors that grow with horizon. A wind farm's output can ramp from near zero to full capacity, or the reverse, within an hour as a weather front passes. These ramps are among the most operationally significant forecasting challenges, because the grid must have flexible resources ready to compensate. Foundation models on grid data How do time-series foundation models perform on this kind of data? A study published in February 2026 offers a useful answer. Luigi Simeone benchmarked several foundation models, Chronos-Bolt, Chronos-2, Moirai 2.0 and IBM's Tiny Time Mixers, against the Prophet forecasting library, a seasonal ARIMA model and the seasonal naive forecast, using hourly load data for ERCOT, the operator of most of the Texas grid, from 2020 to 2024. Deliberately, all experiments ran on consumer hardware without a graphics processor, reflecting the conditions under which many smaller utilities and analysts would actually use such models. With a long context of 2,048 hours, about twelve weeks, and a day-ahead horizon, the best foundation models achieved a mean absolute scaled error of about 0.31, roughly 47 percent lower than the seasonal naive baseline. That is a strong result for a zero-shot model with no access to weather data. With only 24 hours of context, Prophet's forecasts deteriorated catastrophically, with errors more than seventy times the naive baseline's, while the foundation models remained stable, drawing on patterns learned in pretraining to compensate for the short history. On calibration, Chronos-2 produced well-calibrated prediction intervals, while Moirai 2.0 and Prophet were overconfident, their nominal 90 percent intervals containing the actual load only about 70 percent of the time. The study also examined performance during two periods of severe distribution shift: the COVID-19 lockdowns of spring 2020, which abruptly changed daily load patterns as offices closed and people stayed home, and Winter Storm Uri in February 2021. Those periods are the real test of any grid forecasting model, because they are when forecasts matter most and when the patterns learned from normal history are least reliable. Two qualifications apply to results of this kind. First, a zero-shot univariate model that sees only past load cannot anticipate a weather-driven change that is not yet visible in the load. Operational load forecasting systems use weather forecasts as covariates, and the most useful comparison is between a covariate-aware foundation model, such as Chronos-2 with temperature forecasts supplied, and the operator's existing weather-driven model, not between a univariate foundation model and naive baselines. Second, the forecasting systems of major grid operators are highly refined, built and tuned over decades, and the margin by which any new method can improve on them is narrower than the margin over generic baselines. The most immediate value of foundation models in grid forecasting is likely to be at the lower levels of the hierarchy, substations, feeders, distributed generation and new connections, where history is short, series are numerous, and bespoke models are uneconomic. Winter Storm Uri Uri illustrates why forecasting under extreme conditions matters more than average accuracy. In mid-February 2021, an Arctic air mass brought prolonged sub-freezing temperatures across Texas. Demand for electric heating surged to record winter levels while, at the same time, a large fraction of the state's generating capacity failed, as natural gas wellheads and pipelines froze, gas-fired plants lost fuel supply, and equipment at plants of every type, including some wind turbines and a nuclear unit, was disabled by the cold. In the early hours of 15 February, with supply falling far short of demand, ERCOT ordered rotating outages that eventually left millions of customers without power, many for days, in freezing temperatures. More than two hundred deaths were later attributed to the storm in Texas. ERCOT later reported that during the crisis, grid frequency fell below 59.4 hertz for more than four minutes, approaching the nine-minute limit beyond which generators would have begun disconnecting automatically, which could have caused a total collapse requiring weeks to restart. The operators' decision to shed load averted that outcome. The forecasting lesson of Uri is not that demand forecasts were badly wrong, though peak demand did exceed earlier winter planning scenarios. It is that the critical failure was in forecasting supply, specifically the correlated failure of generation under a condition far outside the range of historical experience. No model trained on normal operating history could have learned that a given temperature would disable a large fraction of the generation fleet at once, because that had never happened at that scale. Probabilistic forecasts calibrated on normal conditions understate the probability of such correlated tail events. Foundation models, trained on general temporal patterns, have no special knowledge of the physics of gas-line freezing or plant winterisation. The relevant knowledge comes from engineering assessment, stress testing and scenario analysis, and forecasting models are useful in that context mainly as tools for exploring scenarios rather than as oracles. Synchrophasors and wide-area monitoring The second major application in grids is real-time event detection, and here the data is very different. Traditional grid monitoring through supervisory control and data acquisition systems, SCADA, reports measurements every few seconds, with timestamps that may not be precisely synchronised across substations. Since the early 2000s, and accelerated by the lessons of the 2003 blackout, grid operators have deployed phasor measurement units, PMUs, which measure voltage and current magnitudes and phase angles at rates typically of 30 to 60 samples per second and sometimes higher, all synchronised to a common time reference provided by satellite navigation signals. These synchronised measurements, called synchrophasors, allow operators to see the dynamic behaviour of the grid across a whole interconnection in near real time. Synchrophasor data supports several kinds of detection. Line and generator trips produce characteristic transients: a sudden change in phase angle difference across the grid, followed by oscillations as the remaining generators readjust. Oscillations themselves are a concern. Inter-area oscillations, in which groups of generators in different regions swing against each other at frequencies typically below one hertz, can grow if poorly damped, and a growing oscillation contributed to a major blackout in the western United States in August 1996. Forced oscillations, driven by a malfunctioning control system at a single plant, can propagate across the grid and are best detected by identifying their source from the pattern of phase relationships across many PMUs. And slower phenomena, such as declining voltage at a load centre under heavy loading, can signal approaching voltage instability. Deep learning has been applied to all these detection tasks, with convolutional, recurrent and transformer models trained to classify events from windows of PMU data. Two obstacles have limited progress. The first is data access. Detailed grid measurement data is treated as critical infrastructure information in many jurisdictions, and its distribution is restricted, so public datasets are few, small or synthetic, and models trained on one grid's data may not be shared with researchers or applied to another. The second is the scarcity of labelled events. Major disturbances are rare, each is somewhat unique, and labelling them requires expert analysis of event records. Simulation helps: grid dynamic simulators can generate realistic transients for many kinds of event on a model of the network. But simulated data inherits the simplifications of the model, and the events most worth detecting are often those the model did not anticipate. This is a setting in which pretrained foundation models offer a genuine advantage. A model that has learned general patterns of temporal behaviour, and can serve as a forecaster or reconstructor of normal PMU streams without event labels, provides a starting point for detection that does not require a large labelled dataset. The anomaly score from such a model, combined with the physical knowledge of how different events propagate, can flag candidate events for operator review. The challenge is speed: a PMU stream at 60 samples per second across hundreds of measurement points produces tens of thousands of readings per second, and detection must keep pace. That favours compact, state-based models of the kind described in Chapter 5. Inverter-based resources and new failure modes Solar panels, batteries and most modern wind turbines connect to the grid not through rotating machines but through power-electronic inverters. These inverter-based resources behave very differently from traditional generators during disturbances. They provide no inherent rotational inertia to resist frequency changes, and their response to faults is determined by control software and protection settings rather than by physics. Several significant events have shown how this creates new failure modes. In August 2016, the Blue Cut wildfire in southern California caused a series of transmission faults, and in response roughly 1,200 megawatts of solar generation disconnected or reduced output, not because the faults required it but because the inverters' protection logic misinterpreted the disturbance. In September 2016, a storm in South Australia damaged transmission towers, and the resulting faults triggered the disconnection of several wind farms whose ride-through protection settings were more sensitive than the grid operator had understood, contributing to a statewide blackout. In both cases, the North American and Australian investigations found that the generators' behaviour had not been adequately understood or modelled before the events. The Iberian blackout of 28 April 2025 showed a different facet of the same transition. Shortly after 12:33 that afternoon, the power systems of mainland Spain and Portugal lost synchronism with the rest of the European grid and collapsed within seconds, cutting power to tens of millions of people. The final report by an expert panel convened by ENTSO-E, the association of European transmission operators, published in March 2026, described a sequence in which voltages rose sharply, renewable and conventional generators disconnected in quick succession, some because their overvoltage protection was set below the levels required by regulation, and automatic defence systems could not arrest the collapse. More than 2.5 gigawatts of generation was lost in under a minute. The report also found that operators lacked real-time monitoring of the gap between the reactive power the system needed for voltage control and the reactive power generators were actually supplying, and that some voltage control equipment had to be switched manually. For time-series modelling, these events carry a clear message. The grid's dynamic behaviour is changing as its generation mix changes, so models trained on historical disturbance data from a grid dominated by rotating machines may not generalise to a grid dominated by inverters. The relevant precursor signals, such as a widening gap between needed and delivered reactive power, or rising voltage at multiple nodes, may not be ones that existing monitoring systems track or display. And failure modes in inverter-dominated systems may be fast, coordinated and determined by software settings, which means they may produce little warning in the measured signals before they occur. The most valuable application of anomaly detection here may be less in predicting the final collapse than in continuously monitoring for the gradual erosion of margins that makes collapse possible. The 2003 lesson revisited The 2003 blackout, with which this book began, is often summarised as a failure of situational awareness. The investigation found many contributing causes, including inadequate vegetation management under transmission lines and insufficient coordination between neighbouring operators. But the factor most relevant here is that the control room's alarm processor had failed silently, so that operators received no alarms as lines tripped, and did not realise their monitoring system was compromised. The task force's recommendations included improved real-time monitoring tools, better training and clearer protocols for when operators should act on incomplete information. Two decades later, the technical capacity for monitoring is vastly greater. PMUs provide high-rate synchronised data across the grid, and machine-learning models can process it in real time. But the core lesson of 2003 applies to any monitoring system, including one built on foundation models. A monitoring system can fail silently, and a silent failure is worse than no monitoring at all, because operators trust it. A deployed anomaly detector must therefore monitor itself: it must detect when its inputs have stopped arriving, when its outputs have become implausibly quiet, and when its own behaviour has drifted from its validated baseline. That requirement, which the final chapter takes up in detail, is not a refinement but a precondition for using machine learning in safety-critical control rooms. Hierarchy and coherence A final grid-specific consideration concerns hierarchy. Load and generation are forecast at many levels: feeder, substation, zone, region, system. These forecasts should be coherent, meaning that the forecasts for the parts should add up to the forecast for the whole. Independently produced forecasts at each level generally are not coherent, and incoherent forecasts lead to inconsistent decisions at different levels of the organisation. Statistical methods for forecast reconciliation, developed by Rob Hyndman and colleagues over the past fifteen years, adjust a set of independent forecasts at all levels to make them coherent while improving their overall accuracy, by exploiting the information that each level provides about the others. These methods can be applied to forecasts from any model, including foundation models, and in hierarchical settings they often improve accuracy more than a change of base model does. A foundation model that produces good forecasts for each substation independently, followed by reconciliation, is a natural architecture for a utility's distributed forecasting needs, and one that is likely to become common as foundation models are adopted for the lower levels of the grid hierarchy. Chapter 10. Financial Exchanges: Faint Signals and Adversarial Streams Financial markets generate some of the richest time-series data in existence. A major exchange records every order submitted, modified, cancelled and executed, with timestamps at microsecond or nanosecond resolution, for thousands of instruments simultaneously. The resulting streams are vast, precisely timed, and archived for decades. To a machine-learning researcher, they look like an ideal training ground. They are, in fact, among the hardest time-series data to model usefully, and the reasons are instructive for anyone applying forecasting and anomaly detection elsewhere. Markets are noisy to the point where the signal is often indistinguishable from chance. They are nonstationary in ways that defeat models trained on the past. And they are adversarial: participants adapt to each other's strategies, so that a pattern that is discovered and exploited tends to disappear. Little about prices can be forecast, somewhat more about volatility and volume, and anomaly detection at exchanges turns out to be as much about the integrity of systems and conduct as about prices. What can and cannot be forecast The most important fact about financial prices is that their short-term changes are very hard to forecast. The efficient market hypothesis, in its various forms, holds that prices incorporate available information quickly, so that predictable patterns in returns are arbitraged away by traders seeking to profit from them. The hypothesis is not literally true, and there is a large literature documenting small, persistent anomalies in returns. But as a practical matter, the predictable component of the return on a liquid asset over a horizon of minutes to days is tiny relative to its random component. A model that forecasts the direction of the next day's return correctly 52 percent of the time would be extraordinarily valuable, and is extraordinarily hard to build. This has an immediate implication for general-purpose forecasting models. A foundation model trained largely on series with strong trends and seasonality, such as electricity demand, retail sales or web traffic, has learned priors that are actively misleading for prices, which have no seasonality and no persistent trend. The Google study discussed in Chapter 7 illustrates this: on daily exchange-rate data, close to a random walk, one version of TimesFM produced forecasts with a mean absolute scaled error above 12, meaning its errors were twelve times those of simply predicting no change. Its successor, TimesFM 2.5, did much better, and was the best model in that comparison. But even the best result in such a comparison does not mean the model has found predictable structure in exchange rates; it may mean only that it has learned, correctly, to forecast something close to no change. Other quantities are much more forecastable. Volatility, the magnitude of price changes regardless of direction, exhibits strong persistence: turbulent periods follow turbulent periods, and calm periods follow calm ones. Robert Engle's autoregressive conditional heteroskedasticity model, published in 1982, and Tim Bollerslev's generalisation in 1986, the GARCH model, captured this clustering, and Engle shared the 2003 Nobel Memorial Prize in Economic Sciences partly for this work. Later models using realised volatility, computed from high-frequency intraday returns, improved forecasts further; a simple specification proposed by Fulvio Corsi in 2009, which regresses tomorrow's realised volatility on averages over the past day, week and month, remains a strong benchmark. Trading volume, bid–ask spreads and order-book depth also have predictable intraday patterns and persistence. These quantities matter for risk management, for the execution of large orders, and for the operation of exchanges themselves. The limit order book Most modern exchanges operate a limit order book. Traders submit orders to buy or sell a quantity at a specified price or better. Orders that cannot be executed immediately rest in the book, sorted by price: the highest bid and the lowest ask define the best prices, and the difference between them is the spread. A trade occurs when an incoming order matches a resting one. The state of the book, the quantities resting at each price level on each side, changes with every order event, and the sequence of those events is a multivariate, irregularly timed stream of extraordinary density. Deep learning has been applied extensively to forecasting short-term price movements from order-book data. A widely cited model, DeepLOB, published in 2019 by Zihao Zhang, Stefan Zohren and Stephen Roberts at the University of Oxford, combined convolutional layers that extracted features across price levels with an LSTM that modelled their evolution, and predicted whether the mid-price would rise, fall or stay level over the next several events. It was evaluated on a public benchmark dataset of order-book data from five stocks on the Nasdaq Nordic exchange over ten trading days, published in 2018, and on proprietary data from the London Stock Exchange. Numerous later studies applied transformers and other architectures to the same task. These studies demonstrated that order-book data contains some short-term predictive information about price movements, which is consistent with the market microstructure literature: an imbalance between resting buy and sell quantities, for example, carries information about the direction of the next price change. But they also illustrated the difficulty of translating predictive accuracy into practical value. The predictable movements are typically smaller than the spread, so a trader who acts on them must pay a cost that exceeds the expected gain unless they are already a market maker with privileged access. The relationships learned on one stock or one period often do not transfer to another. And the public benchmark data is small and old by the standards of the field, so results on it say little about performance in current markets. Foundation models for markets General time-series foundation models have had limited success with prices, for the reasons already given. Domain-specific pretraining offers a more promising route. Kronos, published in 2025 by a team led from Tsinghua University, was pretrained on more than 12 billion candlestick records, each summarising an interval's open, high, low and close prices and trading volume, from 45 exchanges worldwide. It uses a learned tokeniser to convert these multi-dimensional records into discrete tokens, preserving both price dynamics and trading-activity patterns, and an autoregressive transformer trained on the resulting sequences. Its authors reported substantial zero-shot improvements over general time-series foundation models on several tasks, including a 93 percent improvement in the rank information coefficient for price forecasting, a measure of how well a model ranks assets by their subsequent returns, over the leading general foundation model, and a 9 percent reduction in error for volatility forecasting. They also reported improved fidelity in generating synthetic candlestick sequences, which has applications in stress testing and in augmenting training data for other models. Results of this kind require particular caution in finance. Financial research has a well-documented problem with backtest overfitting: with enough strategies tried on the same historical data, some will appear profitable by chance, and the more variants are tested, the more likely it is that the best-looking result is spurious. Marcos López de Prado, David Bailey and colleagues have written extensively on methods for estimating the probability that a backtested strategy is overfit and for deflating reported performance accordingly. A foundation model's reported improvement in a ranking metric is not a trading strategy, and the gap between the two, after transaction costs, market impact, capacity constraints and the inevitable decay of any exploited pattern, is usually large. The more defensible applications of financial foundation models are in quantities that are genuinely forecastable, such as volatility and volume, and in generating realistic scenarios for risk management, rather than in forecasting returns. Three kinds of anomaly at an exchange Anomaly detection at an exchange concerns at least three different things, each with its own data, its own stakes and its own methods. The first is market stability: detecting conditions in which prices are moving in disorderly ways, liquidity is evaporating, or a feedback loop between automated participants is developing. Exchanges and regulators use automatic mechanisms, such as trading halts triggered when a price moves more than a set percentage within a set time, as a last line of defence, but earlier detection of deteriorating conditions could allow gentler interventions. The second is market integrity: detecting manipulative or abusive trading. Spoofing, placing large orders with the intention of cancelling them before execution to create a false impression of supply or demand, leaves characteristic patterns in the order stream: orders placed and cancelled in rapid succession, positioned to move the price toward the manipulator's genuine orders on the other side. Layering, wash trading, in which a participant trades with itself to create the appearance of activity, and insider trading, which appears as unusual positioning ahead of announcements, each have their own signatures. Surveillance teams at exchanges and regulators use rule-based alerts and, increasingly, machine-learning models to identify candidate cases for investigation. The third is operational: detecting malfunctions in trading systems, whether the exchange's own matching engines and data feeds or the systems of member firms. A trading system that begins sending erroneous orders can cause losses, and disorder, in minutes. The Flash Crash The events of the afternoon of 6 May 2010 combined all three. In about twenty minutes, major US equity indices fell by around five to six percent, on top of earlier declines that day, and then recovered most of the loss within a similar interval. During the turmoil, some individual stocks traded at absurd prices, a penny or less in some cases, and in others at $100,000 a share, as orders executed against placeholder quotes that market makers had posted far from the market, never expecting them to be filled. The joint report by the staffs of the Securities and Exchange Commission and the Commodity Futures Trading Commission, published in September 2010, traced the start of the decline to a large automated sell order in E-mini S&P 500 futures, 75,000 contracts worth about $4.1 billion, executed by a mutual fund complex using an algorithm that targeted a percentage of trading volume without regard to price or time. As the selling pressure absorbed buying interest, high-frequency traders that had initially bought the contracts began to sell them rapidly to each other and to the market, which increased volume and caused the algorithm to sell faster. Liquidity in the futures market thinned dramatically, and the disorder spread to individual stocks and exchange-traded funds as market makers withdrew. A later prosecution alleged that a London-based trader, Navinder Singh Sarao, had been spoofing the E-mini market that day; he pleaded guilty in 2016 to charges related to spoofing, though the extent of his contribution to the crash remains debated. From an anomaly detection perspective, the Flash Crash had several striking features. The individual signals of distress, a large sell program, thinning order-book depth, rapidly rising volume with little net position change, were visible in the data in real time. But they arose in different markets, futures and equities, monitored by different systems at different institutions, and the feedback loop between them developed in minutes. No single monitor saw the whole picture. The regulatory response, including single-stock circuit breakers and later the limit up–limit down mechanism, which prevents trades outside a band around a recent reference price, addressed the symptoms with automatic rules rather than relying on detection. Knight Capital The operational dimension is illustrated by an event two years later. On the morning of 1 August 2012, Knight Capital, then one of the largest market makers in US equities, deployed new trading software to its servers. The update was installed on seven of eight servers but not the eighth, on which a repurposed configuration flag reactivated old code that had not been used for years. When the market opened, that server began sending a flood of orders into the market. In about 45 minutes, before the problem was identified and stopped, Knight's systems sent millions of orders and accumulated large unwanted positions in around 150 stocks, and the firm lost more than $460 million. It required emergency financing within days and was acquired within months. The Securities and Exchange Commission's subsequent order described a detail that every designer of monitoring systems should know. Before the market opened that morning, one of Knight's internal systems generated 97 automated emails that referred to the malfunctioning component and indicated an error. Those emails were not designed as alerts, were sent to a group of staff who did not typically act on them in real time, and were not acted upon. The information needed to identify the problem existed before the first erroneous order was sent. The organisation did not have the means to recognise it as a warning. This is, at bottom, the same failure as in the 2003 blackout: data present, warning absent. It has nothing to do with the sophistication of the detection model. The Knight emails did not require a foundation model to interpret; they said, in effect, that something was wrong. What was missing was the connection between a signal and a person with the authority and context to act on it, in time. Any monitoring system, however accurate its models, must be designed around that connection. Speed, scale and where models fit The timescales of modern markets constrain where deep learning can be used. The fastest trading firms operate on timescales of microseconds, using specialised hardware such as field-programmable gate arrays and strategies whose logic is simple enough to execute in that time. No foundation model, and indeed no deep network of any significant size, can run at that speed. Deep learning in markets operates at slower layers: at the scale of seconds to minutes for execution algorithms and intraday risk monitoring, minutes to hours for surveillance, and days for portfolio-level risk and volatility forecasting. At those slower layers, the tools described in this book have clear applications. Volatility and volume forecasting benefit from patch-based and state-space architectures, and from pretraining on large collections of market data. Surveillance benefits from anomaly detection models that learn the normal behaviour of individual participants and instruments and flag departures, combined with rule-based detection of known manipulation patterns. Exchange operations benefit from monitoring models that track latency, message rates, error rates and other system health metrics, which behave more like the observability data on which models such as Toto were trained than like prices. The adversarial problem One feature distinguishes markets from grids and factories: the system being monitored contains intelligent participants who respond to the monitoring. A manipulator who learns that a surveillance model flags a certain pattern of order placement and cancellation will change the pattern. A trading strategy that exploits a forecastable regularity will, if successful and widely copied, erode that regularity. This means that models in finance face not only the natural distribution shift that affects all time series, but a deliberate shift driven by the behaviour the model is trying to detect or exploit. The practical consequences are that models must be retrained or recalibrated frequently, that detection systems should combine learned models with rules derived from regulatory definitions of misconduct, which do not change when the manipulator does, and that the most valuable anomaly detection may be the detection of novel patterns rather than known ones. A foundation model trained to recognise normal market behaviour broadly, rather than specific manipulation signatures, may be better placed to flag something new, precisely because it is not looking for anything in particular. Whether it can do so reliably, without overwhelming investigators with false alarms during the many periods of legitimate but unusual market activity, is an empirical question that each surveillance team must answer on its own data. Chapter 11. Industrial Sensors: Failure Before It Happens A modern industrial plant is instrumented to an extent that would have been unimaginable a generation ago. A gas turbine carries hundreds of sensors measuring temperatures, pressures, flows, speeds and vibrations. A chemical plant may have tens of thousands of measurement points feeding its distributed control system. A wind farm reports the power output, rotor speed, pitch angle, nacelle orientation, gearbox temperature and generator vibration of every turbine, every few seconds. Most of this data is collected for control and is then archived, often for years, and rarely examined again. The promise of predictive maintenance is to use that data to detect developing faults before they cause failures, so that maintenance can be scheduled when it is needed rather than on a fixed calendar or after a breakdown. The economic case is strong: unplanned downtime in heavy industry is expensive, catastrophic failures can be dangerous, and calendar-based maintenance replaces many components that still had years of life. But the practical record of predictive maintenance programmes is mixed, and the reasons have less to do with the sophistication of the models than with the nature of industrial failure data. Those reasons also mark the boundary of what deep learning and foundation models can contribute. The failure curve Reliability engineers describe the progression of a typical fault with what is called the P–F curve, a concept developed in the reliability-centred maintenance methodology that emerged from the commercial aviation industry in the 1960s and 1970s. At some point, a component begins to degrade: a bearing race develops a microscopic crack, a seal begins to wear, an insulation layer begins to break down. For a while, the degradation is undetectable. Then it reaches a point, the potential failure point P, at which it becomes detectable by some monitoring technique. If nothing is done, it progresses to the functional failure point F, at which the component no longer performs its function. The interval between P and F, the P–F interval, is the window of opportunity for predictive maintenance. The length of the P–F interval depends on the failure mode and on the monitoring technique. For a rolling-element bearing monitored by high-frequency vibration analysis, the interval can be weeks to months: the earliest signs of a defect appear as faint high-frequency impacts long before the bearing becomes noisy or hot. For the same bearing monitored only by temperature, the interval may be days or hours, because temperature rises only when the bearing is already badly damaged. For some failure modes, such as a sudden fatigue fracture, the interval may be effectively zero with any practical monitoring. This framework clarifies what a predictive model can achieve. It cannot detect a fault before point P, because before P there is no signal to detect. Its value lies in detecting the fault as close to P as possible, which extends the usable warning, and in estimating how far along the curve the fault has progressed, which determines how urgently action is needed. The most important determinant of success is not the model but the choice of what to measure, and at what rate, because that determines where P lies. The scarcity of failures The central difficulty in industrial failure prediction is that failures are rare, varied and poorly recorded. A well-maintained plant may experience a particular failure mode on a particular class of equipment a handful of times in a decade. Each occurrence will differ in its details, because it occurred under different operating conditions, on equipment of different age and maintenance history. And the records of what failed, when and why are often incomplete. Maintenance logs are written by technicians in free text, with inconsistent terminology, and the timestamp of a work order may differ by days from the actual onset of the fault. This means that the supervised learning approach that dominates other applications of deep learning, collect many labelled examples of each class and train a classifier, is rarely available for industrial failures. There are not enough examples, and the labels are unreliable. The practical alternatives are to train on normal data only and detect departures from it, the anomaly detection approach of Chapter 8; to use physics-based simulation to generate synthetic failure data; or to pool data across many similar assets to accumulate enough failures for supervised learning. Each has limitations. A benchmark from simulation The most widely used benchmark for remaining-useful-life prediction illustrates both the value and the limitations of simulation. In 2008, Abhinav Saxena and colleagues at NASA's Ames Research Center released a set of datasets generated by C-MAPSS, a simulation model of a large commercial turbofan engine. Each dataset contains many simulated engines, each starting with a different degree of initial wear and manufacturing variation, run until failure under the progressive degradation of one or more engine modules. Twenty-one sensor measurements, temperatures, pressures, speeds and ratios at stations along the gas path, are recorded for each operating cycle. The task is to predict, from a partial history, how many cycles remain before failure. The four sub-datasets vary in the number of operating conditions and fault modes, from a single condition and single fault mode to six operating conditions and two fault modes. C-MAPSS has been used in hundreds of studies, and deep learning methods, convolutional, recurrent and attention-based, have steadily reduced the reported prediction errors. But the benchmark has well-known limitations. The data is simulated, so the degradation follows the simulation's model, which is smoother and more consistent than real degradation. The sensor noise is synthetic. Most studies cap the remaining-useful-life target at a constant value early in each engine's life, on the assumption that degradation is undetectable then, and results depend substantially on the choice of cap. And because the benchmark has been so extensively studied, there is a risk that reported improvements reflect accumulated tuning to its specific characteristics rather than general advances. A later dataset, released in 2021 by researchers at ETH Zurich and NASA and known as N-CMAPSS, used real flight profiles recorded from commercial aircraft to drive the simulation, producing more realistic operating conditions, and has become an important complement. The deeper lesson of C-MAPSS is about operating conditions. In the sub-datasets with six operating conditions, corresponding to different combinations of altitude, speed and throttle setting, the raw sensor readings are dominated by the operating condition rather than by degradation. A model that does not first account for the operating condition will mostly learn to recognise the condition. Normalising each reading by the typical value for its operating condition, or clustering readings by condition and modelling degradation within each cluster, is essential. Real industrial equipment has the same property, usually to a greater degree: a pump's vibration depends on its flow rate, a turbine's temperatures on its load, a compressor's pressures on the ambient temperature. Separating the effect of operating condition from the effect of degradation is often the most important modelling step. Spacecraft telemetry A second influential case comes from space operations. In a paper presented at the KDD conference in 2018, Kyle Hundman and colleagues at NASA's Jet Propulsion Laboratory described a system for detecting anomalies in telemetry from two spacecraft, the Soil Moisture Active Passive satellite, SMAP, and the Curiosity rover on Mars, whose mission is formally the Mars Science Laboratory, MSL. Spacecraft telemetry presents the anomaly detection problem in a pure form: there are many channels, the operating environment is extreme and changing, failures are rare and costly, and operations teams cannot inspect the hardware. The system trained a separate LSTM forecaster for each telemetry channel, using the channel's own history and the commands sent to the spacecraft as inputs, and computed the prediction error at each step. Rather than using a fixed threshold, it applied a nonparametric dynamic thresholding procedure that examined the distribution of recent smoothed errors and chose a threshold that best separated a small number of large errors from the rest, with a pruning step to reduce false positives. The labelled anomalies used for evaluation were drawn from incident reports filed by spacecraft operations engineers. The SMAP and MSL datasets released with the paper became two of the most widely used benchmarks in deep anomaly detection research. They also became two of the datasets criticised in the analyses described in Chapter 8: some of their labelled anomalies are trivially detectable, and evaluation on them with point adjustment produces inflated scores. The original JPL system, which did not rely on point adjustment and was designed around the operational needs of a specific team, holds up better than many of the methods later benchmarked on its data. That pattern recurs often: a system built for a real application, with attention to how its alerts would be used, tends to be more useful than a system built to improve a benchmark score. Cyber-physical attacks A third case concerns deliberate interference. The Secure Water Treatment testbed, SWaT, built at the Singapore University of Technology and Design, is a scaled-down but functionally realistic six-stage water treatment plant, with real pumps, valves, tanks, chemical dosing and filtration, controlled by industrial programmable logic controllers. In 2015 its operators recorded a dataset covering days of normal operation followed by days in which researchers launched a series of cyberattacks, manipulating sensor readings and actuator commands to disrupt the process. The dataset includes readings from dozens of sensors and actuators, sampled once per second. SWaT has been important for research on detecting attacks on industrial control systems, which is a distinct problem from detecting natural faults. An attacker may deliberately make the manipulated signals look normal, for example by replaying recorded normal readings to the operators while the actual process is driven into an unsafe state. Detecting such attacks requires checking the physical consistency of the readings, whether the level in a tank is consistent with the flow into and out of it, rather than the statistical normality of each signal in isolation. This is a case where modelling cross-channel relationships, grounded in physical laws, is essential and channel-independent models are inadequate. Vibration and the high-frequency regime Rotating machinery, motors, pumps, fans, compressors, gearboxes and turbines, accounts for a large fraction of industrial maintenance effort, and vibration monitoring is the most established technique for detecting its faults. Vibration is measured by accelerometers mounted on the machine's bearing housings, typically sampled at rates of tens of kilohertz to capture the high-frequency content in which early faults appear. The signal processing for vibration analysis is a mature field. A defect on a bearing's outer race, for example, produces a series of impacts at a frequency determined by the bearing's geometry and the shaft speed, and these impacts excite structural resonances at much higher frequencies. Envelope analysis demodulates the high-frequency resonance to recover the impact rate, which can then be compared with the theoretical defect frequencies to identify which component is failing. Spectral kurtosis, a technique developed by Jérôme Antoni and colleagues in the 2000s, identifies the frequency band in which the impacts are most visible. These methods, applied by trained analysts, have been the backbone of condition monitoring programmes for decades. Deep learning has been applied to vibration data extensively, often by converting signals into time–frequency images such as spectrograms and applying convolutional networks. Many studies report very high classification accuracy on public datasets, of which the most widely used, from Case Western Reserve University, consists of vibration recordings from a test rig with artificially seeded bearing defects of known size. But the transfer from such laboratory data to real machines has been disappointing. Seeded defects are not natural defects; test-rig conditions are not plant conditions; and models trained on one machine often fail on another of nominally the same type because of differences in mounting, resonance and operating load. Foundation models have so far contributed less to high-frequency vibration analysis than to lower-frequency process monitoring. The general-purpose models of Chapter 6 were pretrained mostly on data sampled at intervals of seconds to days, and their patch sizes and context lengths are poorly suited to signals at tens of kilohertz. A model with a context of 2,048 readings sees less than a tenth of a second of a vibration signal sampled at 25 kilohertz, which may not contain even one revolution of a slow shaft. Applying foundation models to such data requires either specialised pretraining on high-frequency signals, or preprocessing that extracts lower-rate features, such as band energies or envelope spectra computed over each second, which can then be treated as conventional time series. The second approach is more common in practice and often more effective. Running at the edge Many industrial monitoring applications require models to run on hardware located at the asset: an embedded processor in a sensor module, an industrial gateway in a substation cabinet, a controller on a wind turbine. The reasons include limited or unreliable network connectivity, the volume of high-rate data, which is impractical to transmit continuously, latency requirements for protective actions, and security policies that prohibit sending operational data to external cloud services. Edge hardware is constrained in computing power, memory and energy. A model that requires a graphics processor and gigabytes of memory cannot run there. This has driven interest in compact models: IBM's Tiny Time Mixers, with around a million parameters; state-space and recurrent models with constant memory per step; and techniques such as quantisation, which represents weights with fewer bits, and distillation, which trains a small model to mimic a large one. A common pattern is to use a large foundation model offline, in the cloud or a data centre, to analyse historical data, establish baselines and generate training targets, and to deploy a small distilled or specialised model at the edge for real-time scoring. From alert to action The final link in industrial failure prediction is the maintenance decision. An alert from a monitoring system is useful only if it leads to an action that reduces cost or risk: an inspection, a component replacement, a change in operating conditions, a planned shutdown. Each of these actions has a cost. An inspection requires a technician's time and may require shutting down the equipment. A replacement uses a spare part and labour. A planned shutdown loses production. The value of a monitoring system therefore depends on the balance between the cost of false alarms, each of which triggers an unnecessary action, and the cost of missed or late detections, each of which allows a failure to occur or to cause more damage than necessary. That balance differs by asset. For a critical compressor whose failure would shut down an entire plant, a high false-alarm rate may be acceptable. For a fleet of small pumps with installed spares, it would not be. Operator trust is the critical resource. A monitoring system that produces frequent false alarms, or alerts that cannot be explained, will be ignored, and once ignored it will not be noticed when it is right. Several practices help sustain trust. Alerts should indicate which sensors and patterns triggered them and how the current behaviour differs from normal. They should be graded by severity and urgency. They should be linked, where possible, to known failure modes, so that the technician knows what to look for. And the system's performance should be tracked against actual maintenance findings, so that its alert thresholds can be adjusted and its credibility established over time. A foundation model can improve the statistical quality of the anomaly scores. It cannot by itself supply these elements, which depend on integration with the plant's maintenance processes and on the knowledge of its engineers. What foundation models change Despite these limitations, foundation models do change the economics of industrial monitoring in one important respect. The traditional approach required building and validating a model for each asset or asset class, using months of normal operating data, before any monitoring could begin. For a plant with thousands of assets of hundreds of types, that was prohibitively expensive, and monitoring was limited to the most critical equipment. A pretrained model that can serve as a forecaster or reconstructor of normal behaviour for any process signal, with no asset-specific training, makes it feasible to deploy baseline monitoring across the whole plant from the first day, and to refine it for specific assets as data and experience accumulate. The anomaly scores it produces will not be as good as those of a carefully built specialist model, and they will require the same attention to thresholds, operating conditions and alert design. But broad coverage at modest quality, combined with deep coverage of critical assets, is a better allocation of limited engineering effort than deep coverage of a few assets and none of the rest. That shift, from bespoke monitoring of a few assets to general monitoring of many, is likely to be the most significant practical effect of foundation models in industry. Chapter 12. Building a Real-Time Failure Prediction System The preceding chapters have examined the methods and the domains separately. Brought together, they define the design of a working system: one that ingests live streams from a grid, an exchange or a plant, forecasts their behaviour, detects departures from normal, and delivers warnings that people can act on. The design is presented as a sequence of decisions, each of which corresponds to a failure mode observed in real deployments. None of the decisions is exotic. Together, they distinguish a system that improves outcomes from one that adds noise. Start from the decision, not the data The first decision is what the system is for, stated in terms of an action. Not "detect anomalies in turbine data" but "give the maintenance planner at least two weeks' warning of bearing degradation on the twelve critical turbines, so that bearing replacement can be scheduled during planned outages." Not "monitor the grid" but "alert the control-room operator within ten seconds when a forced oscillation above a set amplitude appears, with an estimate of its source." Not "surveil the market" but "produce a daily queue of no more than twenty candidate spoofing cases, ranked by likelihood, for the surveillance team's review." A statement of this kind fixes the quantities that matter for evaluation: the required warning time, the acceptable false-alarm rate, the capacity of the people who will receive the alerts, and the information they need to act. It also fixes the horizon, the sampling rate and the latency budget, which in turn constrain the choice of model. A day-ahead load forecast can use a large model running on a cloud server for minutes. An oscillation detector must run on streaming data within seconds. A bearing degradation monitor needs a context of weeks but can be updated hourly. Many failed deployments began from the data rather than the decision. An organisation with a large archive of sensor data commissioned an anomaly detection system to find whatever was there, and received a system that flagged many anomalies, most of which were of no operational interest, with no clear owner for any of them. Within months, the alerts were being ignored. Ingestion and the integrity of the stream The second decision concerns the stream itself. Every real-time system must handle data that arrives late, out of order, duplicated, or not at all; timestamps that are inconsistent across sources; sensors that are recalibrated, replaced or moved; and values that are physically impossible. The ingestion layer must detect and handle each of these before any model sees the data, because models trained on clean data will misinterpret these artefacts as real behaviour. Several principles help. Missing data should be represented explicitly as missing, not as zero or as the last observed value, so that downstream models and monitors can distinguish absence from a real reading. Late data should be accepted and incorporated when it arrives, with any affected scores recomputed and the recomputation recorded. Physically impossible values, a negative flow, a temperature above the sensor's range, should be flagged as data-quality events rather than passed to the anomaly detector. Changes to the sensor configuration, such as recalibrations and replacements, should be recorded as metadata and made available to the models, so that a step change following a replacement is not reported as an anomaly. Data-quality events themselves are often the most important early warnings. A sensor that begins to drop out intermittently may be failing, or the equipment it monitors may be causing interference. A communications link that begins to deliver data late may be overloaded. In the 2003 blackout, the most consequential failure was of the monitoring system itself. The ingestion layer should therefore report on its own health, the rate of missing, late and invalid data by source, as a first-class output of the system. A tiered model architecture The third decision is the architecture of the models. The evidence surveyed in this book points toward a tiered design rather than a single model. At the first tier, cheap and robust methods run on every stream at full rate: physical limit checks, simple statistical tests on the recent rate of change, and lightweight forecasters such as exponential smoothing or small state-space models. These catch gross faults immediately, provide a baseline against which more sophisticated models can be compared, and continue to function if the more sophisticated tiers fail. At the second tier, a compact learned model, a small state-space model, a recurrent model, or a distilled version of a foundation model, runs on each stream or group of related streams at the rate needed for the decision. It produces a forecast distribution and an anomaly score at each step, updated incrementally as each reading arrives. This is the workhorse of real-time detection, and its design should favour constant per-step cost and memory, so that it can run indefinitely on many streams. At the third tier, a large foundation model runs less frequently, perhaps every few minutes or hours, on longer windows, or on demand when a lower tier raises a candidate alert. It provides a second opinion with greater context and more general knowledge, and it can handle streams for which no specialised model has been built. In forecasting applications, it may be the primary model for low-volume, high-diversity series, with specialists handling the high-volume, well-understood ones, along the lines of the routing approach described in Chapter 7. This tiered design has several advantages over a single model. It controls cost, because the expensive model runs only when and where it adds value. It provides redundancy, because a failure or degradation of one tier does not blind the system. And it provides interpretability, because when the tiers agree, confidence is high, and when they disagree, the disagreement itself is informative. Context: operating modes and covariates The fourth decision is how to supply the context that determines what is normal. The industrial chapter showed that raw sensor readings are often dominated by operating conditions; the grid chapter showed that load is dominated by weather and calendar; the markets chapter showed that intraday patterns depend on the time of day and the presence of scheduled events. A model that is not told about these factors must infer them, and will often mistake a change in operating condition for an anomaly. The system should therefore maintain an explicit model of operating context: the current operating mode of each asset, derived from control-system states or inferred by clustering; known covariates such as weather forecasts, calendars and production schedules; and planned events such as maintenance, switching operations, market announcements and software deployments. This context should be supplied to the forecasting and detection models as covariates, which modern foundation models such as Chronos-2 can accept directly, and should be used to suppress or annotate alerts that coincide with planned events. Planned events deserve particular attention. A large fraction of false alarms in industrial monitoring arise from maintenance and testing activities that produce unusual signals by design. A large fraction of operational incidents in trading and software systems arise from deployments and configuration changes, as the Knight Capital case showed. Linking the monitoring system to the change-management process, so that every planned change is known to the monitor and every alert is checked against recent changes, both reduces false alarms and helps identify the cause of real ones. Calibrated scores and principled thresholds The fifth decision concerns the conversion of model outputs into alerts. Each model produces a score, typically a prediction error, a reconstruction error, or a tail probability under the forecast distribution. These scores are not directly comparable across streams, across models or over time, and they are not calibrated probabilities. The system should calibrate scores so that they have a consistent meaning. One approach is to convert each score into an empirical tail probability relative to a recent reference window of scores on the same stream, which accounts for differences in scale and noise level. Conformal methods, described in Chapter 7, provide a principled framework for doing this with guarantees on the long-run false-alarm rate under weak assumptions. Extreme value methods, described in Chapter 8, model the tail of the score distribution directly. Thresholds should then be set to meet the alert budget fixed in the first decision. If the surveillance team can review twenty cases a day, the threshold should produce about twenty cases a day, and the question for the models is how to rank candidates so that the twenty reviewed are the most likely to be real. That is a different optimisation target from maximising a benchmark F1 score, and it is closer to what VUS-PR and related ranking-based metrics measure. Thresholds should be reviewed regularly against the outcomes of investigated alerts, and the system should record every alert, every investigation outcome and every threshold change, so that its performance can be audited. For multivariate systems, combining scores across channels is a design decision in its own right. Taking the maximum across channels catches any single-channel anomaly but increases false alarms as the number of channels grows. Averaging dilutes single-channel anomalies. Learned combinations, or models that score the joint behaviour of related channels directly, capture relationship breaks that no single channel reveals. A practical design often scores individual channels and physically meaningful groups of channels separately, and surfaces both. Explanation as part of the alert The sixth decision concerns what an alert contains. An alert that says only "anomaly detected on asset 47, score 0.97" invites the question "so what?" and will not be acted upon by a busy operator. An alert should state which signals are involved, how their current behaviour differs from the expected behaviour, how long the departure has lasted, whether it is growing, what the forecast predicts if it continues, and whether similar patterns have occurred before and with what outcome. Much of this can be generated from the models' own outputs. A forecasting model's predicted distribution, plotted against the observed values, shows the departure directly. Attribution methods can identify which input channels and time steps contributed most to an anomaly score. A search over historical data for the nearest similar patterns, using the representations computed by a foundation model or the distance computations of the matrix profile, can retrieve past episodes and their outcomes from the maintenance or incident record. Linking an alert to known failure modes, through rules written with domain engineers, tells the operator what the departure might mean physically. The explanation also serves the system's own improvement. When an operator investigates an alert and records the outcome, real fault, harmless anomaly, sensor problem, planned activity, that outcome becomes a label. Over time, these labels accumulate into the dataset of real anomalies and failures that the domain chapters identified as the critical scarcity. A system designed to collect them systematically will improve; a system that discards them will not. Monitoring the monitor The seventh decision is how the system watches itself. A failure prediction system is itself a system that can fail, and the most dangerous failure is a silent one. The system should continuously monitor the rate at which data arrives from each source and raise an alert when it falls; the distribution of its own anomaly scores, raising an alert if scores become implausibly quiet or implausibly noisy; the agreement between its tiers, raising an alert if they diverge persistently; and the drift of its models' forecast errors on normal data, which indicates that the models' picture of normal behaviour is becoming stale. That last point connects to a hazard identified in Chapter 5. An adaptive model with long memory can absorb a slowly developing fault into its picture of normal, so that the fault never produces a large anomaly score. The defence is to compare the current behaviour not only against the recent past, which the model has adapted to, but against a fixed reference from a period of known-good operation, such as the period after the last major overhaul. A slow drift relative to that reference, even with no anomaly relative to the recent past, is a signal of gradual degradation. Monitoring at multiple time scales in this way is standard practice in condition monitoring and should be built into any learned system. The system should also be tested regularly with injected anomalies: synthetic departures added to live data streams, or replayed recordings of past incidents, whose detection is verified end to end, from ingestion through scoring to the arrival of the alert in front of the right person. A system that has not been tested in this way cannot be assumed to work, however good its models' benchmark scores. Updating the models The eighth decision concerns how the models change over time. Every time series drifts. Grid demand changes with electrification and efficiency; markets change with regulation and technology; plants change with wear, modification and changes in product. A model that was accurate when deployed will become less accurate over time unless it is updated. Zero-shot foundation models have an apparent advantage here, since they are not trained on the target data and so cannot become stale in the usual sense; they forecast from whatever context they receive. But their pretraining reflects the data available at the time, and they cannot learn from the deployment data unless they are fine-tuned. The Google operational study noted that frozen foundation models cannot be retrained to correct for drift, and that addressing this requires shadow deployments in which updated or alternative models run alongside the production model so that their performance can be compared before any switch. A disciplined update process has several elements: a fixed evaluation set from recent data, refreshed on a schedule, against which candidate models are compared; shadow deployment of candidates before promotion; a rollback mechanism; and a record of which model version produced each score and each alert, so that past decisions can be audited. These are standard practices in software engineering, and they apply with particular force to models whose behaviour can change subtly with each update. Governance and the human in the loop The final decision concerns who is responsible. In safety-critical settings, grids, plants, financial infrastructure, a learned model should inform human decisions rather than make them, except where automatic action is unavoidable because of timescale, as with protective relays and trading halts, and in those cases the automatic actions should be simple, verified and bounded. The monitoring system's role is to make the human's situational awareness as accurate and timely as possible, not to replace it. This has practical implications. Operators should be trained in what the system can and cannot detect, so that they do not over-trust it. The system's limitations, the failure modes it was not designed to catch, the conditions under which its forecasts are unreliable, should be documented and visible. Responsibility for acting on each class of alert should be assigned to a named role, so that no alert, like the Knight Capital emails, arrives in an inbox where no one is expected to act on it. And the organisation should review, after every significant incident, whether the system detected it, whether the alert reached the right person, and whether the person acted, treating each step as a potential point of failure. None of this is specific to deep learning, and that is the point. The models described in this book are powerful tools for forecasting and detecting changes in temporal data, more powerful than anything available a few years ago. They become useful only when embedded in a system whose design reflects what a warning is for, who will receive it, and what happens when the system itself is wrong. Conclusion In 2022, a single linear layer embarrassed the most sophisticated forecasting architectures in the literature. By 2025, pretrained models with as few as eleven or thirty-five million parameters could produce zero-shot forecasts for series they had never seen that matched or beat specialised models trained on those series, across dozens of domains. The distance between those two points is the story this book has told, and its lesson is more specific than "scale works" or "deep learning wins." What made the difference was a short list of representational choices, each of which respects a property of temporal data that the first generation of transformers ignored. Patches gave the attention mechanism meaningful units to compare, in place of individual readings that carry almost no information on their own. Instance normalisation removed the variation in level and scale that otherwise swamped the variation in shape. Channel independence, or carefully limited sharing between channels, prevented models from learning correlations that would not persist. Decomposition into trend and seasonality at several scales let models extrapolate slow movements and project cycles separately, as forecasters have done by hand for decades. And state-carrying architectures, structured state spaces and modernised recurrent networks, offered a way to process unbounded streams at constant cost per reading. Synthetic data, which turned out to teach temporal structure remarkably well, supplied the variety that real archives lacked. None of these ideas was invented by the foundation-model builders. Their contribution was to combine them and train at a scale where the combination generalised. That account carries a consequence that is easy to miss. If foundation models succeed because they encode general properties of temporal shape, then they will succeed most where those properties dominate, in series governed by trend, seasonality, persistence and local pattern, and least where they do not. The evidence fits. Foundation models are strong on traffic, energy demand, web traffic and retail. They are weak on prices, which have none of these properties in forecastable form. They are least tested on the rare, idiosyncratic, physically specific precursors of failure that matter most in grids, exchanges and plants, because those patterns are scarce in any training corpus, real or synthetic. A general prior about temporal shape is valuable exactly to the extent that the problem is about general temporal shape. What follows for practice Several practical conclusions follow from the chapters taken together. The first is that the leaderboard is a shortlist, not a decision. Aggregate differences between leading models are often a fraction of a percentage point, smaller than the variation across tasks, and the benchmarks carry contamination risks that only private, recent data can eliminate. The model that matters is the one that performs best on the organisation's own data, in the conditions that matter for its decisions, at a cost the application can bear. Sometimes that will be a foundation model. Sometimes it will be a gradient-boosted tree or exponential smoothing. Often it will be both, with a router deciding which series go where. The second is that cost is not a footnote. The thousandfold gap between a large neural forecaster on a graphics processor and a tree model on an ordinary processor will narrow as models become smaller and hardware cheaper, and the trend toward small models, Moirai 2.0's smallest variant beating its larger ones, TiRex at 35 million parameters, Tiny Time Mixers at around a million, is encouraging. But for applications that score millions of streams in real time, or run on hardware at the asset, the gap still decides the architecture. The third is that anomaly detection needs to be evaluated as if the evaluation could be wrong, because for years it was. The point-adjustment episode, in which random scores matched published methods, is a warning that applies beyond its own literature. Any detection system should be tested against strong simple baselines, with metrics that reward ranking rather than lucky hits, on data whose labels have been checked, and finally against the outcomes of real investigations. The fourth, and most important, is that the hard part of failure prediction is rarely the model. The 2003 blackout, the Knight Capital loss and, in a different way, the Iberian collapse all involved information that existed in some form before the failure, and a gap between that information and a person able to act on it. In 2003 the alarm system failed silently. At Knight, the warnings arrived as emails no one was expected to read. In Iberia, operators lacked a real-time view of the reactive-power margin that was eroding beneath them. Better models would have helped in none of these cases unless the system around them had been designed to deliver the right warning, to the right person, with enough context to act, and to tell them when it had itself stopped working. What remains unsettled Several questions remain open, and the answers will shape the next phase of the field. The scaling behaviour of time-series models is unclear. Language models improve predictably with size over many orders of magnitude; time-series models appear to saturate much earlier. Whether this reflects a smaller underlying vocabulary of temporal structure, insufficient diversity in available data, an irreducible noise floor in most series, or simply architectures not yet suited to scale, is not known. The answer will determine whether the next generation of models is larger or merely better designed. The role of explicit structure is unsettled. The largest models mostly abandon explicit decomposition and rely on scale to learn trend and seasonality implicitly. The best domain-specific systems still use decomposition, covariates and physical constraints. It is not yet clear whether general models will absorb these advantages, or whether the most effective systems will remain hybrids of learned priors and explicit domain structure. The treatment of multivariate dependence is unsettled. Channel independence won the early benchmarks, but the most consequential anomalies in physical systems are often breaks in the relationships between channels, and attacks on industrial control systems are detectable mainly through physical inconsistency between signals. Models such as Chronos-2 that learn cross-series dependence from synthetic data are a promising step, but whether such learned dependence can capture the specific physical relationships of a real plant or grid remains to be shown. Calibration under extreme conditions is unsettled. The events that matter most, Uri, the Flash Crash, a cascading grid failure, are precisely those for which probabilistic forecasts trained on normal history are least reliable. Conformal methods offer guarantees on average coverage, but average coverage is not what matters in the tail. Better methods for honest uncertainty in rare, correlated, high-consequence events are among the most important open problems in the field. What the reader should do differently For a reader responsible for a forecasting or monitoring system, the practical upshot can be stated plainly. Treat a foundation model as a strong default prior, especially for new, short or numerous series, and as a way to extend baseline monitoring across assets that would otherwise go unwatched. Test it on your own recent data against the best simple methods you have. Wrap its probabilistic outputs in calibration and check coverage in the conditions you care about. Keep cheap, robust methods running alongside it. Design alerts around the decisions they should trigger and the people who will receive them. Record every outcome. And build the system to report its own failures before anyone has to discover them. The data that might have prevented the next blackout, the next trading accident, the next unplanned shutdown is very likely already being recorded. The tools for reading it have improved more in the past four years than in the preceding twenty. Whether they help depends less on which model is chosen than on whether the system around it is built to turn a signal into a warning, and a warning into an action, in time. Glossary Anomaly score. A number produced by a detection method for each observation or window, higher when the behaviour is less consistent with the model of normal. It becomes an alert only when compared with a threshold. Channel independence. The practice of forecasting each variable of a multivariate series separately with one shared model, rather than feeding all variables into the model together. Conformal prediction. A family of methods that use observed past errors to set the width of prediction intervals so that they achieve a stated coverage, with guarantees that hold under weak assumptions. Contamination. The presence of benchmark test data, or closely related data, in a model's pretraining corpus, which inflates its apparent accuracy. CRPS (continuous ranked probability score). A proper scoring rule for probabilistic forecasts that rewards forecast distributions that are both accurate and appropriately sharp. Decomposition. The separation of a series into a slowly varying trend, one or more repeating seasonal components, and a residual. Foundation model. A large model pretrained on broad data that can be applied to many tasks, often without task-specific training. MASE (mean absolute scaled error). A forecast error measure that divides a forecast's absolute error by that of a naive or seasonal naive forecast on the same series; values below one beat the naive benchmark. Patch. A short window of consecutive readings from one channel, embedded as a single token for a transformer or recurrent model. Phasor measurement unit (PMU). A grid sensor that measures voltage and current magnitudes and phase angles many times per second, time-synchronised by satellite navigation signals. Point adjustment. An evaluation protocol for anomaly detection that credits detection of an entire labelled anomalous segment if any single point within it is flagged; shown to inflate scores to the point that random detectors appear competitive. Remaining useful life (RUL). The estimated time or number of operating cycles before a component reaches functional failure. Reversible instance normalisation (RevIN). Normalising each input window by its own mean and standard deviation before it enters a model, and reversing the transformation on the output. Selective state-space model. A state-space model, such as Mamba, whose state-update parameters depend on the current input, allowing it to choose what to retain and what to forget. State-space model. A model in which a hidden state vector evolves through time according to learned dynamics driven by the input, allowing constant-cost updates as each new observation arrives. VUS-PR (volume under the precision–recall surface). An anomaly detection metric that averages precision–recall performance over a range of tolerances for how far a detection may lie from a labelled anomaly, avoiding a single fixed threshold. Zero-shot forecasting. Producing a forecast for a series using only its recent context and what the model learned in pretraining, with no training on that series or its domain. Further Reading Rob J. Hyndman and George Athanasopoulos, Forecasting: Principles and Practice (OTexts, third edition, 2021). The standard introduction to statistical forecasting, freely available online. Its treatment of exponential smoothing, decomposition, error measures and hierarchical reconciliation is the baseline against which every deep method should be judged. Ailing Zeng, Muxi Chen, Lei Zhang and Qiang Xu, "Are Transformers Effective for Time Series Forecasting?" (AAAI, 2023). The short paper that showed simple linear models outperforming the first generation of forecasting transformers, and probed why. Essential for understanding what the later architectures were designed to fix. Yuqi Nie, Nam H. Nguyen, Phanwadee Sinthong and Jayant Kalagnanam, "A Time Series Is Worth 64 Words: Long-Term Forecasting with Transformers" (ICLR, 2023). The PatchTST paper, which introduced patching and channel independence to time-series transformers and became the template for most later models. Boris N. Oreshkin, Dmitri Carpov, Nicolas Chapados and Yoshua Bengio, "N-BEATS: Neural Basis Expansion Analysis for Interpretable Time Series Forecasting" (ICLR, 2020). A clear demonstration that a neural architecture built around trend and seasonal decomposition can beat the best statistical hybrids on the M4 competition data. Albert Gu and Tri Dao, "Mamba: Linear-Time Sequence Modeling with Selective State Spaces" (2023). The paper that introduced selective state-space models. Read together with Gu, Goel and Ré's earlier S4 paper (ICLR, 2022) for the foundations. Abdul Fatir Ansari and colleagues, "Chronos: Learning the Language of Time Series" (Transactions on Machine Learning Research, 2024), and "Chronos-2: From Univariate to Universal Forecasting" (2025). Two papers from Amazon that bracket the development of pretrained forecasting models, from quantised tokens to covariate-aware group attention trained largely on synthetic data. Abhimanyu Das, Weihao Kong, Rajat Sen and Yichen Zhou, "A Decoder-Only Foundation Model for Time-Series Forecasting" (ICML, 2024). The TimesFM paper from Google, a lucid account of designing and training a practical forecasting foundation model. Taha Aksu and colleagues, "GIFT-Eval: A Benchmark for General Time Series Forecasting Model Evaluation" (2024). The benchmark most widely used to rank foundation models, with a careful discussion of how to avoid contamination. Renjie Wu and Eamonn Keogh, "Current Time Series Anomaly Detection Benchmarks Are Flawed and Are Creating the Illusion of Progress" (IEEE Transactions on Knowledge and Data Engineering, 2023). A sharp and readable critique of the datasets that dominated deep anomaly detection research. Read with Siwon Kim and colleagues, "Towards a Rigorous Evaluation of Time-Series Anomaly Detection" (AAAI, 2022), on point adjustment. Qinghua Liu and John Paparrizos, "The Elephant in the Room: Towards a Reliable Time-Series Anomaly Detection Benchmark" (NeurIPS Datasets and Benchmarks, 2024). The TSB-AD benchmark and its sobering comparison of statistical, neural and foundation-model detectors. Kyle Hundman and colleagues, "Detecting Spacecraft Anomalies Using LSTMs and Nonparametric Dynamic Thresholding" (KDD, 2018). A model of how to design a detection system around the needs of a real operations team. U.S.–Canada Power System Outage Task Force, Final Report on the August 14, 2003 Blackout in the United States and Canada (2004). The definitive account of the 2003 blackout, and a case study in how monitoring systems fail. Staffs of the CFTC and SEC, Findings Regarding the Market Events of May 6, 2010 (2010). The official reconstruction of the Flash Crash, showing how signals spread across markets faster than any single monitor could follow. ENTSO-E Expert Panel, final report on the grid incident in Spain and Portugal on 28 April 2025 (2026). A detailed account of a modern, inverter-rich grid collapse, and of the monitoring gaps that preceded it. Hashtags: #TimeSeriesDeepLearning #TimeSeriesAnalysis #TimeSeriesForecasting #AnomalyDetection #TimeSeriesFoundationModels #DeepLearning #MachineLearning #ArtificialIntelligence #PredictiveAnalytics #ZeroShotForecasting #ProbabilisticForecasting #TransformerModels #PatchTST #TimesFM #Chronos #Moirai #Mamba #StateSpaceModels #RecurrentNeuralNetworks #MultivariateTimeSeries #SeasonalDecomposition #RealTimeMonitoring #StreamingAnalytics #PredictiveMaintenance #FailurePrediction #IndustrialIoT #PowerGridMonitoring #FinancialMarketSurveillance #EdgeAI #ModelEvaluation

Download the Book (PDF): Introduction In 1914, the New York Court of Appeals decided a case about a woman named Mary Schloendorff, who had agreed to be examined under ether at a New York hospital but had, she said, expressly refused an operation. While she was unconscious, surgeons removed a fibroid tumor. Her claim against the hospital failed on grounds that no longer matter much, but the opinion by Judge Benjamin Cardozo contained a sentence that has been quoted in American courts ever since: "Every human being of adult years and sound mind has a right to determine what shall be done with his own body." A surgeon who operates without consent, Cardozo went on, commits an assault. That sentence is the seed from which most of modern American bioethics law has grown. It is the reason a doctor must explain the risks of a procedure before performing it. It is the reason a competent patient may refuse chemotherapy, dialysis, a ventilator, or a feeding tube, even when refusal means death. It underlies the elaborate federal rules that govern research on human subjects, and it is the moral center of the statutes, now in force in a growing number of American jurisdictions, that allow a dying adult to obtain a prescription for medication to end his or her life. When a court, a legislature, or a regulator in the United States is confronted with a new question at the edge of medicine, its first instinct is almost always to ask the question Cardozo asked: who decides, and did that person agree? This booklet argues that the instinct is right as far as it goes, and that it does not go far enough. Consent is the law's most powerful tool for governing medicine, but it was built for a particular situation: a competent adult, a known treatment, a set of risks that can be described, and a choice that affects mainly the person making it. The three frontiers examined here, experimental therapy, the end of life, and the editing of the human genome, each strain one or more of those assumptions. At the frontier of research, the risks are by definition not fully known, and the person consenting is often desperate enough that the line between hope and understanding blurs. At the end of life, the person may no longer be competent, or may be competent and asking for something the law has historically treated as a crime. And at the frontier of genetic engineering, the most consequential choices would affect people who do not yet exist and cannot consent to anything. Where consent is strained, the law has had to supplement it with other tools: procedural safeguards, institutional review, licensing, criminal prohibitions, funding restrictions. Where it has failed to do so, it has left gaps. The most conspicuous of those gaps is the one surrounding heritable human genome editing, which the United States controls not through any statute addressing the question, but through a single sentence in an annual appropriations bill. The shape of the argument The book moves through its three subjects in an order that follows the logic of consent itself. Chapter 1 explains how informed consent became a legal doctrine, moving from Cardozo's battery rule to the modern negligence-based duty of disclosure articulated in Canterbury v. Spence in 1972, and why the choice between a "professional" and a "reasonable patient" standard of disclosure still divides the states. Chapter 2 carries the doctrine into research, where the law of consent was rebuilt after Nuremberg and Tuskegee into a federal regulatory system, and where cases such as Moore v. Regents of the University of California and Grimes v. Kennedy Krieger Institute exposed the limits of treating a research subject as simply a patient with a longer consent form. Chapter 3 turns to the patient who wants access to an unapproved therapy outside a trial, and to the constitutional and statutory fights over expanded access and the federal Right to Try Act of 2018. Chapters 4 through 7 address the end of life. Chapter 4 traces the right to refuse treatment from the Quinlan decision in New Jersey in 1976 through the Supreme Court's decision in Cruzan in 1990 and the long public agony of the Schiavo litigation, and it examines what happens when patients can no longer speak for themselves. Chapter 5 explains why the Supreme Court in 1997 declined to recognize a constitutional right to physician assistance in dying, and how that decision handed the question back to the states. Chapter 6 examines the statutory model that Oregon pioneered in 1994 and that has since spread, in varying forms, to more than a dozen American jurisdictions, including New York and Illinois in the most recent legislative cycle. Chapter 7 steps outside the United States, to Canada, the Netherlands, Belgium, Switzerland, and elsewhere, to test the argument that once assisted dying is legal, its boundaries inevitably expand. Chapters 8 and 9 address genetic engineering. Chapter 8 describes how somatic gene editing, which alters the cells of an existing patient, has been absorbed into the ordinary machinery of drug regulation, from the approval of the first CRISPR-based therapy in late 2023 to the bespoke base-editing treatment of an infant in 2025. Chapter 9 examines germline editing, which alters embryos and would pass changes to future generations, and the thin, improvised, and internationally uneven set of rules that currently stand between the technology and its use. A note on method and register The subjects in this book are among the most emotionally charged in law. People die in these pages, some after long illnesses, some in research that went wrong, some by their own choice with a physician's help. The treatment here is legal and analytical. It describes what the law is, how it came to be that way, what arguments have moved courts and legislatures, and where the doctrine is unstable or incomplete. Where the book takes positions, they are positions about the structure and adequacy of legal rules, not about whether any particular person made the right choice. A few terms deserve precision at the outset. "Medical aid in dying" and "physician-assisted suicide" describe the same practice: a physician prescribes a lethal dose of medication, which the patient takes himself or herself. Supporters prefer the first term; opponents and many older judicial opinions use the second. American statutes generally provide that death under their procedures is not "suicide" for legal purposes. This book uses "medical aid in dying" when discussing the statutes, which is their own vocabulary, and the older term when discussing the cases that used it. "Euthanasia" means something different: a clinician administers the lethal medication directly. It is illegal in every American state and legal in several other countries. The distinction matters, legally and practically, and the book keeps it. Similarly, "somatic" gene editing changes the genes in some of the cells of a living person; the changes are not inherited. "Germline" or "heritable" editing changes the genes of an embryo, egg, or sperm, so that the alteration is present in every cell of the resulting person and can be passed to that person's children. Almost every legal and ethical distinction in the field of genome editing turns on that line. The law described here is primarily American, and it is current through late 2026. Much of it is state law, which varies considerably, and much of it is changing. This book is an explanation of the legal landscape and is not legal advice for any particular situation. Why the frontier matters It would be possible to treat these three subjects as unrelated specialties, each with its own experts and literature. They are connected by more than the fact that each involves medicine. In each, a technology or practice has outrun the categories that the law had available, and the law has responded, first, by reaching for consent, and second, by discovering what consent cannot do on its own. A patient cannot meaningfully consent to risks no one has discovered, so research law adds independent review. A physician cannot safely rely on the consent of a patient whose judgment may be distorted by depression or pressure, so aid-in-dying statutes add waiting periods, witnesses, and capacity assessments. A child who will be born from an edited embryo cannot consent at all, so the question becomes whether society, through its law, should consent on that child's behalf, and if so, through what institution. The answers the law has given are uneven. Some are sophisticated and well tested. Others are accidents of politics and budget procedure. Understanding which is which is the purpose of what follows. Chapter 1: The Body's Border: How Consent Became Law Before informed consent was an ethical principle, it was a trespass rule. The earliest American cases on medical consent did not ask whether a patient understood a procedure. They asked whether the patient had agreed to be touched in the way the surgeon touched her. The answer to that question determined whether the surgeon had committed battery, the ancient tort of unconsented physical contact. Everything that the law now expects of a physician explaining a treatment has been built on that foundation, and some of the most persistent confusions in the field come from the fact that the old foundation and the new structure do not quite fit. From battery to disclosure The classic early cases involve surgeons who did something different from, or more than, what the patient agreed to. In Mohr v. Williams, decided by the Minnesota Supreme Court in 1905, a patient consented to an operation on her right ear. Once she was anesthetized, the surgeon found the left ear in worse condition and operated on it instead. The operation was, by the surgeon's lights, skillful and beneficial. The court nonetheless held that the patient could recover for battery, because she had not agreed to the operation that was performed. The following year, in Pratt v. Davis, the Illinois courts reached a similar result where a surgeon removed a patient's uterus without her agreement. Schloendorff v. Society of New York Hospital, decided in 1914, gave the principle its enduring formulation in Cardozo's sentence about the right of every adult of sound mind to determine what shall be done with his own body. The battery framework has two features worth noticing. First, it is simple. The question is whether the contact was authorized, and a patient who agreed to surgery on the right ear did not authorize surgery on the left. Second, it does not depend on harm. A battery is complete when the unconsented touching occurs; the patient need not prove that the operation made her worse off. That is why Mrs. Mohr could recover even though the surgery may have helped her. These features make battery a poor fit for the problem that came to dominate medical consent law in the twentieth century: the patient who agreed to exactly the procedure that was performed, but was not told about a risk that then materialized. That patient did consent to being touched. Her complaint is that her consent was uninformed. Courts initially tried to fit such cases into battery, reasoning that consent obtained without disclosure of material risks was not really consent at all. But the fit was awkward, and by the middle of the century the law had begun to move the problem into negligence. The phrase "informed consent" appears to have entered American case law in Salgo v. Leland Stanford Jr. University Board of Trustees, a 1957 California appellate decision involving a patient who was left paralyzed after a diagnostic procedure called translumbar aortography. The court held that a physician violates a duty to the patient by withholding facts necessary to form the basis of an intelligent consent. Three years later, in Natanson v. Kline, the Kansas Supreme Court addressed a woman who suffered severe injuries from cobalt radiation therapy after a mastectomy and who had not been warned of the risk. The court treated the failure to disclose as a species of malpractice and measured the physician's obligation by what a reasonable medical practitioner would disclose under the same or similar circumstances. That formulation, which ties the duty of disclosure to professional custom, has a certain logic. Negligence in medicine is ordinarily measured by the standard of the profession: a surgeon is negligent if she performed an operation in a way a reasonably careful surgeon would not have. Applying the same measure to disclosure made informed consent look like any other malpractice claim, proved by expert testimony about what doctors ordinarily do. It also had an obvious weakness. If the profession's custom was to tell patients very little, the professional standard would ratify that silence. Canterbury v. Spence and the patient's point of view The decisive challenge to the professional standard came in 1972, in a decision of the United States Court of Appeals for the District of Columbia Circuit. Canterbury v. Spence involved a nineteen-year-old named Jerry Canterbury who underwent a laminectomy, a spinal operation, for severe back pain. The surgeon did not tell him that the operation carried a small risk of paralysis, roughly one percent according to the surgeon's own testimony. The day after the operation, Canterbury fell from his hospital bed, and he later developed paralysis and incontinence that never fully resolved. The opinion, written by Judge Spottswood Robinson III, rejected the idea that the scope of disclosure should be set by medical custom. The duty to disclose, Robinson reasoned, exists to protect the patient's right to decide, and so its scope must be measured by the patient's needs rather than the profession's habits. In the opinion's words, "the patient's right of self-decision shapes the boundaries of the duty to reveal." The test the court adopted was materiality: a risk must be disclosed if a reasonable person in the patient's position would be likely to attach significance to it in deciding whether to undergo the treatment. The physician must also disclose the nature of the proposed treatment, the alternatives to it, and the likely consequences of doing nothing. Canterbury made three other moves that shaped the field. First, it dispensed with the need for expert testimony on the standard of disclosure, since a jury can decide what a reasonable patient would want to know without a doctor telling it. Expert testimony remains necessary to establish what the risks actually were and how likely they were, but not to establish that they should have been mentioned. Second, it adopted an objective test of causation. A patient who was not warned of a risk must show not merely that he personally would have declined the procedure had he known, which is a claim every injured plaintiff will make in hindsight, but that a reasonable person in his position would have declined. Third, it recognized two exceptions to the duty. In an emergency, where the patient cannot consent and delay would cause serious harm, a physician may proceed. And under what the court called the "therapeutic privilege," a physician may withhold information where disclosure itself would pose a serious threat to the patient's well-being, though the court warned that the privilege must not swallow the rule by allowing doctors to stay silent simply because they fear the patient would refuse. The California Supreme Court adopted a materially similar patient-centered standard the same year in Cobbs v. Grant, as did the Rhode Island Supreme Court in Wilkinson v. Vesey. Other states have held to the professional standard, some by judicial decision and some by statute passed in the malpractice reform movements of the 1970s and 1980s. The states today divide roughly evenly between the two approaches, and a number use hybrid formulations. New York, for example, codified informed consent in its Public Health Law, defining the duty with reference to what a reasonable medical practitioner would disclose, while building in an objective causation requirement that looks to what a reasonably prudent person in the patient's position would have done. Texas created a Medical Disclosure Panel that compiles lists of risks that must be disclosed for particular procedures, and lists of procedures for which no disclosure is required; disclosure in compliance with the lists creates a rebuttable presumption that the duty was met. What must be disclosed Materiality is easy to state and hard to apply, and much of modern informed consent litigation concerns the edges of the category. Several recurring questions show how the doctrine has developed. The first concerns the risks of refusing. In Truman v. Thomas, decided by the California Supreme Court in 1980, a physician repeatedly recommended a Pap smear to a patient who declined, apparently because of the cost. He did not explain what the test was for or what might happen if she did not have it. She later died of cervical cancer that the test would likely have detected in time. The court held that the duty of disclosure extends to the risks of declining a recommended procedure, a doctrine sometimes called "informed refusal." The logic follows directly from Canterbury: a choice to decline treatment is as much an exercise of self-determination as a choice to accept it, and it can be no better informed. The second concerns statistics about prognosis. In Arato v. Avedon in 1993, the California Supreme Court considered a claim by the family of a man with pancreatic cancer who had not been told of the very low five-year survival rate for his disease. His family argued that had he known, he would have declined aggressive chemotherapy and put his business affairs in order. The court declined to hold that physicians must, as a matter of law, disclose statistical life expectancy data, leaving the question of what a reasonable patient would want to know to the jury in the circumstances of the case. The decision is a reminder that materiality remains a jury question, not a checklist. The third, and perhaps most consequential, concerns facts about the physician rather than the procedure. In Johnson v. Kokemoor, decided in 1996, the Wisconsin Supreme Court allowed evidence that a neurosurgeon had overstated his experience with a difficult aneurysm operation and had failed to tell the patient that the risks were substantially lower at a more experienced center. The court reasoned that where a physician's inexperience materially increases the risk, a reasonable patient would want to know it. In Howard v. University of Medicine and Dentistry of New Jersey, the New Jersey Supreme Court in 2002 held that a patient who alleged that his surgeon had misrepresented his credentials and experience could pursue the claim as a matter of informed consent, provided he could show that the misrepresentation was material and would have caused a reasonable patient to decline. Courts have been more reluctant to require disclosure of a physician's personal characteristics, such as health conditions or substance use, where no increased risk to the patient is shown. The fourth concerns who must do the disclosing. In Shinal v. Toms, decided in 2017, the Pennsylvania Supreme Court held that the duty to obtain informed consent belongs to the physician personally and cannot be delegated to a physician assistant or other staff member. The decision drew criticism from hospital groups who argued that team-based care makes delegation routine and sensible. It illustrates the continuing gravitational pull of the battery origins of the doctrine: the person who will perform the procedure is the person who must secure the patient's agreement. Consent as process, and its limits In practice, informed consent in American medicine has two lives. One is the legal doctrine just described, which comes into play only after something has gone wrong and a patient sues. The other is a daily clinical routine, dominated by standardized forms that patients sign, often shortly before a procedure, often without reading closely. Empirical studies of consent conversations and forms have repeatedly found that patients recall little of what they were told and that forms are written at reading levels above those of many patients. The form itself is not the consent; it is evidence that a consent conversation took place. Courts will generally treat a signed form as strong but not conclusive evidence that the required disclosure was made. The gap between legal doctrine and clinical reality has produced several reform efforts. The most interesting from a legal standpoint is the move toward "shared decision-making," in which physicians use structured decision aids to present options and trade-offs, and patients' values are explicitly elicited. Washington State enacted a statute in 2007 that gives physicians who use a certified patient decision aid a stronger evidentiary position in informed consent litigation, an attempt to reward better practice through the liability system rather than simply to punish failures. Three structural limits of the doctrine matter for everything that follows in this book. The first is that informed consent law assumes a competent adult. When the patient lacks decision-making capacity, because of unconsciousness, dementia, severe mental illness, or youth, the law must substitute someone else's decision for the patient's own. The rules for doing so, involving guardians, health care proxies, statutory surrogate hierarchies, and parental authority, are the subject of much of the end-of-life law discussed in Chapter 4. They are an admission that consent in its pure form is not always available. The second is that the doctrine assumes known risks. Canterbury asks what a reasonable patient would want to know about risks that the physician knows or should know. It has little to say about risks that no one yet understands. For established treatments, the unknown risks are usually small. For experimental therapies, the unknown is the point, which is why research law has had to develop along its own track. The third is that informed consent is a private law doctrine enforced by individual lawsuits. Its remedy is damages after the fact, and its incentives operate only where an injured patient can prove that a reasonable person would have chosen differently. This is a weak lever for governing practices whose harms are diffuse, delayed, or borne by someone other than the person who consented. A parent who consents to a genetic procedure on an embryo is not consenting for herself, and the person who bears the consequences may not exist for years, or may bear them in ways no court can measure. The law of informed consent was not designed for that situation, and it cannot be stretched to cover it. These limits do not diminish what the doctrine accomplished. In the space of about sixty years, American law moved from treating medical consent as a question of whether a surgeon trespassed to treating it as a question of whether the patient was equipped to decide. That shift reflects a changed understanding of the relationship between physician and patient, from one of trusted authority to one of shared, if unequal, responsibility. The rest of this book examines what happens when that model is asked to do more than it was built for. Chapter 2: Consent at the Frontier: Research Subjects and the Regulatory State A patient who agrees to an established operation is choosing among known options for her own benefit. A research subject is in a different position. She is agreeing to take part in an activity whose primary purpose is to produce knowledge, not to treat her, and whose risks are uncertain precisely because the knowledge does not yet exist. She may also be ill, frightened, and hopeful, and she may be dealing with an investigator who is also her physician, who has a professional and sometimes a financial stake in the study, and whom she trusts. The common law of informed consent, built around individual lawsuits after injury, was never adequate to that situation. The law that governs research today was built instead in the aftermath of scandal, as a system of regulation that attempts to protect subjects before they are harmed rather than compensate them afterward. Scandal and response The modern law of human research begins at Nuremberg. In 1947, an American military tribunal tried twenty-three German physicians and administrators for experiments conducted on concentration camp prisoners. The judgment in United States v. Karl Brandt, known as the Doctors' Trial, set out ten principles for permissible experimentation, now called the Nuremberg Code. Its first principle begins: "The voluntary consent of the human subject is absolutely essential." The Code required that the subject have legal capacity, be free of coercion, and have sufficient knowledge and comprehension of the experiment to make an enlightened decision. It was an extraordinary statement, but for years American researchers tended to regard it as a code for barbarians, not for themselves. That complacency did not survive the 1960s. In 1966, the Harvard anesthesiologist Henry Beecher published an article in the New England Journal of Medicine describing twenty-two studies, published in reputable journals by researchers at respected institutions, in which subjects had been exposed to serious risks, often without their knowledge. Other episodes became public in the same period. At the Jewish Chronic Disease Hospital in Brooklyn in 1963, investigators injected live cancer cells into elderly patients without telling them what the injections contained. At the Willowbrook State School in New York, researchers deliberately infected children with intellectual disabilities with hepatitis to study the disease, obtaining parental consent in circumstances where admission to the overcrowded institution was, for a time, easier for families who agreed to the research. The episode that finally produced federal legislation was the United States Public Health Service study of untreated syphilis in Black men in Macon County, Alabama, conducted from 1932 until 1972. The men were not told they had syphilis, were told they were being treated for "bad blood," and were deliberately left untreated even after penicillin became the standard cure in the 1940s. When the Associated Press reported the study in 1972, the public reaction led Congress to pass the National Research Act of 1974. The Act created a National Commission for the Protection of Human Subjects of Biomedical and Behavioral Research, and it required institutions receiving federal research funds to establish institutional review boards to review research involving human subjects. The National Commission's most influential product was the Belmont Report of 1979. It set out three principles that still frame American research ethics. Respect for persons requires treating individuals as autonomous agents and protecting those with diminished autonomy; its practical expression is informed consent. Beneficence requires minimizing harm and maximizing benefit; its practical expression is the assessment of risks and benefits by review committees. Justice requires fair distribution of the burdens and benefits of research; its practical expression is fairness in the selection of subjects, so that research burdens do not fall disproportionately on the poor, the institutionalized, or the racially marginalized, as they had at Tuskegee and Willowbrook. The architecture of federal research law The regulations that implement those principles have two main branches. The first is the Federal Policy for the Protection of Human Subjects, known as the Common Rule, codified for the Department of Health and Human Services at 45 C.F.R. Part 46 and adopted in 1991 by a group of federal departments and agencies. It applies to research conducted or supported by those agencies, and to research at institutions that have agreed to apply it. The second is the Food and Drug Administration's regulations at 21 C.F.R. Parts 50 and 56, which apply to clinical investigations of drugs, biologics, and medical devices regulated by the FDA, regardless of who pays for them. The two sets of rules overlap heavily but are not identical. Under both, the central mechanisms are the same: prospective review of research by an institutional review board, or IRB, and informed consent of the subject or the subject's legally authorized representative. An IRB must find, among other things, that risks to subjects are minimized, that risks are reasonable in relation to anticipated benefits and the importance of the knowledge expected, that selection of subjects is equitable, and that informed consent will be sought and documented. The regulations list the required elements of consent: a statement that the study involves research, its purposes and procedures, the reasonably foreseeable risks and discomforts, the expected benefits, appropriate alternatives, the extent of confidentiality, whether compensation or treatment is available for injury in research involving more than minimal risk, contacts for questions, and a statement that participation is voluntary and may be discontinued at any time without penalty. The comparison with ordinary clinical consent is instructive, and Table 1 sets out the main differences. Table 1. Consent in clinical care compared with federally regulated research. Feature Clinical care Common Rule research FDA-regulated investigation Source of rule State tort law and statutes 45 C.F.R. Part 46 21 C.F.R. Parts 50 and 56 When it applies All treatment Federally conducted or funded research Trials of FDA-regulated products Prior review None required IRB approval IRB approval plus FDA oversight Disclosure standard Professional or reasonable-patient, by state Enumerated elements; reasonable-person framing Enumerated elements Main enforcement Damages suits after injury Loss of federal funding, agency action Clinical holds, warning letters, disqualification Two points stand out. First, research consent is regulated before the fact, while clinical consent is policed only after the fact. Second, the federal regulations do not generally create a private right of action. A subject who was harmed by inadequate consent in a federally funded study cannot sue directly under the Common Rule; she must bring a state-law claim for negligence, battery, fraud, or breach of fiduciary duty, and courts frequently look to the federal regulations as evidence of the applicable standard of care. The Common Rule was substantially revised in a rule published in January 2017, with most provisions taking effect in January 2019. The revision responded to longstanding criticism that consent forms had become lengthy legal documents designed to protect institutions rather than inform subjects. The revised rule requires that consent begin with a concise and focused presentation of the key information most likely to help a prospective subject understand why he or she might or might not want to participate, and it frames the overall disclosure obligation around the information that a reasonable person would want to have to make an informed decision. The echo of Canterbury is deliberate: the federal research rules have adopted the patient-centered materiality standard that remains contested in state tort law. The revision also created a new category of "broad consent" for storage and future research use of identifiable biospecimens and data, and it required most federally funded cooperative research to use a single IRB. The FDA has been working to harmonize its own regulations with the revised Common Rule, as Congress directed in the 21st Century Cures Act of 2016, and it issued proposed rules to that end in 2022. Until harmonization is complete, investigators working on studies subject to both regimes must comply with the stricter requirement on each point. The regimes leave a notable gap. Research that is neither federally funded nor conducted at an institution that has extended the Common Rule to all its research, and that does not involve an FDA-regulated product, is subject to no federal human-subjects regulation at all. A privately funded behavioral study, or a study of an unregulated procedure, may proceed without IRB review. A few states, notably Maryland and New York, have filled part of this gap with statutes of their own, but most have not. The gap will reappear in Chapter 9, because research on human embryos is one of the areas in which federal funding is prohibited and private funding therefore operates with fewer federal controls. When consent is not enough Several cases decided under state law show both the power and the limits of consent as a protection for research subjects. Grimes v. Kennedy Krieger Institute, decided by the Maryland Court of Appeals in 2001, involved a study of lead paint abatement methods in Baltimore. Researchers at an affiliate of Johns Hopkins University enrolled families living in older rental housing that had received different levels of lead abatement, and they measured lead levels in children's blood over time. The study was designed in part to determine whether cheaper, partial abatement methods were effective, which necessarily meant that some children lived in housing where lead exposure continued. Two families sued, alleging that they had not been adequately informed of the hazards. The trial court dismissed the cases on the ground that the researchers owed the subjects no legal duty. The Court of Appeals reversed in a sharply worded opinion. It held that the consent agreements and the research relationship itself could give rise to a duty of care, and it compared the study to notorious episodes of research abuse. The court also suggested that parents could not consent to their children's participation in nontherapeutic research presenting more than minimal risk. On a motion for reconsideration, the court clarified that the statement was not intended as a sweeping rule, but the case remains the leading example of a court treating the research relationship as one of legal responsibility rather than mere agreement. The death of Jesse Gelsinger in 1999 exposed a different weakness. Gelsinger was eighteen and had a mild, medically managed form of ornithine transcarbamylase deficiency, a genetic disorder of the liver. He enrolled in a Phase 1 gene therapy trial at the University of Pennsylvania's Institute for Human Gene Therapy, which used an adenovirus vector to deliver a working copy of the gene. He died four days after the infusion from a massive immune reaction. Investigations by the FDA found that the investigators had not adequately disclosed serious adverse events in earlier participants or the deaths of animals in preclinical studies, had enrolled Gelsinger despite laboratory values that arguably should have excluded him, and had not clearly disclosed that the institute's director held equity in a company with a financial interest in the research. The family's lawsuit against the university and others settled in 2000. In 2005, the university and the researchers reached a civil settlement with the Department of Justice that restricted the director's future work with human subjects. The Gelsinger case is still taught because it shows how consent can fail even when every signature is in place. A healthy young man with a controlled disease agreed to a trial that offered him no realistic prospect of personal benefit. He did so, by his family's account, in a spirit of altruism. The information that would have allowed him to weigh the risks realistically was either missing or muted. And the institution was operating under a financial conflict that the consent process did not bring into view. That last theme was central to Moore v. Regents of the University of California, decided by the California Supreme Court in 1990. John Moore was treated for hairy cell leukemia at the UCLA Medical Center. His physician recommended removal of his spleen, which was medically appropriate, and over the following years had him return for repeated samples of blood and other tissue. Without telling Moore, the physician and a researcher developed a cell line from his cells and obtained a patent on it, which proved commercially valuable. Moore sued on several theories. The court rejected his claim that the use of his cells amounted to conversion of his property, reasoning that extending property law to excised human tissue would hinder research. But it held that he had stated a cause of action for breach of fiduciary duty and lack of informed consent, because a physician must disclose personal interests unrelated to the patient's health, whether research or economic, that may affect the physician's professional judgment. Moore established a principle that the federal research regulations only partly capture: the physician-investigator's conflicts of interest are themselves material information. Later cases tested how far the principle reaches. In Greenberg v. Miami Children's Hospital Research Institute, a federal district court in Florida in 2003 considered claims by families who had donated tissue and information to help researchers find the gene responsible for Canavan disease, only to find that the resulting patent was used to restrict access to genetic testing. The court dismissed the informed consent claim, declining to extend a duty to disclose economic interests to researchers who were not treating physicians, but allowed a claim for unjust enrichment to proceed. The dispute between Arizona State University researchers and members of the Havasupai Tribe, who had given blood samples for diabetes research and later learned that the samples had been used for studies of schizophrenia, inbreeding, and population migration, settled in 2010 with a payment and the return of the remaining samples. And the long story of Henrietta Lacks, whose cervical cancer cells were taken without her knowledge in 1951 and became the HeLa line used in laboratories worldwide, reached a settlement between her estate and a biotechnology company in 2023. The therapeutic misconception The deepest problem with research consent is not a missing disclosure but a persistent misunderstanding. In the early 1980s, the psychiatrist Paul Appelbaum and colleagues documented what they called the "therapeutic misconception": the tendency of research subjects to believe that decisions about their care in a study are being made for their individual benefit, when they are in fact being made according to a protocol designed to answer a scientific question. Subjects in randomized trials often believe they will receive whichever treatment is best for them, and subjects in early-phase trials often overestimate the likelihood that they will benefit. The misconception is not cured by better forms. It arises from the circumstances: a sick person, a physician in a white coat, a hospital setting, and a natural reluctance to accept that one's participation serves someone else's purposes. It is most acute in first-in-human trials of novel therapies, including gene therapies and gene editing, where the primary purpose is to assess safety and the realistic chance of direct benefit may be small. The Declaration of Helsinki, the World Medical Association's statement of research ethics, which was most recently revised in October 2024, requires that physicians combining research with care do so only to the extent justified by the potential value of the research and when there is good reason to believe participation will not adversely affect the health of the patients involved. That standard asks something of investigators that consent alone cannot supply. The research regulations respond to the misconception in two ways. They require that consent documents state clearly that the activity is research, and they place the burden of the risk-benefit judgment on the IRB rather than on the subject alone. The subject's consent is necessary, but it is not sufficient: a study that is unreasonably risky cannot be rescued by a signature. The regulations also include a narrow exception to consent for emergency research, adopted by the FDA in 1996, which permits investigation of treatments for life-threatening conditions in patients who cannot consent, such as those in cardiac arrest or with severe head injuries, provided that the community has been consulted in advance and other safeguards are met. The exception is an explicit acknowledgment that some valuable research cannot be done if individual consent is an absolute requirement, and that the law must then supply other protections. This division of labor, in which consent is paired with independent review, is the research system's central contribution to bioethics law. It recognizes that the individual subject is not always the best judge of what she is agreeing to, not because she is incompetent, but because the information she would need is complex, uncertain, and presented by people with interests of their own. The same insight will reappear in the design of aid-in-dying statutes and, most urgently, in the debate over whether anyone can consent to the editing of a future child's genome. Chapter 3: Hope Outside the Trial: Expanded Access and the Right to Try Clinical trials are designed to answer questions, not to serve every patient who might want the drug being tested. Trials have eligibility criteria, limited enrollment, fixed locations, and control groups who may receive a placebo or standard treatment. A patient with a terminal illness who has exhausted approved therapies may learn of an experimental drug that appears promising, only to find that she is too sick, too old, too far away, or otherwise ineligible for the trial. For such a patient, the question is not whether she has given informed consent to an experiment. It is whether she has a right to consent at all, and whether the government may stand between her and a drug she is willing to risk. American law has answered that question in three overlapping ways: a constitutional answer from the courts, a regulatory answer from the FDA, and a statutory answer from Congress and the states. The three do not fully agree, and the tension between them says a great deal about what consent can and cannot justify. The constitutional answer The Supreme Court addressed a version of the question in 1979 in United States v. Rutherford. Terminally ill cancer patients sought to use laetrile, an extract of apricot pits that had been promoted as a cancer treatment but had not been approved by the FDA. The lower courts had held that the requirement that drugs be shown safe and effective could have no meaning for patients who were going to die anyway. The Supreme Court unanimously disagreed as a matter of statutory interpretation. The Federal Food, Drug, and Cosmetic Act, the Court held, contains no implicit exception for the terminally ill. Such patients, the Court observed, are vulnerable to exactly the kind of fraudulent or useless remedies the Act was designed to screen out, and a drug that does not work is not safe for a patient who forgoes effective care to take it. Rutherford did not decide whether the Constitution requires such an exception. That question came to the courts in the early 2000s through the efforts of the Abigail Alliance for Better Access to Developmental Drugs. The organization was founded by the father of Abigail Burroughs, a young woman who died of head and neck cancer in 2001 after unsuccessfully seeking access to investigational drugs, including cetuximab, which was later approved for a related use. The Alliance argued that terminally ill, competent adults have a fundamental right under the Due Process Clause of the Fifth Amendment to access investigational drugs that have passed Phase 1 safety testing, when no approved alternatives remain. A divided panel of the United States Court of Appeals for the District of Columbia Circuit agreed in 2006, reasoning that the right to try to preserve one's life is closely related to rights of self-defense and bodily integrity that the Constitution protects. In 2007, the full court sitting en banc reversed by a vote of eight to two in Abigail Alliance v. von Eschenbach. Applying the test the Supreme Court had set out in Washington v. Glucksberg, discussed in Chapter 5, the majority asked whether the asserted right was deeply rooted in the nation's history and tradition. It concluded that it was not: the government has regulated drugs for safety since the early twentieth century and for efficacy since 1962, and there is no tradition of a right to use drugs the government has not found safe. The court applied rational basis review and upheld the FDA's authority. The Supreme Court declined to hear the case in 2008. The Abigail Alliance dissent argued that the majority had framed the right too narrowly, describing it as a right to experimental drugs rather than a right to attempt to save one's own life. The disagreement about the level of generality at which a right is described is the same disagreement that runs through the end-of-life cases, and it is not an accident. Both lines of cases ask whether individual autonomy over the body extends to choices the government has decided to regulate for the individual's own protection. In both, the courts' answer has been that it does not, as a constitutional matter, and that the question belongs to legislatures. The regulatory answer: expanded access The FDA's own answer to the problem long predates the litigation. Informal compassionate use of investigational drugs existed for decades, and the AIDS epidemic of the 1980s produced intense pressure for faster and wider access to experimental treatments. The agency formalized "treatment IND" procedures in 1987 and adopted comprehensive expanded access regulations in 2009. Those regulations recognize three categories: access for individual patients, including in emergencies; access for intermediate-sized groups; and widespread treatment use under a treatment protocol. Expanded access has several features that distinguish it from a clinical trial. Its primary purpose is treatment, not research. The patient must have a serious or immediately life-threatening condition with no comparable or satisfactory alternative therapy. The potential benefit must justify the potential risks, and providing the drug must not interfere with its development. Each use requires FDA authorization, which in practice the agency grants in the overwhelming majority of cases, often within days and, in emergencies, by telephone. Each use also requires IRB review, although the FDA has streamlined this for individual patients by allowing review by a single IRB member. And informed consent under the FDA's research consent regulations is required, with the consent explaining that the drug is investigational and that its risks and benefits are not established. The most important feature of expanded access is one that is often overlooked in public debate: the FDA cannot compel a manufacturer to provide its drug. A company may decline, for reasons that include limited supply, concern that adverse events in very sick patients will complicate the regulatory record, the cost of manufacturing and administering the drug, and the diversion of patients who might otherwise enroll in trials. In practice, the manufacturer's decision, not the FDA's, is usually the bottleneck. The 21st Century Cures Act of 2016 responded by requiring companies developing drugs for serious diseases to publish their policies on expanded access requests, but it did not require them to grant any. The statutory answer: Right to Try Frustration with that system produced a political movement. Beginning with Colorado in 2014, and promoted by the Goldwater Institute, a libertarian policy organization, states enacted "right to try" laws permitting manufacturers to provide, and eligible patients to receive, investigational drugs that had completed Phase 1 trials, without FDA authorization. Within a few years, some forty states had adopted versions of the law. Because drug regulation is primarily federal, the state laws had limited practical effect: a manufacturer that shipped an investigational drug for use outside an FDA-authorized pathway still risked violating federal law. The state laws did, however, create political momentum. In May 2018, Congress enacted the Trickett Wendler, Frank Mongiello, Jordan McLinn, and Matthew Bellina Right to Try Act, named for patients with terminal illnesses. The federal Act creates a pathway parallel to expanded access. An eligible patient is one who has been diagnosed with a life-threatening disease or condition, has exhausted approved treatment options and is unable to participate in a clinical trial involving the drug, as certified by a physician, and has given written informed consent. An eligible investigational drug is one that has completed a Phase 1 clinical trial, has not been approved, and is the subject of an active application or is under investigation in an ongoing trial intended to form the basis of an application, and whose active development has not been discontinued. The Act's significance lies in what it removes. A patient and physician using the Right to Try pathway need not obtain FDA authorization for the individual use, and the Act does not require IRB review. The manufacturer must report annually to the FDA on uses of its drug under the Act and on known serious adverse events. The Act also grants a liability shield: no manufacturer, sponsor, prescriber, or dispenser is liable for acts or omissions with respect to an eligible drug provided under the Act, unless the conduct amounts to reckless or willful misconduct, gross negligence, or an intentional tort under applicable state law. And it limits the FDA's use of clinical outcomes from Right to Try use in its review of the drug, unless the agency determines that doing so is critical to assessing safety. What the Act does not do is equally significant. Like the expanded access regulations, it does not require any manufacturer to provide a drug. It permits manufacturers to charge only the direct costs of providing the drug, which limits the incentive to participate. Reported use of the pathway has been modest, and the principal practical effect of the Act may have been to confirm, rather than change, the fact that manufacturers control access. The differences between the three routes to an investigational drug are summarized in Table 2. Table 2. Three routes to an investigational drug in the United States. Feature Clinical trial FDA expanded access Federal Right to Try Primary purpose Research Treatment Treatment FDA authorization for each use Protocol authorized under IND Yes No IRB review Yes Yes, streamlined for individuals Not required Patient eligibility Protocol criteria Serious condition, no satisfactory alternative Life-threatening condition, options exhausted, trial unavailable Drug eligibility Under investigation Under investigation or development Phase 1 completed and in active development Manufacturer obligated to provide No No No Some states have gone further than the federal model. In 2023, Montana enacted a law allowing licensed experimental treatment centers to offer drugs that have completed Phase 1 testing to patients who need not be terminally ill. The law's premise is that competent adults should be able to purchase access to investigational products on the same basis they purchase other medical services. Whether such state laws can operate in the face of the federal prohibition on introducing unapproved drugs into interstate commerce, and whether the FDA will seek to enforce federal law against them, remains uncertain. The question tests the outer boundary of the idea, embraced in varying degrees by these statutes, that informed consent by an adult can substitute for regulatory screening. Consent without a referee The Right to Try debate isolates a question that the rest of this book returns to repeatedly: can consent alone justify exposing a person to serious and uncertain risk, or must consent be paired with an independent judgment that the risk is reasonable? The research regulations answer that consent is necessary but not sufficient. An IRB must independently find that risks are reasonable, and the FDA must be satisfied that a study is safe to proceed. Expanded access retains both forms of review, adapted to individual treatment. The Right to Try Act removes both for individual uses and relies on the patient's consent and the physician's certification. Its supporters argue, with some force, that for a dying patient who has exhausted every alternative, the reasonableness of taking a risk is a question only the patient can answer, and that the paternalism of regulators has cost lives. Its critics respond that the premise of consent, a patient who understands the risks, is weakest precisely in these circumstances. An investigational drug that has completed only Phase 1 has been tested for basic safety in a small number of people; its efficacy is unknown, and its risks in very sick patients are poorly understood. The treating physician may know little more about the drug than what the manufacturer has published. And the patient's desperation, which is the moral heart of the claim, is also the condition most likely to distort judgment. The same tension is visible in litigation over unapproved stem cell clinics, which market treatments derived from patients' own fat or bone marrow directly to consumers who pay out of pocket. The clinics have argued that procedures using a patient's own cells are the practice of medicine, not the manufacture of drugs, and that their patients consent to the risks. The FDA has taken the position that many such products are drugs requiring approval. In 2021, the United States Court of Appeals for the Eleventh Circuit agreed with the agency in United States v. US Stem Cell Clinic, and in 2024 the Ninth Circuit, reversing a district court, likewise sided with the FDA in its case against a California clinic. Patients who had been blinded by injections of stem cell products into their eyes at one such clinic, as reported in the medical literature in 2017, had signed consent forms. The consent did not make the product safe. None of this resolves the moral question. A legal system that respects autonomy should be troubled by rules that prevent competent adults from making informed choices about their own survival. But the law's reluctance to treat consent as self-justifying is not simply paternalism. It reflects accumulated experience that consent is a fragile instrument, easily distorted by hope, fear, trust, and incomplete information, and that the conditions under which people most want to exercise it are often the conditions under which it is least reliable. That same experience shapes the law of the end of life, where the stakes of a mistaken choice are, if anything, higher. Chapter 4: The Right to Refuse: From Quinlan to Cruzan and Beyond The modern law of dying did not begin with a debate about hastening death. It began with a debate about machines. In the 1960s and 1970s, mechanical ventilation, dialysis, cardiopulmonary resuscitation, and artificial nutrition made it possible to keep alive patients who would previously have died quickly. The question that followed was whether a patient, or someone speaking for a patient, could refuse such treatment, and whether a physician who withdrew it at the patient's request was killing the patient or merely allowing a disease to take its course. American law answered, over the span of about fifteen years, that the right to refuse treatment was a direct extension of the right Cardozo had described in 1914. The harder question, which has never been fully answered, is how that right is to be exercised by patients who can no longer speak. Quinlan and the surrogate decision In April 1975, Karen Ann Quinlan, then twenty-one, stopped breathing after consuming alcohol and sedatives and suffered severe brain damage. She entered what physicians described as a persistent vegetative state, a condition in which a person has cycles of sleep and wakefulness but no apparent awareness. She was maintained on a ventilator. After several months, her parents, devout Catholics who had consulted their parish priest, asked that the ventilator be removed. Her physicians refused, and her father went to court to be appointed her guardian with authority to authorize the withdrawal. In 1976, in In re Quinlan, the New Jersey Supreme Court granted the request. The court held that the constitutional right of privacy, which the United States Supreme Court had recently recognized in cases involving contraception and abortion, was broad enough to encompass a patient's decision to decline medical treatment under certain circumstances. Because Karen could not exercise the right herself, the court allowed her guardian and family to exercise it on her behalf by rendering their best judgment as to whether she would have chosen to discontinue treatment. The court also suggested that such decisions be reviewed by a hospital ethics committee rather than routinely brought to court, a recommendation that helped spur the development of institutional ethics committees across the country. The ventilator was removed. Karen Quinlan continued breathing on her own and lived for nearly ten more years, sustained by artificial nutrition, which her parents did not ask to have withdrawn. Quinlan introduced what became known as the "substituted judgment" standard: the surrogate tries to make the decision the patient would have made if competent. The Massachusetts Supreme Judicial Court applied that standard the following year in Superintendent of Belchertown State School v. Saikewicz, a case involving a sixty-seven-year-old man with profound intellectual disabilities who had developed leukemia. The court concluded that chemotherapy could be withheld, reasoning that Saikewicz, who could not understand why he was being subjected to painful treatment, would have declined it. The decision was criticized because Saikewicz had never been competent and so had never expressed any preference; the "substituted judgment" was in substance a judgment about his best interests. The court also insisted that such decisions ultimately be made by judges, not families and physicians, a position that sat uneasily with Quinlan's preference for keeping them out of court. New York took a stricter line. In In re Storar, decided with a companion case in 1981, the New York Court of Appeals held that life-sustaining treatment could be withdrawn from an incompetent patient only on clear and convincing evidence that the patient, while competent, had expressed a wish to refuse it. In the companion case, an elderly member of a religious order had discussed his views about extraordinary treatment with fellow members in the context of the Quinlan case, and the court found his wishes sufficiently proved. In Storar itself, involving a man with profound intellectual disabilities who had never been competent, no such evidence was possible, and the court refused to permit the withholding of blood transfusions. The New Jersey Supreme Court returned to the problem in In re Conroy in 1985, involving an elderly nursing home resident with severe dementia who was being fed through a nasogastric tube. The court held that artificial nutrition and hydration are medical treatments that can be refused like any other, rejecting the argument that food and water are basic care that can never be withdrawn. It also set out a framework of three tests: a subjective test, where the patient's own wishes are clearly known; a "limited-objective" test, where there is some trustworthy evidence of the patient's wishes and the burdens of treatment clearly outweigh the benefits; and a "pure-objective" test, where there is no evidence of wishes but the burdens of continued life with treatment are so clearly excessive that treatment would be inhumane. Conroy thus acknowledged that when a patient's own voice cannot be recovered, the law must fall back on a judgment about best interests. Competent patients' right to refuse treatment was never seriously in doubt during this period, though its limits were tested. In Bouvia v. Superior Court, a California appellate court in 1986 upheld the right of Elizabeth Bouvia, a young woman with severe cerebral palsy who was competent and not terminally ill, to have a feeding tube removed, even though the hospital suspected her motive was to die. The court treated the right to refuse as not depending on the patient's motives or prognosis. Cruzan and the constitutional floor The Supreme Court addressed the question for the first time in Cruzan v. Director, Missouri Department of Health in 1990. Nancy Cruzan was injured in a car accident in 1983, at the age of twenty-five, and entered a persistent vegetative state. She was sustained by a surgically implanted feeding tube. Her parents asked that it be removed. The trial court authorized removal, relying on testimony that Nancy had told a housemate she would not want to live as a "vegetable." The Missouri Supreme Court reversed, holding that the state could require clear and convincing evidence of the patient's own wishes before permitting withdrawal, and that the evidence presented did not meet that standard. The United States Supreme Court affirmed by a vote of five to four. Chief Justice Rehnquist's opinion for the Court assumed, for purposes of the case, that the Due Process Clause of the Fourteenth Amendment protects a competent person's liberty interest in refusing unwanted medical treatment, including artificial nutrition and hydration. But the Court held that a state could constitutionally require clear and convincing evidence of an incompetent patient's wishes before a surrogate could exercise that right on her behalf. The state's interest in protecting and preserving human life, the Court reasoned, justified a heightened evidentiary standard, because an erroneous decision to withdraw treatment is irreversible while an erroneous decision to continue it can be corrected. Justice O'Connor's concurrence emphasized that the Court had not decided whether a state must give effect to the decisions of a surrogate the patient herself had appointed, and suggested that it might. Justice Brennan's dissent argued that Missouri had improperly weighted the scale toward continued treatment, contrary to what most people would want. Cruzan is often described as recognizing a constitutional "right to die." It did not quite do that. It assumed a right to refuse treatment for competent persons, and it held that states may impose demanding procedural requirements on the exercise of that right by others. After the decision, several of Nancy Cruzan's former co-workers came forward with additional testimony about her statements. A Missouri trial court found the new evidence clear and convincing, the feeding tube was removed, and she died in December 1990. The decision's most lasting practical effect was legislative. Within months, Congress enacted the Patient Self-Determination Act of 1990, which requires hospitals, nursing homes, and other providers participating in Medicare and Medicaid to inform adult patients at admission of their rights under state law to make decisions about their care, including the right to refuse treatment and to execute advance directives. States, for their part, expanded their advance directive statutes. California's Natural Death Act of 1976 had been the first living will statute; by the early 1990s, every state recognized some form of written advance directive, and most recognized the durable power of attorney for health care, which allows a person to appoint a proxy decision-maker. Most states also enacted default surrogate statutes, which specify a hierarchy of family members, typically beginning with a spouse, then adult children, then parents, who may make decisions for an incapacitated patient who has not appointed a proxy. The Uniform Law Commission promulgated a Uniform Health-Care Decisions Act in 1993 and approved a substantially revised version in 2023, reflecting three decades of experience with how such documents actually function. Schiavo and the limits of procedure If Cruzan seemed to settle the legal framework, the case of Terri Schiavo demonstrated how bitterly it could still be contested in practice. Schiavo suffered a cardiac arrest in 1990 and sustained severe brain damage. Her husband, Michael Schiavo, was appointed her guardian. In 1998 he petitioned to have her feeding tube removed, saying that she would not have wanted to be kept alive in that condition. Her parents, Robert and Mary Schindler, disputed both her diagnosis and her wishes. Florida courts, after hearing evidence, found clear and convincing evidence that Terri would have chosen to discontinue artificial nutrition, and that she was in a persistent vegetative state. What followed was more than seven years of litigation and political intervention. The feeding tube was removed and reinserted more than once. In 2003, the Florida Legislature passed a statute, known as "Terri's Law," authorizing the governor to order the tube reinserted; the Florida Supreme Court struck it down in 2004 in Bush v. Schiavo as a violation of the separation of powers. In March 2005, Congress passed, and President George W. Bush signed, a private bill giving federal courts jurisdiction to hear the parents' claims. The federal district court and the United States Court of Appeals for the Eleventh Circuit declined to order the tube reinserted, and the Supreme Court declined to intervene. Terri Schiavo died on March 31, 2005. An autopsy found severe and irreversible brain damage. The Schiavo case is usually remembered for its politics, but its legal lessons are more specific. The Florida courts applied exactly the kind of clear-and-convincing-evidence standard that Cruzan had approved, and they applied it through a full adversarial process. The legal framework did not fail; it was simply overwhelmed by a family dispute that no procedure could resolve to both sides' satisfaction. The case also exposed the limits of written advance directives: Schiavo, like most young adults, had none, and her wishes had to be reconstructed from conversations. Advance directives remain far less common than their advocates hoped, and studies have found that even when they exist, they are often unavailable when needed or too general to guide specific decisions. Refusal, futility, and the definition of death The right to refuse treatment has a counterpart that the law has handled much less clearly: the claim by patients or families that treatment must be continued over physicians' objections. Physicians sometimes conclude that further interventions for a dying patient are "futile," meaning they cannot achieve any goal the patient could value, and that continuing them imposes suffering without benefit. Families sometimes disagree, for reasons that include religious conviction, distrust of the medical system, and hope for recovery. Courts have generally been reluctant to authorize physicians to override such demands. In In re Wanglie, a Minnesota court in 1991 declined a hospital's request to appoint an independent conservator for an elderly woman in a persistent vegetative state whose husband insisted on continued ventilation, and instead confirmed the husband as her decision-maker. In In re Baby K, the United States Court of Appeals for the Fourth Circuit in 1994 held that the federal Emergency Medical Treatment and Labor Act required a hospital to provide ventilator support to an infant born with anencephaly whenever she arrived in respiratory distress, over the physicians' view that such treatment was medically inappropriate. Texas took a different approach. Its Advance Directives Act of 1999 created a statutory process under which, if an attending physician's refusal to honor a request for life-sustaining treatment is reviewed and upheld by a hospital ethics committee, the hospital must make reasonable efforts to transfer the patient and may stop treatment if no transfer is found within a specified period. The process has been sharply criticized by disability rights groups and others as allowing hospitals to make life-and-death decisions without meaningful judicial review, and the Texas Legislature amended it in 2023 to lengthen the waiting period and to bar decisions based on a patient's disability. The comparison with England, where disputes such as those involving the infants Charlie Gard in 2017 and Alfie Evans in 2018 were resolved by the courts under a best-interests standard that allowed treatment to be withdrawn over parental objection, highlights how much American law defers to the family's voice in cases of disagreement. At the far end of this spectrum is the question of when death itself occurs. The Harvard Medical School committee that proposed criteria for "irreversible coma" in 1968 laid the groundwork for the legal recognition of death by neurological criteria, and the Uniform Determination of Death Act of 1981, adopted in some form in nearly every state, provides that an individual who has sustained either irreversible cessation of circulatory and respiratory functions, or irreversible cessation of all functions of the entire brain, including the brain stem, is dead. The standard has come under pressure from cases such as that of Jahi McMath, a California teenager declared brain dead in 2013 whose family moved her to New Jersey, which allows families to object to a declaration of death by neurological criteria on religious grounds. A Uniform Law Commission effort to revise the Act to address inconsistencies between the statutory language and actual clinical testing was suspended in 2023 without agreement. The interaction of these rules with other areas of law can produce results that surprise people who assume their advance directives settle everything. Many state advance directive statutes contain pregnancy exclusions, which suspend or limit the effect of a directive to withdraw life-sustaining treatment while the patient is pregnant. The issue became acutely visible in 2025 when a pregnant woman in Georgia who had been declared brain dead was maintained on mechanical support for months, with the hospital pointing to the state's restrictive abortion statute as the reason. The case illustrated that the right to refuse treatment, however firmly established in principle, operates within a web of other legal commitments that can override it. Refusal as foundation By the end of the 1990s, the law had settled several propositions with remarkable consistency across jurisdictions. A competent adult may refuse any medical treatment, including treatment necessary to sustain life. Artificial nutrition and hydration are medical treatments for this purpose. The right survives incompetence and may be exercised through advance directives, appointed proxies, or statutory surrogates, subject to state rules about the evidence required. Physicians who withdraw treatment at the request of a patient or authorized surrogate are not liable for homicide or assisted suicide. And the administration of medication to relieve pain, even in doses that may hasten death, is lawful when the intent is to relieve suffering, a principle often associated with the doctrine of "double effect." These propositions rest on a distinction that is legally clear but philosophically contested: the distinction between allowing a patient to die by withdrawing treatment and causing the patient's death by providing the means. The law treats withdrawal of a ventilator as letting a disease take its natural course, even though the physician's act is the immediate occasion of death, and treats the prescription of a lethal medication as participating in the patient's decision to end life. Whether that distinction can bear the weight placed on it was the question the Supreme Court confronted in 1997. Chapter 5: The Constitution Declines: Glucksberg, Vacco, and the Return to the States By the early 1990s, the right to refuse life-sustaining treatment was firmly established, and advocates for terminally ill patients began to ask why the law should stop there. A patient on a ventilator could have it removed and die within hours. A patient with advanced cancer who was not dependent on any machine had no comparable option: no treatment to refuse whose withdrawal would bring death, only months of decline. If the right to refuse treatment rested on the patient's interest in controlling the timing and manner of her death, the argument ran, it should also protect a request for medication to bring death about. And if the law already permitted physicians to withdraw treatment knowing that the patient would die, it was difficult to see why prescribing medication that the patient would take herself was categorically different. The argument was pressed in the courts in the same years that Jack Kevorkian, a retired Michigan pathologist, was publicly assisting the deaths of dozens of people and repeatedly being acquitted by juries. Kevorkian's practices bore little resemblance to the careful protocols advocates proposed; he often met his patients only briefly and sometimes assisted people who were not terminally ill. His conviction for second-degree murder in 1999, after he directly administered a lethal injection to a man with amyotrophic lateral sclerosis and allowed a recording to be broadcast on national television, marked the end of his campaign. But the constitutional litigation that ran alongside it reached the Supreme Court first. Two cases, one day In 1996, two federal courts of appeals struck down state laws prohibiting assisted suicide as applied to physicians helping competent, terminally ill patients. In Compassion in Dying v. Washington, the United States Court of Appeals for the Ninth Circuit, sitting en banc, held that Washington's ban violated a liberty interest protected by the Due Process Clause of the Fourteenth Amendment. The court drew heavily on Cruzan and on the Supreme Court's abortion decision in Planned Parenthood v. Casey, which had described the Constitution as protecting the most intimate and personal choices a person may make in a lifetime. In Quill v. Vacco, the United States Court of Appeals for the Second Circuit reached the same result by a different route. It held that New York's law violated the Equal Protection Clause, because New York permitted patients on life support to hasten death by refusing treatment while denying the equivalent option to patients who were not on life support. The Supreme Court reversed both decisions on June 26, 1997, and no justice dissented from the judgments. In Washington v. Glucksberg, Chief Justice Rehnquist's opinion for the Court set out a method for identifying fundamental rights that has shaped constitutional law ever since. The Due Process Clause, the Court said, specially protects those fundamental rights and liberties that are objectively "deeply rooted in this Nation's history and tradition," and the analysis requires a "careful description" of the asserted right. The Court rejected the Ninth Circuit's description of the right as a liberty to choose how to die, or a right to control one's final days, and described it instead as a right to commit suicide, which itself includes a right to assistance in doing so. So described, the right had no historical pedigree. The Court surveyed seven hundred years of Anglo-American law, from the medieval common law treatment of suicide as a crime through the adoption of assisted suicide statutes in the nineteenth century and their recent reaffirmation by many states, and concluded that the prohibition of assisting suicide was a longstanding and consistent feature of American law. Having found no fundamental right, the Court upheld Washington's ban under rational basis review. It identified several legitimate state interests the ban served: preserving human life; preventing suicide and treating its causes, including depression; protecting the integrity and ethics of the medical profession; protecting vulnerable groups, including the poor, the elderly, and people with disabilities, from abuse, neglect, and mistakes, as well as from subtle pressure to end their lives; and avoiding a path that might lead to voluntary and even involuntary euthanasia. On the last point, the Court cited reports on the practice in the Netherlands as evidence that regulation might prove difficult to confine. The opinion closed with a sentence that became the practical meaning of the decision: "Throughout the Nation, Americans are engaged in an earnest and profound debate about the morality, legality, and practicality of physician-assisted suicide. Our holding permits this debate to continue, as it should in a democratic society." In Vacco v. Quill, decided the same day, the Court rejected the equal protection argument. The distinction between letting a patient die by refusing treatment and making a patient die by providing lethal medication, the Court held, is widely recognized in medical ethics and in the law, and is rational. It rests on familiar legal principles of causation and intent. A patient who refuses life-sustaining treatment dies from an underlying disease; a patient who ingests lethal medication dies from the medication. A physician who withdraws treatment at a patient's request intends to respect the patient's wishes and to cease doing useless and futile or degrading things; a physician who assists a suicide must necessarily intend primarily that the patient be made dead. The Court noted that the law has long used intent to distinguish between two acts that may have the same result, and it observed that a physician who administers pain medication that hastens death may intend only to relieve pain. What the concurrences left open The unanimity of the judgments concealed real division in the reasoning. Five justices wrote or joined concurring opinions, and several of them suggested that the question was not closed. Justice O'Connor, whose vote was necessary to the majority opinion, wrote that there was no need to address whether a mentally competent person experiencing great suffering has a constitutionally cognizable interest in controlling the circumstances of his or her imminent death, because the laws at issue did not prevent patients from obtaining palliative care, including medication to alleviate pain even to the point of hastening death. Justice Breyer, joining her, suggested that a right to die with dignity might have a stronger claim than the right to commit suicide as the majority described it, but agreed that the laws did not substantially burden such a right so long as palliative care remained available. Justice Stevens emphasized that the decision did not foreclose the possibility that an individual plaintiff might prevail in a more particularized challenge. And Justice Souter, rejecting the majority's history-focused method in favor of a more open "reasoned judgment" approach, concluded that the state's interest in protecting patients from the risks of a legalized practice was sufficient for the time being, given that the evidence about how such a practice would operate was still emerging. The combined effect of these concurrences was to suggest that access to aggressive palliative care, including what is now called palliative sedation, sedation to unconsciousness for refractory suffering at the end of life, occupies constitutionally protected ground, or at least that the state's authority to forbid assisted suicide depends in part on its not forbidding adequate pain relief. That understanding has shaped subsequent practice. American law broadly accepts palliative sedation and aggressive pain management for dying patients, and many clinicians and courts treat voluntary stopping of eating and drinking by a competent patient as an exercise of the right to refuse, rather than as suicide. The majority's method has had a longer reach than its holding. The Glucksberg test for identifying unenumerated rights, with its demand for careful description and deep historical roots, was the central analytical tool of the Supreme Court's 2022 decision in Dobbs v. Jackson Women's Health Organization, which overruled Roe v. Wade. Whatever doubt some of the 1997 concurrences may have created about the future of a federal constitutional claim to aid in dying has been substantially reduced. As of 2026, there is no realistic prospect that the federal courts will recognize such a right. The federal government and Oregon Glucksberg left states free to prohibit assisted suicide, and it equally left them free to permit it. Oregon had already done so. Its Death with Dignity Act was approved by voters in 1994 and, after litigation and a failed repeal measure in 1997, took effect in late 1997. The federal government's response illustrates how the question has been fought on federal terrain even after the Supreme Court declined to constitutionalize it. Litigation in federal court against the Act, including an equal protection challenge brought on behalf of terminally ill patients who argued that the Act denied them the protection of Oregon's laws against suicide, initially succeeded in a federal district court in Lee v. Oregon but was dismissed on appeal in 1997 by the Ninth Circuit on the ground that the plaintiffs lacked standing. Congress enacted the Assisted Suicide Funding Restriction Act of 1997, which prohibits the use of federal funds, including Medicare and Medicaid, to pay for items and services provided for the purpose of causing or assisting in the death of an individual. That statute remains in force; aid-in-dying medications are paid for privately or through state programs. The more serious federal threat came from the Controlled Substances Act. The medications prescribed under the Oregon Act, originally barbiturates, are controlled substances, and physicians prescribe them under registrations issued by the Drug Enforcement Administration. In November 2001, Attorney General John Ashcroft issued an interpretive rule declaring that prescribing controlled substances to assist suicide was not a "legitimate medical purpose" under the federal regulations and would render a physician's registration subject to revocation. Oregon sued, and the case reached the Supreme Court as Gonzales v. Oregon. In 2006, the Court ruled against the Attorney General by a vote of six to three. Justice Kennedy's opinion for the Court held that the Controlled Substances Act did not give the Attorney General authority to declare a medical practice authorized under state law to be illegitimate. The Act, the Court reasoned, was designed to combat drug abuse and trafficking, not to allow the Attorney General to define general standards of medical practice, which the structure of the Act and the tradition of state regulation of medicine left to the states. Justice Scalia, in dissent, argued that the ordinary meaning of "legitimate medical purpose" plainly excluded assisting suicide. The decision is formally one of statutory interpretation, and Congress could change the result by amending the Act. Bills to do so, such as the proposed Pain Relief Promotion Act around the turn of the century, have not passed. State constitutions and the Montana exception With the federal Constitution unavailable, advocates turned to state constitutions, many of which contain explicit privacy guarantees or have been interpreted more expansively than their federal counterpart. The results have been almost uniformly unsuccessful. The Florida Supreme Court rejected a claim under that state's explicit privacy clause in Krischer v. McIver in 1997. The Alaska Supreme Court rejected a claim in Sampson v. State in 2001. In Morris v. Brandenburg, decided in 2016, the New Mexico Supreme Court reversed a trial court ruling that had recognized a state constitutional right to aid in dying, holding that the state's statute prohibiting assisted suicide was constitutional. In Myers v. Schneiderman, decided in 2017, the New York Court of Appeals held that neither the state constitution's due process nor equal protection guarantee required the state to permit aid in dying, while noting that the legislature was free to authorize it. And in Kligler v. Attorney General, decided in 2022, the Massachusetts Supreme Judicial Court held that the state constitution did not protect a right to physician-assisted death, while emphasizing that its ruling did not prevent the legislature from acting. The common thread in these decisions is institutional. The courts did not generally hold that aid in dying is wrong. They held that the design of safeguards, the balancing of patient autonomy against the protection of vulnerable people, and the judgment about whether the risks can be managed are questions better suited to legislatures, which can hold hearings, collect evidence, draft detailed procedures, and revise them over time. In two of those states, New Mexico and New York, the legislatures subsequently did exactly that. The one exception is Montana. In Baxter v. State, decided in 2009, the Montana Supreme Court declined to decide whether the state constitution protected a right to aid in dying. Instead, it held that the state's homicide statutes, which recognize the consent of the victim as a defense in some circumstances, did not make it a crime for a physician to provide a lethal prescription to a competent, terminally ill patient who requested it, because such conduct was not against public policy. The court pointed to the state's Rights of the Terminally Ill Act, which allows patients to refuse life-sustaining treatment, as evidence that Montana policy respected end-of-life autonomy. The result is that aid in dying is legally available in Montana in the sense that physicians who provide it are shielded from criminal prosecution, but there is no statute establishing eligibility requirements, procedures, reporting, or safeguards. Bills to overturn Baxter by statute and bills to codify it have both been introduced in the Montana legislature, without either becoming law. Montana is instructive precisely because it is anomalous. It shows what a legal regime built only on consent looks like: a competent patient may request and a willing physician may provide, with no statutory structure around the transaction. Most observers, including many supporters of aid in dying, regard that as a less protective arrangement than the statutory model the other jurisdictions have adopted. The statutory model, and the choices embedded in it, is the subject of the next chapter. The legacy of 1997 It is worth pausing on what the Supreme Court's refusal to act in 1997 accomplished. In the field of abortion, the Court's decision in Roe v. Wade in 1973 established a national rule, and the next half-century of American politics was shaped by the effort to overturn it. In the field of aid in dying, the Court declined to establish a national rule, and the result has been a gradual, state-by-state process of legislation, referendum, and revision. Oregon's statute has been in operation for nearly three decades. Other states have adopted it, amended it, and learned from it. Opponents have had the opportunity to press their concerns in legislative hearings, and some of those concerns have been written into law in the form of safeguards. That is exactly what the Glucksberg Court said it intended: a democratic debate that could continue. Whether one regards the outcome as a model of federalism or a patchwork that leaves a person's end-of-life options dependent on her address, it has produced a body of experience, data, and legislative design that no court could have created. It has also produced a set of hard questions about residency, eligibility, and the relationship between federal and state authority, which the following chapters take up. Chapter 6: Medical Aid in Dying by Statute: The Oregon Model and Its Variations Every American jurisdiction that has authorized medical aid in dying by statute has used a single template. The template was drafted in Oregon in the early 1990s, approved by the state's voters in 1994, and has been copied, amended, and refined by legislatures and voters from Washington State to New Jersey. As of late 2026, thirteen jurisdictions have statutes built on it: Oregon, Washington, Vermont, California, Colorado, the District of Columbia, Hawaii, New Jersey, Maine, New Mexico, Delaware, New York, and Illinois, the last three of which acted in 2025 and early 2026. Montana, as described in the previous chapter, permits the practice by virtue of a court decision rather than a statute. Understanding the template, and the ways it has been altered, is the key to understanding what American law actually permits and what it is trying to prevent. The architecture of the Oregon Act The Oregon Death with Dignity Act is short, and its structure is best understood as a series of gates, each designed to address a specific concern that opponents raised about legalization. The first gate is eligibility. The patient must be an adult, must have been determined by an attending physician and a consulting physician to be suffering from a terminal disease, defined as an incurable and irreversible disease that will, within reasonable medical judgment, produce death within six months, and must be "capable," meaning able to make and communicate health care decisions. The six-month prognosis, borrowed from the Medicare hospice benefit, confines the practice to patients who are already dying. Age, disability, and chronic illness alone do not qualify. The second gate is the request. The patient must make two oral requests separated by at least fifteen days, and a written request on a prescribed form, signed in the presence of two witnesses who attest that the patient is capable, acting voluntarily, and not being coerced. At least one witness must not be a relative, a person entitled to part of the patient's estate, or an owner or employee of the health care facility where the patient is being treated. The requests must come from the patient; no one else, not a proxy, not a guardian, not an advance directive, can make them. This is the statute's most important structural choice. By requiring a contemporaneous request from a capable patient, it excludes every patient who has lost capacity, however clearly she may have expressed her wishes in advance. The third gate is evaluation. The attending physician must confirm the diagnosis and prognosis, determine capacity and voluntariness, and inform the patient of the diagnosis, prognosis, the potential risks and probable result of taking the medication, and the feasible alternatives, including comfort care, hospice care, and pain control. The consulting physician must independently confirm the diagnosis and the patient's capacity. If either physician believes the patient may be suffering from a psychiatric or psychological disorder or depression causing impaired judgment, the patient must be referred for counseling, and no prescription may be written until the counselor determines that the patient's judgment is not impaired. The attending physician must also recommend that the patient notify next of kin, though the patient may decline to do so. The fourth gate is administration. The patient must take the medication herself. The Act does not authorize any person to administer it by injection or otherwise, and it expressly provides that nothing in it authorizes lethal injection, mercy killing, or active euthanasia. This requirement is what keeps the Oregon model on the "assisted" side of the line between assisted death and euthanasia, and it is the reason the statutes use the vocabulary of prescribing rather than performing. The fifth gate is documentation. The attending physician must document each step in the medical record and report to the state health authority, which publishes an annual report summarizing the characteristics of patients who received prescriptions and those who died after ingesting the medication. Around these gates the Act places protections. Physicians, pharmacists, and health care facilities may decline to participate. Actions taken in accordance with the Act do not constitute suicide, assisted suicide, mercy killing, or homicide under the law. Insurance policies and annuities may not be conditioned on or affected by a patient's request, and wills and contracts may not be conditioned on it. And the Act creates criminal penalties for anyone who forges a request or coerces a patient into making one. Nearly three decades of data The annual reports published under the Oregon Act, and similar reports in other states, have become the principal evidence in the debate about whether the statutory model works as intended. Several patterns have been stable across decades and jurisdictions. The number of patients who use the law is small relative to all deaths in the state, though it has grown over time. A substantial fraction of patients who receive prescriptions never take the medication; for many, having it available appears to provide reassurance. Most patients who die under the Act have cancer, with neurological diseases such as amyotrophic lateral sclerosis the next most common category. Most are older adults, most are enrolled in hospice at the time of death, and the great majority have health insurance. The end-of-life concerns most frequently reported by physicians for their patients are loss of autonomy, decreasing ability to participate in activities that make life enjoyable, and loss of dignity. Inadequate pain control or concern about it is reported less often than these. Concern about being a burden on family, friends, or caregivers has been reported for a significant minority of patients and has been cited by critics as evidence of social pressure. Both sides read these data to support their positions. Supporters point out that the patients using the law are overwhelmingly not the poor, uninsured, or socially isolated people whose vulnerability opponents emphasized, and that the reported motivations center on control rather than untreated suffering or financial desperation. Critics respond that the data are self-reported by participating physicians, that the state does not investigate the adequacy of capacity determinations or the reasons for requests, that referrals for psychiatric evaluation have been very rare in some years, and that the burden-on-others concern reflects exactly the kind of pressure the safeguards were supposed to catch. Both positions have a basis in the numbers. The reports are designed for surveillance, not for evaluating whether each individual decision was sound, and they cannot answer the question critics most want answered: whether any patient died under the Act who would have chosen differently with better care, support, or evaluation. The practical mechanics have also changed. The barbiturates originally used became expensive and harder to obtain, and physicians have moved to compounded combinations of other drugs. Time from ingestion to death is usually short, but reports have documented a minority of cases in which it was prolonged, and a small number of cases in which patients regained consciousness. How the template has changed Later statutes have kept the architecture of the Oregon Act while adjusting its components, often in response to the experience of earlier states. Some of the most significant variations, and the arguments behind them, are set out in Table 3. Table 3. Key design choices in American aid-in-dying statutes. Element Original Oregon design Common later variations Waiting period Fifteen days between oral requests Shortened in several states; waivable when death is imminent Who may prescribe Physicians only Some states allow advanced practice nurses or physician assistants Residency State residents only Dropped in Oregon and Vermont after litigation; retained elsewhere Mental health evaluation Only if impairment suspected Hawaii requires counseling evaluation for every patient Administration Self-administration only Unchanged in every statute Advance requests Not permitted Unchanged in every statute The trend on waiting periods has been toward shortening them. Experience showed that a meaningful number of patients who began the process died before the fifteen-day period expired, which proponents argued made the law unavailable to the very patients it was meant to serve. Oregon itself amended its Act in 2019 to allow the waiting period to be waived when the patient is expected to die before it would end. California, whose End of Life Option Act took effect in 2016, amended it in 2021 to reduce the waiting period between oral requests to forty-eight hours and to extend the Act's sunset date. Washington, Hawaii, and other states have made comparable reductions. Opponents regard these changes as evidence that safeguards presented as essential during enactment are treated as obstacles once the law is in place, a version of the argument that assisted dying regimes expand over time. The trend on who may prescribe has been toward broadening. New Mexico's statute, enacted in 2021, allowed advanced practice registered nurses and physician assistants to serve as prescribing clinicians, in part because of the shortage of physicians in rural areas and the reluctance of many physicians to participate. Several other states have since followed. The treatment of mental health evaluation has varied. Most statutes follow Oregon in requiring referral only when a clinician suspects impaired judgment. Hawaii's Our Care, Our Choice Act, which took effect in 2019, requires every patient to be evaluated by a counselor, such as a psychiatrist, psychologist, or clinical social worker, to confirm that the patient does not have conditions, including inadequately treated depression, that impair decision-making. The two features that have not changed are the most important. No American statute permits a clinician to administer the medication, and no American statute permits a request to be made through an advance directive or by a surrogate. Those two features, together with the six-month prognosis requirement, define the boundary between the American model and the broader regimes discussed in the next chapter. Proposals to relax them, for instance to permit patients with dementia to make advance requests, have been discussed but not enacted in any American jurisdiction. Litigation over the edges Because the statutes are carefully drafted, most litigation has concerned their edges rather than their core. The most active area has been residency. Every statute originally limited eligibility to state residents, largely to avoid the perception that a state was inviting people to travel there to die. In 2021, an Oregon physician and a patient challenged Oregon's residency requirement in federal court, arguing that it violated the Privileges and Immunities Clause of Article IV, which protects the right of citizens of one state to obtain services, including medical services, in another on equal terms with residents, and the dormant Commerce Clause. In 2022, Oregon settled the case, Gideonse v. Brown, by agreeing not to enforce the requirement, and the legislature repealed it in 2023. Vermont settled a similar challenge brought by a Connecticut resident in 2023 and amended its law. Courts have not uniformly accepted the argument, however. In late 2025, the United States Court of Appeals for the Third Circuit rejected a challenge by out-of-state patients to New Jersey's residency requirement. The question of whether states may confine aid in dying to their residents thus remains unsettled, and its resolution will determine whether the practice is effectively available only in the states that authorize it or, for those able to travel, more broadly. A second line of litigation has come from opponents. In 2018, a California trial court declared the End of Life Option Act invalid on the ground that it had been enacted in a special legislative session convened for other purposes. A state appellate court reversed on procedural grounds later that year, and the Act has remained in force. Disability rights organizations have argued in several fora that the statutes discriminate against people with disabilities by offering them assistance in dying rather than suicide prevention, and that the six-month prognosis criterion can capture people whose conditions are terminal only because they are not receiving available treatment. The latter concern has been sharpened by published reports of patients with severe anorexia nervosa who were found eligible on the basis of the terminal medical complications of their disorder, which critics view as the use of a physical diagnosis to authorize death for what is at root a psychiatric illness. A third line has come from supporters challenging the self-administration requirement. Patients with advanced neurological diseases may lose the ability to swallow or move, which can make them ineligible at the point when they most want the option. A federal suit in California argued that the requirement discriminates against such patients under the Americans with Disabilities Act; the challenge has so far been rejected, on the reasoning that removing the requirement would fundamentally alter the program by converting it from assisted death to euthanasia. Finally, there is the question of institutional participation. The statutes allow health care facilities to prohibit their employees and contractors from participating on their premises, and many religiously affiliated hospitals and hospice organizations have done so. In areas where such institutions dominate the health care market, the practical availability of aid in dying may be quite limited even though it is legal. Some states have required objecting providers at least to inform patients of their policies and to transfer records on request, a compromise between conscience protection and patient access that remains contested on both sides. The newest statutes The most recent enactments illustrate both the durability of the template and the pressures on it. Delaware's governor signed its statute in May 2025, after the legislature had passed the bill in earlier sessions only to see it vetoed. Illinois enacted its End-of-Life Options Act when the governor signed it in December 2025, with implementation scheduled for 2026. In New York, where the Court of Appeals in Myers had left the question to the legislature, a bill that had been introduced repeatedly for a decade passed both houses in 2025, and the governor approved it after negotiating amendments that added safeguards to the enacted text; the law took effect in 2026. These are two of the most populous states in the country, and together they add more than thirty million people to the population living in jurisdictions where medical aid in dying is legal, which now approaches a third of the country. Each of these statutes follows the Oregon architecture: terminal illness with a six-month prognosis, a capable adult, repeated requests, two clinicians, self-administration, conscience protections, and reporting. The debates over them in legislative chambers turned less on the core concept than on its details: the length of waiting periods, whether mental health evaluation should be mandatory, whether residency should be required, and how to protect patients in institutions that decline to participate. That shift, from whether to how, is the clearest measure of how far the American debate has moved since Glucksberg. It also means that the most important questions about the future of American aid in dying now concern whether the safeguards built into the template will hold, a question that other countries, which built different templates, have already begun to answer. Chapter 7: Beyond Oregon: Comparative Law and the Question of the Slope The most persistent argument against legalizing medical aid in dying is that its limits will not hold. Once the law accepts that a competent adult's suffering can justify an assisted death, the argument runs, it will be difficult to explain why the practice should be confined to people who are terminally ill, or to people who can take the medication themselves, or to people who are competent at the moment of death, or to adults. Each boundary will come to look arbitrary, and each will be challenged as discriminatory against those it excludes. The Supreme Court in Glucksberg relied on a version of this argument, citing the Netherlands. American legislators still debate it every time a new state considers the Oregon template. The argument is partly logical and partly empirical. The logical version holds that the principles used to justify aid in dying, autonomy and relief of suffering, cannot in principle be confined by the lines the statutes draw. The empirical version holds that, in practice, jurisdictions that legalize assisted dying do in fact expand it. The empirical claim can be tested, because a number of countries have now operated legal regimes for years or decades. What the comparative record shows is more interesting than either side of the American debate usually admits: expansion has occurred in some places and not others, and whether it occurs depends heavily on the legal source of the right and the institution that polices its boundaries. The Low Countries The Netherlands developed its regime from the bottom up, through prosecutions. From the 1970s onward, Dutch courts faced cases in which physicians had ended the lives of patients at their request. In a series of decisions, culminating in a 1984 ruling by the Dutch Supreme Court, the courts recognized that a physician facing a conflict between the duty to preserve life and the duty to relieve unbearable suffering could invoke a defense of necessity. Prosecutors and the medical profession developed guidelines, called "due care" criteria, and a notification procedure. The Termination of Life on Request and Assisted Suicide (Review Procedures) Act, which took effect in 2002, codified this practice. The Dutch statute differs from the Oregon model at nearly every point. It permits both euthanasia, in which the physician administers the drug, and assisted suicide, and in practice euthanasia accounts for the great majority of cases. It does not require terminal illness. It requires instead that the physician be satisfied that the patient's request is voluntary and well considered, that the patient's suffering is unbearable with no prospect of improvement, that the patient has been informed of the situation and prospects, that there is no reasonable alternative, that at least one independent physician has seen the patient and given a written opinion, and that the procedure is performed with due medical care. Compliance is reviewed after the fact by regional review committees composed of a lawyer, a physician, and an ethicist, which refer cases they find noncompliant to prosecutors and medical disciplinary authorities. Because the criteria turn on suffering rather than diagnosis, the Dutch regime has from the beginning encompassed people with non-terminal conditions, including psychiatric illness and early dementia, though such cases remain a small fraction of the total. It permits requests from minors from age twelve, with parental involvement until sixteen, and it permits a written advance directive to substitute for a contemporaneous request in some circumstances. In 2020, the Dutch Supreme Court held in a case involving a woman with advanced dementia, who had written an advance directive requesting euthanasia but whose later statements were ambiguous, that a physician may act on such a directive when the patient is no longer able to express her will, provided the due care criteria are otherwise met. The Netherlands also permits termination of life of severely ill newborns under a separate protocol, and in 2024 extended a regulated framework to children between the ages of one and twelve with no prospect of improvement. Assisted deaths now account for around five percent of all deaths in the country. Belgium enacted its euthanasia statute in 2002, the same year as the Dutch law took effect, and it similarly does not require terminal illness, requiring instead constant and unbearable physical or psychological suffering from a serious and incurable disorder. In 2014, Belgium removed any minimum age for euthanasia, allowing minors with the capacity for discernment to request it if they are terminally ill and suffering physically, subject to parental consent and psychological assessment. Belgium's regime has attracted international legal scrutiny. In Mortier v. Belgium, decided in 2022, the European Court of Human Rights considered the euthanasia of a woman with long-standing depression, performed without her son's knowledge. The court found that Belgium's legal framework and the procedure followed in her case did not violate the right to life under Article 2 of the European Convention on Human Rights, but that the state had violated Article 2 because the post-hoc review by the federal commission lacked independence, since the physician who performed the euthanasia sat on the commission that reviewed it, and the criminal investigation had been inadequate. Switzerland and the rest of Europe Switzerland represents a distinct model. Article 115 of the Swiss Criminal Code, which dates from 1942, penalizes inciting or assisting suicide only when the person acts from selfish motives. Assistance for altruistic reasons is therefore not a crime, and neither a physician nor a terminal diagnosis is legally required. Euthanasia by a physician remains unlawful. Right-to-die organizations such as Exit, which serves Swiss residents, and Dignitas, which accepts foreigners, have operated within this space for decades, with lethal medication obtained by prescription under medical and professional guidelines. Switzerland's willingness to allow non-residents has made it a destination for people from countries where assistance is illegal, and has generated repeated debates in other countries about whether relatives who accompany a person to Switzerland commit an offense at home. The appearance in 2024 of a portable suicide capsule designed to be operated by the person without medical involvement, whose first use in Switzerland led to arrests, demonstrated that even this permissive regime has limits enforced through the criminal law. The European Court of Human Rights has generally held that states have a wide margin of appreciation in this area. In Pretty v. United Kingdom in 2002, the court held that the Convention does not require states to permit assisted suicide. In Haas v. Switzerland in 2011, it recognized that an individual's right to decide how and when to end her life, provided she can form her will freely, is an aspect of private life under Article 8, while holding that Switzerland could require a prescription to obtain lethal medication. And in Karsai v. Hungary in 2024, it held that Hungary's prohibition of assisted dying did not violate the Convention rights of a man with amyotrophic lateral sclerosis, while noting that the question is one on which European states continue to differ. National courts have been more interventionist. Germany's Federal Constitutional Court in February 2020 struck down a 2015 criminal prohibition on the "business-like" promotion of assisted suicide, holding that the general right of personality under the German Basic Law includes a right to a self-determined death and to seek and accept help from third parties in exercising it. The German legislature has not yet agreed on a replacement regulatory framework; two competing bills failed in 2023. Austria's Constitutional Court struck down its prohibition on assisted suicide in 2020, and Austria enacted a law regulating the practice in 2022. Italy's Constitutional Court, in a 2019 case arising from the prosecution of an activist who had driven a paralyzed man to Switzerland, held that assisting a suicide cannot be punished in narrowly defined circumstances, including dependence on life-sustaining treatment. Spain enacted a statute in 2021 permitting both euthanasia and assisted suicide for people with serious and incurable illnesses or serious, chronic, and incapacitating conditions. Portugal enacted a law in 2023 after a series of presidential vetoes and constitutional review, though its implementation has been slow. In the United Kingdom, section 2 of the Suicide Act 1961 makes it a crime to encourage or assist a suicide. After the House of Lords in R (Purdy) v. Director of Public Prosecutions in 2009 required the Director of Public Prosecutions to publish a policy on when prosecution would be pursued, prosecutions of relatives acting from compassion have become rare. In R (Nicklinson) v. Ministry of Justice in 2014, the UK Supreme Court declined to declare the prohibition incompatible with the European Convention, with several justices indicating that Parliament should consider the question. Parliament did. The Terminally Ill Adults (End of Life) Bill, which would have permitted assisted dying for terminally ill adults in England and Wales with a prognosis of six months and a requirement of approval by a multidisciplinary panel, passed the House of Commons in June 2025 by a narrow margin. It then stalled in the House of Lords, where it faced an unusually large number of proposed amendments, and it did not complete its passage before the parliamentary session ended in 2026. A separate bill was introduced in the Scottish Parliament. In France, the National Assembly in May 2025 approved at first reading a bill that would create a right to aid in dying, building on a 2016 law that already permitted deep and continuous sedation until death for patients with short-term prognoses. Canada: expansion through constitutional adjudication Canada provides the most closely watched test of the slope argument, because its regime began in a form close to the American model and expanded rapidly. In Carter v. Canada (Attorney General), decided unanimously in 2015, the Supreme Court of Canada held that the criminal prohibition on assisted dying violated the right to life, liberty, and security of the person under section 7 of the Canadian Charter of Rights and Freedoms, insofar as it prohibited physician-assisted death for a competent adult who clearly consents and has a grievous and irremediable medical condition causing enduring suffering that is intolerable to the individual. Notably, Carter did not limit the right to terminal illness. Parliament responded in 2016 with legislation, commonly called Bill C-14, that legalized medical assistance in dying, including both clinician-administered and self-administered forms, but required, among other criteria, that the person's natural death be "reasonably foreseeable." In 2019, in Truchon v. Attorney General of Canada, the Superior Court of Quebec held the reasonable-foreseeability requirement unconstitutional, because it excluded people who met the criteria articulated in Carter but were not near death. The federal government did not appeal. Parliament responded in 2021 with Bill C-7, which created a two-track system. For people whose natural death is reasonably foreseeable, the safeguards were relaxed, including by eliminating a ten-day reflection period. For people whose death is not reasonably foreseeable, a second track was created with additional safeguards, including a minimum ninety-day assessment period and the involvement of a practitioner with expertise in the person's condition. Bill C-7 excluded people whose sole underlying condition is mental illness, but provided that the exclusion would expire. Parliament has since twice postponed that expiration; it is currently scheduled for March 2027. Quebec, exercising its authority over health care, has separately authorized advance requests for people diagnosed with serious and incurable illnesses leading to incapacity, such as Alzheimer's disease, with that regime in force since late 2024. The practice has grown substantially. Health Canada's annual report for 2024 recorded more than sixteen thousand medically assisted deaths, about five percent of all deaths in the country, the great majority in the first track. Reports of individual cases on the second track, in which applicants with disabilities or chronic conditions cited inadequate housing, poverty, or lack of support services among the sources of their suffering, have generated intense criticism, including from disability rights organizations, from the Ontario coroner's review committee in reports published in 2024, and from a United Nations disability rights committee in 2025. Some provincial governments have since sought to restrict eligibility. What the comparison shows Table 4 compares the main features of the regimes discussed above with the American model. Table 4. Selected assisted dying regimes compared. Jurisdiction Euthanasia permitted Terminal illness required Psychiatric illness alone Minors Advance requests U.S. statutory states No Yes, six months No No No Switzerland No No Contested, rare Not in practice No Netherlands Yes No Yes From age twelve; younger under protocols Yes Belgium Yes No, except for minors Yes No age minimum Limited to irreversible unconsciousness Canada Yes No, two-track system Excluded until March 2027 No Quebec only Australian states Limited, if unable to self-administer Yes, six or twelve months No No No Three conclusions follow from the comparison. First, expansion is not inevitable. The American statutes have been in operation for nearly three decades in Oregon without any change to the terminal illness requirement, the prohibition on clinician administration, or the exclusion of advance requests. The Australian states, which began legislating with Victoria's statute in 2017 and completed adoption across all six states by 2023, and New Zealand, whose End of Life Choice Act was approved by referendum in 2020, have similarly maintained a terminal illness requirement, with prognoses of six months or, for neurodegenerative conditions in most Australian states, twelve. The American changes that have occurred, such as shortened waiting periods and broader prescriber eligibility, have altered procedures, not eligibility. Second, where expansion has occurred, its engine has been identifiable. In the Netherlands and Belgium, the regimes were never confined to terminal illness; they were built from the start on a criterion of unbearable suffering, which is inherently more elastic than a prognosis. In Canada, the expansion came from constitutional adjudication. A right grounded in the Charter's guarantee of liberty and security of the person, and tested against equality principles, is difficult to confine to a subset of people who suffer in similar ways, because any line looks like discrimination against those on the far side of it. That is exactly the mechanism the logical version of the slope argument predicts, and it operated where a court, rather than a legislature, defined the right. Third, the American choice in Glucksberg to leave the question to legislatures appears, in retrospect, to have been the most important structural safeguard of all. Because no American court has recognized a constitutional right to aid in dying, the boundaries of the practice are set by statutes that legislatures can write narrowly and are not required to justify under heightened scrutiny. A legislature can say that it permits aid in dying for people with six months to live and not for others, and that line need only be rational. The same line, drawn in a regime grounded in a constitutional right, would face the question the Canadian courts asked in Truchon: why should someone with equal suffering be denied an equal right? This does not settle the moral question of where the lines should be drawn. It does show that the slope, where it exists, is a feature of legal architecture rather than an inevitable consequence of permitting assisted death at all. That insight carries beyond the end of life. When the law confronts a new technology, the choice of institution, court or legislature, regulator or funding body, determines not only the initial rule but how that rule will change over time. Nowhere is that clearer than in the governance of human genome editing, where the question of institutional design has barely been asked in the United States at all. Chapter 8: Editing the Patient: Somatic Genome Editing Inside the System In 2012, Jennifer Doudna of the University of California, Berkeley, and Emmanuelle Charpentier, then working in Sweden, published a paper in Science showing that a bacterial immune system called CRISPR, together with an enzyme called Cas9, could be programmed to cut DNA at a chosen location. Within months, laboratories including that of Feng Zhang at the Broad Institute of MIT and Harvard had shown that the system worked in human cells. Scientists had been able to edit genes before, using tools such as zinc finger nucleases and TALENs, but those tools were difficult and expensive to design for each new target. CRISPR made targeted editing cheap, fast, and accessible to almost any molecular biology laboratory. Doudna and Charpentier received the Nobel Prize in Chemistry in 2020. The mechanism is worth understanding in outline, because the legal and ethical questions depend on it. The Cas9 enzyme is guided to its target by a short piece of RNA that matches the DNA sequence to be edited. Once there, it cuts both strands of the DNA. The cell then repairs the break, and the repair process can be harnessed either to disrupt a gene or, with a supplied template, to insert a desired sequence. Later refinements avoid cutting both strands entirely. Base editing, first described by David Liu's laboratory in 2016, chemically converts one DNA letter to another. Prime editing, described in 2019, can write short new sequences without a double-strand break. Each generation has improved precision, but none is perfect. Edits can occur at unintended locations, called off-target effects, and the intended edit can produce unintended rearrangements at the target site. A cell that has been edited cannot be unedited. That last fact frames the governance problem. Most medical interventions can be stopped. A patient who reacts badly to a drug can stop taking it; a device can be removed. A genome edit, once made in a patient's cells, persists for the life of those cells and, if they are long-lived or self-renewing, for the life of the patient. For somatic editing, the consequences are confined to the patient. For germline editing, discussed in the next chapter, they are not. The regulatory machinery In the United States, somatic genome editing therapies are regulated as gene therapy products, which are biological products subject to both the Public Health Service Act and the Federal Food, Drug, and Cosmetic Act. Oversight belongs to the FDA's Center for Biologics Evaluation and Research. The path from laboratory to patient is the same one any new biologic follows. A sponsor must submit an investigational new drug application before testing a product in humans, supported by preclinical evidence of safety. Clinical trials proceed through phases, under IRB review and informed consent as described in Chapter 2. If the evidence is sufficient, the sponsor submits a biologics license application, and the FDA decides whether to approve. Several features of this machinery have been adapted to the particular risks of gene therapy and genome editing. The FDA has issued guidance on long-term follow-up after gene therapy, recommending that subjects in trials of products involving genome editing be followed for up to fifteen years to detect delayed adverse events, such as cancers arising from unintended edits. It has issued guidance specific to products incorporating human genome editing, first published in draft in 2022, addressing the characterization of off-target effects and the design of preclinical studies. Congress created a designation for regenerative medicine advanced therapies in the 21st Century Cures Act of 2016, allowing products for serious conditions to receive expedited development and review, and in 2022 created a program for designating "platform technologies" that can be reused across products, which is particularly relevant to editing systems in which only the guide sequence changes from one therapy to the next. For much of the history of gene therapy, a second layer of review operated at the National Institutes of Health. The Recombinant DNA Advisory Committee, established in 1974 in response to concerns about recombinant DNA research, reviewed human gene therapy protocols in public session, creating a forum for ethical as well as scientific scrutiny. After the Gelsinger death, the committee's role in monitoring adverse events was strengthened. In 2019, however, the NIH eliminated the committee's protocol-by-protocol review, on the ground that gene therapy had matured and that the duplication of FDA and IRB review was no longer justified, and reconstituted it as a broader advisory body on emerging technologies. The change removed the only standing federal body that reviewed gene therapy trials in a public, deliberative forum. From first approval to bespoke editing The first approval of a CRISPR-based therapy came in late 2023. Britain's Medicines and Healthcare products Regulatory Agency approved exagamglogene autotemcel, marketed as Casgevy, in November 2023, and the FDA approved it for sickle cell disease in patients aged twelve and older on December 8, 2023, and for transfusion-dependent beta thalassemia in January 2024. The therapy, developed by Vertex Pharmaceuticals and CRISPR Therapeutics, is an ex vivo treatment: a patient's own blood stem cells are collected, edited in the laboratory to disable a genetic switch that suppresses production of fetal hemoglobin, and returned to the patient after the patient's bone marrow has been cleared with high-dose chemotherapy. The raised fetal hemoglobin compensates for the defective adult hemoglobin that causes the disease. The approval was a medical milestone and a demonstration of the limits of what approval accomplishes. The treatment requires myeloablative conditioning, which carries serious risks including infertility, and a lengthy hospitalization. Its list price in the United States was announced at 2.2 million dollars. Sickle cell disease in the United States primarily affects Black Americans, many of whom rely on Medicaid, and the question of access, whether public programs would pay and whether hospitals had the capacity to deliver the treatment, became as important as the question of efficacy. The Centers for Medicare and Medicaid Services responded with a Cell and Gene Therapy Access Model, under which participating states pay for sickle cell gene therapies under outcomes-based agreements negotiated centrally with manufacturers. The consent issues in this context are real but subtle: a patient deciding whether to undergo a curative but grueling and irreversible procedure, with fertility at stake and long-term outcomes unknown, faces a decision of exactly the kind Canterbury contemplated, at the outer edge of what a reasonable person can meaningfully evaluate. In vivo editing, in which the editing system is delivered directly into the body, usually by lipid nanoparticles that travel to the liver, presents a different profile. There is no need to remove and return cells, which makes treatment simpler, but there is also no opportunity to check the edited cells before they go into the patient. Trials of in vivo editing for conditions including transthyretin amyloidosis and inherited high cholesterol have produced striking results in reducing levels of the targeted proteins. They have also produced safety signals. In late 2025, the FDA placed a clinical hold on one of the most advanced in vivo editing programs after a trial participant developed serious liver injury. The broader field of gene therapy was shaken the same year by deaths from acute liver failure in patients who had received an approved gene therapy for Duchenne muscular dystrophy, which led the FDA to seek restrictions on its use. Neither episode involved the germline or any novel legal question, but both illustrated that the ordinary machinery of trials, adverse event reporting, and clinical holds remains the principal protection for patients. The most remarkable development came in 2025. A team at the Children's Hospital of Philadelphia and the University of Pennsylvania treated an infant, identified publicly as KJ, who had been born with a severe deficiency of the liver enzyme carbamoyl phosphate synthetase 1, a rare metabolic disorder that is frequently fatal in infancy. Within roughly six months of his diagnosis, the team designed a base editor tailored to KJ's specific mutation, manufactured it, tested it in animals, and obtained FDA authorization to administer it under a single-patient investigational application. KJ received the first dose in early 2025, and the team reported encouraging early results in the New England Journal of Medicine that May. The case raised legal and regulatory questions as significant as its scientific ones. The ordinary drug development model assumes a product that will be tested in hundreds or thousands of patients and sold to many more. A therapy designed for a single mutation carried by a single child cannot be tested in a randomized trial, and its costs cannot be spread across a market. If bespoke editing is to become more than a heroic exception, the regulatory framework must accept evidence of a different kind: confidence in the platform and the mechanism, rather than a large controlled trial of each individual product. Senior FDA officials signaled in late 2025 that the agency was prepared to develop a pathway along these lines, sometimes described as approval based on a "plausible mechanism," for individualized therapies for rare diseases. How such a pathway is designed will determine whether the principle of independent review, which has anchored research regulation since the 1970s, is adapted to personalized medicine or quietly eroded by it. Consent at the edge of the known The consent problems raised by somatic editing trials are variations on the themes of Chapter 2, sharpened by the permanence of the intervention. The first concerns withdrawal. The research regulations promise that a subject may withdraw from a study at any time. A subject in a genome editing trial can decline further study visits, but cannot withdraw the edit. The consent process must therefore explain that the right to withdraw protects the subject's time and privacy, not her body, and that long-term follow-up, which the FDA recommends for up to fifteen years, is designed around the assumption that participants will remain in contact. Asking a subject to commit in advance to fifteen years of monitoring, while honoring her legal right to stop, is a tension that consent documents can describe but not resolve. The second concerns children. Many of the diseases that genome editing targets, including sickle cell disease and rare metabolic disorders, cause their most severe harm in childhood, and there are strong reasons to intervene early. The federal research regulations include special protections for children, which permit research involving more than minimal risk only if it holds out the prospect of direct benefit to the child and the risk is justified by that benefit, or, in narrower circumstances, if it involves only a minor increase over minimal risk and is likely to yield vitally important knowledge about the child's condition. Research that does not fit either category may proceed only after review at the level of the Secretary of Health and Human Services or the FDA Commissioner. Parents give permission, and children old enough to understand give assent. For an infant such as KJ, the decision rests entirely with parents facing a fatal diagnosis, and the question of whether a first-in-human intervention is in the child's interest is answered by the physicians, the IRB, and the FDA as much as by the family. That is, once again, consent supplemented by review. The third concerns justice, in the sense the Belmont Report used the term. Early trials of editing therapies for sickle cell disease enrolled patients from a community with specific historical grounds for distrust of medical research, and the resulting therapies were priced beyond what many of those patients' insurers could readily pay. The legal system has few tools for requiring that the populations who bear the risks of research share in its benefits. The Common Rule's requirement of equitable subject selection addresses who is enrolled; it says nothing about who will be able to afford the product. The edges of the system Somatic editing, for all its novelty, has fit within existing law. The FDA's authority over biologics is clear, the trial system is well established, and the questions of consent and access are familiar ones. There are, however, edges where the system is thinner. One is the practice of medicine. The FDA regulates products, not physicians, and once a product is approved, physicians may generally use it for purposes other than those on the label. That flexibility, which is valuable in ordinary medicine, will matter more as editing platforms become reusable and as the line between approving a platform and approving each use becomes blurred. Another is the do-it-yourself movement. Some self-described biohackers have injected themselves with homemade editing constructs, generally without any credible prospect of effect, and kits for simple editing experiments in bacteria have been sold to hobbyists. California enacted a statute in 2019 requiring that such kits carry warnings that they are not for self-administration. Self-experimentation of this kind is not regulated as research, because it is not conducted by an institution, and it is not regulated as a drug unless a product is being sold for human use. A third is enhancement. The regulatory framework is organized around disease: the FDA approves products to diagnose, treat, or prevent disease, or to affect the structure or function of the body. A somatic edit intended to enhance a healthy person's traits, such as muscle mass, would fall within the FDA's jurisdiction if marketed, but there is no specific rule addressing whether such uses should be permitted at all. For somatic interventions, the ordinary tools of safety review may be enough, because the person bearing the risk is the person who chose it. That premise, that the person who bears the risk is the one who consents to it, is what makes somatic editing governable within the framework the law has built since Nuremberg. It is exactly the premise that fails for germline editing. Chapter 9: The Germline Vacuum: Heritable Editing and the Absence of Law On November 25 and 26, 2018, on the eve of the Second International Summit on Human Genome Editing in Hong Kong, the Chinese scientist He Jiankui announced through a series of online videos and interviews that twin girls had been born from embryos he had edited using CRISPR. He had targeted the gene CCR5, which encodes a receptor that some strains of HIV use to enter cells, with the stated aim of making the girls resistant to HIV infection. Their father was HIV-positive. A third child, from another couple, was later born from an edited embryo. The reaction was swift and almost uniformly condemnatory. Scientists pointed out that there was no unmet medical need, since well-established techniques allow HIV-positive fathers to conceive children without transmitting the virus; that the edits He made did not reproduce the naturally occurring protective mutation and produced mosaicism, meaning that not all cells in the embryos carried the same edit; that the consequences of disabling CCR5 were not fully understood; and that the consent process had been deeply deficient, with the couples recruited through an HIV patient group and given consent forms that described the project as an AIDS vaccine development program. Investigators found that He had evaded oversight and used forged ethics review documents. In December 2019, a court in Shenzhen convicted He and two collaborators of illegal medical practice. He was sentenced to three years in prison and fined three million yuan. He was released in 2022. The He Jiankui affair is usually described as the act of a rogue scientist, and in a sense it was. But it also exposed a structural fact about the law of heritable genome editing: in most of the world, including the United States, there was no statute that clearly addressed what he did. China prosecuted him under a general offense of practicing medicine without a license, and then legislated. The United States has not legislated at all. Why the germline is different Heritable genome editing means editing the DNA of an embryo, egg, or sperm, or of the cells that give rise to them, in a way that is intended to result in a pregnancy. The edit is present in every cell of the resulting person, including that person's own reproductive cells, and so can be passed to later generations. Every framework discussed so far in this book rests on the consent of the person who bears the consequences, or of someone authorized to decide on that person's behalf in the person's interest. Germline editing fits neither model cleanly. The embryo cannot consent. The parents who choose the edit are exercising what American law has long recognized as a protected sphere of procreative decision-making, but they are not choosing a treatment for an existing person; they are choosing which person, with which genome, will come into existence. The resulting child cannot consent to the edit, cannot withdraw from it, and will pass it to her own children, who also cannot consent. Any unexpected harm may not become apparent for years, and may emerge only in later generations. None of the tools of informed consent law, from Canterbury to the Common Rule, was built for a decision whose most affected parties do not yet exist. There is also the question of need. For most couples at risk of passing on a serious single-gene disorder, preimplantation genetic testing already offers an alternative: embryos created through in vitro fertilization are tested, and one without the disease-causing variant is transferred. The situations in which editing would be the only way to have a genetically related, unaffected child, for instance where both parents are homozygous for a recessive condition, are rare. That rarity has shaped the international debate, because it means the strongest medical case for heritable editing applies to very few people, while the potential uses that would affect many people, including the reduction of common disease risk or the selection of non-disease traits, are exactly the ones most societies are least prepared to accept. How the United States governs the germline: a rider In the United States, the principal legal obstacle to heritable genome editing is a single provision in the annual appropriations act that funds the FDA. First included in the Consolidated Appropriations Act of 2016, enacted in December 2015, and renewed in each appropriations cycle since, the rider provides that none of the funds made available by the Act may be used to notify a sponsor or otherwise acknowledge receipt of a submission for an exemption for investigational use of a drug or biological product in research in which a human embryo is intentionally created or modified to include a heritable genetic modification. Any such submission is deemed not to have been received, and the exemption may not go into effect. The mechanism is indirect and relies on the FDA's longstanding position that a genetically modified embryo intended for implantation is a product subject to its jurisdiction, requiring an investigational new drug application before clinical use. Under the rider, no such application can be accepted, so no clinical trial can lawfully proceed, and anyone who implanted an edited embryo in the United States would be introducing an unapproved biological product in violation of federal law. The rider also applies to mitochondrial replacement techniques, which transfer the nuclear DNA of an egg or embryo into a donor egg with healthy mitochondria, because the donor's mitochondrial DNA is inherited. When an American fertility specialist used such a technique in Mexico in 2016, resulting in a birth reported that year, the FDA later wrote to him that the technique could not be performed in the United States without an investigational application that the agency could not accept. The rider has held for a decade, and it has the practical effect of a prohibition on clinical use. But as a legal instrument, it is strikingly thin. It is not a statute addressing heritable editing on the merits; it is a limitation on the use of appropriated funds that must be renewed by Congress every year, and that would lapse if an appropriations act were passed without it. It addresses only the FDA's processing of applications and has no application to activity outside FDA jurisdiction. It does not distinguish between uses: it bars a carefully reviewed trial to prevent a fatal disease in the same terms as a trial of cosmetic trait selection. And it was adopted with little public deliberation, as one provision among thousands in an omnibus spending bill. The rider coexists with a second funding provision, the Dickey-Wicker Amendment, which has been attached to the appropriations act for the Department of Health and Human Services every year since 1996. It prohibits federal funding for the creation of human embryos for research purposes or for research in which embryos are destroyed or subjected to risk of injury or death beyond what is permitted for research on fetuses in utero. The NIH has stated that it will not fund any use of gene editing technologies in human embryos. The result is that research on editing human embryos in the laboratory, short of any pregnancy, is not prohibited in the United States, but must be privately funded. Such research has been conducted. In 2017, a team led by researchers at Oregon Health and Science University reported in Nature that it had used CRISPR to correct a disease-causing mutation in human embryos, which were not implanted. Because the work was privately funded, the federal Common Rule did not apply to it by virtue of funding, though the institution's own review processes did. Beyond these federal funding provisions, American law says very little. No federal statute prohibits heritable genome editing. State laws on embryo research vary widely, from states that restrict it sharply to states that permit it with oversight, but none has built a comprehensive framework for heritable editing. The result is not a regime but a vacuum held in place by a budget rider. The international patchwork The rest of the world has approached the question in a variety of ways, most of them more formal than the American rider. Table 5 summarizes the principal approaches. Table 5. Selected legal approaches to heritable human genome editing. Jurisdiction Main instrument Approach United States FDA appropriations rider, renewed annually FDA barred from accepting clinical applications; no statute United Kingdom Human Fertilisation and Embryology Act 1990, as amended Only unmodified embryos may be implanted; licensed embryo research permitted; mitochondrial donation licensed by regulation Canada Assisted Human Reproduction Act 2004 Criminal prohibition on heritable alteration Council of Europe Oviedo Convention, Article 13 Treaty bar on modifications aimed at descendants, for ratifying states European Union Clinical Trials Regulation, Article 90 No trials that modify the subject's germline genetic identity China Civil Code Article 1009; Criminal Law Amendment XI Criminal penalties for implanting edited embryos The United Kingdom's model deserves particular attention because it shows what a licensing approach looks like. The Human Fertilisation and Embryology Act 1990 created a statutory regulator, the Human Fertilisation and Embryology Authority, which licenses clinics and research involving human embryos. The Act, as amended in 2008, permits only "permitted embryos," whose nuclear DNA has not been altered, to be placed in a woman. Research on embryos, including editing research, is permitted under license up to fourteen days of development, and in 2016 the Authority granted the first license for editing research on human embryos, to a team at the Francis Crick Institute studying early development. Parliament approved regulations in 2015 permitting mitochondrial donation under license, after years of scientific review and public consultation, and in 2025 researchers in Newcastle reported the births of eight children conceived using the technique. The British approach demonstrates that a legal system can prohibit clinical heritable editing while leaving room for research, and can authorize a specific germline technique through a deliberate, reviewable process when the case for it has been made. Canada takes the most direct approach. The Assisted Human Reproduction Act of 2004 makes it a criminal offense to alter the genome of a human cell or in vitro embryo such that the alteration is capable of being transmitted to descendants, with penalties including imprisonment. The prohibition is categorical and applies regardless of purpose, which critics argue forecloses even laboratory research that would inform future policy. The Council of Europe's Convention on Human Rights and Biomedicine, known as the Oviedo Convention, provides in Article 13 that an intervention seeking to modify the human genome may be undertaken only for preventive, diagnostic, or therapeutic purposes and only if its aim is not to introduce any modification in the genome of any descendants. The Convention binds only states that have ratified it, and several major European countries, including the United Kingdom and Germany, have not. The European Union's Clinical Trials Regulation separately prohibits gene therapy trials that result in modifications to the subject's germline genetic identity. China's response to the He Jiankui affair was rapid. The Civil Code that took effect in January 2021 provides that medical and scientific research involving human genes and embryos must not endanger human health or violate ethical norms. The Eleventh Amendment to the Criminal Law, effective in March 2021, created a specific offense of implanting gene-edited or cloned embryos into humans or animals, punishable by up to seven years in prison. National ethics guidelines issued in 2024 reaffirmed that clinical germline editing is prohibited. Other countries have adopted prohibitions through reproductive technology statutes, as in Australia, or through guidelines rather than legislation. The global picture is one in which most countries with significant biomedical research capacity prohibit clinical heritable editing in some form, but the prohibitions differ in their legal force, their treatment of research, and their capacity to adapt. A 2024 revision of research guidelines in South Africa briefly appeared to many observers to open a path for heritable editing, prompting criticism and clarification, an episode that illustrated how a gap in one jurisdiction can attract attention from those seeking a permissive venue. Soft law and the consensus that did not bind Alongside these national laws, the scientific community has produced an extensive body of soft law: statements, reports, and guidelines without binding legal force. The First International Summit on Human Gene Editing, held in Washington in 2015 and convened by the national academies of the United States, the United Kingdom, and China, concluded that it would be irresponsible to proceed with any clinical use of germline editing unless and until safety and efficacy issues had been resolved and there was broad societal consensus about the appropriateness of the proposed application. A 2017 report of the US National Academies of Sciences and Medicine took a more open position, concluding that heritable editing might be permissible in the future for serious diseases where no reasonable alternatives exist, subject to stringent criteria and oversight. After the He Jiankui announcement, a group of prominent scientists called in 2019 for a global moratorium on clinical germline editing. An international commission convened by the US National Academies and the Royal Society reported in 2020 that no heritable editing should proceed until it could be shown to be safe and effective, and that any initial uses should be restricted to serious monogenic diseases for couples with no or very poor alternatives. The World Health Organization published a governance framework and recommendations in 2021, including a registry of human genome editing trials. The Third International Summit, held in London in March 2023, concluded that heritable human genome editing remains unacceptable at this time. The International Society for Stem Cell Research's guidelines similarly classify it as not currently permitted. Soft law has real force within the scientific community, shaping what journals will publish, what institutions will permit, and what funders will support. It shaped, too, the private licensing terms that the holders of key CRISPR patents have attached to their technology, several of which exclude human germline modification from the permitted uses. But the He Jiankui affair showed that soft law does not bind those who choose to ignore it, and it now faces a different kind of test. In 2025, press reports described several venture-backed start-up companies openly exploring heritable embryo editing, with backing from well-known technology investors and, in at least one case, reported interest in conducting work in jurisdictions with permissive or unclear rules. Such companies are not bound by the NIH's funding restrictions, since they do not seek NIH funds, and may not be bound by the FDA rider if they operate abroad. They present precisely the scenario the patchwork is least equipped to handle: well-funded private actors, not rogue individuals, who can choose their venue. A related market has already developed without any specific regulation in the United States. Several companies offer polygenic screening of embryos, which estimates each embryo's relative risk of common conditions or other traits based on many genetic variants, allowing prospective parents undergoing IVF to choose among embryos. The practice involves no editing and so falls outside the rider, and because fertility services are lightly regulated in the United States, it is governed largely by professional guidance, consumer protection law, and the market. Professional bodies have questioned its predictive validity. Its rapid commercial growth illustrates what happens in the space around the rider: technologies that shape the genomes of future children, by selection rather than editing, are offered to consumers with no specific legal framework at all. What a framework would require The argument of this book has been that consent is necessary but never sufficient where the risks are unknown, the person deciding is not the person bearing the consequences, or the choice cannot be undone. Heritable genome editing presents all three conditions at once. A defensible legal framework for it would therefore need what the other frontiers have required: independent review in addition to consent, a legislative rather than merely budgetary source of authority, and the capacity to draw and revise lines deliberately. In concrete terms, that would mean a statute that addresses heritable editing on the merits rather than through a funding limitation. It would mean an institution, whether a new body modeled on the British Human Fertilisation and Embryology Authority or an expanded role for an existing agency, with authority to license research and, if ever justified, specific clinical uses. It would mean criteria that distinguish between uses: serious disease with no alternatives, on one hand, and enhancement or trait selection, on the other. It would mean long-term registration and follow-up of any children born, with the tension that such monitoring creates for their own privacy and autonomy acknowledged rather than ignored. And it would mean international coordination, because a prohibition that holds only within one country's borders will simply redirect activity elsewhere. None of that exists in the United States. What exists is a rider that has worked so far because no one has seriously tested it, surrounded by research that is legal but federally unfunded, and a fertility market that is largely unregulated. The rider's supporters might reasonably argue that a blunt prohibition is appropriate while the science remains immature, and that detailed regulation would imply a readiness to permit. That argument has force. But it treats the absence of law as though it were a considered legal position, and it leaves the most consequential decisions in the field to the annual appropriations process and to the choices of private companies about where to incorporate. Conclusion: Consent and What Must Stand Beside It Cardozo's sentence about the right of every adult of sound mind to determine what shall be done with his own body has proved one of the most productive ideas in American law. It carried the law from battery to the modern duty of disclosure, from the silence of the professional standard to Canterbury's reasonable patient. It gave competent patients the right to refuse any treatment, and gave surrogates, within limits, the right to refuse on their behalf. It was the moral foundation of the federal research rules, and it is the foundation of every aid-in-dying statute now in force in the United States. When the law has had to decide something new about medicine, the first question has nearly always been who agreed. The three frontiers examined in this book show that the first question is never the last one. Across them, a consistent pattern appears, and it suggests what the law should do at the next frontier, whatever it turns out to be. The pattern Consent works best when four conditions hold: the person deciding is competent; the risks are known well enough to describe; the person deciding is the person who bears the consequences; and the decision can be reversed or at least contained. Ordinary clinical medicine usually satisfies all four, and there the law is content to police consent through after-the-fact lawsuits. Where one condition fails, the law has added a second mechanism. In research, where risks are unknown, it added prospective independent review by IRBs and the FDA, and it declared that no subject's signature could make an unreasonable study acceptable. Where the right to try investigational drugs removed that review, as the federal Right to Try Act did, the result has been a pathway that few use, partly because manufacturers, who retain their own form of review, decline to participate. In the law of refusing treatment, where the patient is often no longer competent, the law added advance directives, surrogate hierarchies, evidentiary standards like the one upheld in Cruzan, and, in hard cases, courts. In the law of aid in dying, where the choice cannot be reversed and the patient's competence and voluntariness may be compromised by depression, pressure, or despair, the Oregon template added waiting periods, witnesses, two independent clinicians, capacity assessment, self-administration, and public reporting. Where all four conditions fail at once, as they do in heritable genome editing, the law needs the most robust supplementary mechanisms of all. In the United States it has the weakest: a budget rider. What the comparisons teach The book's comparative chapters point to a second lesson, about the source of legal rules. The Supreme Court's refusal in Glucksberg to find a constitutional right to aid in dying was criticized at the time as abdication. In retrospect, it placed the drawing of lines where lines can be drawn most deliberately: in legislatures, which can hold hearings, write detailed procedures, revise them in light of experience, and choose boundaries that need only be rational rather than perfectly consistent with an underlying principle. Canada's experience, where a constitutional right defined by courts has driven a rapid expansion of eligibility, shows the alternative. Neither approach is costless. The American approach leaves a person's options at the end of life dependent on the state in which she lives, and it leaves residency rules and other boundaries to be fought out in litigation. But it has produced stable limits, tested over nearly three decades, and it has allowed states to adopt aid in dying incrementally, most recently New York and Illinois, without any court compelling the practice's extension to categories of people the legislature did not choose to include. The same lesson applies to genome editing, in reverse. Because no American institution has been assigned the task of drawing lines for heritable editing, the lines that exist are drawn by default. The appropriations rider bars all clinical use without distinction. The Dickey-Wicker Amendment pushes embryo research into private hands. And the fertility market, largely unregulated, has already begun to offer parents tools for shaping the genomes of their children by selection. The British experience, with a statutory regulator that has licensed embryo research, prohibited clinical editing, and authorized mitochondrial donation after years of deliberation, shows that another path is available. It is not a path the United States has chosen, because it has not chosen at all. What remains unsettled Several questions will shape the next decade. In research law, the most important is whether regulators can adapt independent review to individualized therapies such as the bespoke base editor designed for a single infant in 2025, without abandoning the evidentiary standards that make review meaningful. A pathway that approves products on the basis of a plausible mechanism rather than a controlled trial may save lives; it may also shift more of the burden of risk assessment onto patients and families, whose consent, as the history of research ethics shows, is least reliable when hope is highest. The design of that pathway deserves more public attention than it has received. In end-of-life law, the questions are about boundaries. Will the residency requirements that still apply in most American jurisdictions survive challenges under the Privileges and Immunities Clause, or will aid in dying become, in practice, available to anyone able to travel to a state that permits it? Will American legislatures continue to hold the line on advance requests, which the growing number of people facing dementia will press them to reconsider? Will the self-administration requirement, which excludes some patients with advanced neurological disease, remain the bright line between the American model and euthanasia? And will the experience of Canada, where the mental illness exclusion is scheduled to expire in March 2027, provide evidence that informs these choices or simply harden positions on both sides? In genome editing, the question is whether the United States will legislate before it is forced to react. The He Jiankui affair led China, within two years, to adopt specific criminal prohibitions. An American analog, whether a birth abroad arranged by an American company or a challenge to the rider's renewal, would produce pressure for hasty legislation. Legislating deliberately, before such an event, would allow the law to distinguish between uses, create a regulator with real expertise, and coordinate with other countries. Legislating afterward will more likely produce another blunt instrument. For the reader For a reader who encounters these questions not as a policymaker but as a patient, a family member, or a citizen, the practical lessons are specific. Consent is a right, but it is also a responsibility, and it is worth exercising deliberately: asking about alternatives and about the physician's experience, as Canterbury and Johnson v. Kokemoor entitle a patient to do; understanding, before enrolling in a trial, that its purpose is to produce knowledge rather than to treat; and recognizing that the right to refuse treatment is only as effective as the documents and conversations that make one's wishes knowable when one can no longer speak. Few of the families in this book's end-of-life cases had written anything down. Many of the hardest disputes arose because they had not. For those thinking about the law more broadly, the lesson is structural. Consent is the law's way of honoring the person. Independent review, procedural safeguards, and deliberate legislation are the law's way of acknowledging that persons are sometimes wrong, sometimes pressured, sometimes absent, and sometimes not yet born. A legal system that relied only on consent would abandon people in precisely the moments when they most need protection. A legal system that relied only on regulation would forget whose body it was. The task at each frontier of medicine is to decide, deliberately and through institutions accountable for the choice, what must stand beside consent. At the end of life, American law has made that decision with care. At the edge of the genome, it has not yet begun. Notes Introduction 1. Schloendorff v. Society of New York Hospital, 211 N.Y. 125, 105 N.E. 92 (1914). Chapter 1 1. Mohr v. Williams, 95 Minn. 261, 104 N.W. 12 (1905). 1. Pratt v. Davis, 224 Ill. 300, 79 N.E. 562 (1906). 2. Salgo v. Leland Stanford Jr. University Board of Trustees, 154 Cal. App. 2d 560, 317 P.2d 170 (1957). 3. Natanson v. Kline, 186 Kan. 393, 350 P.2d 1093 (1960). 4. Canterbury v. Spence, 464 F.2d 772 (D.C. Cir. 1972). 5. Cobbs v. Grant, 8 Cal. 3d 229, 502 P.2d 1 (1972); Wilkinson v. Vesey, 110 R.I. 606, 295 A.2d 676 (1972). 6. N.Y. Public Health Law § 2805-d; Tex. Civ. Prac. & Rem. Code §§ 74.101–74.106. 7. Truman v. Thomas, 27 Cal. 3d 285, 611 P.2d 902 (1980). 8. Arato v. Avedon, 5 Cal. 4th 1172, 858 P.2d 598 (1993). 9. Johnson v. Kokemoor, 199 Wis. 2d 615, 545 N.W.2d 495 (1996). 10. Howard v. University of Medicine and Dentistry of New Jersey, 172 N.J. 537, 800 A.2d 73 (2002). 11. Shinal v. Toms, 162 A.3d 429 (Pa. 2017). 12. Wash. Rev. Code § 7.70.060. Chapter 2 1. United States v. Karl Brandt et al., in Trials of War Criminals before the Nuernberg Military Tribunals under Control Council Law No. 10, vol. 2 (Washington, D.C.: U.S. Government Printing Office, 1949). 1. Henry K. Beecher, "Ethics and Clinical Research," New England Journal of Medicine 274 (1966): 1354–1360. 2. National Research Act, Pub. L. No. 93-348, 88 Stat. 342 (1974). 3. National Commission for the Protection of Human Subjects of Biomedical and Behavioral Research, The Belmont Report: Ethical Principles and Guidelines for the Protection of Human Subjects of Research (1979). 4. 45 C.F.R. Part 46; Federal Policy for the Protection of Human Subjects, 82 Fed. Reg. 7149 (Jan. 19, 2017). 5. 21 C.F.R. Parts 50 and 56; 21 C.F.R. § 50.24 (exception from informed consent for emergency research). 6. 21st Century Cures Act, Pub. L. No. 114-255, 130 Stat. 1033 (2016). 7. Grimes v. Kennedy Krieger Institute, Inc., 366 Md. 29, 782 A.2d 807 (2001). 8. Moore v. Regents of the University of California, 51 Cal. 3d 120, 793 P.2d 479 (1990). 9. Greenberg v. Miami Children's Hospital Research Institute, Inc., 264 F. Supp. 2d 1064 (S.D. Fla. 2003). 10. Rebecca Skloot, The Immortal Life of Henrietta Lacks (New York: Crown, 2010). 11. Paul S. Appelbaum, Loren H. Roth, and Charles Lidz, "The Therapeutic Misconception: Informed Consent in Psychiatric Research," International Journal of Law and Psychiatry 5 (1982): 319–329. 12. World Medical Association, Declaration of Helsinki: Ethical Principles for Medical Research Involving Human Participants (as revised October 2024). Chapter 3 1. United States v. Rutherford, 442 U.S. 544 (1979). 1. Abigail Alliance for Better Access to Developmental Drugs v. von Eschenbach, 445 F.3d 470 (D.C. Cir. 2006), vacated on rehearing en banc, 495 F.3d 695 (D.C. Cir. 2007), cert. denied (2008). 2. Expanded Access to Investigational Drugs for Treatment Use, 74 Fed. Reg. 40900 (Aug. 13, 2009), codified at 21 C.F.R. Part 312, Subpart I. 3. Trickett Wendler, Frank Mongiello, Jordan McLinn, and Matthew Bellina Right to Try Act of 2017, Pub. L. No. 115-176, 132 Stat. 1372 (2018), codified in part at 21 U.S.C. § 360bbb-0a. 4. United States v. US Stem Cell Clinic, LLC, 998 F.3d 1302 (11th Cir. 2021). 5. Ajay E. Kuriyan et al., "Vision Loss after Intravitreal Injection of Autologous 'Stem Cells' for AMD," New England Journal of Medicine 376 (2017): 1047–1053. Chapter 4 1. In re Quinlan, 70 N.J. 10, 355 A.2d 647 (1976). 1. Superintendent of Belchertown State School v. Saikewicz, 373 Mass. 728, 370 N.E.2d 417 (1977). 2. In re Storar, 52 N.Y.2d 363, 420 N.E.2d 64 (1981). 3. In re Conroy, 98 N.J. 321, 486 A.2d 1209 (1985). 4. Bouvia v. Superior Court, 179 Cal. App. 3d 1127 (1986). 5. Cruzan v. Director, Missouri Department of Health, 497 U.S. 261 (1990). 6. Patient Self-Determination Act, enacted as part of the Omnibus Budget Reconciliation Act of 1990, Pub. L. No. 101-508, §§ 4206, 4751. 7. Bush v. Schiavo, 885 So. 2d 321 (Fla. 2004); An Act for the Relief of the Parents of Theresa Marie Schiavo, Pub. L. No. 109-3, 119 Stat. 15 (2005); Schiavo ex rel. Schindler v. Schiavo, 403 F.3d 1223 (11th Cir. 2005). 8. In re Baby K, 16 F.3d 590 (4th Cir. 1994). 9. Tex. Health & Safety Code § 166.046. 10. Ad Hoc Committee of the Harvard Medical School, "A Definition of Irreversible Coma," JAMA 205 (1968): 337–340. 11. Uniform Law Commission, Uniform Determination of Death Act (1981); Uniform Health-Care Decisions Act (1993, revised 2023). Chapter 5 1. Compassion in Dying v. Washington, 79 F.3d 790 (9th Cir. 1996) (en banc); Quill v. Vacco, 80 F.3d 716 (2d Cir. 1996). 1. Washington v. Glucksberg, 521 U.S. 702 (1997). 2. Vacco v. Quill, 521 U.S. 793 (1997). 3. Lee v. Oregon, 107 F.3d 1382 (9th Cir. 1997). 4. Assisted Suicide Funding Restriction Act of 1997, Pub. L. No. 105-12, 111 Stat. 23. 5. Gonzales v. Oregon, 546 U.S. 243 (2006). 6. Dobbs v. Jackson Women's Health Organization, 597 U.S. 215 (2022). 7. Krischer v. McIver, 697 So. 2d 97 (Fla. 1997); Sampson v. State, 31 P.3d 88 (Alaska 2001). 8. Morris v. Brandenburg, 2016-NMSC-027, 376 P.3d 836. 9. Myers v. Schneiderman, 30 N.Y.3d 1 (2017). 10. Kligler v. Attorney General, 491 Mass. 38 (2022). 11. Baxter v. State, 2009 MT 449, 354 Mont. 234, 224 P.3d 1211. Chapter 6 1. Oregon Death with Dignity Act, Or. Rev. Stat. §§ 127.800–127.897. 1. Oregon Health Authority, Oregon Death with Dignity Act annual data summaries (published yearly since 1999). 2. California End of Life Option Act, Cal. Health & Safety Code § 443 et seq., as amended by S.B. 380 (2021). 3. Hawaii Our Care, Our Choice Act, Haw. Rev. Stat. ch. 327L. 4. Elizabeth Whitefield End-of-Life Options Act, N.M. Stat. Ann. § 24-7C-1 et seq. 5. Gideonse v. Brown (D. Or.), settled 2022. 6. Jennifer L. Gaudiani, Alison Bogetz, and Joel Yager, "Terminal Anorexia Nervosa: Three Cases and Proposed Clinical Characteristics," Journal of Eating Disorders 10 (2022): 23. Chapter 7 1. Termination of Life on Request and Assisted Suicide (Review Procedures) Act (Netherlands, 2001, in force 2002). 1. Belgian Act on Euthanasia of 28 May 2002, as amended in 2014. 2. Mortier v. Belgium, European Court of Human Rights, judgment of 4 October 2022. 3. Pretty v. United Kingdom, European Court of Human Rights (2002); Haas v. Switzerland, European Court of Human Rights (2011); Karsai v. Hungary, European Court of Human Rights (2024). 4. Bundesverfassungsgericht (Federal Constitutional Court of Germany), Judgment of 26 February 2020, 2 BvR 2347/15. 5. Corte costituzionale (Italy), Judgment No. 242 of 2019. 6. R (Purdy) v. Director of Public Prosecutions [2009] UKHL 45; R (Nicklinson) v. Ministry of Justice [2014] UKSC 38. 7. Carter v. Canada (Attorney General), 2015 SCC 5; Truchon c. Procureur général du Canada, 2019 QCCS 3792. 8. An Act to amend the Criminal Code (medical assistance in dying), S.C. 2016, c. 3; S.C. 2021, c. 2. 9. Health Canada, Annual Report on Medical Assistance in Dying in Canada, 2024 edition. Chapter 8 1. Martin Jinek et al., "A Programmable Dual-RNA–Guided DNA Endonuclease in Adaptive Bacterial Immunity," Science 337 (2012): 816–821. 1. Alexis C. Komor et al., "Programmable Editing of a Target Base in Genomic DNA without Double-Stranded DNA Cleavage," Nature 533 (2016): 420–424. 2. Andrew V. Anzalone et al., "Search-and-Replace Genome Editing without Double-Strand Breaks or Donor DNA," Nature 576 (2019): 149–157. 3. U.S. Food and Drug Administration, Long Term Follow-Up After Administration of Human Gene Therapy Products: Guidance for Industry (2020); Human Gene Therapy Products Incorporating Human Genome Editing (draft guidance, 2022). 4. Haydar Frangoul et al., "CRISPR-Cas9 Gene Editing for Sickle Cell Disease and β-Thalassemia," New England Journal of Medicine 384 (2021): 252–260. 5. Julian D. Gillmore et al., "CRISPR-Cas9 In Vivo Gene Editing for Transthyretin Amyloidosis," New England Journal of Medicine 385 (2021): 493–502. 6. Kiran Musunuru et al., "Patient-Specific In Vivo Gene Editing to Treat a Rare Genetic Disease," New England Journal of Medicine (2025). 7. 45 C.F.R. Part 46, Subpart D; 21 C.F.R. Part 50, Subpart D. Chapter 9 1. Consolidated Appropriations Act, 2016, Pub. L. No. 114-113, div. A, § 749, 129 Stat. 2242 (2015), and successor provisions in subsequent appropriations acts. 1. Balanced Budget Downpayment Act, I, Pub. L. No. 104-99, § 128 (1996) (original Dickey-Wicker Amendment), and successor provisions. 2. Hong Ma et al., "Correction of a Pathogenic Gene Mutation in Human Embryos," Nature 548 (2017): 413–419. 3. Human Fertilisation and Embryology Act 1990 (UK), as amended by the Human Fertilisation and Embryology Act 2008, s. 3ZA; Human Fertilisation and Embryology (Mitochondrial Donation) Regulations 2015. 4. Assisted Human Reproduction Act, S.C. 2004, c. 2, s. 5(1)(f). 5. Council of Europe, Convention for the Protection of Human Rights and Dignity of the Human Being with regard to the Application of Biology and Medicine (Oviedo, 1997), ETS No. 164, art. 13. 6. Regulation (EU) No 536/2014 on clinical trials on medicinal products for human use, art. 90. 7. National Academies of Sciences, Engineering, and Medicine, Human Genome Editing: Science, Ethics, and Governance (Washington, D.C.: National Academies Press, 2017). 8. Eric S. Lander et al., "Adopt a Moratorium on Heritable Genome Editing," Nature 567 (2019): 165–168. 9. International Commission on the Clinical Use of Human Germline Genome Editing, Heritable Human Genome Editing (Washington, D.C.: National Academies Press, 2020). 10. World Health Organization, Human Genome Editing: A Framework for Governance and Human Genome Editing: Recommendations (Geneva: WHO, 2021). 11. Organising Committee of the Third International Summit on Human Genome Editing, Statement (London, March 2023). 12. International Society for Stem Cell Research, Guidelines for Stem Cell Research and Clinical Translation (2021). Further Reading Ruth R. Faden and Tom L. Beauchamp, A History and Theory of Informed Consent (Oxford University Press, 1986). Still the most thorough account of how consent developed in law, medicine, and research ethics, and of the philosophical concept of autonomous choice beneath it. Jay Katz, The Silent World of Doctor and Patient (Free Press, 1984). A classic argument, by a psychiatrist and law professor, that the legal doctrine of informed consent had changed less in clinical practice than its champions believed. Rebecca Skloot, The Immortal Life of Henrietta Lacks (Crown, 2010). A narrative history of the HeLa cell line that illuminates the questions of consent, ownership, and justice raised in research on human tissue. Neil M. Gorsuch, The Future of Assisted Suicide and Euthanasia (Princeton University Press, 2006). A careful legal and philosophical argument against legalization, written before its author joined the federal bench, with extensive discussion of Glucksberg and the Dutch and Oregon experiences. Ronald Dworkin, Life's Dominion: An Argument about Abortion, Euthanasia, and Individual Freedom (Knopf, 1993). A philosopher's influential defense of individual authority over end-of-life decisions, grounded in an account of the sanctity of life. Atul Gawande, Being Mortal: Medicine and What Matters in the End (Metropolitan Books, 2014). A surgeon's reflection on how medicine handles aging and dying, useful background for understanding what patients seek in end-of-life decisions. Oregon Health Authority, Oregon Death with Dignity Act annual data summaries, and Health Canada, Annual Reports on Medical Assistance in Dying in Canada. The primary public data sources for the two most closely studied regimes, published yearly. Jennifer A. Doudna and Samuel H. Sternberg, A Crack in Creation: Gene Editing and the Unthinkable Power to Control Evolution (Houghton Mifflin Harcourt, 2017). An account of the discovery of CRISPR-Cas9 by one of its developers, with her reflections on the ethics of germline editing. Henry T. Greely, CRISPR People: The Science and Ethics of Editing Humans (MIT Press, 2021). A law professor's detailed analysis of the He Jiankui affair and a clear-eyed assessment of the legal and policy options for heritable editing. Françoise Baylis, Altered Inheritance: CRISPR and the Ethics of Human Genome Editing (Harvard University Press, 2019). A bioethicist's argument for a broad societal conversation, rather than a scientific consensus, as the precondition for any heritable editing. Kevin Davies, Editing Humanity: The CRISPR Revolution and the New Era of Genome Editing (Pegasus Books, 2020). A journalist's history of the technology and its applications, including the first clinical trials. National Academies of Sciences, Engineering, and Medicine, Human Genome Editing: Science, Ethics, and Governance (2017), and International Commission on the Clinical Use of Human Germline Genome Editing, Heritable Human Genome Editing (2020). The two most important institutional reports on the subject, both freely available from the National Academies Press. Hashtags: #BioethicsAndTheLaw #Bioethics #MedicalEthics #HealthcareLaw #InformedConsent #PatientAutonomy #PatientRights #MedicalDecisionMaking #ClinicalResearchEthics #HumanSubjectsResearch #InstitutionalReviewBoards #BelmontReport #RightToTry #ExperimentalTherapies #EndOfLifeCare #EndOfLifeDecisions #AdvanceDirectives #RightToRefuseTreatment #MedicalAidInDying #PhysicianAssistedDying #PalliativeCare #HealthcareDecisionMaking #GeneticEngineering #GenomeEditing #CRISPR #GeneTherapy #SomaticGeneEditing #GermlineEditing #HeritableGenomeEditing #BiomedicalRegulation

Download the Book (PDF): Introduction In December 2020 the organisers of a long-running scientific competition did something unusual. They announced that a problem their field had been working on for half a century was, for most practical purposes, solved. The competition was CASP, the Critical Assessment of protein Structure Prediction, and the problem was how to work out the three-dimensional shape of a protein from the string of amino acids that makes it up. The entry that prompted the announcement came from DeepMind, a company better known at the time for building programs that beat people at board games. Its system, AlphaFold 2, predicted structures that were in many cases as accurate as those determined by laboratory experiment, work that can take a skilled structural biologist months or years for a single protein. Four years later two of the people behind AlphaFold, Demis Hassabis and John Jumper, shared the Nobel Prize in Chemistry with David Baker, whose laboratory in Seattle had spent decades on the related problem of designing proteins from scratch. The award was a signal that something had shifted. Machine learning was no longer a tool scientists used at the edges of their work, to sort images or clean data. It had produced a result at the centre of a discipline, one that a committee of chemists judged comparable to the discoveries their prize usually honours. Since then the claims have multiplied. Google DeepMind announced that a model called GNoME had found 2.2 million new crystal structures, more than the previous history of materials science combined. Microsoft and a US national laboratory used machine learning to filter tens of millions of candidate compounds down to a new battery electrolyte that uses substantially less lithium, and made it in the lab within months. Particle physicists at CERN now run neural networks on custom chips that must decide in a few millionths of a second whether a proton collision is worth keeping. Laboratories around the world are building what they call self-driving labs, in which an algorithm proposes an experiment, a robot performs it, and the result goes straight back to the algorithm to choose the next one. Companies with hundreds of millions of dollars in funding are being founded on the premise that an AI scientist is close at hand. Some of these claims hold up. Some, on inspection, are weaker than the headlines suggested. A few have been publicly challenged by other scientists who went through the results one by one and found that many of the supposedly new materials were not new, were not stable, or were not useful. Sorting the substance from the noise is hard for anyone outside the specialist fields involved, and not always easy for those inside them. The argument of this book This book makes one argument, and uses biology, chemistry and physics to test it. Artificial intelligence does not replace the scientific method. It relocates its bottleneck. For most of the history of experimental science, the slow and expensive step was generating good candidates: a plausible structure, a promising compound, a hypothesis worth testing. A chemist might synthesise a few dozen new materials in a career. A structural biologist might solve a handful of proteins. The checking step, the experiment, was laborious too, but it was matched in pace to the rate at which ideas could be produced. Machine learning changes that balance. Trained on the accumulated results of decades of careful measurement, a model can propose candidates millions at a time and rank them by how likely they are to have the property you want. The search problem becomes a ranking problem. When that works, it works spectacularly, and the cases where it works share three features. There is a large, carefully curated body of past measurements to learn from. There is a well-defined target that can be scored. And there is a fast, trustworthy way to check what the model proposes. Protein structure prediction had all three: the Protein Data Bank, built over fifty years by thousands of crystallographers; a precise geometric target; and a blind competition that had been testing predictions against unpublished experimental structures since 1994. Where one of the three is missing, the results tend to disappoint, and the disappointment usually arrives at the verification step, when somebody tries to make, measure or reproduce what the model promised. The consequence is that the value of AI in science is set less by the cleverness of the model than by the quality of the data it learned from and the experiments that check it. That sounds like a modest claim. It is not. It means that the institutions which look least glamorous, the databases, the benchmark competitions, the instrument facilities, the people who measure things carefully, become more important as AI becomes more capable, not less. It also means that the most consequential questions about AI in science are not about whether a model can generate an answer, but about who checks the answer, how, and how quickly. What the book covers The chapters move through three sciences in an order that follows the argument rather than the disciplines. The first two chapters are about AlphaFold, because it is the cleanest example of the conditions under which AI succeeds and because its limits are now well enough understood to be instructive. Chapter 1 explains what the protein folding problem is, why it resisted solution for so long, and what AlphaFold 2 actually did. Chapter 2 follows what happened next: the release of predicted structures for nearly every known protein, the extension to complexes with DNA, RNA and drug molecules in AlphaFold 3, the turn from predicting proteins to designing them, and the places, from flexible proteins to drug discovery, where the predictions run out. Chapters 3 and 4 move to materials, where the description of this book promises an account of generative models designing new alloys for batteries. Chapter 3 explains how generative and screening models search the space of possible crystals, and why a computed prediction that a material is stable is a long way from a material anyone can make. Chapter 4 takes batteries as its test case, covering alloys, electrolytes and electrodes, and the self-driving laboratories that are supposed to close the gap between prediction and synthesis, including the dispute over whether one of the most prominent of them did what it claimed. Chapters 5 and 6 turn to physics. Chapter 5 is about the Large Hadron Collider and the problem of filtering signal from noise when an experiment produces far more data than can ever be stored, a setting where machine learning has been in routine use for longer than almost anywhere else in science. Chapter 6 follows AI inside physics instruments more broadly: fast simulation, the tuning of accelerators, the control of fusion plasmas, and the statistical care needed when a neural network becomes part of a measurement. Chapter 7 covers chemistry in the narrow sense: predicting reactions, planning syntheses, and the large language model agents that can now read a procedure, write the code to run a robot, and report the result. Chapter 8 gathers the ways AI results in science go wrong, from data leakage and flattering benchmarks to physically impossible outputs, and treats verification as a discipline in its own right. The conclusion asks what follows for scientists, for funders and for the institutions that hold science together. What the book leaves out This is a short book, and it declines to cover a great deal. It does not survey AI in medicine, where questions of clinical evidence and regulation would need a book of their own, though it touches on drug discovery where AlphaFold's story leads there. It does not cover weather and climate modelling, astronomy or genomics in any depth, despite important work in all three. It does not explain the mathematics of neural networks beyond what is needed to follow the science. And it does not try to predict when, or whether, an artificial system will make a discovery entirely unaided. That question is interesting but premature; the more useful question is what the systems we already have are doing to the way discoveries are made, and that is the one this book tries to answer. The reader it has in mind is curious and intelligent but not a specialist: a scientist in one field wondering what is happening in another, a policymaker or funder deciding where to put money, a student choosing a direction, or anyone who has read a headline announcing that AI has discovered something and wanted to know whether to believe it. By the end such a reader should be able to ask the three questions that sort the real advances from the inflated ones. What did the model learn from? What exactly was it asked to produce? And who checked the result, against what? Chapter 1: Fifty Years of a Grand Challenge A protein begins life as a chain. Inside a cell, a ribosome reads a strand of messenger RNA and joins amino acids together one at a time, in an order dictated by a gene. There are twenty kinds of amino acid in the standard set, and a typical human protein strings together a few hundred of them. As the chain emerges it does not stay a chain. Within milliseconds to seconds, most proteins collapse into a specific, intricate three-dimensional shape: helices packed against sheets, loops arranged around pockets, the whole thing folded so precisely that atoms in distant parts of the sequence end up a few tenths of a nanometre apart. That shape is what lets the protein do its job. An enzyme's shape holds a reactive group in exactly the right place to cut a bond. An antibody's shape fits a particular surface on a virus. A channel protein's shape forms a pore that lets potassium through but not sodium. Knowing the shape of a protein is therefore close to knowing how it works, and for the whole of modern molecular biology finding that shape has been slow and hard. This chapter explains why, what DeepMind's AlphaFold 2 did about it, and why the conditions behind its success matter as much as the model itself. The problem and why it resisted solution The idea that a protein's sequence determines its structure has a precise origin. In experiments in the late 1950s and early 1960s, Christian Anfinsen at the US National Institutes of Health took the enzyme ribonuclease, unfolded it with chemicals until it lost all activity, and then removed the chemicals. The protein refolded on its own and regained its function. The information needed to reach the folded state, he concluded, is contained in the amino acid sequence. Anfinsen shared the 1972 Nobel Prize in Chemistry for this work, and his result turned a biological question into what looked like a physics problem. If the sequence determines the structure, then in principle the structure can be computed from the sequence. In principle. In 1969 the biophysicist Cyrus Levinthal pointed out the difficulty that bears his name. A chain of a hundred amino acids has an astronomical number of possible conformations, because every link in the backbone can rotate. If a protein found its shape by trying them in turn, even at a rate of trillions per second, it would take longer than the age of the universe. Real proteins fold in seconds, so they cannot be searching at random; the energy landscape must funnel them towards the right answer. But a computer trying to reproduce that process faces the same vast space without the physical shortcuts, and it must also calculate the energy of each conformation accurately enough to tell the right fold from millions of nearly right ones. The forces involved, hydrogen bonds, the tendency of oily side chains to hide from water, electrostatic attraction and repulsion, are individually weak and collectively decisive. Small errors in modelling them add up to the wrong fold. So for decades the reliable route was experimental. X-ray crystallography, which yielded the first protein structure, John Kendrew's myoglobin, in 1958, requires persuading a protein to form a well-ordered crystal and then interpreting how that crystal diffracts X-rays. Many proteins refuse to crystallise. Membrane proteins, which sit in the oily layer surrounding cells and include many drug targets, are notoriously difficult. Nuclear magnetic resonance spectroscopy works for smaller proteins in solution. From around 2013 a third method, cryo-electron microscopy, underwent what its practitioners called a resolution revolution, as better detectors and software allowed it to image frozen proteins at near-atomic detail; its developers received the Nobel Prize in Chemistry in 2017. All three methods are expensive, specialised and slow. Solving a single difficult structure could take a doctoral student their entire degree. Meanwhile the number of known protein sequences exploded. Genome sequencing became cheap in the 2000s, and the sequence databases grew into the hundreds of millions of entries. The number of experimentally determined structures grew too, but far more slowly. The gap between sequences we could read and shapes we understood widened every year. Fifty years of partial answers Computational biologists attacked the gap from several directions, and each partial success contributed something AlphaFold would later rely on. The first approach was physical simulation: model every atom and the forces between them, and let the protein fold on the computer. Molecular dynamics has become an indispensable tool for studying how proteins move, and in 2010 a purpose-built supercomputer designed by D. E. Shaw Research succeeded in folding a number of small, fast-folding proteins from scratch. But the approach did not scale to the large, slow-folding proteins that matter most in biology, and the force fields it depends on remain approximations. The second approach was homology modelling. Proteins that share an evolutionary ancestor usually share a fold, even after their sequences have diverged considerably. If a new sequence resembles one whose structure is already known, the known structure can serve as a template. This works well when a close relative exists and fails when none does. The third approach, associated above all with David Baker's Rosetta software, assembled structures from short fragments borrowed from known proteins and searched for low-energy arrangements using a carefully tuned scoring function. Rosetta became one of the most widely used tools in the field, and Baker's group used it not only to predict structures but, from the early 2000s, to design entirely new proteins. It even became a game: Foldit, released in 2008, invited members of the public to fold proteins by hand, and some players found solutions the algorithms had missed. The fourth idea arrived around 2011 and proved decisive. It came from evolution. Suppose two amino acids sit next to each other in a folded protein. If a mutation changes one of them, the fold may be disrupted unless the other changes in a compatible way. Over evolutionary time, then, positions that touch in three dimensions tend to mutate together. By lining up thousands of related sequences from different organisms, a so-called multiple sequence alignment, and looking for pairs of positions whose variations are correlated, researchers could infer which parts of the chain are in contact. Statistical methods developed by several groups, including Debora Marks, Chris Sander and colleagues, separated direct contacts from indirect correlations well enough to guide structure prediction. The genome sequencing boom, which had created the gap between sequences and structures, turned out to contain information that could help close it. By the late 2010s, deep learning had entered the field. Groups including Jinbo Xu's showed that convolutional neural networks, borrowed from image recognition, could predict contact maps from sequence alignments more accurately than statistical methods. Progress was real but incremental. The competition that kept everyone honest None of this progress could have been measured without CASP. The competition was founded in 1994 by John Moult and Krzysztof Fidelis, and its design is the single most important reason the AlphaFold result was believed. Every two years, CASP collects the sequences of proteins whose structures experimentalists have just solved but not yet published. Prediction groups receive the sequences and submit their models blind. Once the experimental structures are released, independent assessors compare the predictions with reality. The main score, the global distance test or GDT, measures roughly what percentage of a protein's amino acids are placed within a set of distance thresholds of their true positions, on a scale from 0 to 100. A score around 90 is generally regarded as competitive with an experimental structure. Blind assessment matters because it removes the most common way computational results flatter themselves. A model tested on data its developers have already seen, or could have seen, will always look better than it is. CASP made that impossible. It also created a shared record of how the whole field performed over time. For most of its history, the best scores on the hardest targets, proteins with no close relatives of known structure, stalled at levels far below experimental accuracy. At CASP13 in 2018, a DeepMind team entered a first version of AlphaFold and came top. Its key move was to predict not just whether two residues were in contact but a full probability distribution over the distance between every pair, then fold the chain by optimising against those distances. It was a clear improvement, but not a solution. What AlphaFold 2 did At CASP14 in 2020, AlphaFold 2 achieved a median GDT of about 92 across all targets and close to 90 even on the hardest category. The assessors judged that around two-thirds of its predictions were competitive with experimental structures. In some cases the prediction was arguably more reliable than the experimental model it was being judged against, and in at least one case the prediction helped experimentalists resolve a structure they had been struggling with. The paper describing the system, by John Jumper and colleagues, appeared in Nature in July 2021 along with the source code. The system was not a single new trick but a carefully engineered combination of ideas, several of which had been in the field for years. Understanding its broad architecture explains both why it worked and where it fails. AlphaFold 2 takes as input the target sequence, a multiple sequence alignment of evolutionary relatives found by searching large databases, and, where available, structural templates from the Protein Data Bank. It builds two internal representations. One describes the alignment: for each related sequence and each position, a vector of learned features. The other describes pairs: for every pair of positions in the target, a vector encoding what the network currently believes about their relationship. The core of the network, which the authors called the Evoformer, repeatedly passes information between these two representations. Evolutionary signals in the alignment update the beliefs about pairs; the beliefs about pairs reshape how the alignment is read. Crucially, the network is built to reason geometrically about triangles of residues. If A is close to B and B is close to C, that constrains how close A can be to C. Updates that respect these triangle relationships let the network build a self-consistent picture of distances. A second component, the structure module, then turns this picture into explicit three-dimensional coordinates. It treats each amino acid as a rigid body with a position and orientation, and uses an attention mechanism designed so that its outputs do not change if the whole protein is rotated or moved, which is physically correct: a protein's structure does not depend on where it sits in space. The whole system is trained end to end, so the loss on the final atomic positions shapes every earlier layer. And the output is fed back in for several further passes, a process called recycling, which lets the network refine its answer. Just as important for working scientists, AlphaFold 2 reports its own confidence. Each residue gets a score called pLDDT, from 0 to 100, estimating how accurately its local environment has been predicted. A separate output, the predicted aligned error, estimates how confident the model is in the relative position of any two parts of the structure, which tells a user whether two domains are placed correctly with respect to each other or merely each folded correctly on their own. These confidence measures turned out to be well calibrated, and they are the reason the predictions could be used responsibly: a biologist can see at a glance which parts to trust. Why it worked when it did It is tempting to tell this story as one of algorithmic genius, and the engineering was genuinely exceptional. But the conditions that made it possible are the more useful lesson, because they recur in every successful case in this book. The first condition was data. AlphaFold 2 learned from the Protein Data Bank, an archive founded in 1971 with seven structures and grown, by the time of training, to well over 150,000. Every entry represents months or years of experimental work, deposited under community rules that require coordinates and supporting data to be made public, checked by curators against agreed standards. It is one of the great collective achievements of twentieth-century science, and it was built for reasons that had nothing to do with machine learning. AlphaFold also drew on public sequence databases holding hundreds of millions of sequences, the product of another generation of shared infrastructure. Without these resources there would have been nothing to learn from. The second condition was a well-defined target. The structure of a protein, at least its dominant folded state, is a set of atomic coordinates. A prediction can be scored precisely against it. There is no ambiguity about what a right answer looks like, which is not true of most questions in biology. The third condition was a trustworthy check. CASP's blind format meant that when AlphaFold 2 scored 92, nobody had to take DeepMind's word for it. The field had a quarter of a century of comparable scores to set it against, and the assessors were independent. Within months, experimentalists around the world were testing the released code on their own unpublished proteins and reporting the same accuracy. Remove any one of these and the story changes. A model trained on a small or biased dataset would have learned less. A fuzzier target would have made success hard to define. A result announced without blind assessment would have met justified scepticism, as some later claims in this book did. AlphaFold succeeded on a problem that had been prepared for it, unwittingly, by fifty years of careful public science. What it did not do Two clarifications prevent common misunderstandings. AlphaFold 2 did not solve protein folding in the sense of explaining how proteins fold. It predicts where a protein ends up, not the pathway it takes to get there, and it does so by pattern recognition over evolutionary and structural data rather than by simulating physics. It has no explicit model of the forces Anfinsen and Levinthal were thinking about. That is why, as Chapter 2 discusses, it struggles with exactly those proteins whose behaviour depends on physics not captured in evolutionary statistics: proteins that switch between shapes, proteins that have no fixed shape at all, and the effects of single mutations. Nor did it predict structure from a single sequence. It relies heavily on the multiple sequence alignment, and its accuracy drops when a protein has few known relatives. Proteins from poorly studied lineages, and designed proteins with no evolutionary history, are harder for it. Later language-model-based approaches, such as Meta's ESMFold, which learns from hundreds of millions of single sequences without needing explicit alignments, traded some accuracy for speed and reduced this dependence, but did not remove the underlying point: the models are distilling patterns from life's existing diversity. These limits do not diminish the achievement. They define it. AlphaFold 2 turned a slow experimental measurement into a fast computational prediction for the large class of proteins that resemble, in their evolutionary statistics, the proteins already studied. That was enough to change structural biology, and the next chapter describes how. Chapter 2: After the Breakthrough A scientific result changes a field in two ways. The first is direct: people use it. The second is indirect: it changes what people think is possible, and therefore what they try next. AlphaFold did both, and within five years the indirect effect was arguably the larger. This chapter follows both, and then turns to the places where the predictions stop being reliable, because knowing where a tool fails is what makes it safe to use. Two hundred million structures In July 2021, alongside the publication of AlphaFold 2, DeepMind and the European Bioinformatics Institute (EMBL-EBI) launched the AlphaFold Protein Structure Database with predicted structures for nearly the entire human proteome and those of around twenty other organisms widely used in research. A year later they expanded it to more than 200 million entries, covering almost every protein sequence catalogued in UniProt, the main public protein sequence database. The predictions were released free, with confidence scores attached, under an open licence. The scale is hard to take in. The Protein Data Bank had accumulated around 200,000 experimental structures in fifty years, many of them repeated determinations of the same proteins. Overnight, researchers had a structural model, of varying quality, for nearly any protein they cared about. For a parasitologist studying an obscure enzyme from a tropical pathogen, or a plant biologist working on a crop protein no crystallographer had ever touched, this was transformative. The question was no longer whether a structure existed but how far to trust the one in front of them, and the per-residue confidence scores answered that directly. Meta's ESM Metagenomic Atlas, released in 2022, went further in a different direction, predicting structures for hundreds of millions of proteins identified only from environmental DNA, sequences from soil, seawater and gut microbes whose organisms had never been grown in a laboratory. Much of that collection was low confidence, but it gave the first glimpse of the structural diversity hidden in the parts of the tree of life nobody had studied. How working scientists used it The direct uses fall into a few patterns, and seeing them clarifies what kind of tool AlphaFold actually is. The most common is as a starting point for experiment. Crystallographers had long used a technique called molecular replacement, in which a structure of a similar protein is used to interpret new diffraction data. AlphaFold models turned out to be excellent for this, often better than any available experimental relative. Structures that had sat unsolved for years because the data could not be interpreted were completed in days. Cryo-electron microscopists similarly began fitting predicted models into their density maps, especially at lower resolution where building an atomic model from scratch is guesswork. The most spectacular example of this combination came in 2022, when several groups published models of the human nuclear pore complex, a gigantic assembly of around a thousand protein copies that controls traffic in and out of the cell nucleus. Cryo-electron tomography provided the overall shape at modest resolution; AlphaFold supplied confident models of the individual components and many of their interfaces; the two together produced a far more complete picture than either could alone. Neither the experiment nor the prediction was sufficient. The combination was. A second pattern is hypothesis generation. A biologist with a gene of unknown function can look at the predicted structure, recognise a fold associated with a particular enzymatic activity or binding behaviour, and design experiments accordingly. A third is in vaccine and antibody research, where a predicted structure can show which parts of a pathogen's surface protein are exposed and stable enough to target. Researchers at Oxford working on a malaria transmission-blocking vaccine candidate, for example, used AlphaFold predictions alongside experimental data to understand a parasite protein's structure and choose where antibodies might bind. In each case, the prediction did not replace the experiment. It made the experiment faster, cheaper and better aimed. That is the pattern this book returns to repeatedly. Reading a prediction responsibly Because the predicted structures arrived in such numbers, the most practical skill they demanded was not running AlphaFold but reading its output. The database colours each residue by its confidence score, and the bands it uses are a reasonable working guide. Residues with a pLDDT above 90 are modelled with high accuracy, often good enough to reason about the positions of individual side chains in an active site. Between 70 and 90 the backbone is usually right but details may not be. Between 50 and 70 the model is uncertain, and below 50 the region is probably disordered or simply unpredictable from the available information. A typical predicted human protein is a patchwork: confident folded domains connected by low-confidence linkers and flanked by floppy tails. The predicted aligned error adds a second layer that users often overlook. Two domains can each be predicted with high pLDDT while their relative orientation is essentially a guess. A structure displayed on a screen looks equally solid everywhere, and a researcher who measures the distance between two residues in different domains without consulting the error matrix may be measuring an artefact. The same applies to complexes, where the confidence in an interface between two proteins is distinct from the confidence in each protein alone. There are further traps. A predicted structure shows a protein in isolation, without the partners, ions, cofactors or membranes that shape it in the cell. Sometimes the model places side chains as though a ligand were present, because the training structures usually had one bound, and sometimes it does not. A pocket that looks open in the prediction may be closed in reality, or the reverse. None of this makes the predictions unreliable; it makes them hypotheses with stated error bars, which is exactly how a careful scientist treats any measurement. What happened to structural biologists An early worry was that AlphaFold would make experimental structural biology obsolete. The opposite happened, or at least the field changed direction rather than shrinking. With single-protein structures widely available, experimentalists turned to the questions predictions cannot answer: how large assemblies fit together, how proteins move between states, what they look like inside intact cells. Cryo-electron tomography, which images proteins in thin slices of frozen cells, became one of the fastest-growing areas, precisely because prediction made it easier to interpret the blurry shapes it reveals. Time-resolved crystallography, which captures proteins mid-reaction using ultra-short X-ray pulses, asks questions about dynamics no static prediction addresses. The experimental record also gained a new importance. Every major model since AlphaFold 2 has been trained on the Protein Data Bank, and the frontier problems, protein–drug complexes, nucleic acids, conformational change, are limited by how many good experimental examples exist. Structural biologists who once spent years solving individual proteins increasingly see their work as producing the data that the next generation of models will learn from. The bottleneck relocated, and the people at the new bottleneck became more valuable rather than less. From prediction to complexes and design The successors to AlphaFold 2 pushed in two directions: from single proteins to the molecular assemblies they form, and from predicting nature's proteins to designing new ones. The main systems and their scope are set out in Table 1. Table 1. Major structure prediction and design systems and what each extended. System Developer, year What it predicts or produces Main extension AlphaFold 2 DeepMind, 2020–21 Single protein chains Near-experimental accuracy on most targets RoseTTAFold Baker lab, 2021 Proteins and protein complexes Openly developed, comparable approach AlphaFold-Multimer DeepMind, 2021 Multi-chain protein complexes Interfaces between proteins ESMFold Meta, 2022 Single chains from sequence alone Speed; no alignment needed RFdiffusion Baker lab, 2023 New protein backbones Generative design to a specification AlphaFold 3 Google DeepMind and Isomorphic Labs, 2024 Proteins with DNA, RNA, ligands, ions Broad biomolecular complexes Source: Jumper et al. 2021; Baek et al. 2021; Evans et al. 2021; Lin et al. 2023; Watson et al. 2023; Abramson et al. 2024. AlphaFold 3, published in Nature in May 2024, was the more radical change in architecture. Rather than the structure module of its predecessor, it uses a diffusion model, the same family of generative techniques behind image generators. Diffusion models learn to remove noise: during training, real structures are progressively blurred with random displacements and the network learns to reverse the process; at prediction time it starts from noise and refines towards a structure consistent with the input. This allowed AlphaFold 3 to handle not just proteins but DNA, RNA, small drug-like molecules, metal ions and chemical modifications in a single framework. On the problem of predicting how a small molecule sits in a protein's binding pocket, the authors reported that it substantially outperformed traditional docking programs on a benchmark designed to catch physically implausible predictions. The switch to a generative model brought a new failure mode. Diffusion models can produce confident-looking structure where none exists. In regions of a protein that are naturally disordered, AlphaFold 3 sometimes generated tidy helices that do not occur in reality, a behaviour its authors acknowledged and partly mitigated by training on AlphaFold 2 predictions, which tend to render disordered regions as obviously unstructured loops. It is a small but telling example of a theme that will recur: generative models produce plausible outputs, and plausibility is not truth. Access was also contested. AlphaFold 3 was initially available only through a web server with restrictions on use, without released code, which drew public criticism from researchers who argued that a paper in a major journal should be reproducible. The code and model weights were released for academic use in November 2024. Meanwhile academic and commercial groups built open reproductions and alternatives, a sign of how quickly the field had absorbed the ideas. The design direction is the one most likely to matter in the long run. Prediction asks: given this sequence, what shape? Design asks the inverse: given a shape or a function I want, what sequence will produce it? Baker's laboratory had pursued design with physics-based tools for two decades. Deep learning accelerated it dramatically. RFdiffusion, published in 2023, generates new protein backbones conditioned on a specification, such as a shape that wraps around a particular site on a target protein. A companion network, ProteinMPNN, then proposes amino acid sequences likely to fold into each backbone, and AlphaFold or a similar predictor is used as a filter to check whether the designed sequence is predicted to fold as intended. Only the designs that pass are made in the lab. That pipeline is a compact illustration of this book's argument. Three models generate and screen candidates at enormous speed, and the experiment at the end decides. Success rates for designed binders, proteins built to stick to a chosen target, rose from a fraction of a percent with older methods to levels at which a laboratory could test a few dozen designs and expect some to work. Designed binders against snake venom toxins, published by Baker's group and collaborators in 2025, protected mice from otherwise lethal doses in experiments, a striking demonstration of what the approach can deliver when the check is real. The 2024 Nobel Prize in Chemistry recognised both directions: half to Baker for computational protein design, half jointly to Hassabis and Jumper for structure prediction. Where the predictions run out The limits of AlphaFold are not a footnote. They follow directly from how it learned, and anyone using the predictions needs to know them. The first limit is that AlphaFold predicts one structure, and many proteins have more than one. Proteins are machines, and machines move. Transporters alternate between conformations that open to one side of a membrane and then the other. Some proteins, called fold-switchers, adopt entirely different folds under different conditions. Studies of such proteins found that AlphaFold 2 usually predicts only one of the states, typically the one better represented in the training data. Researchers have devised workarounds, such as subsampling the sequence alignment to push the model towards alternative states, but these are explorations, not reliable predictions of the conformational ensemble that governs function. The second limit is disorder. A substantial fraction of the human proteome, by many estimates around a third of all residues, lies in regions that have no fixed structure at all. These intrinsically disordered regions are often functionally important, mediating signalling and regulation through transient contacts. AlphaFold 2 assigns them low confidence scores, which is the right answer, and its low-confidence output has even proved a useful predictor of disorder. But it says little about how these regions behave. The third limit is mutation. Because AlphaFold learns from evolutionary patterns, it is largely insensitive to a single changed amino acid, which may produce the same predicted structure as the original. Yet a single change is exactly what causes many genetic diseases. Studies testing AlphaFold 2 directly on whether it could predict the structural effects of missense mutations found it could not, in general. DeepMind's response was a different model built on AlphaFold's internal representations, AlphaMissense, published in Science in 2023, which classifies possible single amino acid changes in human proteins as likely pathogenic or likely benign. Its predictions for around 71 million variants have become a resource for clinical geneticists, but they are a calibrated estimate of pathogenicity, not a structural explanation, and the authors were careful to present them as supporting evidence rather than diagnosis. The fourth limit concerns everything outside the training distribution: proteins with few relatives, designed proteins unlike anything in nature, complexes involving unusual chemistry. Accuracy drops, and while the confidence scores usually fall in step, they are not infallible. The drug discovery question Much of the public excitement about AlphaFold concerned medicine, and here a sober assessment is necessary. Knowing a protein's structure has long been useful in drug design, and better predictions, especially of how small molecules bind, help. But structure was rarely the main reason drugs failed. Most candidate drugs that enter clinical trials fail because they do not work well enough in people or because they cause unacceptable side effects, and those failures arise from biology far more complex than a binding pocket: which target is worth hitting at all, how the drug is absorbed and metabolised, what else it binds, how the disease actually progresses. Isomorphic Labs, spun out of DeepMind in 2021 to pursue drug discovery, signed partnerships with Eli Lilly and Novartis in 2024 and raised substantial outside investment in 2025, but by its own account the timeline for its first candidates to enter human trials slipped. That is not a failure; it is how drug development works. The more interesting point is structural. AlphaFold accelerated a step in drug discovery that was already relatively fast compared with the steps that dominate cost and time. Relocating the bottleneck does not remove it. In drug discovery the bottleneck has moved, as it always tends to, to the slowest and most expensive form of verification: the clinical trial. The lesson of the first case AlphaFold is the best case for AI in science, and its story sets the terms for the rest of this book. It succeeded on a problem with abundant curated data, a precise target and an honest check. It changed practice not by replacing experiment but by making experiment faster and better aimed. It spawned generative design methods whose output is only as good as the filters and laboratory tests applied to it. And its limits fall exactly where the training data is thin or the physics it never learned becomes decisive. The next two chapters take the same ideas into materials science, a field that would very much like its own AlphaFold and has been tempted to announce one. The conditions there are less favourable, and the difference is instructive. Chapter 3: Searching the Space of Possible Materials Almost every technology that matters to the energy transition is limited by a material. Batteries are limited by how much lithium their electrodes can hold and how quickly ions can move through their electrolytes. Solar cells are limited by how efficiently a semiconductor turns light into current and how long it survives in the sun. Catalysts that could make fertiliser or fuel with less energy are limited by surfaces that bind the right molecules just strongly enough. In each case, a better material would change the economics of an entire industry, and in each case the space of possible materials is so vast that nobody has searched more than a sliver of it. That combination, enormous value and an unsearched space, makes materials science an obvious target for the methods that worked on proteins. This chapter explains how machine learning searches for new materials, what the most prominent efforts have claimed, and why a computed prediction that a material is stable is the beginning of the work rather than the end. The size of the search An inorganic crystal is defined by which elements it contains, in what proportions, and how the atoms are arranged in a repeating unit called the unit cell. There are around ninety elements stable enough to be useful. Combinations of two elements are manageable to enumerate; combinations of four or five, in varying ratios and arrangements, are effectively unlimited. Experimental databases such as the Inorganic Crystal Structure Database hold a few hundred thousand entries accumulated over a century, and many of those are variations on the same few thousand structural themes. Searching this space by synthesis is slow. A solid-state chemist might make a new compound by grinding powders together, heating them in a furnace, and analysing the product by X-ray diffraction, a cycle that takes days and frequently yields something other than what was intended. Over a career, the number of genuinely new compounds any one person makes is small. The first computational shortcut came from quantum mechanics. Density functional theory, or DFT, is a method for calculating the energy of an arrangement of atoms from first principles, approximately but usefully. It became the workhorse of computational materials science in the 1990s and 2000s. Given a candidate crystal, DFT can estimate its energy and therefore whether it is likely to be stable compared with other combinations of the same elements. The key concept here is the convex hull. Imagine plotting the energy of every known compound in a chemical system, say lithium, iron and oxygen, against its composition. The lowest-energy compounds at each composition define a surface, the hull. A new candidate whose computed energy lies on or below that surface is thermodynamically stable: it should not spontaneously decompose into a mixture of other compounds. One that lies above it is metastable or unstable, and the height above the hull, measured in electron-volts per atom, is a rough measure of how unstable. Many useful materials are in fact slightly metastable, which is one of several reasons the hull is a guide rather than a verdict. From around 2011, projects such as the Materials Project, founded by Gerbrand Ceder and Kristin Persson, along with the Open Quantum Materials Database and AFLOW, ran DFT calculations systematically on tens and then hundreds of thousands of known and hypothetical compounds and made the results public. These databases did for computational materials science something like what the Protein Data Bank did for structural biology: they created a large, consistent, openly available body of results to learn from. The difference, which matters a great deal, is that the Protein Data Bank contains measurements, while these databases contain calculations. A model trained on them learns to reproduce DFT, approximations included. Screening and generating Machine learning entered this field in two broad modes, and the distinction between them is central to understanding the claims made since. The first mode is screening. A model is trained to predict a property, such as energy above the hull, from a description of a crystal. Because a trained neural network can evaluate a candidate in a fraction of a second, against hours of supercomputer time for DFT, it can be used to filter millions of hypothetical structures and send only the most promising to DFT for confirmation. The candidates themselves are generated by simple rules: take known structures and substitute chemically similar elements, or assemble random arrangements under symmetry constraints. The second mode is generation. Instead of enumerating candidates by rule and filtering them, a generative model learns the distribution of plausible crystal structures and samples new ones directly, ideally steered towards a desired property. This is the materials counterpart of RFdiffusion in protein design: ask for a crystal with a particular property, and the model proposes structures that might have it. A third development, less visible in headlines but arguably more important to working scientists, is the universal machine learning interatomic potential. These are models trained to predict the energies and forces of arbitrary arrangements of atoms across most of the periodic table, so that they can stand in for DFT in simulations of how a material behaves at finite temperature, how ions move through it, or how it responds to strain. Models with names such as M3GNet, CHGNet and MACE-MP-0, released between 2022 and 2024, made simulations practical that had previously been too expensive to attempt at scale. Table 2 compares the four approaches. Table 2. Four computational approaches to finding new inorganic materials. Approach How candidates arise What the model predicts Typical check Main weakness High-throughput DFT Rule-based enumeration None; direct calculation Synthesis of top hits Slow; limited by compute ML-accelerated screening Substitution and random search Stability from structure DFT, then synthesis Inherits DFT's blind spots Generative models Sampled from learned distribution Structures with target properties DFT, then synthesis Novelty and realism hard to verify Universal ML potentials Supplied by other methods Energies and forces for simulation Comparison with DFT and experiment Errors outside training data How a network sees a crystal The models behind most of this work share an architectural idea worth understanding, because it explains both their strengths and their characteristic failures. A crystal is represented as a graph: each atom is a node, and atoms within a certain distance of each other are joined by edges, with the repeating nature of the crystal handled by connecting atoms across the boundaries of the unit cell to their neighbours in the adjacent copy. Each node starts with a description of its element, and each edge with the distance between the atoms it connects. The network then passes messages along the edges. In each round, every atom updates its description by combining information from its neighbours, so that after several rounds an atom's representation reflects not only its own identity but the arrangement of atoms around it out to some distance. Finally, these local representations are combined into a prediction for the whole crystal, such as its energy per atom. Because the prediction is built from local environments, a network that has learned what stable environments look like for, say, oxygen surrounded by four magnesium atoms can transfer that knowledge to new crystals containing similar environments. This locality is the source of both power and weakness. It lets the models generalise across chemistry in a way that resembles a chemist's intuition about bonding preferences. But properties that depend on long-range effects, such as the subtle electronic interactions in many magnetic and strongly correlated materials, or the behaviour of charged defects, are harder for such models to capture. And a model that has seen many examples of one kind of local environment and few of another will be confident where it has data and unreliable where it does not, which in materials terms means reliable for well-studied chemistries and less so for the unusual combinations where genuinely new materials might be found. The GNoME announcement In November 2023, Google DeepMind published in Nature the results of a project called GNoME, short for Graph Networks for Materials Exploration. It was the largest exercise in ML-accelerated screening to date, and its headline claim was that it had discovered 2.2 million new crystal structures, of which around 380,000 were predicted to be stable, lying on the updated convex hull. The paper presented this as an order-of-magnitude expansion of the known stable materials. The method combined graph neural networks, which represent a crystal as a network of atoms connected by bonds, with an active learning loop. Candidates were generated by substitution and by random structure search; the networks predicted their stability; the most promising were checked with DFT; and the DFT results were added to the training data, improving the networks for the next round. Over several rounds, the fraction of candidates that DFT confirmed as stable rose substantially, showing that the models were genuinely learning. The authors also reported that several hundred of the predicted structures had been independently synthesised by other researchers, and that the trained models served as accurate interatomic potentials. They released the stable structures publicly. In the same issue, a team at Lawrence Berkeley National Laboratory led by Gerbrand Ceder reported on the A-Lab, an autonomous laboratory that attempted to synthesise targets drawn partly from the Materials Project and GNoME data, claiming to have made 41 new compounds out of 58 targets over 17 days of continuous operation. Chapter 4 returns to that work and the dispute it provoked. The critics' reading Within months, the GNoME results drew a careful public critique. In a perspective published in Chemistry of Materials in 2024, the solid-state chemists Anthony Cheetham and Ram Seshadri examined a random sample of the predicted stable compounds by hand. They reported that a large proportion contained combinations of elements that were exotic, expensive or radioactive, that many were close variants of known structures rather than new structural types, and that they found little evidence in the sample of materials with obvious utility. Their argument turned on a distinction chemists care about: a compound is a combination of elements in a structure, while a material is a compound with a useful property that someone can make reliably. GNoME, in their reading, had predicted compounds. Whether it had discovered materials was unproven. Other critics raised a technical point. DFT calculations, and therefore models trained on them, usually describe a perfectly ordered crystal at a temperature of absolute zero. Real materials made at high temperature often have disordered arrangements, with different elements sharing the same sites at random. A structure predicted to be new and ordered may correspond, in reality, to a known compound in its disordered form. This is not a quibble. It goes to whether a prediction counts as a discovery at all. The fairest summary is that both sides were right about different things. GNoME demonstrated that machine learning can screen inorganic chemistry at a scale and accuracy, relative to DFT, that was not possible before, and its models and data became useful tools. What it could not demonstrate, because no computational method can, was that its predictions were materials in the chemist's sense. The word discovery, used in the headlines, claimed the verification step without having done it. Generative design and MatterGen Generative models for crystals developed in parallel. Early systems in 2021 and 2022 adapted variational autoencoders and diffusion models to the peculiar geometry of crystals, which repeat periodically in three dimensions and can be described by the same structure in many equivalent ways. The most prominent result came from Microsoft Research, whose model MatterGen was published in Nature in January 2025. MatterGen is a diffusion model that jointly generates the types of atoms, their positions, and the shape of the repeating unit cell. A base model is trained on several hundred thousand stable structures from the Materials Project and a related database. It can then be fine-tuned, using small adapter modules, to steer generation towards particular targets: a chemical system, a symmetry, a magnetic property, or a mechanical property such as bulk modulus, which measures resistance to compression. The authors reported that MatterGen produced stable, new structures at a substantially higher rate than earlier generative models, and that steering towards a target property was more efficient than screening a large pool of candidates for it. As a proof of concept, the team and collaborators in China synthesised one generated material, a tantalum chromium oxide designed to have a bulk modulus of 200 gigapascals. The measured value was around 169, within about 20 per cent of the target. Critics pointed out that the synthesised sample was disordered, so that the experimental material was not quite the ordered structure the model had generated, and that compounds of this composition had appeared in earlier literature. The authors had themselves acknowledged the disorder. The episode illustrates the same gap as GNoME at a smaller scale: the generative step works, and the claim of novelty depends on details that only careful experimental chemistry can settle. The gap between stable and synthesisable The deepest problem facing all of these methods is that thermodynamic stability is neither necessary nor sufficient for a material to be made. It is not sufficient because synthesis is governed by kinetics as much as thermodynamics. A compound may be the lowest-energy arrangement of its elements and still be practically impossible to reach, because the reactions that would form it are blocked by intermediate phases that form first and are themselves stable. Solid-state chemists spend much of their effort choosing precursors and heating profiles that steer reactions around these traps, and that knowledge lives largely in the experimental literature and in experience, not in DFT databases. It is not necessary because many of the most useful materials are metastable. Diamond is metastable with respect to graphite at room pressure. Many battery electrode materials operate in states that are thermodynamically unstable but kinetically persistent. Filtering strictly for hull stability discards such candidates. Machine learning researchers have tried to address this by training models to predict synthesisability directly, from the record of which compounds have been reported as made, or to predict synthesis recipes from text mined from published papers. These efforts are promising but limited by the data: published papers mostly report successes, so a model learns little about what fails, and the conditions reported are often incomplete. There is also a quieter problem. A model trained on DFT inherits DFT's systematic errors. Some classes of material, notably those with strongly interacting electrons, such as many transition-metal oxides important for batteries and catalysis, are described poorly by standard DFT approximations. A model that predicts DFT energies perfectly will still be wrong about those materials in exactly the ways DFT is wrong. In protein structure prediction, the training data were experimental measurements; in materials prediction, the training data are mostly calculations. That single difference explains much of why materials science has not yet had its AlphaFold moment, and why the verification step carries so much weight. What the search has actually delivered None of this means the effort is wasted. The universal interatomic potentials that emerged from these projects have changed what computational materials scientists can simulate, and benchmarks such as Matbench Discovery, which tests models' ability to identify stable materials in a prospective setting rather than on data resembling their training set, have brought some of CASP's discipline to the field. Screening models now routinely narrow the candidate pool for experimentalists. Generative models let researchers ask for structures with combinations of properties that would never come up by substitution. What these methods produce is a ranked list of candidates, and the ranking is only as good as the energy model behind it. Turning that list into a material requires making things. The next chapter takes batteries as the test case, because it is the field in which the promise is largest, the experimental check is most demanding, and the attempts to close the gap between prediction and synthesis have gone furthest. Chapter 4: Designing Better Batteries A lithium-ion battery is a deceptively simple device. Two electrodes are separated by an electrolyte that lets lithium ions through but blocks electrons. When the battery charges, ions leave the positive electrode, the cathode, travel through the electrolyte and lodge in the negative electrode, the anode; electrons take the long way round through the external circuit. Discharging reverses the journey. Almost everything that matters about a battery, how much energy it stores, how fast it charges, how many cycles it survives, whether it catches fire, comes down to the materials at each step of that journey and, above all, the interfaces between them. Batteries are therefore the natural proving ground for AI in materials science. The value of improvement is enormous, the materials questions are well posed, and decades of research have produced large datasets. But batteries also expose the verification problem in its harshest form. A battery's most important properties only reveal themselves over hundreds or thousands of charge cycles, under real conditions, at interfaces that no bulk calculation describes. This chapter follows AI through the three main components, electrolytes, electrodes and the alloys that increasingly form them, and then through the self-driving laboratories meant to close the loop between prediction and test. Thirty-two million candidates The most widely reported example of AI-driven battery discovery came in January 2024, from a collaboration between Microsoft's Azure Quantum team and Pacific Northwest National Laboratory, a US Department of Energy laboratory with long experience in battery research. Its target was a solid electrolyte, a material that would replace the flammable liquid electrolyte in conventional cells with a solid that conducts ions, improving safety and potentially allowing higher energy density. A secondary goal was to reduce dependence on lithium. The process was a funnel. The team generated about 32 million hypothetical inorganic materials by substituting elements into known crystal structures. Machine learning models predicted their stability and kept roughly half a million that looked thermodynamically plausible. Further models predicted properties relevant to an electrolyte, such as whether the material was electronically insulating and stable at the voltages a battery would impose. Simulations using a machine learning interatomic potential estimated how quickly ions would move through the surviving candidates. Only at the end did the team turn to conventional DFT calculations, and finally to human judgement, to choose a small number for experiment. The screening stages took around 80 hours of cloud computing, a task the participants estimated would have taken years by traditional calculation. From the final shortlist, PNNL chemists synthesised a material in which a substantial share of the lithium in a known class of chloride electrolytes was replaced by sodium, reducing the lithium content by up to around 70 per cent relative to comparable materials. They built a working prototype cell. The news coverage was understandably enthusiastic. Read carefully, the result is both genuine and modest, and the distinction is the lesson. It is genuine because a computational funnel did, in a matter of days, produce a candidate that chemists could make and that worked in a cell. It is modest because the material was a variation on a known family of chloride electrolytes, its ionic conductivity was not reported as better than the best existing solid electrolytes, and its long-term behaviour in a real battery remained to be established. The AI compressed the search. It did not, and could not, compress the months of cycling, interface studies and engineering that decide whether a new electrolyte is useful. The bottleneck moved to the laboratory, exactly as this book's argument predicts. Why the interface defeats the calculation The gap between a promising electrolyte on a shortlist and a useful one in a cell is mostly a story about interfaces, and it explains why battery materials are so hard to verify computationally. A solid electrolyte must conduct lithium or sodium ions quickly, but it must also survive contact with both electrodes. At the anode, especially a lithium metal anode, the electrochemical environment is strongly reducing: it tends to push electrons into whatever it touches. At the cathode, charged to high voltage, the environment is strongly oxidising. Very few materials are thermodynamically stable across the whole window. Sulfide electrolytes, which conduct lithium ions exceptionally well, are reduced by lithium metal and can react with oxide cathodes. Chloride electrolytes, the family the Microsoft and PNNL candidate belonged to, tend to be stable against high-voltage cathodes but are vulnerable at the anode. Oxide electrolytes are more stable but harder to process and often less conductive. What actually happens at an interface is that a thin layer of new compounds forms, an interphase, whose properties decide whether the cell works. If that layer conducts ions but not electrons, it can stabilise the interface and the battery survives. If it conducts electrons, it keeps growing and the battery degrades. The interphase's composition depends on kinetics, temperature, pressure, the exact surface of each material and the history of charging, and it may be only nanometres thick. Bulk stability calculations, and the models trained on them, see none of this. They can estimate the voltage window in which a material should be stable on its own, and they can predict likely decomposition products, which is useful for ruling candidates out. They cannot reliably rule candidates in. Mechanical behaviour adds another layer. Electrodes swell and shrink as ions move in and out. Solid electrolytes cannot flow to maintain contact the way a liquid does, so a cell can lose performance simply because the layers separate. Lithium can force its way along grain boundaries in a ceramic electrolyte and cause a short circuit even when the bulk material looks impenetrable. All of these are properties of the assembled cell, not of a crystal in a database. This is why the experienced battery researchers who reviewed AI-driven screening results tended to be welcoming about the speed and cautious about the claims. The funnel narrows the field from millions to a handful efficiently. The handful must still go through the same slow sequence as any candidate: synthesis, characterisation, conductivity measurement, pairing with electrodes, long-term cycling, and post-mortem analysis of what changed. Machine learning interatomic potentials trained on interface data are beginning to make simulations of interphases more realistic, and that may eventually shift some of this work onto computers. For now, the interface is where the verification step lives. Cost, abundance and scale A further filter matters as much as performance and is easier to build into a model: whether the material can be made cheaply and at scale from elements that are not scarce. Cobalt, used in many high-performance cathodes, is expensive and much of it is mined under conditions that raise serious ethical concerns. Lithium supply has swung between shortage and glut. A material that performs brilliantly but requires tantalum, germanium or a rare earth in large proportions will not reach a car. Screening funnels can impose these constraints from the start, excluding expensive or scarce elements before any calculation is run, and the Microsoft and PNNL work was explicitly motivated by reducing lithium content. Critics of GNoME's output made the same point from the other side: a large proportion of the predicted stable compounds contained elements nobody would use in a commercial product. Building practical constraints into the objective is one of the simplest ways to make a materials search more useful, and it is a decision for the people setting the search, not for the model. Alloys and the closed loop The description of this book mentions designing new alloys for batteries, and alloys are where the combinatorial problem is most acute. An alloy is a mixture of metals, and since the early 2000s metallurgists have been exploring so-called high-entropy alloys, which mix five or more elements in roughly equal proportions rather than adding small amounts of others to a single base metal. The idea, associated with Jien-Wei Yeh in Taiwan and Brian Cantor in Britain, opened a space of compositions far too large for trial and error, and many of these alloys have unusual combinations of properties. Batteries need alloys in several places. Anodes made of silicon, tin or antimony form alloys with lithium and can store several times more charge than conventional graphite, but they swell dramatically as they do so, cracking and losing contact. Mixing in other elements can buffer that expansion. Lithium metal anodes, which promise the highest energy density of all, tend to grow dendrites, needle-like deposits that can short-circuit a cell, and thin alloy layers at the surface can encourage smoother deposition. Sodium-ion batteries, a lower-cost alternative attracting heavy investment, need their own anode materials, again including alloys. Cathodes increasingly use multiple metals in a single layered oxide, and researchers have begun to apply high-entropy design ideas there too, mixing many elements to stabilise the structure through repeated cycling. The general approach to designing such materials with machine learning is best illustrated by an alloy study outside batteries that set a template for the field. In 2022 a team at the Max Planck Institute for Iron Research in Düsseldorf, led by Dierk Raabe, published in Science an active-learning search for high-entropy alloys with very low thermal expansion, a property known as the Invar effect. They combined a generative model to propose compositions, machine learning and physics-based models to predict properties, and actual synthesis and measurement in a loop. Over a few iterations, testing only a few dozen compositions from a space of millions, they found alloys with thermal expansion among the lowest reported for such materials. The key feature was not the generative model on its own but the loop: each experimental result updated the model, which then chose more informative experiments. The statistical engine behind most such loops is a technique called Bayesian optimisation. Its logic is simple to state. Build a model that predicts the property of interest across the space of possible experiments and also says how uncertain it is at each point. Then choose the next experiment by balancing two goals: testing where the model predicts the best result, and testing where it is most uncertain, because that is where a measurement will teach it the most. After each experiment, update the model and repeat. The approach is efficient when experiments are expensive, because it spends them where they carry the most information. Closing the loop on battery testing The slowest step in battery research is not making materials but testing cells, and machine learning has been applied directly to that bottleneck. In 2019 a team from Stanford, MIT and the Toyota Research Institute showed in Nature Energy that a model could predict the eventual cycle life of commercial lithium iron phosphate cells, how many cycles before they degraded significantly, from data recorded in their first hundred cycles, long before failure. A year later, the same collaboration reported in Nature a closed-loop system that used this early prediction together with Bayesian optimisation to search for fast-charging protocols that would not shorten battery life. It evaluated 224 candidate protocols in 16 days, a search the authors estimated would otherwise have taken more than 500 days. At Carnegie Mellon University, a team led by Venkat Viswanathan and Jay Whitacre built a robotic system, nicknamed Clio, that mixed liquid electrolyte formulations and measured their conductivity, with a Bayesian optimiser choosing each next formulation. It found electrolyte blends that outperformed a baseline in a few dozen automated experiments, and the improvements carried over to better fast-charging in pouch cells. These results matter more than their modesty suggests. They show AI attacking the verification bottleneck itself: not proposing more candidates, but making each test cheaper, faster or more informative. In a field where the honest check takes months, that may ultimately be the larger contribution. The self-driving laboratory The ambition that ties these threads together is the self-driving laboratory, in which a computer plans experiments, robots execute them, instruments measure the results, and software analyses the data and plans the next round without a human in the loop. The idea has been pursued in chemistry for more than a decade. A widely noticed early demonstration came from Andrew Cooper's group at the University of Liverpool, whose mobile robot, reported in Nature in 2020, moved around an ordinary laboratory operating instruments and ran 688 experiments over eight days to find improved photocatalyst formulations for producing hydrogen from water. For inorganic materials, the most prominent effort was the A-Lab at Lawrence Berkeley National Laboratory, described in Nature in November 2023 alongside GNoME. The A-Lab used robotic arms to weigh and mix powders, load furnaces and prepare samples for X-ray diffraction. Recipes for each target were proposed by models trained on synthesis procedures mined from the literature, and when a first attempt failed, an active learning algorithm drawing on thermodynamic data suggested alternative routes. The diffraction patterns were interpreted by machine learning models. The paper reported that over 17 days of continuous operation the lab successfully synthesised 41 of 58 target compounds, most of them predicted to be stable but not previously reported. In early 2024, a group of solid-state chemists including Robert Palgrave of University College London and Leslie Schoop of Princeton published a detailed reanalysis in PRX Energy. They argued that the automated interpretation of the X-ray diffraction data was unreliable, that many of the products were better explained as mixtures or as known compounds, and that once the possibility of disorder was taken into account, few if any of the claimed new materials had clearly been made. The Berkeley team responded in defence of their workflow and the core of the result. Whatever one's view of the specific compounds, the exchange exposed the critical point. In a self-driving laboratory, the machine learning does not only propose; it also judges. If the model that reads the diffraction pattern is wrong, the whole loop believes it has succeeded. Automating the verification step does not remove the need for verification. It moves it to the question of whether the automated judge can be trusted. What batteries teach The battery case shows the argument of this book under pressure. AI is already valuable in battery research at both ends of the pipeline: it shrinks the space of candidates by many orders of magnitude, and it makes testing faster by predicting long-term behaviour from early data and choosing experiments intelligently. In between lies the hard part. A battery material is useful only if it can be made reproducibly at scale, survives contact with the other components, and performs for thousands of cycles under real conditions, and none of that is well captured in the databases the models learned from. The practical consequences for anyone funding or managing this research follow directly. Value a computational result by the strength of its experimental check, not the size of its candidate pool. Treat claims of novelty in solid-state chemistry with caution until crystallographers have looked at the data, including for disorder. Invest in the instrumentation, characterisation and testing capacity that the verification step demands, because a faster funnel feeding a laboratory that cannot test more is a faster way of building a queue. And look for the projects that use AI to speed up the test as well as the search, because that is where the bottleneck now sits. The next two chapters move from materials to physics, where the relationship between AI and data takes a different form. At a particle collider the problem is not too few experiments but far too much data, and AI's job is to decide, in real time, what is worth keeping. Chapter 5: Needles in a Collision Storm The Large Hadron Collider at CERN, on the French–Swiss border near Geneva, accelerates two beams of protons around a 27-kilometre ring in opposite directions and smashes them together at four points where enormous detectors wait. The protons travel in bunches, and at the design spacing a bunch crossing occurs every 25 nanoseconds, forty million times a second. At each crossing several dozen pairs of protons may collide at once. Each collision sprays particles outwards through layers of detector, which record their tracks, their energies and their timings across many millions of electronic channels. If every crossing were read out in full, the data flowing from a large detector such as CMS or ATLAS would run to something of the order of a petabyte per second, far beyond what any system could transmit, let alone store or analyse. Almost all of it is uninteresting: glancing collisions producing familiar particles that have been studied for decades. The events physicists are hunting, the production of a Higgs boson, a rare decay, the signature of something unknown, are needles of extraordinary scarcity. A Higgs boson is produced roughly once in every billion or so collisions, and most of those decay in ways that are buried in background. Particle physics therefore faces the problem of signal and noise in its most extreme form, and it has been using machine learning to address it for longer than almost any other science. This chapter describes how. The story differs from those of proteins and materials in one crucial respect: in particle physics, the verification apparatus was built first, and AI was brought inside a statistical framework that already knew how to check it. The trigger: deciding in microseconds Since the data cannot all be kept, the experiments decide in real time which collisions to record. The system that does this is called the trigger, and it works in stages, each slower and more sophisticated than the last, as Table 3 summarises for the CMS experiment. Table 3. Stages of event selection at the CMS experiment, current and planned. Stage Hardware Time per decision Output rate, LHC Run 2 Planned output, High-Luminosity LHC Collisions — Every 25 ns 40 MHz 40 MHz Level-1 trigger Custom electronics and FPGAs About 4 microseconds Up to 100 kHz Up to 750 kHz High-level trigger Computing farm Of order 100 ms About 1 kHz About 7.5 kHz Source: CMS Collaboration technical design reports for the Phase-2 upgrade. The first stage, the Level-1 trigger, must make its decision within a few microseconds while the full detector data waits in buffers. It cannot run on ordinary computers. It runs on specialised electronics, including field-programmable gate arrays, or FPGAs, chips whose circuitry can be configured for a specific task and that execute it with fixed, tiny delays. Using coarse information from the calorimeters, which measure energy, and the muon detectors, the Level-1 trigger throws away all but about one crossing in four hundred. Everything it rejects is lost forever. The survivors pass to the high-level trigger, a farm of many thousands of processor cores running a streamlined version of the full reconstruction software. It has about a tenth of a second per event and reduces the rate by another factor of a hundred or so. What remains is written to permanent storage and distributed to computing centres around the world for analysis. The trigger is where the stakes of filtering are highest, because its errors are irreversible. A physics signature that the trigger was not designed to recognise will simply never be recorded. This is why the design of trigger algorithms is among the most carefully argued work in the field, and why introducing machine learning into it required both technical innovation and cultural acceptance. Neural networks on a chip Running a neural network within the Level-1 time budget is a formidable engineering problem. The network must produce its output in well under a microsecond, using limited on-chip resources, with completely predictable timing. From 2018, a collaboration of physicists and engineers developed a tool called hls4ml, which translates trained neural networks into firmware for FPGAs. Making the networks fit required compressing them aggressively: pruning connections that contribute little, and representing numbers with a handful of bits rather than the 32 bits standard on ordinary computers, while training the network to be robust to the resulting loss of precision. The result was neural networks that could perform inference in tens to hundreds of nanoseconds. These tools have since found uses well beyond particle physics, wherever fast decisions must be made on streaming data, but their origin was the trigger. Networks now help with tasks such as estimating muon momenta, identifying particle types from calorimeter deposits, and reconstructing quantities at Level-1 more accurately than hand-crafted algorithms. The most interesting development has been anomaly detection. Traditional triggers select events matching specific signatures that theorists have predicted: two energetic photons, a high-momentum muon, a large imbalance in transverse momentum suggesting an invisible particle. If new physics takes an unexpected form, these triggers may discard it. In 2024 CMS began running an anomaly-detection algorithm in its Level-1 trigger, a type of neural network called an autoencoder, trained on ordinary collision data to compress and reconstruct events. Events that it reconstructs poorly are, by construction, unlike the bulk of the data, and a fraction of them can be kept for later study regardless of whether they match any predicted signature. It is a small change in rate and a large change in philosophy: a trigger that looks for the unexpected rather than only the predicted. Keeping more by keeping less A second response to the trigger's irreversibility is to change what is kept rather than only which events. The full raw record of a collision is large, around a megabyte, because it includes the readout of every channel of the detector. Most analyses use a much smaller summary: the reconstructed list of particles, jets and their properties. If the trigger system can reconstruct events well enough in real time, it can save only that summary for a much larger number of events, within the same storage budget. CMS calls this data scouting, and ATLAS uses a similar strategy under a different name. It has allowed searches for relatively light new particles whose signatures would otherwise be discarded because they look too much like ordinary collisions to pass standard thresholds. Scouting depends heavily on the quality of real-time reconstruction, which is where machine learning enters again. Algorithms running on the high-level trigger farm, increasingly on graphics processors as well as conventional processors, must produce analysis-quality objects in a fraction of a second, without the careful offline calibration applied later. The raw detector data for those events is gone, so any reconstruction error is permanent. The trade-off is deliberate: more events, each recorded less completely, in exchange for sensitivity to physics that would otherwise never be recorded at all. It is an example of how filtering decisions are scientific decisions, embodying a judgement about where discoveries are likely to lie. Pileup: subtracting the background Each interesting collision at the LHC arrives accompanied by dozens of other, simultaneous, uninteresting ones from the same bunch crossing. Physicists call this pileup. During the second run of the LHC, the average number of simultaneous interactions was in the range of thirty to forty; at the High-Luminosity LHC, scheduled to begin operating around 2030 after a long shutdown for upgrades that began in 2026, it is expected to reach up to about two hundred. Pileup corrupts measurements. Particles from unrelated collisions add energy to jets, the sprays of particles produced when quarks and gluons fly out of a collision, and distort the measurement of missing momentum that signals invisible particles. Removing their contribution is a filtering problem of exactly the kind machine learning is good at: deciding, particle by particle, whether each one belongs to the collision of interest. The standard approaches were developed with physical reasoning. Charged particles leave tracks that can be traced back to their point of origin, so charged particles from other collision vertices can be removed directly. Neutral particles leave no tracks, and their origin must be inferred from context. An algorithm called PUPPI, introduced in 2014, assigns each particle a weight based on how its surroundings compare with what pileup typically looks like. Subsequent work has trained neural networks, including graph networks that treat the particles in an event as nodes connected to their neighbours, to perform the same task, showing improvements in simulation and increasingly in real data. The physics-based method remains the backbone, with machine learning refining it, which is a common pattern in this field. Identifying what came out Once events are recorded, the analysis problem is to identify what produced them. The most important applications of machine learning here concern jets. A jet produced by a bottom quark looks subtly different from one produced by a lighter quark or a gluon. Hadrons containing bottom quarks live long enough to travel a few millimetres before decaying, so their decay products emerge from a displaced point, and they decay into characteristic combinations of particles. Identifying such jets, called b-tagging, is essential for studying the Higgs boson, which decays most often into a pair of bottom quarks, and the top quark, which almost always decays into one. Early b-taggers combined a few handcrafted variables. Over the 2010s they were replaced by neural networks taking ever lower-level information, eventually the full list of tracks and particles in the jet. The architectures followed the structure of the data. A jet is a variable-sized, unordered set of particles, which fits poorly into the fixed grids that image networks expect. Graph networks such as ParticleNet, introduced in 2019, treat a jet as a cloud of points and learn from the relationships between neighbouring particles. Transformer-based models such as Particle Transformer, introduced in 2022, use attention to weigh interactions between all pairs of particles and have set new standards on public benchmarks. Similar approaches identify jets produced by the decays of heavy, fast-moving particles such as top quarks and W, Z and Higgs bosons, whose decay products merge into a single wide jet with internal substructure. The gains are not cosmetic. Better tagging translates directly into better measurements. When CMS and ATLAS announced in 2018 that they had observed the Higgs boson decaying into bottom quarks, the result depended on sophisticated multivariate techniques to separate a small signal from overwhelming backgrounds, and subsequent analyses using deep learning taggers have improved sensitivity further. Searches for the production of Higgs boson pairs, which probe the shape of the Higgs field's potential and therefore one of the deepest open questions in the Standard Model, are among the measurements most dependent on these improvements, because the signal is so rare that every gain in efficiency matters. A long history and a culture of checking Machine learning in particle physics is not new. Neural networks were used to classify events at the Large Electron–Positron collider in the 1990s, and boosted decision trees played an important role in neutrino physics and in the observation of single top quark production at Fermilab's Tevatron in 2009. The 2012 discovery of the Higgs boson used multivariate classifiers in several channels. In 2014 ATLAS physicists organised a public machine learning challenge, hosted on the Kaggle platform, around identifying Higgs decays to tau leptons, attracting nearly two thousand teams. What distinguishes the field is not the age of its machine learning but the framework around it. Every analysis at the LHC is designed to produce a statistical statement: a measurement with uncertainties, or a limit on how large an unseen effect could be. Analyses are typically blinded, meaning the region where a signal would appear is not looked at until the method is fixed, preventing physicists from unconsciously tuning their selections to produce a result. Every step must be calibrated against data in control regions where the answer is known. Results are cross-checked by teams within each collaboration of several thousand physicists, and the most important are checked by the rival experiment with independent detectors, as happened with the Higgs discovery itself. When a neural network enters this framework, it inherits these disciplines. A b-tagger's efficiency is not taken from simulation; it is measured in data using samples where bottom quarks are known to be present, and correction factors with uncertainties are applied. A classifier that separates signal from background is treated as just another variable whose behaviour must be validated. This is why particle physicists could adopt deep learning aggressively without generating a crisis of trust. The verification apparatus was already there, and it was designed on the assumption that every tool, human or machine, might be biased. Looking for what nobody predicted The most intriguing use of machine learning in collider physics is the search for phenomena without a specific prediction. The LHC has not found the new particles many theorists expected, and one response has been to ask whether the searches were too narrowly designed. Standard searches compare data with a specific model of new physics; if nature chose differently, the signal may hide in plain sight. Methods developed since 2017 aim to detect anomalies with minimal assumptions. One of the most influential, known as classification without labels, trains a classifier to distinguish two regions of the data that should be statistically identical if there is no new physics. If the classifier succeeds, something in one region is different. ATLAS published a search for new resonances using a version of this technique in 2020. A community exercise called the LHC Olympics, held the same year, released simulated datasets containing hidden signals and invited groups to find them blind, a deliberate echo of the competitive assessment that disciplined protein structure prediction. Anomaly detection raises statistical questions that are still being worked out. An unsupervised method will always find something unusual; the question is whether the unusual events are new physics, detector malfunctions, or rare corners of known physics. Interpreting an anomaly, and quantifying how surprised to be, requires the same careful calibration as any other search, and it is harder because the method was designed not to know what it was looking for. What particle physics shows Particle physics illustrates the argument of this book from an unusual angle. Its central problem is not generating candidates but discarding noise, and its AI is deployed at the point of measurement rather than at the point of hypothesis. Yet the same principle holds. Machine learning works superbly where there is abundant data, here supplied by simulation and by the collisions themselves; a well-defined target, such as the identity of a jet; and a rigorous check, the field's apparatus of calibration, blinding and independent confirmation. The field's long experience suggests that the verification culture is what makes ambitious use of AI possible, not what slows it down. The trigger also sharpens the stakes. Its decisions are irreversible, so a biased filter does not merely produce a wrong answer; it destroys the evidence that could correct it. The next chapter follows AI further inside the instruments of physics, into simulation, accelerator control and fusion, where the relationship between model and measurement becomes more intimate still. Chapter 6: Inside the Instruments of Physics In most popular accounts, AI in science sits outside the experiment. A model proposes a molecule or a crystal; an experiment tests it. Physics increasingly puts AI somewhere else: inside the apparatus. Neural networks now simulate detectors, extract physical parameters from data, tune accelerators and steer fusion plasmas. In these roles the model is not proposing a hypothesis to be checked. It is part of the machinery by which the check is made. That position changes what can go wrong. A bad hypothesis is caught by the experiment. A flaw in the experiment itself may not be caught at all. This chapter follows AI into four corners of physical instrumentation, simulation, inference, accelerator tuning and plasma control, and draws out the discipline each requires. Simulation as the hidden bottleneck Every measurement at a particle collider depends on simulation. To know what a Higgs boson would look like in a detector, or what the background would look like without one, physicists generate billions of artificial collisions and pass each simulated particle through a detailed software model of the detector, typically using a toolkit called Geant4 that tracks particles step by step through every layer of material, recording each interaction. The comparison between simulated and real data is the basis for nearly every result. This detailed simulation is extraordinarily expensive. Simulation and its associated processing account for a large share of the worldwide computing grid used by the LHC experiments, and the most expensive part by far is the calorimeter, where a single energetic particle generates a cascade, or shower, of thousands of secondary particles that must each be followed. At the High-Luminosity LHC, with many more collisions to match and more complex detectors, the experiments' own projections showed that detailed simulation at the required scale would outstrip any plausible computing budget. Generative models offered a way out. If a neural network could learn what calorimeter showers look like, it could produce them directly, in a fraction of the time, without following every secondary particle. An early demonstration, CaloGAN, published in 2018, used a generative adversarial network, a pair of networks in which one generates samples and the other tries to tell them from real ones, to produce showers several orders of magnitude faster than full simulation. ATLAS incorporated a generative adversarial network into its fast simulation framework, AtlFast3, which it described in 2022 and which now produces a large fraction of the experiment's simulated events. Subsequent research has moved to normalising flows and diffusion models, which tend to capture the full distribution of shower shapes more faithfully. A community benchmark, the Fast Calorimeter Simulation Challenge of 2022, compared dozens of approaches on common datasets. The difficulty is not generating something that looks right. It is generating something that is right in every respect an analysis might later depend on, including rare tails and subtle correlations between quantities. A shower generator that reproduces the average energy well but gets the spread slightly wrong will bias any measurement that depends on resolution. Validating a generator in a space with hundreds or thousands of dimensions is hard, and the community has developed new tools for it, including training a separate classifier to try to distinguish generated from fully simulated showers: if it cannot, the generator is good; if it can, the classifier reveals where the differences lie. Here, as elsewhere, the generator is only as trustworthy as the test applied to it. Inference without a formula The second use is subtler. Physicists extract parameters, the mass of a particle, the strength of a coupling, from data by comparing what they observe with what theory predicts for each possible value of the parameter. The rigorous way to do this uses the likelihood: the probability of the observed data given the parameter. For complex experiments, the likelihood cannot be written down. The chain from theory through particle interactions and detector response is defined only by simulation, which can generate samples but not compute probabilities. The traditional response was to compress each event into one or two summary quantities, a reconstructed mass, say, and fit histograms of those. This throws away information. A family of methods known as simulation-based inference uses neural networks trained on simulated data to estimate likelihoods or likelihood ratios directly from high-dimensional event data. A review by Kyle Cranmer, Johann Brehmer and Gilles Louppe in 2020 set out the framework and its uses across science. ATLAS has since applied neural simulation-based inference in a published measurement of Higgs boson properties, reporting improved sensitivity compared with traditional methods. A related technique addresses unfolding, the correction of measured distributions for detector effects to recover what actually happened at the collision. A method called OmniFold, introduced in 2020, uses neural networks to perform unfolding on full events without first sorting them into bins, and was applied to real data by the H1 collaboration, reanalysing electron–proton collisions recorded years earlier at the HERA collider in Hamburg. That last point is worth noticing. Old datasets, carefully preserved, can yield new measurements when new methods arrive, which is an argument for preserving data that becomes stronger as the methods improve. These methods carry a specific risk. They rely on the simulation being accurate, and a neural network can exploit features of the simulation that do not exist in real data, extracting apparent sensitivity from artefacts. The disciplines that guard against this are the same as for any analysis: calibrate in control regions, propagate uncertainties from every known mismodelling, and test whether the result changes when the simulation is varied. Simulation-based inference makes these checks harder, because the network's dependence on the simulation is less transparent than a histogram's. It does not make them optional. Machines that tune machines Particle accelerators are themselves among the most complex instruments humans have built, and operating them involves adjusting hundreds or thousands of magnets, radio-frequency cavities and other components to produce beams of the right energy, intensity and quality. For decades this was done by skilled operators using physics models, experience and patience. Tuning a facility after a change in configuration could take hours, during which no science was done. At SLAC National Accelerator Laboratory in California, which operates the Linac Coherent Light Source, an X-ray free-electron laser that produces extremely bright, short pulses used to image molecules and materials, researchers applied Bayesian optimisation to the tuning problem. The same logic described in Chapter 4 for battery experiments applies: a model of how beam quality depends on the settings, with uncertainty estimates, chooses the next adjustment to try. Results published in 2020 showed that this approach could tune the laser's output faster than standard methods, and that by building physics knowledge into the model's prior assumptions it could work in higher-dimensional settings than generic optimisers. Similar methods have been adopted at other accelerator facilities in Europe and the United States, alongside neural network surrogates that predict beam behaviour quickly enough to support real-time decisions. It helps to see concretely what the optimiser is doing. An operator wants to maximise the energy of the X-ray pulses, which depends on the settings of, say, a dozen focusing magnets. Each setting can be changed and the pulse energy measured within seconds, but the measurement is noisy, and the response to the magnets is a tangled function with interactions between them. The optimiser begins with a statistical model that assumes, from prior physics knowledge or past tuning sessions, roughly how smoothly pulse energy varies with each magnet. It tries a setting, observes the result, and updates its estimate of the whole landscape, including where it is still uncertain. It then picks the next setting where the expected improvement, weighing the predicted value against the uncertainty, is highest. A human operator does something similar by instinct; the optimiser does it with many more dimensions in view at once and without fatigue. The appeal here is directly economic. Beam time at a major light source or collider is scarce and expensive, and every hour saved in tuning is an hour of experiments for the scientists waiting to use it. The risk is limited because the objective is measurable on the spot: the beam either improves or it does not, and operators can watch the optimiser work and intervene. Holding a plasma in place Fusion energy offers the most dramatic example of AI as instrument controller. In a tokamak, the doughnut-shaped device at the centre of most fusion research, a plasma of hydrogen isotopes at temperatures exceeding a hundred million degrees is held away from the walls by magnetic fields shaped by coils around the vessel. The plasma is unstable and constantly trying to escape; the currents in the coils must be adjusted thousands of times a second to hold it in shape. Traditionally this was done by a set of carefully engineered feedback controllers, one for each aspect of the plasma's position and shape, designed by physicists over many years for each new configuration. In 2022, researchers from DeepMind and the Swiss Plasma Center at EPFL in Lausanne reported in Nature that they had trained a single neural network controller, using reinforcement learning in a simulator of the tokamak, that could command all of the TCV tokamak's control coils directly. Reinforcement learning trains an agent by trial and error, rewarding it when it achieves the desired outcome; here the training happened entirely in simulation, and the trained controller was then deployed on the real machine. It produced a range of plasma shapes, including configurations with two separate plasmas held simultaneously in the vessel, and it did so with a single learned policy rather than a set of hand-designed loops. In 2024 a team from Princeton and collaborators reported in Nature a different application at the DIII-D tokamak in San Diego. They trained a reinforcement learning controller to anticipate a specific kind of instability, called a tearing mode, which can disrupt the plasma and end the pulse, and to adjust the plasma in advance so as to avoid it while maintaining high performance. They reported that the controller could forecast the instability a few hundred milliseconds before it occurred, long enough to steer away from it. Both results depend on the same thing: a simulator good enough that a controller trained on it works on the real machine. The physics of plasma behaviour is far from fully understood, and the gap between simulation and reality is one of the main obstacles to applying such methods to larger devices. Training in simulation and transferring to reality works when the simulator captures the features that matter for control, and the only way to find out is to try it on hardware, carefully, with safeguards. In a future power plant, where a disruption could damage the machine, the question of how to certify that a learned controller will behave safely in conditions it has never encountered becomes central. That is a verification problem of a new kind, and the field has only begun to work on it. Forecasting a disruption Before learned controllers, fusion researchers had already turned to machine learning for a narrower and more urgent task: predicting disruptions. A disruption is the sudden loss of confinement of a tokamak plasma, in which its stored energy and current are dumped into the surrounding structure within milliseconds. In today's experimental machines, disruptions are a nuisance that ends an experiment and occasionally damages components. In ITER, the large international tokamak under construction in southern France, the stored energy will be far greater, and an unmitigated disruption could cause serious damage. ITER therefore needs a system that recognises an approaching disruption early enough to trigger mitigation, typically by injecting material that radiates the energy away more gently. Disruption prediction is a natural machine learning problem. Each tokamak has recorded thousands of plasma pulses, some ending normally and some in disruptions, with dozens of diagnostic signals sampled throughout. A model can be trained to recognise the patterns that precede a disruption. In 2019 Julian Kates-Harbeck, Alexey Svyatkovskiy and William Tang published in Nature a deep learning predictor trained on data from the DIII-D tokamak in the United States and the JET tokamak in Britain. Its most significant result concerned transfer: a model trained largely on one machine retained useful predictive power on the other, which matters because ITER cannot afford to learn about its own disruptions by experiencing many of them. The verification problem here is unusually sharp. A predictor that fires too late is useless; one that fires too often ends good experiments and, in a power plant, would cost electricity. Evaluating a predictor means measuring both rates, on pulses it has never seen, from machines and operating regimes that may differ from its training data. And the rarest, most dangerous events are by definition the ones with the fewest examples. This is a case where a model's errors are concentrated precisely where the consequences are greatest, and where physics-based understanding of why disruptions happen remains essential for knowing when the model can be believed. When the model becomes part of the measurement The common thread through these examples is that AI has moved from producing candidates to forming part of the instrument. This has consequences that the earlier chapters did not need to confront. First, errors become systematic rather than random. A biased fast simulation or a mistuned inference network does not produce scattered mistakes that average out; it shifts every result in the same direction. Physicists already handle systematic uncertainties from imperfect detector models, and they are extending those methods to learned components, assigning uncertainties to network outputs and testing how results change when the networks are retrained or their inputs perturbed. Second, the distinction between simulation and data must be guarded closely. A network trained on simulation and applied to data will behave differently if the two differ in ways it has learned to depend on, a problem known as domain shift. In jet tagging, for example, physicists learned early that classifiers could sculpt the distribution of jet mass, creating artificial bumps that look like new particles, because the network had learned to use mass indirectly. Techniques to decorrelate classifiers from such variables are now standard, but only because people looked for the problem. Third, certification matters when the stakes are physical. An optimiser tuning an accelerator under an operator's eye is low risk. A learned controller in a power plant, or a trigger that permanently discards data, needs stronger guarantees, and the field is still developing what those should be. The lesson is the one this book keeps returning to, applied at a deeper level. When AI proposes hypotheses, verification is the experiment. When AI becomes part of the experiment, verification must turn inward, onto the AI itself. Physics, with its long habit of treating every tool as a possible source of bias, is better placed than most fields to do this, and its practices are worth copying elsewhere. Chapter 7: Chemistry Learns to Plan Organic chemistry has a reputation as the most craft-like of the physical sciences. Making a complex molecule, a natural product, a drug candidate, a new catalyst, means designing a sequence of reactions, each converting one compound into another, and then carrying them out at the bench, where yields disappoint, side products appear and procedures that worked in someone else's hands fail in yours. The knowledge required is vast, partly codified in the literature and partly carried in the intuition of experienced chemists. It is exactly the kind of knowledge that people long assumed computers could not capture. They were partly right. This chapter covers three things AI now does in chemistry: proposing molecules worth making, planning how to make them, and, most recently, acting as an agent that reads, reasons and directs laboratory equipment. In each, the pattern of this book reappears, with a twist specific to chemistry: the training data are not just limited but systematically skewed towards success. Molecules worth making The space of possible small organic molecules is even larger than the space of crystals. A commonly quoted estimate puts the number of drug-like molecules that could in principle exist at around ten to the sixtieth power, a number that dwarfs any conceivable synthesis effort. Drug discovery has always been a search through a minuscule, historically accidental corner of this space. Machine learning first entered as a screening tool, predicting properties such as binding, solubility or toxicity from molecular structure so that only promising compounds would be made. The method gained public attention in 2020, when a team at MIT led by James Collins and Regina Barzilay reported in Cell the discovery of a compound they named halicin. They trained a neural network on a few thousand molecules tested for their ability to inhibit the growth of Escherichia coli, then used it to rank a library of several thousand existing drugs and drug candidates, and later screened over a hundred million molecules computationally. Halicin, originally investigated for an unrelated purpose, was predicted to have antibacterial activity and structurally unlike existing antibiotics. Laboratory tests confirmed that it killed a range of bacteria, including some resistant to existing drugs, and it was effective in mouse infection models. The same group later used a similar approach to identify abaucin, a compound active against Acinetobacter baumannii, one of the bacteria the World Health Organization lists as a critical threat. These results show the screening mode at its best: a modest, high-quality training set, a clearly measurable property, and a fast laboratory check. They also show its natural limits. A compound that kills bacteria in a dish and in mice is the start of a drug development programme, not the end. As of this writing, none of these AI-identified antibiotics has completed clinical trials. Generative models for molecules emerged in parallel, proposing new structures optimised for predicted properties. Several companies built drug discovery pipelines around them, and a small number of AI-designed molecules have advanced into clinical trials. The most closely watched, a drug for idiopathic pulmonary fibrosis developed by Insilico Medicine, in which both the target and the molecule were identified with AI tools, reported results from a phase 2a trial in Nature Medicine in 2025, suggesting it was safe and possibly beneficial in a small group of patients over twelve weeks. Whether such programmes will succeed at higher rates than conventional ones is the question that matters and will take years of larger trials to answer. As with AlphaFold, the bottleneck has moved to the clinic. Planning a synthesis A molecule worth making is no use if nobody can make it. The intellectual framework for planning syntheses was formalised by Elias James Corey in the 1960s, work recognised with the 1990 Nobel Prize in Chemistry. Corey called it retrosynthetic analysis: start from the target and work backwards, asking which bond could be formed in the last step and what simpler precursors that implies, then repeat for each precursor until you reach compounds that can be bought. Corey also pioneered the idea that a computer could assist, with a program called LHASA developed from the late 1960s. For decades, computer-aided synthesis planning struggled. The rules connecting targets to precursors are numerous and riddled with exceptions, and a plan that is formally valid may fail in practice because of a functional group elsewhere in the molecule that reacts when it should not. A system called Chematica, developed by Bartosz Grzybowski and colleagues and later sold commercially as Synthia, encoded tens of thousands of reaction rules by hand, with expert chemists specifying the conditions under which each applies, and in 2018 demonstrated routes to several targets that were then carried out successfully in the lab. The machine learning approach took the opposite path, learning from data rather than hand-written rules. In 2018 Marwin Segler, Mike Preuss and Mark Waller published in Nature a system that combined neural networks trained on millions of reactions from the chemical literature with Monte Carlo tree search, the same search technique behind DeepMind's Go-playing programs. The networks suggested which transformations were plausible at each step; the search explored sequences of steps towards purchasable starting materials. In a blind test, organic chemists asked to compare the system's routes with routes from the literature showed no clear preference between them. In parallel, work by Philippe Schwaller and colleagues at IBM recast reaction prediction as a translation problem, using transformer networks to convert text representations of reactants into representations of products, a forward prediction that can check whether each step in a planned route is plausible. It is worth following how such a planner reasons, because the steps show both its power and where a chemist must intervene. Take a typical drug-like target: two ring systems joined by an amide bond, with a second nitrogen-containing ring attached elsewhere through a carbon–nitrogen bond. The planner's first move is to propose disconnections, bonds that could plausibly be formed in the final step. A network trained on literature reactions will rank the amide highly, because amide couplings are among the most frequently reported reactions in medicinal chemistry; it suggests a carboxylic acid and an amine as precursors. It may also propose breaking the carbon–nitrogen bond via a palladium-catalysed coupling, another workhorse reaction. Each proposal becomes a branch in a tree. The search then expands each branch, proposing disconnections for each precursor, and uses learned estimates of how promising each partial route looks to decide which branches to explore further. It stops a branch when every leaf is a compound in a catalogue of purchasable materials. The output is a ranked set of complete routes, each a sequence of known reaction types, often with links to literature precedents for each step. A forward prediction model can then check each step, asking whether these reactants under these conditions would really give this product rather than something else. A chemist reviewing the result looks for things the planner may have missed. If the amine precursor contains a second, more reactive nitrogen, the amide coupling may happen at the wrong place, and a protecting group strategy, adding two steps, will be needed. If the palladium coupling is proposed on a substrate with a sulfur atom nearby, the catalyst may be poisoned. If one purchasable starting material costs thousands of pounds per gram, the route may be impractical at scale. Planners have improved at handling such issues, partly through better data and partly through explicit rules layered on top of the learned models, but they remain the place where experience earns its keep. The machine proposes a dozen routes in seconds. The chemist chooses one and anticipates where it will go wrong. Synthesis planning tools are now in routine use in pharmaceutical companies. They are good at proposing routes to drug-like molecules using well-established reactions, and they are an effective way for a chemist to see options they might not have considered. They are weaker at predicting yields, choosing reaction conditions, and handling unusual chemistry. Those weaknesses trace back to the data. The problem of missing failures The reaction data on which these models train comes overwhelmingly from patents and published papers, and published chemistry is a record of what worked. Failed reactions are rarely reported. Yields are reported inconsistently, often optimised, and sometimes optimistic. Conditions are described in prose that omits details the authors considered obvious. A model trained on this record learns which reactions are reported, which is not the same as learning which reactions work, let alone how well. The consequence is starkest for yield prediction. Researchers have found that models trained on literature data predict yields poorly, often barely better than simple baselines, while models trained on carefully designed high-throughput experiments, in which every combination of conditions is run and every result recorded, including the failures, do much better within the chemical space those experiments covered. A 2022 analysis by Felix Strieth-Kalthoff, Frank Glorius and colleagues made the case directly: machine learning for chemical reactivity needs failed experiments, and the literature does not provide them. This has prompted efforts to change how chemical data is recorded. The Open Reaction Database, launched in 2021, offers a structured, open format for reporting reactions, including unsuccessful ones and full experimental details. Electronic laboratory notebooks and automated experimentation generate data in machine-readable form as a by-product. Progress is real but slow, because it requires changing the habits and incentives of a whole discipline. It is another instance of the book's central claim. The binding constraint on AI in chemistry is not the model architecture but the quality of the record it learns from, and that record was built for human readers who could fill in the gaps. Quantum accuracy at a discount A less visible but foundational development concerns the calculations chemists use to understand molecules. Quantum chemical methods can predict the energies and structures of molecules with high accuracy, but the most accurate are so expensive that they are limited to small molecules, and even the workhorse methods are too slow to simulate a large molecule moving in solvent for any useful length of time. Classical force fields, which treat atoms as balls on springs, are fast but miss chemistry: they cannot describe bonds breaking and forming. Machine learning potentials for molecules occupy the space between. Trained on large sets of quantum chemical calculations, they learn to predict energies and forces for new arrangements of atoms at a tiny fraction of the cost. An early influential example, ANI-1, published by Justin Smith, Olexandr Isayev and Adrian Roitberg in 2017, was trained on millions of calculations on small organic molecules and reproduced their quantum chemical energies at a cost closer to that of a classical force field. Successors have extended coverage to more elements, charged species and reactions, and the same families of architectures underlie the universal potentials for crystals described in Chapter 3. These potentials matter for the argument of this book because they shift the checking step as well as the generating step. Chemists use them to test candidate molecules and reaction mechanisms computationally before going to the bench: whether a proposed catalyst geometry is stable, whether a drug candidate adopts the shape needed to bind, how a reaction might proceed. A cheaper check that is nearly as good as an expensive one is a real gain. The caution is the same as for crystals. A potential trained on certain kinds of molecules may fail without warning on others, and its accuracy cannot exceed that of the quantum calculations it learned from. It is an excellent intermediate filter and a poor final judge. Chemists made of language The newest development is the use of large language models, the systems behind conversational AI, as chemical agents. A language model on its own knows a good deal of chemistry from its training text but is unreliable on details, prone to stating plausible falsehoods, and has no access to laboratory equipment. Connected to tools, it becomes something different. Two papers published in 2023 and 2024 established the idea. Coscientist, developed by Gabe Gomes and colleagues at Carnegie Mellon and published in Nature in December 2023, used a large language model that could search the web, read documentation for laboratory hardware, write and run code, and send instructions to automated liquid-handling equipment. Given a high-level request, it planned and executed palladium-catalysed coupling reactions, a staple of modern synthesis, and reasoned from the results to improve the conditions. ChemCrow, developed by Andrew White, Philippe Schwaller and colleagues, connected a language model to around eighteen specialised chemistry tools, including synthesis planners and property calculators, and to a cloud-connected robotic synthesis platform, and used it to plan and carry out syntheses including an insect repellent. Since then the ambition has grown. In 2025 Google described an AI co-scientist system built from multiple cooperating language model agents that generate, debate and rank hypotheses, and reported early tests in which it proposed candidate drug repurposing ideas later supported in laboratory experiments. Several research organisations and start-ups are building systems that aim to automate larger parts of the research cycle, from literature review to experimental design. It is important to be precise about what these systems do. Their strength is integration: they connect search, reasoning, code and hardware in a way that removes friction from routine research tasks. The chemistry they have executed autonomously so far is mostly well-established chemistry, chosen because it is reliable enough to test the agent. Their hypotheses are generated by models trained on the existing literature, and the question of whether they produce ideas that a well-read human expert would not is still open. Most important, their output still needs checking, and the checking is harder than it looks, because a fluent explanation from a language model is easy to mistake for a correct one. The dual-use problem Chemistry also forces a question that the other sciences in this book raise less sharply. The same tools that find antibiotics can find toxins. In 2022, researchers at Collaborations Pharmaceuticals published a short paper in Nature Machine Intelligence describing what happened when, for a conference on biological and chemical weapons, they inverted the objective of their own generative model, rewarding rather than penalising predicted toxicity. In a matter of hours it proposed tens of thousands of molecules predicted to be highly toxic, including known chemical warfare agents and many unfamiliar compounds predicted to be comparably dangerous. The authors had not synthesised anything, and turning a predicted molecule into a weapon involves many further obstacles. But the exercise made concrete a concern that grows as agents become able to plan syntheses and operate laboratory equipment. Responses so far include restricting access to some models, screening requests to automated laboratories and synthesis services, and building refusal behaviours into general-purpose AI systems. None is complete. The point for this book is that verification has a second meaning in chemistry. It is not only checking that a result is true, but checking what a system is being asked to produce, and by whom. What chemistry shows Chemistry confirms the pattern of the earlier chapters and adds a warning about data. Screening models work where training data are carefully measured and the laboratory check is quick, as with antibiotics. Synthesis planners work where the literature is dense and the reactions are routine, and struggle where the literature is silent about failure. Language model agents remove friction from research and lower the cost of trying things, which is valuable and also, in the wrong hands, dangerous. Across all three, the systems learn from a record that was shaped by what chemists chose to publish. Their blind spots are the discipline's blind spots, magnified by scale. The next chapter gathers the ways AI results in science go wrong, across all three sciences, and asks what a serious practice of verification looks like. Chapter 8: How AI Results Fail Every chapter so far has ended at the same place: the value of a model depends on how its output is checked. This chapter turns that observation into a working discipline. It describes the main ways AI results in science go wrong, with examples from the fields already covered, and then sets out what serious verification looks like. None of the failures is exotic. Most are old problems in statistics and experimental design that machine learning makes easier to commit and harder to see. Leakage: when the test is not a test The most common failure is called leakage. A model is evaluated on data that is not truly independent of the data it was trained on, so its measured performance reflects memory rather than understanding. The model looks excellent in the paper and disappoints in use. Leakage takes many forms. The simplest is duplication: the same item appears in both the training and test sets. In science the more insidious form is similarity. Proteins come in evolutionary families; molecules come in chemical series; crystals come in structural types. If a test set is formed by randomly splitting a database, nearly every test item will have a close relative in the training data, and the model can score well by recognising the family rather than learning the underlying physics. When the same model meets something genuinely new, its performance falls. This problem is widespread. In a 2023 survey published in Patterns, Sayash Kapoor and Arvind Narayanan of Princeton collected cases of leakage in machine-learning-based science and found it reported in hundreds of papers across seventeen fields, from medicine to political science, in many cases leading to wildly overoptimistic conclusions. Their analysis catalogued the forms leakage takes and argued for standard reporting that would expose it. Structural biology learned this lesson in an especially instructive way. Deep learning models for predicting how small molecules bind to proteins, a central task in drug discovery, reported rapid progress on a popular benchmark derived from the Protein Data Bank. Later analyses showed that much of that progress came from similarity between test and training complexes. When evaluated on proteins unlike those in their training data, many methods performed much worse. In 2024 Martin Buttenschoen, Garrett Morris and Charlotte Deane at Oxford introduced a test suite called PoseBusters, which checked not only whether a predicted binding pose was close to the experimental one but whether it was physically plausible: correct bond lengths, no atoms overlapping, sensible geometry. Many of the deep learning methods produced poses that failed these basic checks, and classical physics-based docking programs, long regarded as superseded, often did better on validity and generalisation. Newer methods, including AlphaFold 3, reported results on these stricter tests and improved on them, which is how the process is meant to work. CASP's blind design is the antidote, and its success is the strongest argument for copying it. A prospective test, in which predictions are made before the answers exist, cannot leak. Materials science adopted the idea with benchmarks such as Matbench Discovery, which evaluates models on their ability to identify stable crystals drawn from a later stage of exploration than their training data. Particle physics has its blinded analyses. Wherever a field can construct a truly prospective test, it should. Plausible but impossible The second failure is specific to generative models. These models are trained to produce outputs that resemble their training data, and resemblance is not correctness. A generative model can produce a protein with a confident, tidy helix where nature has a disordered loop, a crystal structure that duplicates a known one in disguise, a molecular pose with atoms closer together than physics permits, or a calorimeter shower whose average looks right but whose fluctuations are wrong. The danger is that such outputs look exactly like good ones. A human glancing at them sees what a correct answer would look like, because that is what the model was trained to produce. Catching errors requires checks that the model was not trained to pass: physical validity tests, independent calculations, comparison against a separate method, and ultimately experiment. A related problem is novelty. A generative model's claim to have produced something new must be tested against everything already known, and in chemistry and materials science that is not straightforward. The same crystal can be described in many equivalent ways; a disordered known compound can look like several ordered new ones; a molecule may be absent from one database and present in an obscure paper from decades ago. Several of the disputes described in Chapters 3 and 4 turned on exactly this point. Claims of discovery that rest on the absence of a match in a database are only as strong as the database and the matching procedure. Confidence without calibration A model's output is useful only if one knows how far to trust it. AlphaFold's confidence scores were one of its most important features precisely because they were well calibrated: residues with high pLDDT were, on average, as accurate as the score suggested. Many models report no uncertainty at all, and many that do are poorly calibrated, especially on inputs unlike their training data, which is exactly where uncertainty matters most. The danger is greatest when a model is applied outside its domain. A universal interatomic potential trained mostly on stable crystals may give confident and wrong answers for a highly distorted structure or a surface. A jet tagger trained on simulation may behave differently on real data. A screening model for antibacterial activity trained on one family of compounds may be meaningless for another. The general principle is easy to state and difficult to practise: a model's errors are smallest where it least needs to be used and largest where it is most tempting to use it. The fields with the best practice treat uncertainty as an output as important as the prediction itself. Particle physicists assign systematic uncertainties to every learned component. Bayesian optimisation, used in the laboratory loops of Chapter 4, makes uncertainty part of the decision about what to test next. Protein structure predictors report per-residue confidence. These habits should be standard elsewhere. A checklist of failures The failures described so far, and a few others, recur across all three sciences. Table 4 summarises them with an example from earlier chapters and the check that guards against each. Table 4. Common failure modes of AI results in science and how they are caught. Failure mode What goes wrong Example from this book Check that catches it Leakage Test data resembles training data Protein–ligand benchmarks Prospective or dissimilar test sets Implausible outputs Generated result violates physics Overlapping atoms in docked poses Physical validity tests False novelty Known result presented as new Disordered known crystals Expert review against full literature Poor calibration Confidence does not match accuracy Models used outside training domain Uncertainty estimates tested on new data Simulation gap Model exploits simulator artefacts Domain shift in jet taggers Calibration in real-data control regions Automated misjudgement Automated analysis declares false success Diffraction interpretation in autonomous labs Independent human or orthogonal analysis Proxy mismatch Optimised property is not the goal Stability versus synthesisability Testing the property that actually matters The last row deserves emphasis because it is the least technical and the most common. Models optimise what they are told to optimise. A materials model optimises predicted stability; what the chemist wanted was something that could be made and that worked. A molecule generator optimises predicted binding; what the drug developer wanted was efficacy and safety in patients. The gap between the proxy and the goal is not a flaw in the model. It is a choice by the people who set the objective, and it determines how much of the model's success translates into science. Incentives and openness Some failures are not technical at all. Announcements of AI results in science are made by organisations with strong incentives to describe them as large: companies competing for attention and talent, laboratories competing for funding, journals competing for impact. Words such as discovery, solved and breakthrough carry weight, and in several cases described in this book they were applied before the verification step that would justify them. Openness is the main structural defence. AlphaFold 2 was trusted quickly partly because its code was released with its paper, so that thousands of researchers could test it on their own proteins. AlphaFold 3's initial release without code provoked an open letter from researchers and a debate about whether a result that could not be reproduced belonged in a scientific journal; the subsequent release of code for academic use settled the immediate question. GNoME's structures were released, which is what allowed Cheetham and Seshadri to examine them. The A-Lab's data were published, which is what allowed Palgrave, Schoop and their colleagues to reanalyse it. In each case, openness did not prevent overstatement, but it made correction possible. A further constraint is the capacity of the scientific community to check claims at all. A model that generates millions of candidates creates a verification burden that the traditional machinery of peer review cannot absorb. No reviewer can examine 380,000 predicted crystals. Spot checks by experts, independent benchmarks and community challenges are the only scalable responses, and they need funding and recognition that they rarely receive. Reproduction when the model costs millions A traditional experimental result is reproduced by repeating the experiment. A computational result is reproduced by rerunning the code. For the largest AI models in science, neither is straightforward. Training a frontier model may require computing resources that no university group can match, so independent researchers can test a released model but cannot retrain it to check whether its performance depends on choices its developers did not report. Training is also not perfectly deterministic: the same code run twice on large parallel hardware can produce models that differ slightly, and evaluations that compare models by a fraction of a percentage point may be measuring noise. The practical response has been to separate what must be reproducible from what need not be. Inference, running a released model on new inputs, is cheap and should be reproducible by anyone, which is why releasing model weights matters so much. Training data should be documented precisely enough that others can check for overlap with their own test sets, the most direct defence against leakage. Evaluations should report variation across repeated runs, not single numbers. Independent groups have also shown, repeatedly, that the central ideas of a large model can be reproduced at smaller scale: open reimplementations of AlphaFold 2 and AlphaFold 3 appeared within months of the original papers and matched much of their performance, which did more to establish confidence in the approach than any amount of description could have. Auditing an announcement: a worked example It may help to walk through how the questions of this chapter apply to a typical announcement. Consider an illustrative, composite case of the kind that appears regularly: a research team reports that its generative model has designed a hundred new solid catalysts for converting carbon dioxide into fuel, that ninety of them are predicted to be stable and highly active, and that one has been synthesised and shown to work. The first question is what the model learned from. If its training data were DFT calculations of catalyst surfaces, its predictions of activity inherit the known weaknesses of DFT for the binding of small molecules to metal surfaces, which can be significant. If the activity predictions came from a second model trained on a few hundred experimental measurements, the relevant question is how similar the new candidates are to those measured. The second is what was actually tested. Ninety predicted to be stable and active is a computational claim, and its strength depends on whether the predictions were checked on a held-out set of catalysts dissimilar to the training data. One synthesised and shown to work is an experimental claim, and its strength depends on details: whether the catalyst's structure was confirmed by independent characterisation, how its activity compared with the best existing catalysts under the same conditions, whether it was stable over hours or days of operation, and whether anyone outside the team has reproduced the measurement. The third is novelty. Was the synthesised material genuinely new, or a known compound in a slightly different form? Was it the best of the hundred, chosen after the fact, or chosen in advance as a test of the model? If it was chosen after several failed attempts, those failures are evidence too, and should be reported. The fourth is whether the objective matched the goal. Activity in a laboratory reactor at small scale is a proxy for usefulness, which also depends on cost, selectivity for the desired product, durability and the energy needed to run the process. A catalyst that is highly active but rapidly degrades has solved a different problem from the one that matters. Asked in this way, the questions rarely reveal fraud or even error. They reveal how much of the announcement is a prediction and how much is a verified result, which is exactly what a reader needs to know. In the illustrative case, the honest summary would be: a generative model produced a hundred candidates, one of which was made and showed promising activity in initial tests. That is a worthwhile result, and it is a long way from a hundred new catalysts. What good verification looks like Drawing these threads together, a serious practice of verification for AI in science has a recognisable shape. First, test prospectively whenever possible. A blind prediction, made before the answer is known, is worth more than any number of retrospective benchmarks. Fields that can organise community challenges in the CASP mould should do so. Second, test on what is different. Construct test sets deliberately dissimilar from training data, by evolutionary family, chemical scaffold, structural type or time of discovery, and report performance on them separately. Third, check physical validity independently. Run every generated structure through tests based on physics that the model was not trained to satisfy, and report how many fail. Fourth, demand experimental confirmation in proportion to the claim. A claim to have found candidates needs computational evidence. A claim to have discovered materials needs synthesis, characterisation by experts, and measurement of the property that matters. A claim of medical benefit needs clinical trials. Fifth, report uncertainty and calibrate it, so that users know where the model can be trusted. Sixth, release enough code, data and models for others to check, and fund the people who do the checking. None of this is new to science. It is the ordinary discipline of experimental work, applied to a new kind of instrument. What is new is the scale and speed at which AI produces results needing verification, and the corresponding temptation to skip steps. The conclusion turns to what follows from this for the practice of science as a whole. Conclusion The cases in this book point to a conclusion that is easy to state and harder to act on. Artificial intelligence has made generating candidates cheap: structures, compounds, alloys, routes, hypotheses, even decisions about which collisions to keep. It has not made checking them cheap. Science has therefore become, in the fields where AI has arrived in force, a discipline in which the scarce resource is no longer ideas but trustworthy verification. Most of what follows for scientists, funders and institutions comes from taking that shift seriously. The infrastructure was the breakthrough The first consequence concerns where value lies. The public story of AlphaFold is a story about a model. The deeper story is about the Protein Data Bank, built over fifty years by crystallographers who deposited their coordinates under community rules, and about CASP, a quarter-century of blind tests run on modest budgets by people who believed predictions should be checked before they were believed. Those institutions were not built for machine learning. They made it possible. The fields that have struggled to produce comparable results are, almost without exception, those lacking one of the pieces. Materials science has large databases, but they are mostly of calculations rather than measurements, and the experimental record of synthesis, especially of failures, is thin and scattered. Chemistry has an enormous literature, but it is written for human readers, records mostly successes, and omits conditions its authors thought obvious. Drug discovery has abundant data on binding but far less on what happens in people. Particle physics, by contrast, has data in abundance, simulations calibrated against decades of measurement, and a culture of systematic uncertainty, which is why it absorbed deep learning without a crisis of confidence. The implication for anyone who funds science is direct. The highest-return investments in AI for science may not be in AI. They are in the data and verification infrastructure that AI depends on: curated public databases of measurements, standard formats that capture full experimental detail, high-throughput experiments designed to record negative results, characterisation facilities with the capacity to check what models propose, and blind community benchmarks for fields that lack them. These are unglamorous, chronically underfunded, and hard to attribute to any single breakthrough. They are also what separated AlphaFold from the claims that did not survive scrutiny. There is a question of fairness here too. The most capable AI systems for science are increasingly built by a handful of companies with the computing resources to train them, on data assembled by publicly funded scientists over generations. That is not inherently wrong; AlphaFold's predictions were given back freely, and the result was a gift to biology. But it establishes an expectation. Organisations that build on the public scientific record have reason to return to it, in open models, released data and support for the infrastructure that made their work possible, and funders have reason to make that a condition rather than a courtesy. What scientists do now The second consequence concerns the work of scientists themselves. If generating candidates is cheap, the skills that become more valuable are those at either end of the pipeline: deciding what to look for, and judging what was found. Deciding what to look for means setting objectives, and the cases in this book show how much rides on them. A model told to optimise thermodynamic stability will find stable compounds, not useful materials. A model told to optimise predicted binding will find binders, not drugs. Specifying the right target, and recognising the gap between a measurable proxy and the property that actually matters, is a scientific judgement that requires deep knowledge of the field. It cannot be delegated to the model, because the model has no access to what the scientist really wants except through the objective it is given. Judging what was found means verification, in all the senses Chapter 8 described. The solid-state chemists who reanalysed the A-Lab's diffraction patterns, the structural biologists who built PoseBusters, the physicists who calibrate taggers in control regions, the crystallographers who sampled GNoME's predictions by hand: these are not obstacles to AI-driven science. They are the part of it that makes the rest credible. Training programmes that teach students to build models but not to break them are preparing them for half the job. This also suggests a new kind of experiment. When candidates were scarce, an experiment's purpose was to test a hypothesis. When candidates are abundant, experiments increasingly serve a second purpose: generating the data that the next model will learn from. The closed loops of Chapter 4 make this explicit, choosing each experiment for what it will teach the model as well as what it will reveal about the world. Designing experiments for their informational value to a learning system, recording everything including failures, and treating the resulting dataset as a primary scientific product are practices that most laboratories have yet to adopt. What remains unsettled Three questions remain genuinely open, and honesty requires naming them. The first is whether AI produces understanding. AlphaFold predicts structures without explaining folding; a jet tagger identifies bottom quarks without stating a rule a physicist could write down; a screening model finds an antibiotic without saying why it works. Prediction without explanation has real value, and science has often used empirical rules long before understanding them. But science has also historically advanced by turning predictions into theories that generalise beyond the cases they were derived from. Whether AI systems can be made to do this, or whether it remains the human scientist's role to extract understanding from the model's success, is not yet clear. Efforts to interpret what trained networks have learned, and to build physical knowledge into their structure, are early attempts at an answer. The second is whether AI can move science beyond the distribution of what is already known. Every system in this book learned from the existing record, and every one performed worst on inputs least like its training data. The most important discoveries are often precisely those that do not resemble what came before. Generative models can interpolate impressively and extrapolate somewhat. Whether they can propose the kind of idea that reorganises a field, rather than filling in a space the field had already mapped, has not been shown. The third is how far automation of verification can go. Self-driving laboratories and language model agents are beginning to perform the checks as well as the proposals. Where the check is a simple, reliable measurement, this works. Where the check requires expert interpretation, as with the diffraction data in the A-Lab dispute, automation risks a loop that confirms its own errors. Building automated judges that can be trusted, and knowing when they cannot, is perhaps the most consequential engineering problem in the whole enterprise. Three questions for every claim For the reader who will encounter, in the coming years, a steady stream of announcements that AI has discovered something, the practical upshot is a habit of mind. The introduction proposed three questions, and the chapters have shown why each matters. What did the model learn from? If the answer is a large body of careful measurements, the result has a foundation. If it is calculations, the result inherits their approximations. If it is a literature that records only successes, the model's blind spots are the literature's. What exactly was it asked to produce? If the objective is the property that matters, the result may be directly useful. If it is a proxy, the distance between proxy and goal is where the claim may fail. Who checked the result, and against what? A blind prospective test, an independent synthesis, a calibration in real data or a clinical trial is a check. A retrospective benchmark, an automated analysis or a press release is not, or not yet. These questions will not tell a reader whether a particular result is right. They will tell them how much of it has been earned. That distinction, between what a model has proposed and what science has verified, is the one this book has argued matters most. AI has made the first part of discovery fast. The second part is where the work now is, and where the credit should go. Notes Chapter 1 1. C. B. Anfinsen, "Principles that govern the folding of protein chains," Science 181 (1973): 223–230. Anfinsen's Nobel lecture. 2. J. Jumper et al., "Highly accurate protein structure prediction with AlphaFold," Nature 596 (2021): 583–589. 3. A. W. Senior et al., "Improved protein structure prediction using potentials from deep learning," Nature 577 (2020): 706–710. The first AlphaFold, as entered at CASP13. 4. J. Moult et al., "A large-scale experiment to assess protein structure prediction methods," Proteins 23 (1995): ii–v. The founding description of CASP. 5. D. S. Marks et al., "Protein 3D structure computed from evolutionary sequence variation," PLoS ONE 6 (2011): e28766. 6. Z. Lin et al., "Evolutionary-scale prediction of atomic-level protein structure with a language model," Science 379 (2023): 1123–1130. ESMFold and the ESM Metagenomic Atlas. Chapter 2 1. K. Tunyasuvunakool et al., "Highly accurate protein structure prediction for the human proteome," Nature 596 (2021): 590–596. 2. M. Varadi et al., "AlphaFold Protein Structure Database: massively expanding the structural coverage of protein-sequence space with high-accuracy models," Nucleic Acids Research 50 (2022): D439–D444. 3. M. Baek et al., "Accurate prediction of protein structures and interactions using a three-track neural network," Science 373 (2021): 871–876. RoseTTAFold. 4. R. Evans et al., "Protein complex prediction with AlphaFold-Multimer," bioRxiv preprint (2021). 5. J. Abramson et al., "Accurate structure prediction of biomolecular interactions with AlphaFold 3," Nature 630 (2024): 493–500. 6. J. L. Watson et al., "De novo design of protein structure and function with RFdiffusion," Nature 620 (2023): 1089–1100. 7. J. Dauparas et al., "Robust deep learning-based protein sequence design using ProteinMPNN," Science 378 (2022): 49–56. 8. S. Vázquez Torres et al., "De novo designed proteins neutralize lethal snake venom toxins," Nature (2025). 9. J. Cheng et al., "Accurate proteome-wide missense variant effect prediction with AlphaMissense," Science 381 (2023): eadg7492. 10. The Royal Swedish Academy of Sciences, Scientific Background to the Nobel Prize in Chemistry 2024, "Computational protein design and protein structure prediction." Chapter 3 1. A. Jain et al., "Commentary: The Materials Project: A materials genome approach to accelerating materials innovation," APL Materials 1 (2013): 011002. 2. A. Merchant et al., "Scaling deep learning for materials discovery," Nature 624 (2023): 80–85. GNoME. 3. A. K. Cheetham and R. Seshadri, "Artificial intelligence driving materials discovery? Perspective on the article: Scaling deep learning for materials discovery," Chemistry of Materials 36 (2024): 3490–3495. 4. C. Zeni et al., "A generative model for inorganic materials design," Nature 639 (2025): 624–632. MatterGen. 5. C. Chen and S. P. Ong, "A universal graph deep learning interatomic potential for the periodic table," Nature Computational Science 2 (2022): 718–728. M3GNet. 6. B. Deng et al., "CHGNet as a pretrained universal neural network potential for charge-informed atomistic modelling," Nature Machine Intelligence 5 (2023): 1031–1041. 7. J. Riebesell et al., "A framework to evaluate machine learning crystal stability predictions," Nature Machine Intelligence (2025). Matbench Discovery. Chapter 4 1. C. Chen et al., "Accelerating computational materials discovery with machine learning and cloud high-performance computing: from large-scale screening to experimental validation," Journal of the American Chemical Society (2024). The Microsoft and Pacific Northwest National Laboratory electrolyte study. 2. Z. Rao et al., "Machine learning–enabled high-entropy alloy discovery," Science 378 (2022): 78–85. 3. K. A. Severson et al., "Data-driven prediction of battery cycle life before capacity degradation," Nature Energy 4 (2019): 383–391. 4. P. M. Attia et al., "Closed-loop optimization of fast-charging protocols for batteries with machine learning," Nature 578 (2020): 397–402. 5. A. Dave et al., "Autonomous optimization of non-aqueous Li-ion battery electrolytes via robotic experimentation and machine learning coupling," Nature Communications 13 (2022): 5454. 6. B. Burger et al., "A mobile robotic chemist," Nature 583 (2020): 237–241. 7. N. J. Szymanski et al., "An autonomous laboratory for the accelerated synthesis of novel materials," Nature 624 (2023): 86–91. The A-Lab. 8. J. Leeman et al., "Challenges in high-throughput inorganic materials prediction and autonomous synthesis," PRX Energy 3 (2024): 011002. Chapter 5 1. J. Duarte et al., "Fast inference of deep neural networks in FPGAs for particle physics," Journal of Instrumentation 13 (2018): P07027. The hls4ml tool. 2. D. Bertolini, P. Harris, M. Low and N. Tran, "Pileup per particle identification," Journal of High Energy Physics 2014, no. 10 (2014): 59. 3. H. Qu and L. Gouskos, "ParticleNet: Jet tagging via particle clouds," Physical Review D 101 (2020): 056019. 4. H. Qu, C. Li and S. Qian, "Particle Transformer for jet tagging," Proceedings of the 39th International Conference on Machine Learning (2022). 5. E. M. Metodiev, B. Nachman and J. Thaler, "Classification without labels: learning from mixed samples in high energy physics," Journal of High Energy Physics 2017, no. 10 (2017): 174. 6. ATLAS Collaboration, "Dijet resonance search with weak supervision using √s = 13 TeV pp collisions in the ATLAS detector," Physical Review Letters 125 (2020): 131801. 7. G. Kasieczka et al., "The LHC Olympics 2020: a community challenge for anomaly detection in high energy physics," Reports on Progress in Physics 84 (2021): 124201. 8. CMS Collaboration, The Phase-2 Upgrade of the CMS Level-1 Trigger, Technical Design Report CERN-LHCC-2020-004; and The Phase-2 Upgrade of the CMS Data Acquisition and High Level Trigger, CERN-LHCC-2021-007. Chapter 6 1. M. Paganini, L. de Oliveira and B. Nachman, "CaloGAN: Simulating 3D high energy particle showers in multilayer electromagnetic calorimeters with generative adversarial networks," Physical Review D 97 (2018): 014021. 2. ATLAS Collaboration, "AtlFast3: the next generation of fast simulation in ATLAS," Computing and Software for Big Science 6 (2022): 7. 3. K. Cranmer, J. Brehmer and G. Louppe, "The frontier of simulation-based inference," Proceedings of the National Academy of Sciences 117 (2020): 30055–30062. 4. A. Andreassen et al., "OmniFold: A method to simultaneously unfold all observables," Physical Review Letters 124 (2020): 182001. 5. J. Duris et al., "Bayesian optimization of a free-electron laser," Physical Review Letters 124 (2020): 124801. 6. J. Degrave et al., "Magnetic control of tokamak plasmas through deep reinforcement learning," Nature 602 (2022): 414–419. 7. J. Kates-Harbeck, A. Svyatkovskiy and W. Tang, "Predicting disruptive instabilities in controlled fusion plasmas through deep learning," Nature 568 (2019): 526–531. 8. J. Seo et al., "Avoiding fusion plasma tearing instability with deep reinforcement learning," Nature 626 (2024): 746–751. Chapter 7 1. J. M. Stokes et al., "A deep learning approach to antibiotic discovery," Cell 180 (2020): 688–702. 2. G. Liu et al., "Deep learning-guided discovery of an antibiotic targeting Acinetobacter baumannii," Nature Chemical Biology 19 (2023): 1342–1350. 3. Z. Xu et al., "A generative AI-discovered TNIK inhibitor for idiopathic pulmonary fibrosis: a randomized phase 2a trial," Nature Medicine (2025). 4. M. H. S. Segler, M. Preuss and M. P. Waller, "Planning chemical syntheses with deep neural networks and symbolic AI," Nature 555 (2018): 604–610. 5. P. Schwaller et al., "Molecular Transformer: a model for uncertainty-calibrated chemical reaction prediction," ACS Central Science 5 (2019): 1572–1583. 6. F. Strieth-Kalthoff et al., "Machine learning for chemical reactivity: the importance of failed experiments," Angewandte Chemie International Edition 61 (2022): e202204647. 7. S. M. Kearnes et al., "The Open Reaction Database," Journal of the American Chemical Society 143 (2021): 18820–18826. 8. J. S. Smith, O. Isayev and A. E. Roitberg, "ANI-1: an extensible neural network potential with DFT accuracy at force field computational cost," Chemical Science 8 (2017): 3192–3203. 9. D. A. Boiko, R. MacKnight, B. Kline and G. Gomes, "Autonomous chemical research with large language models," Nature 624 (2023): 570–578. 10. A. M. Bran et al., "Augmenting large language models with chemistry tools," Nature Machine Intelligence 6 (2024): 525–535. 11. F. Urbina, F. Lentzos, C. Invernizzi and S. Ekins, "Dual use of artificial-intelligence-powered drug discovery," Nature Machine Intelligence 4 (2022): 189–191. Chapter 8 1. S. Kapoor and A. Narayanan, "Leakage and the reproducibility crisis in machine-learning-based science," Patterns 4 (2023): 100804. 2. M. Buttenschoen, G. M. Morris and C. M. Deane, "PoseBusters: AI-based docking methods fail to generate physically valid poses or generalise to novel sequences," Chemical Science 15 (2024): 3130–3139. Further Reading Jumper et al., "Highly accurate protein structure prediction with AlphaFold," Nature (2021).** The original paper, with its long supplementary methods, remains the clearest account of what the system does. Read alongside the CASP14 assessment papers in the journal Proteins for an independent view of how good the predictions were. The Royal Swedish Academy of Sciences, Scientific Background to the Nobel Prize in Chemistry 2024. A careful, readable history of protein structure prediction and design, written for scientists outside the field and freely available from the Nobel Prize website. Cheetham and Seshadri, "Artificial intelligence driving materials discovery?" Chemistry of Materials (2024).** A short, pointed critique of the GNoME results by two senior solid-state chemists, and the best single document for understanding the difference between predicting compounds and discovering materials. Leeman et al., "Challenges in high-throughput inorganic materials prediction and autonomous synthesis," PRX Energy (2024).** The detailed reanalysis of the A-Lab results. Worth reading for its method as much as its conclusions: it shows how expert verification of automated results is actually done. Cranmer, Brehmer and Louppe, "The frontier of simulation-based inference," PNAS (2020).** A clear introduction, with examples from particle physics and beyond, to using machine learning when the only model of a system is a simulator. The HEPML-LivingReview (iml-wg.github.io/HEPML-LivingReview). A continuously updated, community-maintained bibliography of machine learning in particle physics, organised by application. The fastest way into the literature on triggers, tagging, fast simulation and anomaly detection. Kapoor and Narayanan, "Leakage and the reproducibility crisis in machine-learning-based science," Patterns (2023).** A cross-disciplinary survey of the most common way AI results in science go wrong, with a practical taxonomy that applies directly to the sciences in this book. Buttenschoen, Morris and Deane, "PoseBusters," Chemical Science (2024).** A model of how to build a benchmark that checks physical validity rather than just apparent accuracy, and a cautionary tale about progress measured on leaky test sets. Boiko et al., "Autonomous chemical research with large language models," Nature (2023).** The Coscientist paper, a concrete picture of what a language model agent connected to laboratory hardware can and cannot do. Hashtags: #AIForScientificDiscovery #ArtificialIntelligence #ScientificDiscovery #AIInScience #MachineLearning #DeepLearning #ComputationalBiology #ComputationalChemistry #ComputationalPhysics #AlphaFold #ProteinStructurePrediction #ProteinFolding #ProteinDesign #GenerativeAI #DrugDiscovery #MolecularModeling #MaterialsDiscovery #MaterialsScience #GenerativeMaterialsDesign #BatteryInnovation #QuantumChemistry #DensityFunctionalTheory #GraphNeuralNetworks #ParticlePhysics #LargeHadronCollider #CERN #PhysicsSimulation #AutonomousLaboratories #BayesianOptimization #ExperimentalValidation

Download the Book (PDF): Introduction Somewhere in a hospital archive there is a set of chest scans that would make a diagnostic model better. Each one shows a rare lung condition, the kind that a general radiologist might see a handful of times in a career. The hospital has perhaps forty of them. The model it wants to train has seen tens of thousands of normal scans and learned, sensibly from its own point of view, that the safest guess is almost always "normal". The forty scans are not enough to change its mind, and they cannot be shared with the research group across the border that has another thirty, because they are health records about identifiable people and the law treats them accordingly. A few hundred kilometres away, an engineering team is trying to prove that its automated driving system behaves correctly when a child runs into the road from behind a parked van at dusk, in rain, with the low sun reflecting off wet tarmac. The team has driven millions of real kilometres. In all of them, that exact situation has occurred perhaps never, and nobody would arrange for it to happen deliberately. At a bank, a fraud model is trained on a year of card transactions. Roughly one in six hundred of them is fraudulent. The fraud patterns that matter most are the new ones, which by definition are the least represented of all. These three problems look different, but they share a structure. In each case the data that would teach a model the thing it most needs to know is scarce, and it is scarce for a reason: because the event is rare, because the data is about people who have a right not to be exposed, or because collecting it would mean waiting for, or causing, harm. And in each case the same tempting answer has emerged over the past decade. If we cannot collect enough of the right data, perhaps we can make it. What synthetic data is Synthetic data is data produced by a model or a process rather than recorded directly from the world. The term covers a wide span. At one end are simple tricks such as flipping and rotating images or interpolating between two existing records. At the other are deep generative models, trained on real data, that can produce new photographs, medical scans, transaction histories or patient records that resemble the originals in their statistical character without copying any single one of them. Between the two sit physics-based simulators, rule-based record generators, and hybrids that use a learned model to make a simulator's output look more like reality. Two families of deep generative model dominate the modern practice, and this booklet spends a good deal of time on both. Generative adversarial networks, introduced in 2014, train two networks against each other: one generates samples, the other tries to tell them apart from real ones, and the contest pushes the generator towards realism. Diffusion models, which became dominant around 2021 and 2022, learn to reverse a gradual process of adding noise, and generate new samples by starting from pure noise and removing it step by step. These are the techniques behind most of the striking synthetic images of recent years, and increasingly behind synthetic medical images, synthetic tabular records and synthetic driving scenes. The tools have improved so fast that it is easy to slip from "we can generate realistic data" to "we can generate useful data", and from there to "we no longer need so much real data". The first claim is now plainly true. The second is often true. The third is true only under conditions that are rarely stated and frequently ignored. The argument of this booklet The central claim of what follows is simple to state and has large consequences: a generator cannot give a model knowledge that is not already present in the generator's training data or in the assumptions its builders put into it. Synthetic data moves knowledge around. It can redistribute it, so that a rare class receives more of a model's attention. It can recombine it, so that a car sees a pedestrian it has met before in a weather condition it has also met before, but never the two together. It can extrapolate it, cautiously, along directions the builders have reason to trust. And it can disguise it, so that the statistical regularities of a dataset can be shared without sharing the people in it. What it cannot do is conjure facts about the world that nobody measured. Seen this way, the three great promises of synthetic data become separate questions, each with its own answer. Balancing minority classes is a question of redistribution. Synthetic samples help when the classifier's problem is that it is not paying attention to the rare class, and they help much less when the real problem is that the rare class has not been observed in enough variety. Chapter 5 examines where the evidence lands. Reducing privacy risk is a question of disguise, and disguise can fail. A generator trained on real people can memorise them, and well-documented attacks can sometimes tell whether a particular person's record was in the training set, or even reconstruct it. Synthetic data can lower privacy risk substantially, and in the right conditions it can be treated as falling outside the rules that govern personal data. But "synthetic" is not a legal category, and it is not a way to escape legal obligations. Whether a synthetic dataset is still personal data depends on whether people can reasonably be identified from it, and that is an empirical question about the specific generator and dataset, not a property of the word. Chapter 6 sets out what the law actually asks and what the attacks actually show. Simulating edge cases for automated driving is a question of recombination and extrapolation, and it rests on how faithful the simulator is to the physics and behaviour of real roads. Here synthetic data is not merely useful but indispensable: no company could validate a driving system on real miles alone. Yet the hardest part of the problem is not rendering a convincing image of a child in the rain; it is knowing which combinations of circumstances matter, and knowing whether the system's behaviour in simulation predicts its behaviour on the street. Chapter 7 follows that problem from scenario libraries to the newest neural world models. How the booklet is organised Chapter 1 explains why data runs out precisely where it is most needed, and why simply collecting more is so often not an option. Chapter 2 covers the older and humbler methods, from geometric augmentation and the SMOTE oversampling algorithm to rule-based record generators and game-engine simulators, because they remain the baseline against which any deep generative model must justify its cost. Chapters 3 and 4 explain, without equations but without hand-waving, how generative adversarial networks and diffusion models work, why the first were difficult to train and the second displaced them for most purposes, and what each implies for the kind of synthetic data it produces. Chapters 5, 6 and 7 take the three applications in turn. Chapter 8 turns to the question that every project eventually faces: how to tell whether a synthetic dataset is any good, how to measure its fidelity, its usefulness and its privacy at the same time, and how to avoid the slow degradation that sets in when models are trained on the outputs of other models. The conclusion draws out what follows for anyone deciding whether, and how, to rely on synthetic data. The booklet assumes no mathematics beyond an intuitive sense of what a probability distribution is, and it explains technical terms where they first appear. It is written for engineers and data scientists who want a clear map of the field before diving into papers, for product leaders and clinicians who need to judge claims made by vendors, and for lawyers and privacy officers who are increasingly asked whether a synthetic dataset can be shared. It does not try to survey every method or every tool. It tries instead to give the reader a way of thinking about synthetic data that will still be correct when the current generation of models has been replaced, as it surely will be. The way of thinking is this. Before generating a single sample, ask what knowledge the synthetic data is supposed to carry, where that knowledge comes from, and how you will know if it has arrived intact. Every success story in this field answers those three questions well. Most of the failures skip them. CHAPTER 1 Where Data Runs Out The popular image of modern machine learning is one of abundance. Language models are trained on a large fraction of the public internet; image models on billions of captioned pictures; recommender systems on the clicks of hundreds of millions of users. It is natural to conclude that data scarcity is a problem of the past, solved by scale. That conclusion is wrong in a precise and important way. Data is abundant on average and scarce at the edges, and the edges are where the consequential decisions are made. A model of skin lesions has plenty of benign moles and very few melanomas on dark skin. A speech recogniser has thousands of hours of standard accents and minutes of some regional dialects. A driving system has millions of uneventful motorway kilometres and almost nothing of a tyre bouncing across three lanes. Scale fills in the middle of the distribution. It does very little for the tails, because the tails grow at the same slow proportion as everything else. Understanding exactly why data runs out, and in what form, is the first step in deciding whether synthetic data can help. There are three distinct kinds of scarcity, and each calls for a different response. Scarcity by rarity The first and most familiar kind is statistical rarity. Some events simply happen seldom, and a dataset collected from the world will reflect that. A public benchmark of European credit card transactions released by researchers at the Université Libre de Bruxelles contains 284,807 transactions, of which 492 are fraudulent, about 0.17 per cent. Rates of that order are typical in fraud, in industrial fault detection, in many diagnostic tasks and in the safety-critical events that matter for autonomous systems. Rarity damages learning in two separate ways, and they are worth keeping apart because synthetic data addresses them differently. The first is a problem of attention. Most training procedures minimise average error across all examples. If 99.8 per cent of examples belong to one class, a model can achieve 99.8 per cent accuracy by ignoring the other class entirely, and the training signal from the rare examples is drowned out. This is a problem about the balance of the dataset rather than its content. In principle, the information needed to recognise fraud is present in those 492 cases; the model simply has too little incentive to extract it. The second is a problem of coverage. Even a model that pays full attention to the rare class can only learn from the variety it has seen. If the 492 fraud cases come from a handful of attack patterns, the model will learn those patterns and miss others. If the forty rare lung scans come from two scanner models and a narrow age range, the model will not know what the condition looks like on a third scanner or in a child. This is a problem about content, and it is far harder. Rebalancing does nothing for it. Only new information about the unseen variety can help, and new information is exactly what a generator trained on the same forty scans does not have. Much of the confusion in discussions of synthetic data for imbalanced learning comes from treating these two problems as one. A technique that multiplies the rare class may cure the attention problem beautifully while leaving the coverage problem untouched, and the resulting model may look excellent on a test set drawn from the same narrow distribution while failing on the cases it was actually needed for. Scarcity by restriction The second kind of scarcity is legal and ethical. The data exists, sometimes in great quantity, but it cannot be used freely because it describes people. Health records are the archetype. A national health system may hold decades of detailed records on millions of patients, and the research value of that data is enormous. But access is restricted, and properly so. In the European Union and the United Kingdom, health data is a special category of personal data under the General Data Protection Regulation, and processing it requires both a lawful basis and one of a narrow set of additional conditions. In the United States, the HIPAA Privacy Rule governs how covered entities may use and disclose protected health information. Financial records, education records, location traces, and the contents of private communications are all subject to their own regimes, and many organisations add contractual and ethical constraints on top. These restrictions produce scarcity of a peculiar kind. The data is not rare in the world; it is rare in the hands of the people who could make use of it. A start-up developing a diagnostic tool may not be able to get access at all. A university group may wait a year for approval to use a dataset inside a secure research environment where nothing can be taken out. A hospital may be unable to share data with a hospital in another country, even for a joint study, because the transfer rules are complex and the risk of getting them wrong is high. There are established responses to this kind of scarcity: anonymisation, pseudonymisation, aggregation, secure research environments in which analysts can run code but not see or export individual records, and federated learning, in which models are trained across institutions without the data leaving each one. Synthetic data enters as another option, and an attractive one. If a model can learn the statistical structure of a sensitive dataset and then produce new records that preserve that structure without corresponding to any real person, the synthetic records might be shared, published and experimented with far more freely than the originals. The word "might" carries a great deal of weight in that sentence. Whether a synthetic dataset actually protects the people in its source data is not settled by the fact that it is synthetic. It depends on how the generator was trained, whether it memorised any records, how unusual the individuals in the source data were, and what an attacker could plausibly know. Chapter 6 treats this in detail. For now it is enough to note that restriction-driven scarcity is a different problem from rarity-driven scarcity. The goal is not to create more examples of something but to create a substitute that is safer to handle while remaining useful for the purpose at hand. Scarcity by danger and cost The third kind of scarcity arises when collecting the data would be dangerous, prohibitively expensive or simply impossible in the time available. Automated driving is the clearest case. In 2016 researchers at the RAND Corporation, Nidhi Kalra and Susan Paddock, asked how many miles an autonomous fleet would need to drive to demonstrate statistically that it was safer than human drivers. Because fatal crashes in the United States occur at a rate of roughly one per hundred million vehicle miles, the answer for demonstrating even parity with useful confidence ran to hundreds of millions of miles, and for demonstrating a meaningful improvement it ran to billions. Their conclusion was that test driving alone could not, in any practical time frame, establish the safety of an automated vehicle, and that other methods, simulation prominent among them, would be needed. The problem is sharper than the raw numbers suggest. The miles that matter are not average miles. A system that has driven a billion kilometres of clear motorway has learned little about a lorry shedding its load on a mountain pass in fog. And many of the most informative situations cannot ethically be staged with real people: nobody will arrange for a child to run in front of a test vehicle, or for a cyclist to swerve suddenly across its path, in order to check the response. Similar structures appear elsewhere. Robotics teams cannot afford to break thousands of real robots learning to walk, so they train in simulation first. Manufacturers testing visual inspection systems may have plenty of photographs of good parts but very few of a specific crack that occurs once in a hundred thousand units. Disaster response models need examples of floods and wildfires that, thankfully, happen rarely in any given place. Climate and epidemiological models need scenarios that have not occurred yet at all. In these settings synthetic data is not merely a convenience. It may be the only route to any data at all for the situations that matter most. That makes it more valuable and also more dangerous, because when the real data is absent, there is little to check the synthetic data against. Why "just collect more" often fails Faced with any of these forms of scarcity, the first answer should always be to ask whether more real data can be obtained. Synthetic data is a substitute, and substitutes are rarely as good as the real thing. It is worth being clear about why that answer so often fails before turning to the alternatives. For rarity, collecting more data means collecting proportionally more of everything. To double the number of fraud examples, a bank must wait twice as long, by which time the fraud patterns have changed. To double the number of rare lung scans, a hospital network must double the population it draws from, which may mean recruiting across countries and running straight into the restrictions above. Targeted collection, in which one deliberately seeks out the rare cases, helps a great deal where it is possible: clinical studies can recruit specifically for a rare condition, and driving programmes can route vehicles towards complex junctions. But targeted collection is slow and expensive, and it skews the data in ways that need careful handling. For restriction, collecting more means negotiating more access, which is a legal, ethical and institutional process rather than a technical one. It can and often should be done. But it takes time, and the outcome may still be access under conditions that make the data hard to use for development work. For danger and cost, collecting more is, by definition, the thing that cannot be done. There is also a quieter reason that more real data does not always help: labelling. Raw data is often abundant while labelled data is scarce. Millions of hours of dashcam video exist, but each frame must be annotated with the positions of cars, pedestrians, lane markings and signs before it can train a perception model, and careful annotation is slow and costly. Medical images need experts to label them, and experts are expensive and frequently disagree. One of the less glamorous but most commercially significant advantages of synthetic data is that it comes with perfect labels for free. A simulator that places a pedestrian at a given position knows exactly where that pedestrian is, down to the pixel, and can produce depth maps, segmentation masks and three-dimensional bounding boxes that would take a human annotator hours to draw. What synthetic data offers, and what it cannot Against this background, the appeal of synthetic data can be stated clearly. It offers control over the composition of a dataset, so that rare classes and rare situations can be represented as often as needed. It offers a way of sharing the statistical structure of sensitive data with reduced exposure of the individuals in it. It offers access to situations that cannot be collected safely or affordably. And it offers labels that are exact and free. What it cannot offer is a guarantee that any of this corresponds to the real world. Every synthetic sample is the output of a model, and the model was built from some combination of real data and human assumptions. A generative network trained on forty scans knows only what those forty scans contain, plus whatever biases its architecture and training procedure introduce. A driving simulator knows only the physics, the behaviour models and the visual appearance its developers put into it. When the synthetic data is used to train another model, that second model inherits all of the first model's knowledge and all of its blind spots. This is the principle that runs through the rest of the booklet. Synthetic data is a means of moving knowledge from where it is to where it is needed: from the majority of a dataset into its neglected minority, from a protected database into a shareable file, from an engineer's understanding of physics and traffic into examples a perception system can learn from. When the knowledge is genuinely there and the movement preserves it, synthetic data can be remarkably effective. When the knowledge is absent, or the movement distorts it, synthetic data produces confident models that are wrong in ways that are hard to see. A taxonomy to carry forward It helps to fix some vocabulary before going further, because the field uses words loosely. Data augmentation usually means creating modified copies of existing examples: cropping, rotating, recolouring, adding noise, or mixing two examples together. Augmented examples stay close to real ones. They teach a model to ignore variations that should not matter, such as the exact framing of a photograph, rather than showing it anything genuinely new. Oversampling means increasing the number of examples in a minority class, either by repeating existing ones or by creating new ones near them. It is a specific use of synthetic data aimed at the attention problem. Simulation means generating data from an explicit model of the process that produces it: a physics engine, a traffic model, a set of clinical rules about how diseases progress. Simulated data is only as good as the model behind it, but that model can be inspected, and its assumptions can be argued over. Generative modelling means learning a model of the data distribution from examples and then sampling from it. Generative adversarial networks and diffusion models are the leading examples. Generative models make few explicit assumptions about how the data arose; they learn what they can from the examples they are given, and their assumptions are hidden in their architecture and training procedure rather than written down. Fully synthetic data contains no real records at all; every row or image is generated. Partially synthetic data replaces only some values, typically the most sensitive or identifying ones, while leaving the rest real. Hybrid approaches mix real and synthetic records in one dataset, which is the norm when synthetic data is used to augment training sets. The boundaries between these categories blur in practice. Modern driving simulators use generative networks to make rendered scenes look more like camera footage. Modern oversampling may use a diffusion model rather than simple interpolation. But the distinction between learning a distribution from data and specifying it from knowledge remains useful, because it determines where the knowledge in the synthetic data comes from and therefore how it should be checked. The next chapter starts with the older, simpler methods, not out of historical piety but because they set the bar. A great many projects that reach for a deep generative model would have been served as well, or better, by a technique that can be explained in a paragraph. CHAPTER 2 The Baseline: Augmentation, Interpolation and Simulation Every field has a moment when a powerful new tool makes the old ones look quaint. In synthetic data, that moment came with generative adversarial networks around 2016 and arrived again with diffusion models around 2022. In both cases, the older methods did not stop working. They are cheaper, more transparent and often just as effective, and a serious practitioner treats them as the baseline that any deep generative approach must beat. This chapter describes them and explains what each can and cannot do. Augmentation: teaching a model what to ignore The oldest form of synthetic data is so routine that many practitioners do not think of it as synthetic at all. When a convolutional network is trained to classify images, each training image is typically flipped horizontally at random, cropped to a slightly different window, rotated a few degrees, darkened or brightened, or has its colours shifted. Each epoch of training therefore sees slightly different versions of the same pictures. The logic is straightforward. A cat is a cat whether it faces left or right, whether it fills the frame or sits in a corner, whether the photograph was taken in daylight or under a tungsten bulb. By showing the model many such variants, augmentation tells it that these changes do not alter the label. The model learns to be invariant to them and is less likely to latch onto accidental features of the training set, such as the fact that most of the cat photographs happened to be taken outdoors. Augmentation became more inventive through the 2010s. Cutout blanks a random square of the image so that the model cannot rely on any single region. Mixup blends two images and their labels in proportion, so that a picture that is seventy per cent cat and thirty per cent dog is labelled the same way. CutMix pastes a patch from one image onto another and mixes the labels according to the area. Automated methods such as AutoAugment and RandAugment search for the combination of transformations that works best for a given dataset. In audio, models are trained on recordings with added background noise, altered speed or shifted pitch. In text, sentences are paraphrased, translated into another language and back again, or have words swapped for synonyms. What unites these techniques is that each one encodes a piece of human knowledge about which variations are irrelevant to the task. That is both their strength and their limit. Flipping a chest X-ray horizontally may seem harmless, but the heart sits on the left, and a model trained on flipped images may learn that its position does not matter, which for some diagnoses is exactly wrong. Flipping a road scene teaches a driving model that traffic can come from either side, which is untrue in any given country. Augmentation is only as good as the knowledge behind the choice of transformations, and a careless choice teaches the model something false. More fundamentally, augmentation stays near the original examples. It cannot show the model a tumour in a location where none of the training tumours occurred, or a fraud pattern that none of the training frauds followed. It helps with robustness and with the attention problem to a modest degree. It does almost nothing for coverage. Interpolation: SMOTE and its descendants For tabular data, where geometric transformations make no sense, the classic approach to imbalance is the Synthetic Minority Over-sampling Technique, published by Nitesh Chawla and colleagues in 2002 and still one of the most widely used algorithms in applied machine learning. SMOTE works in the space of features. For each example in the minority class, it finds that example's nearest neighbours within the same class. It then picks one of those neighbours at random and creates a new example somewhere on the straight line between the two, at a randomly chosen point. Repeat this enough times and the minority class can be inflated to any desired size, filled out with points that lie between existing ones rather than exactly on top of them. The idea behind this is that the minority class occupies a region of feature space, and the existing examples are scattered samples from that region. Filling in the gaps between them gives the classifier a better sense of the region's extent and pushes the decision boundary outwards, away from the minority examples. Compared with simply duplicating minority examples, which tends to make the classifier draw tight boundaries around each one, SMOTE produces smoother and more general boundaries. The algorithm has well-known weaknesses. Interpolating between two points is only sensible if everything between them belongs to the same class, which is not true when the minority class is fragmented into several separate clusters or when it overlaps with the majority. SMOTE can create synthetic examples that sit in the middle of majority territory, confusing the classifier rather than helping it. It also handles categorical variables poorly: there is no meaningful point halfway between "card present" and "card not present", or between two postcodes. A family of variants addresses these problems. Borderline-SMOTE generates new examples only near the boundary between classes, where they are most informative. ADASYN generates more examples in regions where the minority class is hardest to learn. SMOTE-NC handles mixtures of numerical and categorical features. Combinations of SMOTE with cleaning methods such as Tomek links remove ambiguous points near the boundary after oversampling. The open-source imbalanced-learn library in Python implements most of these and has made them a standard part of the toolkit. The deeper limitation is the same as for augmentation. SMOTE can only create points within the convex region spanned by existing minority examples. It is a method of redistribution, not of discovery. If the training data contains three kinds of fraud, SMOTE will produce more of those three kinds and blends between them. It will not produce a fourth. It is also worth noting a result that recurs throughout the imbalanced learning literature and that surprises many newcomers: for strong modern classifiers, particularly gradient-boosted trees, simple remedies such as weighting the minority class more heavily in the loss function, or adjusting the decision threshold after training, often match or beat SMOTE. Several systematic comparisons have reached roughly this conclusion. The attention problem, in other words, can frequently be fixed without generating any data at all. That does not make synthetic oversampling useless, but it does mean that any proposed generator must be compared against these cheap alternatives, not just against doing nothing. Statistical and rule-based generators A different tradition, rooted in statistics and official data rather than machine learning, has long produced synthetic datasets for privacy purposes. The idea was proposed by Donald Rubin in 1993 in the context of census and survey data: rather than releasing real microdata, an agency could fit a statistical model to it and release draws from that model, which analysts could use to estimate the same quantities they would have estimated from the real data. Roderick Little proposed partially synthetic data, in which only sensitive values are replaced, around the same time. Statistical agencies have since released several such products. The United States Census Bureau, for instance, has produced synthetic versions of linked survey and administrative data, such as the SIPP Synthetic Beta, with a validation service that lets researchers check results obtained on the synthetic data against the confidential original. These statistical generators typically model the data one variable at a time, conditioning each on those already generated, using regression models, classification trees or similar tools. The approach is often called sequential or fully conditional synthesis. The open-source synthpop package for R implements it and is widely used in social science. Another approach, implemented in the Synthetic Data Vault project from MIT, uses copulas, a statistical device for modelling how variables depend on one another separately from how each is distributed on its own. These methods have real virtues. They are relatively transparent: one can inspect the conditional models and see what relationships they encode. They are fast and need modest data. They do well at preserving the low-order statistics, means, variances, correlations and two-way tables, that many analyses rely on. Their weaknesses are the mirror image: they can miss complex interactions among many variables, and their quality depends on the modeller's choices about order and model form. A further tradition generates records from explicit domain rules rather than from data at all. Synthea, an open-source project developed by MITRE, simulates the lifetimes of synthetic patients. Each patient is born, ages, and moves through modules representing diseases and care pathways, with transitions governed by probabilities drawn from public health statistics and clinical guidelines. The output is a complete synthetic health record, with encounters, diagnoses, medications and procedures, in standard formats. Because no real patient record is used to train it, Synthea data carries essentially no privacy risk from the source data. Because it is built from rules rather than observations, it carries no subtle real-world correlations either; it reflects exactly what its modules encode. It is excellent for testing software that consumes health records, for teaching, and for prototyping. It is not a substitute for real data when the question is how real patients actually behave. In England, the cancer registry's synthetic dataset known as the Simulacrum takes a middle path. It was built by Health Data Insight in partnership with what was then Public Health England, using statistical models fitted to the national cancer registration data and released so that researchers can develop and test their analysis code on realistic synthetic data before requesting access to run it against the real records. That workflow, synthetic data for development and real data for the final answer, is one of the most robust uses of synthetic data in sensitive domains, and it recurs in later chapters. Simulation from first principles The final baseline is the one that dominates in robotics and automated driving: simulation built from explicit models of physics, geometry and behaviour. A driving simulator such as the open-source CARLA, released in 2017 by researchers at Intel Labs, the Toyota Research Institute and the Computer Vision Center in Barcelona, builds three-dimensional towns in a game engine, populates them with vehicles and pedestrians controlled by behaviour models, simulates cameras, lidar and radar, and lets an automated driving system drive through them. Commercial platforms from a range of vendors do the same at higher fidelity and with tools for building specific scenarios. Robotics teams use physics engines such as MuJoCo or NVIDIA's Isaac Sim to train manipulators and walking robots before they touch hardware. Simulation's great strength is control. An engineer can specify exactly what happens, vary any parameter, repeat a scenario thousands of times with small changes, and obtain perfect ground-truth labels for every frame. Simulation can produce situations that are too dangerous or rare to collect, and it can do so at a scale limited only by computing power. Waymo reported in 2019 that its vehicles had driven ten billion miles in simulation, against a far smaller number on public roads. Simulation's great weakness is the reality gap. A model trained on rendered images may fail on real camera footage, because the rendered images differ in subtle ways: textures are too clean, lighting is too simple, sensor noise is missing or wrong, and the behaviour of simulated agents is too predictable. A robot policy trained in a physics engine may fail on hardware because friction, motor response and contact dynamics are modelled imperfectly. Two classic responses to the reality gap illustrate the two strategies that run through the whole field. The first is to make the simulation more realistic, investing in better rendering, better sensor models and better physics. The second, called domain randomisation and popularised by Josh Tobin and colleagues at OpenAI in 2017, takes the opposite approach: rather than trying to match reality precisely, randomise the simulation's textures, lighting, colours, camera positions and physical parameters so widely that reality looks like just another variation. A model that has learned to pick up objects under thousands of bizarre colour schemes and lighting conditions may treat the real world as one more unusual setting. Domain randomisation proved strikingly effective for some robotic tasks, and its logic, that diversity can substitute for fidelity, reappears in later chapters. Choosing among the baselines: an inspection line A concrete case shows how these methods divide the work. Consider a manufacturer that wants a camera system to spot hairline cracks in cast metal brackets on a production line. It has photographed a hundred thousand good brackets and has eighty photographs of cracked ones, collected over two years. The cracks vary in length and position, but nearly all were photographed under the same lights, on the same conveyor, by the same camera. Augmentation is the obvious first step, but the choice of transformations needs thought. Small rotations and shifts are safe, because brackets do sit at slightly different angles on the belt. Brightness and contrast changes are safe within the range the factory lights actually produce. Horizontal flips are safe only if the bracket is symmetrical; if it is not, a flipped image shows a part that does not exist. Heavy blurring may be harmful, because a hairline crack blurred away is no longer a crack, and the model would be taught that an unmarked bracket can be labelled defective. Each of these choices is a judgement about what the real variation on the line looks like, and the people best placed to make it are the line engineers, not the data scientists. SMOTE is of little use here. Interpolating the pixel values of two crack images produces a faint superposition of two cracks, which is neither realistic nor informative. A simpler kind of synthesis often works better. Engineers can cut the crack regions out of the eighty defect images and paste them, with careful blending, onto images of good brackets at positions and orientations where cracks are physically plausible, such as along the stress lines near the mounting holes. This copy-paste augmentation draws its knowledge from two sources at once: the real appearance of cracks, from the eighty images, and the engineers' understanding of where cracks form, from metallurgy and experience. It can multiply the defect class many times over at almost no cost, and its assumptions can be written down and checked. Simulation is a further option. A three-dimensional model of the bracket, rendered with the factory's lighting and camera parameters, can be given procedurally generated cracks of any length and shape. This reaches crack geometries that the eighty photographs never showed. It also opens the reality gap: rendered metal does not quite look like photographed metal, and a model trained heavily on renders may learn to detect rendering artefacts rather than cracks. The sensible sequence is to start with careful augmentation and copy-paste, measure performance on a set of real cracked brackets held back from all synthesis, and only then decide whether simulation or a learned generator would add enough to justify its cost. Very often the cheap methods close most of the gap, and the remaining errors point to a need for more real examples of particular crack types rather than for a more elaborate generator. What the baselines teach Taken together, the baseline methods set out the whole landscape of synthetic data in miniature. Augmentation and interpolation work close to the real examples and redistribute what is already there. Statistical generators learn a distribution from data and resample it, offering a path to sharing data with reduced privacy risk. Rule-based generators and physical simulators encode human knowledge explicitly and can reach situations that no data contains, but only as far as that knowledge is correct. The deep generative models of the next two chapters do not change this landscape. They change the position of the boundaries within it. They can learn far more complex distributions than any hand-built statistical model, capturing the texture of a skin lesion or the joint pattern of fifty variables in a patient record. They can be conditioned on labels and descriptions, so that one can ask for a specific kind of sample. And they can be combined with simulators to close the reality gap. But they are still models learned from data, and everything they know, they learned from the examples they were shown. CHAPTER 3 Adversarial Generators In 2014 Ian Goodfellow and colleagues at the Université de Montréal published a paper describing a new way to train a generative model. The idea was strikingly simple. Instead of writing down a formula for how good a generated sample is, let a second network learn to judge. One network, the generator, takes random numbers as input and turns them into samples. The other, the discriminator, is shown a mix of real samples and generated ones and must say which is which. The generator is trained to fool the discriminator; the discriminator is trained not to be fooled. As each improves, the other must improve to keep up. If all goes well, the contest ends with a generator whose samples the discriminator cannot distinguish from real data. The paper called these models generative adversarial networks, and within a few years they had transformed what machine-generated images could look like. By 2019 NVIDIA's StyleGAN could produce photographs of human faces that most viewers could not tell from real ones. GANs were applied to medical images, satellite imagery, fashion, art, music, and, of particular interest here, to the generation of synthetic training data. Although diffusion models have since displaced them for most image generation tasks, GANs remain in use, particularly for tabular and time-series data and in settings where fast sampling matters, and understanding them makes clear what any generative model must achieve. How the contest works It helps to follow the training process in detail, without equations. The generator is a neural network that maps a vector of random numbers, usually drawn from a standard bell-shaped distribution and called the latent vector, to a sample in the data space, for example an image of a fixed size. At the start of training its weights are random, so its outputs are noise. The discriminator is another neural network that takes a sample and outputs a single number, its estimate of the probability that the sample is real. Training alternates between the two. In one step, the discriminator is shown a batch of real images and a batch of images freshly produced by the generator, and its weights are adjusted to make it better at telling them apart. In the next step, the discriminator is held fixed and the generator's weights are adjusted so that its outputs receive higher "real" scores from the discriminator. Crucially, the generator never sees a real image directly. Everything it learns about the data comes through the discriminator's judgements, passed back to it as gradients that tell it which small changes to its output would make that output look more real. Goodfellow and colleagues showed that, in an idealised setting with unlimited capacity and perfect optimisation, this game has a unique equilibrium in which the generator's distribution exactly matches the real data distribution and the discriminator can do no better than guess. That theoretical result is reassuring, but it says nothing about whether real networks trained with real optimisers will reach the equilibrium, and in practice they often do not. Why GANs were hard to train The history of GANs between 2014 and about 2019 is in large part a history of attempts to make training stable. Three failure modes were notorious. The first is non-convergence. Because two networks are optimising opposing objectives, training does not settle into a minimum the way an ordinary model does. It can oscillate, with the generator and discriminator chasing each other in circles, or diverge entirely. The second is vanishing gradients. If the discriminator becomes too good too quickly, it confidently rejects every generated sample, and the signal it passes back to the generator becomes too weak to indicate how to improve. The generator stalls. The third, and the most important for synthetic data, is mode collapse. A real dataset has many modes: many distinct kinds of sample. A dataset of faces includes old and young people, many skin tones, glasses and no glasses, smiles and frowns. A generator that has found one kind of face that reliably fools the discriminator has no direct incentive to produce the others. It can collapse onto a narrow range of outputs, sometimes producing almost the same image for every input. Partial mode collapse, in which the generator covers the common modes but drops the rare ones, is subtler and more common, and it is precisely the wrong behaviour for a tool meant to help with rare cases. A GAN asked to model a dataset in which a rare subtype appears in two per cent of examples may simply never generate that subtype. A long list of remedies emerged. The DCGAN architecture of Alec Radford and colleagues in 2015 established design conventions for convolutional generators and discriminators that trained more reliably. The Wasserstein GAN of Martin Arjovsky and colleagues in 2017 replaced the discriminator's real-or-fake classification with a smoother measure of distance between distributions, which gave more useful gradients even when the two distributions were far apart; a follow-up added a gradient penalty that made it more stable still. Spectral normalisation constrained the discriminator's sensitivity. Progressive growing, introduced by Tero Karras and colleagues at NVIDIA, started training at low resolution and added layers gradually, which made high-resolution faces achievable. StyleGAN and its successors reorganised the generator so that different layers controlled different levels of detail, from overall pose to fine texture. These techniques worked, but they left GAN training as something of a craft. Results depended on architecture choices, learning rates and many small details, and a model that trained well on one dataset might fail on another. For practitioners generating synthetic training data in specialised domains with small datasets, that fragility was a real cost. Conditional GANs: asking for what you want For synthetic data generation, an unconditional generator that produces random samples is of limited use. One usually wants samples of a particular kind: a fraudulent transaction, a scan showing a specific lesion, a street scene at night. Conditional GANs, introduced by Mehdi Mirza and Simon Osindero in 2014, address this by feeding a label or other condition to both networks. The generator receives the label alongside its random input and must produce a sample of that class; the discriminator receives the label alongside the sample and must judge whether it is a real sample of that class. With a conditional GAN trained on a labelled dataset, one can request as many examples of the minority class as needed. A related family translates one kind of image into another. The pix2pix model of Phillip Isola and colleagues, published in 2017, learns a mapping from paired examples, for instance from semantic label maps to photographs, so that a simple drawing of where roads, cars and buildings should be can be turned into a realistic street scene. CycleGAN, from Jun-Yan Zhu and colleagues in the same year, learns such mappings without paired examples, by requiring that translating an image to the other domain and back again should recover the original. CycleGAN made it possible to turn summer scenes into winter ones, or simulated driving images into ones that looked more like real camera footage, which made it an early tool for narrowing the reality gap discussed in the previous chapter. In medical imaging, conditional and translation GANs were applied quickly. A frequently cited early study by Maayan Frid-Adar and colleagues, published in Neurocomputing in 2018, used GANs to generate synthetic CT images of liver lesions in three categories and reported that adding them to a small training set of 182 lesions improved classification sensitivity and specificity compared with classic augmentation alone. Studies along similar lines followed for skin lesions, chest X-rays, brain MRI, retinal images and histopathology slides. Many reported gains; many were small and from single institutions; and few tested whether the gains held up on data from other hospitals. Chapter 5 returns to the question of how to read this evidence. GANs for tables and time series Images are the natural home of GANs, but much of the data that organisations actually hold is tabular: rows of records with a mixture of numerical and categorical columns. Tabular data poses problems that images do not. Numerical columns often have strange distributions, with several peaks, long tails or a large spike at zero. Categorical columns may have many categories, some very rare. And the relationships between columns are often the whole point of the data. The most influential response was CTGAN, introduced by Lei Xu and colleagues at MIT in 2019 as part of the Synthetic Data Vault project. CTGAN made two key changes. First, it represented each numerical column using a technique called mode-specific normalisation, which fits a mixture of bell curves to the column and encodes each value by which curve it belongs to and where it falls within that curve; this allows the generator to reproduce multi-peaked distributions. Second, it addressed imbalance in categorical columns with a conditional generator and a training-by-sampling scheme: during training, it deliberately samples categories evenly so that the generator learns to produce rare categories as well as common ones, then corrects for this at generation time. The same paper introduced a variational autoencoder alternative, TVAE, and a benchmark on which, notably, TVAE often performed as well as or better than CTGAN. Sequential data, such as patient vital signs over time, sensor readings or transaction histories, adds a further challenge: the generator must capture not just what each step looks like but how steps follow each other. TimeGAN, published by Jinsung Yoon, Daniel Jarrett and Mihaela van der Schaar in 2019, combined adversarial training with a supervised loss that taught the model to predict the next step, encouraging it to learn realistic temporal dynamics. Privacy-oriented GANs also appeared. PATE-GAN, from James Jordon, Jinsung Yoon and Mihaela van der Schaar in 2019, trained the discriminator using an approach called Private Aggregation of Teacher Ensembles, so that the generator would satisfy the formal guarantee of differential privacy discussed in Chapter 6. DP-GAN variants added carefully calibrated noise to the gradients during training for the same purpose. These methods trade some fidelity for a mathematical bound on how much any one record can influence the result. A tabular GAN at work It helps to follow what happens when a team actually applies a tabular GAN. Suppose a hospital analytics group wants to share a table of emergency admissions with an external modelling partner. Each row is an admission, with columns for age, sex, arrival mode, triage category, length of stay, a handful of laboratory values, the primary diagnosis code and whether the patient was readmitted within thirty days. Several features of this table are awkward for a generator. Length of stay has a large spike at zero days for patients discharged the same day, a broad hump around two to five days, and a long tail of patients who stay for weeks. A single bell curve cannot describe that shape, which is why CTGAN's mode-specific normalisation exists: it lets the generator place a value in one of several humps and then position it within that hump. The diagnosis code may have hundreds of categories, many appearing only a few times. Without CTGAN's training-by-sampling, the generator would learn the common diagnoses and largely ignore the rest, because the discriminator rarely sees enough rare ones to penalise their absence. And the relationships among columns are clinically meaningful: certain laboratory values go with certain diagnoses, older patients stay longer, and readmission depends on a mix of all of these. After training, the team would check the synthetic table in layers. Do the individual columns have the right shapes, including the spike at zero and the long tail? Are the rare diagnoses present at roughly the right rates? Do the main correlations hold, such as that between age and length of stay? Are there synthetic rows that combine attributes in clinically impossible ways, such as a pregnancy-related diagnosis on a male patient, or a laboratory value far outside the range compatible with life? Generators trained without explicit constraints produce such rows with some regularity, because nothing in the adversarial objective forbids them unless the discriminator happens to learn to spot them. Many tools now allow logical constraints to be specified and enforced, which is another instance of expert knowledge supplementing what is learned from data. Finally, the team would need to check that no synthetic row is a near-copy of a real admission, a question that belongs to Chapter 6. A generator that reproduces an unusual real patient, an elderly person with a rare diagnosis and an exceptionally long stay, has created a privacy problem precisely where it seemed to be doing its best work. What the generator actually learns It is worth pausing on a point that matters for every application in later chapters. A GAN's generator learns to produce samples that its discriminator cannot distinguish from training samples. That is a statement about the training set, not about the world. If the training set over-represents one hospital's scanner, the generator will reproduce that scanner's characteristics. If the training set contains forty examples of a rare condition, the generator's idea of that condition is formed entirely from those forty. There are two ways a GAN trained on a small set can go wrong, and they pull in opposite directions. It can underfit, failing to capture the real variety even within the training set, which shows up as mode collapse and blurry or repetitive samples. Or it can overfit, memorising training samples and reproducing near-copies of them. With very small datasets, the discriminator itself tends to overfit, essentially learning to recognise the specific training images, and the generator in turn learns to reproduce them. Techniques such as adaptive discriminator augmentation, introduced by Karras and colleagues in 2020, help by augmenting the images seen by the discriminator so that it cannot simply memorise them. But the fundamental tension remains. A generator that is too faithful to its training set is a privacy hazard and adds little new; one that is too loose produces samples that do not reflect the data. The generator's samples between the training examples are, in a sense, its guesses about what the space between them looks like. Those guesses can be good. A model trained on many faces can produce new faces that are plausible combinations of features it has seen. But plausible to a discriminator is not the same as correct. A synthetic CT image might look entirely convincing to a human reader and to the discriminator while containing anatomically impossible details that a diagnostic model then learns from. This is one reason why careful practitioners treat synthetic medical images as a supplement to real data rather than a replacement, and why they validate models trained with synthetic data on real held-out data from different sources. Where GANs stand now From around 2021, diffusion models overtook GANs on the main image generation benchmarks, and the bulk of research attention moved with them. The reasons, explored in the next chapter, include more stable training, better coverage of the data distribution, and easier conditioning on text and other inputs. GANs did not vanish. They remain much faster at generation, producing a sample in a single pass through the network rather than the dozens or hundreds of steps a diffusion model may need, and that speed matters for some applications. They remain widely used for tabular data, where CTGAN and its relatives are standard options in open-source and commercial tools. And adversarial training lives on as a component inside other systems, including some fast diffusion samplers that use a discriminator to refine their outputs. The lasting contribution of GANs to synthetic data is perhaps less a technique than a demonstration. They showed that a neural network could learn a data distribution complex enough to produce convincing photographs, scans and records, and in doing so they made the promise of synthetic training data concrete. They also revealed, through mode collapse and memorisation, the two failures that every generator must guard against: missing the rare cases, and copying the real ones. The next chapter shows how diffusion models changed the balance between those two failures without removing either. CHAPTER 4 Diffusion Models Imagine taking a photograph and adding a tiny amount of random static to it. Then a little more, and a little more, over a thousand small steps, until nothing remains but noise indistinguishable from any other noise. Each step is easy to describe and easy to compute. Now imagine running the process backwards: starting from pure static and, step by step, removing a little noise at a time until a photograph emerges. If a neural network could learn to perform one backward step, removing a small amount of noise from a slightly noisy image, then chaining a thousand such steps would turn random static into a new image. That is the core idea of diffusion models. It was introduced in 2015 by Jascha Sohl-Dickstein and colleagues, drawing on ideas from statistical physics, and developed in parallel through score-based models by Yang Song and Stefano Ermon from 2019. It became practical with the paper "Denoising Diffusion Probabilistic Models" by Jonathan Ho, Ajay Jain and Pieter Abbeel in 2020, which showed that a simplified training procedure produced image quality competitive with the best GANs. Within two years, diffusion models had become the dominant approach to image generation, and they now underpin widely used text-to-image systems as well as a growing range of synthetic data tools for medicine, science and engineering. How a diffusion model learns The training procedure is, by the standards of GANs, remarkably calm. Take a real image from the training set. Choose a random step in the noising process, say step 400 of 1,000. Add the amount of random noise corresponding to that step; because the noise is drawn from a known distribution, this can be done in a single calculation rather than by actually running 400 steps. Now show the noisy image and the step number to a neural network and ask it to predict the noise that was added. Compare its prediction to the actual noise and adjust its weights to reduce the error. Repeat with millions of images and randomly chosen steps. That is the whole training loop. There is one network, not two. There is no adversary, no game, and no risk of one player overpowering the other. The objective is an ordinary prediction error that decreases steadily as the network improves. This simplicity is a large part of why diffusion models displaced GANs: they train reliably across datasets and scales without the delicate balancing that GANs required. Generation runs the process in reverse. Start with pure random noise. Ask the network to predict the noise in it, and subtract a portion of that prediction, along with a small amount of fresh randomness, to obtain a slightly less noisy image. Repeat for each step down to zero. At each step the network sees an image that is a little clearer than before and makes a slightly more detailed prediction. Early steps establish overall composition and layout; later steps fill in texture and fine detail. There is a useful way to understand what the network is learning. Predicting the noise in a noisy image is equivalent to estimating which direction, in the space of all possible images, leads towards more probable images. Score-based models make this explicit: the network learns the score, a kind of gradient field that points from any image towards regions where real images are dense. Generation then amounts to starting somewhere random and following the field, with some added randomness, until arriving in a region of realistic images. Because the field is learned across the whole space at many noise levels, the generator can reach all the regions where data lies, not just the easiest ones. Why diffusion displaced GANs Three properties made diffusion models the preferred choice for most image synthesis by about 2022. The first, already discussed, is stable training. The second is coverage. Because diffusion models are trained to denoise every training example at every noise level, they are pushed to model the whole data distribution, including its less common regions. In a well-known 2021 paper, Prafulla Dhariwal and Alex Nichol at OpenAI showed that diffusion models could beat the best GANs on standard image benchmarks, and subsequent work found that they tended to produce more diverse samples, covering more of the modes that GANs dropped. For synthetic data aimed at rare cases, this is exactly the property one wants, though it is not a guarantee: a mode with very few training examples is still learned from very few examples. The third is conditioning. Diffusion models can be guided towards particular kinds of output with great flexibility. The simplest approach trains the network with the condition, a class label or a text description, as an additional input. Classifier-free guidance, introduced by Jonathan Ho and Tim Salimans, trains a single network both with and without the condition and then, at generation time, extrapolates from the unconditional prediction towards the conditional one, which strengthens the effect of the condition at the cost of some diversity. The strength of this extrapolation, the guidance scale, is a dial between faithful-but-varied and vivid-but-stereotyped samples, and its setting turns out to matter a great deal for synthetic training data: high guidance produces images that strongly match the label but cluster around a prototype, which can reduce the variety a downstream classifier needs. The main cost of diffusion models is speed. Generating a sample requires many passes through the network, one per step, where a GAN needs only one. Much research since 2020 has reduced this cost. Improved samplers cut the number of steps from a thousand to a few dozen. Distillation methods train a fast student model to imitate many steps of a slow teacher in a few, or even one. Latent diffusion, introduced by Robin Rombach and colleagues in 2022 and the basis of the Stable Diffusion family, runs the diffusion process not on full-resolution pixels but in a compressed representation produced by a separate autoencoder, which makes training and sampling far cheaper and made high-resolution generation feasible on ordinary hardware. Table 1 sets the main families of generator side by side on the properties that matter most when the goal is synthetic training data rather than impressive pictures. Table 1. Families of synthetic data generator compared. Generator family Training behaviour Coverage of rare modes Sampling speed Typical synthetic-data use Statistical (sequential models, copulas) Fast, transparent Good for low-order statistics; weak on complex interactions Very fast Official and survey microdata; tabular sharing Variational autoencoder Stable Moderate; samples often blurry Fast Tabular data (TVAE); compressed latents for other models Generative adversarial network Unstable; sensitive to settings Prone to dropping modes Very fast (single pass) Tabular (CTGAN), time series, image translation Diffusion model Stable Generally better than GANs Slow, improved by distillation Images, medical scans, increasingly tabular and video Diffusion for structured and scientific data Although diffusion models were developed for images, the underlying idea, learning to reverse a noising process, applies to any kind of data for which a sensible noising process can be defined. For tabular data, TabDDPM, published by Akim Kotelnikov and colleagues in 2023, applied ordinary diffusion to numerical columns and a related process for categorical ones, in which categories are gradually randomised rather than blurred. On a benchmark of tabular datasets, it outperformed CTGAN and TVAE on the usefulness of its synthetic data for training downstream models, though the authors also noted that interpolation-based SMOTE remained a surprisingly strong competitor and, by some measures, raised privacy concerns of its own by generating points very close to real ones. Several later tabular diffusion models have built on this work, and commercial synthetic data platforms now offer diffusion-based generators alongside GAN-based and statistical ones. For medical imaging, diffusion models have been trained to generate chest X-rays, brain MRI, retinal photographs, dermatology images and histopathology tiles, often conditioned on diagnoses or on text drawn from radiology reports. Researchers have adapted latent diffusion models, originally trained on internet images, to medical domains by fine-tuning them on comparatively small sets of medical images with their reports. The generated images can be strikingly realistic. Whether they are clinically correct is a separate question that requires expert review, and published evaluations increasingly include blinded reading by radiologists alongside automated metrics. For video and driving scenes, diffusion models have been extended to generate sequences of frames that remain consistent over time, conditioned on maps, object layouts, or the actions of the vehicle. These world models, discussed in Chapter 7, are among the most active areas of research in automated driving. In the sciences, related models generate protein structures, candidate molecules and weather fields. The common thread is the same: a learned model of a complex distribution that can be sampled under specified conditions. Synthetic images as training data: what the evidence shows A natural question is whether images generated by large text-to-image diffusion models can replace or supplement real training data for ordinary classification tasks. A body of research since 2022 has tested this directly. Ruifei He and colleagues, in a paper presented at ICLR 2023 titled "Is synthetic data from generative models ready for image recognition?", found that synthetic images from a text-to-image model could substantially improve classifiers in settings with no or very few real examples, and helped somewhat with pre-training, but that a model trained only on synthetic images still fell short of one trained on the equivalent real data. Shekoofeh Azizi and colleagues at Google reported in 2023 that fine-tuning a diffusion model on ImageNet and then adding its generated images to the real training set improved ImageNet classification accuracy. Brandon Trabucco and colleagues proposed DA-Fusion, which uses a diffusion model to edit existing images so as to change their appearance while preserving their class, and showed gains in few-shot classification, including on a dataset of a weed species that the base model had never seen. A pattern emerges from this work. Synthetic data from diffusion models helps most when real data is very scarce, when the generator has been adapted to the target domain, and when the synthetic data is used alongside real data rather than instead of it. It helps less, and can even hurt, when used alone, partly because of a subtle distribution gap: generated images differ from real ones in systematic ways, including a tendency towards prototypical, well-lit, centred compositions, that a classifier can learn to depend on. Diversity of the synthetic set matters as much as its realism, and techniques that increase diversity, such as varied prompts and lower guidance, often help more than techniques that make each image more polished. There is also a question of where the generator's knowledge came from. A large text-to-image model has been trained on billions of internet images. When it is used to generate training data for a new classifier, some of that broad knowledge flows into the classifier, which is part of why it helps. But this means the classifier's performance gain is partly a transfer of knowledge from the generator's training data, not a creation of new knowledge. That is fine, and often useful, but it should be understood clearly, particularly when the generator's training data has unknown provenance, may include copyrighted material, or may already contain the test images being used for evaluation. Adapting a large model to a small domain Because training a high-quality diffusion model from scratch requires a great deal of data and computation, most synthetic data work in specialised domains now starts from a model pre-trained on a large general corpus and adapts it. Several adaptation techniques have become standard, and they differ in how much of the original model they change. Full fine-tuning continues training all of the model's weights on the new data. It gives the model the most freedom to learn the new domain and the most freedom to forget what it knew, and with very small datasets it tends to overfit and memorise. Lighter methods change only a small part of the model. Low-rank adaptation, usually called LoRA, adds small trainable matrices alongside the model's existing weights and trains only those, leaving the original untouched; it is cheap, and adaptations can be swapped in and out. DreamBooth, introduced by researchers at Google in 2022, fine-tunes a model on a handful of images of a specific subject, tying it to a rare identifier word, while also training on generated images of the general class to stop the model forgetting what that class looks like in general. Textual inversion leaves the model's weights alone and learns only a new word embedding that, when used in a prompt, evokes the subject of a few example images. Consider a dermatology group with a few hundred images of a rare inflammatory skin condition and many thousands of images of common conditions. A reasonable approach is to adapt a pre-trained latent diffusion model on the full dermatology collection, conditioning on diagnosis and on attributes such as body site and skin tone, so that the model learns the general appearance of skin under clinical photography. The rare condition then shares much of the model's capacity with conditions it resembles, which helps it generate plausible variety from few examples. At generation time, the group requests images of the rare condition across a range of body sites and skin tones, with a moderate guidance scale to preserve diversity. What the group must then do is check. Dermatologists review a sample of generated images for diagnostic fidelity: does the lesion actually look like the condition, or like a generic rash? Images are compared with the training set to catch near-copies. And the classifier trained with the synthetic images is tested on real images, ideally from another clinic, separately for each skin tone. If the synthetic images helped for light skin but not for dark, the generator has probably not learned how the condition presents on darker skin, and no amount of generation will fix that; the group needs real examples. This sequence, adapt broadly, generate with diversity, review with experts, test on independent real data, is the pattern that the most credible applied work follows. It reflects the fact that the generator's value lies mostly in the knowledge it brings from its pre-training and from the related classes in the domain, not in the few rare examples alone. Memorisation in diffusion models The stability and coverage of diffusion models came with a cost that became clear in 2023. Nicholas Carlini and colleagues, in a paper titled "Extracting Training Data from Diffusion Models", generated very large numbers of images from publicly released diffusion models and searched them for near-copies of training images. They found that the models could reproduce a small number of training images almost exactly, particularly images that appeared many times in the training data. Around the same time, Gowthami Somepalli and colleagues reported that diffusion models sometimes replicated substantial portions of training images, and that the risk was higher with smaller training sets. The proportion of generated images that copy training data is low for large models trained on vast datasets. But the finding matters enormously for synthetic data aimed at privacy, because the datasets used in sensitive domains are typically small, and small datasets are exactly where memorisation is most likely. A diffusion model fine-tuned on a few thousand patient scans can, in principle, reproduce one of them. Chapter 6 discusses how to test for this and what to do about it. The generator's knowledge budget The main lesson of the last two chapters is that both major families of deep generator learn a model of their training data, and that their outputs are bounded by what that data contains. Diffusion models cover the training distribution more completely than GANs, which makes them better at producing examples of rare classes that appear in the training data. They can combine concepts they have learned separately, which lets them generate, for instance, a lesion type on a skin tone that never appeared together in training, if both were learned well enough independently. Whether such combinations are realistic depends on whether the combination behaves like the sum of its parts, which in medicine and in physics is often not the case. Neither family can learn something absent from its training data. When a generator produces an image that looks like a new kind of rare case, it is either recombining what it has seen or inventing details that may be wrong. With that in mind, the next three chapters take the applications in turn, starting with the one where synthetic data has been used longest: correcting the imbalance between common and rare classes. CHAPTER 5 Balancing the Minority Class Class imbalance is the oldest and most common reason practitioners reach for synthetic data. The appeal is obvious. A fraud model sees 500 frauds and 280,000 legitimate transactions; generate another 50,000 frauds and the problem seems to disappear. A dermatology model has few images of melanoma on darker skin; generate more and the model's performance gap seems to close. The reality is more interesting. Synthetic oversampling sometimes helps a great deal, sometimes helps not at all, and sometimes makes things worse while appearing to make them better. The difference lies in which of the two problems from Chapter 1, attention or coverage, is actually holding the model back, and in whether the evaluation is honest. First, decide what "better" means Before any data is generated, it is essential to be clear about what the model is for and how its performance will be judged, because imbalance changes the meaning of the usual metrics. Accuracy is nearly useless. On the card fraud benchmark, a model that labels everything legitimate is 99.8 per cent accurate. More informative are measures that look at the minority class directly: recall (the proportion of real frauds the model catches), precision (the proportion of flagged transactions that are actually fraud), and summaries of the trade-off between them across all possible decision thresholds, such as the area under the precision-recall curve. The widely reported area under the ROC curve can look flattering under heavy imbalance, because it rewards the model for correctly ranking the enormous number of easy negatives. Beyond the metric lies the decision. A fraud team that can review a thousand alerts a day needs a model whose top thousand alerts contain as many frauds as possible. A screening programme for a serious disease may accept many false alarms to miss very few cases. These operational constraints determine the right threshold, and the right threshold determines which model is better. A surprising number of published comparisons of oversampling methods report results at a single default threshold of 0.5, which is rarely the threshold anyone would use in practice. When thresholds are tuned properly, many apparent gains from oversampling shrink or vanish. This last point deserves emphasis because it explains much of the field's mixed evidence. A model trained on a dataset rebalanced to 50:50 will produce higher predicted probabilities for the minority class than one trained on the original 1:600 ratio. At a fixed threshold of 0.5, the rebalanced model flags far more cases and therefore has much higher recall. That looks like an improvement. But the original model, with its threshold lowered to match, might achieve the same recall at the same precision. What looks like the effect of synthetic data is, in such cases, merely the effect of moving the threshold. Studies that tune thresholds on validation data for every method are much more reliable guides. The cheap alternatives Because of this, any synthetic oversampling approach should be compared against the alternatives that cost nothing to generate. Table 2 summarises the main options, roughly in order of cost. Table 2. Responses to class imbalance compared. Approach What it changes Addresses attention Addresses coverage Main risk Threshold tuning Decision rule after training Yes No Needs a reliable validation set Class weighting Loss function during training Yes No Can overfit rare examples Random oversampling Repeats minority examples Yes No Tight boundaries around duplicates SMOTE and variants Interpolates between minority neighbours Yes Marginally Points placed in majority regions Deep generative oversampling (GAN, diffusion) Samples new minority examples from a learned model Yes Only by recombining learned features Unfaithful samples; memorisation; high cost Targeted real collection Acquires more real minority cases Yes Yes Slow and expensive The table makes one thing plain: of all the options, only real data reliably addresses coverage. Generative models occupy a middle position. They can do something interpolation cannot, producing samples with genuinely new combinations of learned features, but they cannot supply information about variations the training data never showed. In practice, for tabular problems with modern gradient-boosted trees, a combination of class weighting and threshold tuning is a strong baseline that many sophisticated oversampling schemes fail to beat. A 2022 study by Yotam Elor and Hadar Averbuch-Elor, examining a large set of imbalanced tabular datasets, concluded that for strong classifiers, balancing techniques including SMOTE offered little benefit over tuning the decision threshold, while they could help weaker classifiers. Results of this kind do not mean that synthetic oversampling never helps; they mean that its benefit must be demonstrated rather than assumed. An illustration of the threshold trap A hypothetical example, with round numbers chosen for clarity rather than drawn from any real bank, shows how easily a gain from synthetic data can be an illusion. A payments team has a validation set of 100,000 transactions, of which 200 are fraudulent. Its existing model, trained on the original imbalanced data, flags 400 transactions at the default threshold of 0.5, catching 120 frauds. Its recall is therefore 60 per cent and its precision 30 per cent. A data scientist trains a GAN on the fraud cases, generates enough synthetic fraud to balance the training set, and retrains. At the same 0.5 threshold, the new model flags 1,200 transactions and catches 170 frauds: recall of 85 per cent, a striking improvement, with precision down to about 14 per cent. The comparison is not fair. The rebalanced model has learned that fraud is common, because in its training data half the examples were fraud, so its scores are shifted upward and more transactions cross the threshold. The proper comparison sets both models to flag the same number of transactions, say the 1,200 that the fraud team can review each day, and asks which catches more fraud within that budget. When this is done, the original model, with its threshold lowered until it too flags 1,200 transactions, may catch 165 or 170 frauds or 175. Any of these outcomes is possible. The point is that only the comparison at equal workload says anything about the synthetic data. The comparison at a fixed threshold says only that the threshold moved. When the comparison is done properly, three outcomes are common. Sometimes the synthetic data makes no difference, because the original model had already learned what the fraud examples could teach. Sometimes it helps modestly, typically because it smooths the boundary around a sparse cluster of fraud that the original model was overfitting. And sometimes it hurts, because the generator produced unrealistic fraud examples that pulled the boundary in the wrong direction. Which outcome occurs depends on the data and the model, and it can only be found by testing. Where generative oversampling earns its cost Deep generative oversampling is most likely to justify itself in three situations. The first is high-dimensional perceptual data, such as images, audio and video, where the simple alternatives work poorly. SMOTE interpolation between two medical images produces a ghostly double exposure, not a plausible scan. Geometric augmentation helps but cannot change the anatomy or the appearance of the lesion. A generative model can produce new images whose texture, shape and context vary in ways that the classifier has not seen, at least within the range the generator learned. In medical imaging, dermatology and industrial inspection, studies have repeatedly reported that adding synthetic images of rare classes improves sensitivity, particularly when the real minority set is very small. The second is when the generator can draw on knowledge from outside the narrow training set. A diffusion model pre-trained on a large and varied corpus of images and then adapted to a specific domain brings with it a general understanding of shape, lighting and texture that a model trained only on forty scans cannot have. This is the knowledge-transfer effect described in the previous chapter. It explains why adapted large models often outperform small models trained from scratch, and it suggests where to look for gains: pre-trained foundation models adapted with care, rather than bespoke generators trained on tiny datasets. The third is when generation can be conditioned to fill specific gaps. Suppose a dermatology dataset contains melanomas mostly on light skin and benign lesions on a wider range of skin tones. A generator that has learned what melanoma looks like and, separately, what different skin tones look like may be able to produce melanomas on darker skin. This is recombination, and it is the most ambitious use of generative oversampling: not merely more of the minority class, but the minority class in contexts where it was under-observed. The potential benefit for fairness is real. So is the risk. A melanoma on darker skin may present differently, for instance more often on the palms, soles or under the nails, and with different visual characteristics. A generator that simply transfers the appearance of melanoma on light skin to a darker background will produce images that look plausible and teach the wrong thing. Recombination is only as reliable as the assumption that the features combine independently, and in medicine that assumption should be checked with clinical experts, not taken for granted. Two cautionary patterns Two patterns in the published and practical record should make any team cautious. The first is evaluation leakage. A remarkably common mistake is to generate synthetic minority examples from the full dataset and then split it into training and test sets. If the generator has seen the test examples, its synthetic samples carry information about them, and a classifier trained on those samples will appear to perform well on the test set for reasons that will not hold on new data. The same leak occurs if SMOTE is applied before cross-validation rather than inside each fold. The rule is absolute: the test data must be set aside before any synthetic data is generated, and the generator must be trained only on the training portion. Several published reports of dramatic gains from oversampling have, on inspection, failed this rule. The second is self-confirming evaluation. If the test set is drawn from the same narrow distribution as the training set, a classifier that has learned the narrow distribution well will score highly, whether or not it can handle the variety it will meet in deployment. Synthetic data can make this worse by reinforcing the narrow distribution. A model trained on forty real scans from one hospital and four hundred synthetic scans generated from those forty may perform beautifully on a test set from the same hospital and poorly at a second hospital. The most informative evaluation tests on real data from a different source: another site, another time period, another device. External validation of this kind is standard practice in clinical research and should be standard for any claim about synthetic data. Fraud and the problem of moving targets Fraud detection shows the limits of oversampling from a different angle. Fraud patterns are not fixed. Criminals adapt to detection, so the distribution of fraud this year differs from that of last year. A generator trained on last year's frauds will produce more of last year's frauds. That may still help the classifier learn the general shape of suspicious behaviour, and in practice many banks and payment processors do use some form of minority oversampling or class weighting. But the deeper problem in fraud is not imbalance; it is that the minority class is adversarial and shifting. This points to a valuable but different use of synthetic data in fraud: not to inflate last year's fraud, but to simulate plausible new attacks. A team can construct synthetic fraud scenarios based on expert knowledge of emerging techniques, such as a new kind of account takeover, and test whether the existing model would catch them. That is closer to simulation than to generative oversampling, and it draws its knowledge from investigators rather than from historical data. It cannot be learned from the past because, by assumption, it has not happened yet. A similar logic applies in anti-money-laundering, where labelled examples of laundering are scarce and often unreliable. Several research groups and regulators have built agent-based simulations of financial networks, in which synthetic accounts transact according to rules and some agents follow laundering typologies described by financial intelligence units. The resulting datasets are used to develop and benchmark detection methods. Their realism is limited by the rules, but their labels are exact and their typologies can be updated as investigators learn more. A working protocol Pulling these threads together, a defensible approach to synthetic oversampling looks something like this. Begin by establishing a strong baseline using real data alone: a capable model, appropriate class weighting, and a decision threshold tuned on a validation set for the operational objective. Measure performance with metrics that focus on the minority class, and if at all possible measure it on an external test set from a different source. Then diagnose the problem. If the model's errors on the minority class are scattered and the class is reasonably varied, the issue may be attention, and simple rebalancing may already have dealt with it. If the errors cluster in particular subgroups or contexts that are sparse in the training data, the issue is coverage, and the best investment is usually real data from those contexts, even a small amount. If synthetic data is still warranted, split the data first and train the generator only on the training portion. Prefer generators that bring in relevant outside knowledge, such as pre-trained models adapted to the domain. Generate with diversity in mind, avoiding settings that produce near-identical prototypes. Have domain experts review a sample of the synthetic examples, not to confirm that they look real but to check whether they are correct. Search the synthetic set for near-copies of training examples, which add nothing and may create privacy problems. Finally, compare the model trained with synthetic data against the strong baseline on the external test set, with thresholds tuned fairly for both. Report the result whichever way it falls. If the gain is real, it will survive this comparison. If it does not survive, the synthetic data was solving a problem the baseline had already solved, or a problem it could not solve at all. What synthetic minorities can and cannot do Synthetic oversampling is a tool for moving a model's attention and, at its best, for recombining what the data already contains into contexts where it was under-represented. It is valuable precisely to the extent that the knowledge it moves is real. A generator that has learned the true appearance of a rare lesion can provide a classifier with more varied examples of that appearance than forty scans could. A generator that has not learned it, or has learned an artefact of one hospital's scanner, will multiply the error. The most important question is therefore not which generator to use, but where the knowledge about the minority class will come from. Sometimes it is in the data and merely needs amplifying. Sometimes it is in a large pre-trained model and needs adapting. Sometimes it is in the heads of experts and needs encoding as rules or scenarios. And sometimes it is not anywhere yet, and the only honest answer is to collect more. CHAPTER 6 Privacy: What Synthetic Data Can and Cannot Promise Of all the claims made for synthetic data, the most commercially attractive is that it solves the privacy problem. The pitch is easy to state. Personal data is heavily regulated; synthetic data contains no real people; therefore synthetic data can be shared, sold, published and analysed without the constraints that apply to personal data. Some versions of the pitch go further and describe synthetic data as a way around privacy law altogether. That framing is wrong in a way that matters, and it is worth being precise about why. Synthetic data can genuinely and substantially reduce privacy risk. Under the right conditions, a synthetic dataset may fall outside the rules that govern personal data, because those rules apply to information about identifiable people, and well-made synthetic data may not be such information. But the law does not care whether a dataset is labelled "synthetic". It cares whether people can be identified from it, directly or indirectly, by means reasonably likely to be used. That is a factual question about a specific dataset, the generator that produced it, and the world in which it will be released. Some synthetic datasets pass the test and some fail it. And the process of making synthetic data from real records is itself an act of processing personal data, subject to the full set of legal obligations. Synthetic data is a privacy-enhancing technique, not a legal loophole. The legal question: is it still personal data? Data protection regimes generally draw a line between information that relates to identifiable people, which they regulate, and information that does not, which they leave alone. Where the line falls varies by jurisdiction, and Table 3 sets out how several of the most important regimes frame it. Table 3. How major privacy regimes treat data derived from personal records. Regime Scope When derived data falls outside it Implication for synthetic data EU GDPR Personal data: information relating to an identified or identifiable person When it is anonymous, taking account of all means reasonably likely to be used to identify (Recital 26) Outside scope only if re-identification is not reasonably likely; generation itself is processing UK GDPR and Data Protection Act 2018 Same core definition as EU GDPR Same anonymisation test; regulator guidance on identifiability As for the EU, assessed in context US HIPAA Privacy Rule Protected health information held by covered entities and business associates De-identified via Safe Harbor (removing listed identifiers) or Expert Determination (very small risk) Synthetic health data typically relies on Expert Determination California CCPA as amended Personal information about consumers and households Deidentified information, with reasonable measures, public commitment and contractual controls on recipients Requires organisational safeguards as well as technical ones Source: GDPR Article 4(1) and Recital 26; 45 CFR 164.514; California Civil Code 1798.140. The European test is the most demanding and the most widely discussed. Recital 26 of the GDPR says that data protection principles do not apply to anonymous information, meaning information that does not relate to an identified or identifiable person, or personal data rendered anonymous in such a way that the person is no longer identifiable. To decide whether someone is identifiable, account should be taken of all the means reasonably likely to be used, by the controller or by another person, considering factors such as cost, time, available technology and technological developments. Three features of this test matter for synthetic data. First, it is a risk-based test, not an absolute one. The question is not whether re-identification is conceivable but whether it is reasonably likely. The Court of Justice of the European Union has emphasised this practical approach, most notably in its 2016 judgment in Breyer, which held that dynamic IP addresses could be personal data for a website operator that had legal means of obtaining the information needed to identify the user, and in its September 2025 judgment in EDPS v SRB, which held that pseudonymised data passed to a recipient may not be personal data from that recipient's perspective if the recipient cannot reasonably re-identify the people concerned, while remaining personal data for the organisation that holds the key. The perspective of who holds the data, and what they can realistically do with it, matters. Second, it looks forward. Technological developments count, so a dataset that is anonymous today may not be anonymous after a new attack technique is published. Anonymity is not a permanent state but a judgement that must be revisited. Third, it considers three distinct ways in which people can be exposed. The Article 29 Working Party, the predecessor of the European Data Protection Board, set these out in its 2014 opinion on anonymisation techniques: singling out, the ability to isolate a record relating to one individual; linkability, the ability to link records relating to the same person across datasets; and inference, the ability to deduce with significant probability the value of an attribute about a person. An anonymisation technique that prevents singling out but still allows a confident inference about a person's diagnosis has not fully done its job. Synthetic data has a natural advantage on the first test. Because synthetic records do not correspond one-to-one with real people, there is often no record to single out. But it has no automatic advantage on the third. A synthetic dataset that faithfully preserves the relationships in its source data will, by design, allow inferences about groups. If those relationships are strong enough, it may allow inferences about individuals who belong to small, distinctive groups. That is not necessarily a privacy breach, since learning population patterns is the whole purpose of statistics, but it means the analysis cannot stop at the observation that no synthetic row matches a real one. Making synthetic data is processing A point frequently missed in commercial presentations is that the act of creating synthetic data from personal data is itself processing of personal data. Training a generator on patient records is a use of those records. It needs a lawful basis under the GDPR, and for health data one of the additional conditions for special category data. It must respect the purpose limitation principle, which requires that further processing be compatible with the purpose for which the data was collected, though the GDPR treats processing for scientific research and statistics with some flexibility. It may require a data protection impact assessment. Patients may in some cases have rights to be informed about it. The trained generator itself may also be personal data. In December 2024 the European Data Protection Board adopted an opinion on the processing of personal data in the context of AI models. It concluded that AI models trained on personal data cannot in all cases be considered anonymous, and that whether a model is anonymous must be assessed case by case, considering whether personal data can be extracted from it, directly or through queries, with means reasonably likely to be used. A generator that can be induced to reproduce training records is not anonymous, and sharing it may be sharing personal data. The practical consequence is that a synthetic data project in a regulated domain begins, not ends, with data protection work. The organisation must establish its right to use the source data for this purpose, document the process, assess the risk of the output, and decide what controls to apply to its release. Synthetic data can make the output much less risky. It does not make the input any less regulated. Other legal frameworks touch on synthetic data more directly. The EU's Artificial Intelligence Act, adopted in 2024, permits providers of high-risk AI systems to process special categories of personal data for the purpose of detecting and correcting bias, but only where that cannot be achieved effectively with other data, explicitly including synthetic or anonymised data. In that context the Act treats synthetic data as a less intrusive alternative that must be considered first, which is a recognition of its privacy benefits, and an acknowledgment that it is not always sufficient. How synthetic data leaks To judge whether a particular synthetic dataset protects the people behind it, one has to understand the ways in which it can fail. Research since 2017 has documented several. Memorisation and reproduction. A generator can learn to reproduce training records exactly or nearly so. Chapter 4 described the work by Carlini and colleagues showing that diffusion models can regenerate some training images. For tabular data, a generator trained on a small dataset may output rows that match real ones in all or nearly all fields. Memorisation is most likely for records that are unusual, duplicated, or in very small datasets, which describes much sensitive data. Membership inference. Even without reproducing a record, a generator may reveal whether a particular person's record was in its training data. Reza Shokri and colleagues demonstrated membership inference attacks on machine learning models in 2017, and the idea has since been applied to generative models. The attacker, who knows a target person's record, compares the synthetic data or the generator's behaviour around that record with what would be expected if the record had not been included. If the synthetic data contains more samples near the target than chance would predict, that suggests the target was in the training set. Membership alone can be sensitive: knowing that someone's record was used to train a generator for an HIV clinic's data reveals that they attended the clinic. Attribute inference. An attacker who knows some of a person's attributes, such as age, postcode and sex, may use the synthetic data to infer an unknown attribute, such as a diagnosis. If the generator has learned that a particular rare combination of known attributes is associated with a particular diagnosis, and only one real person has that combination, the synthetic data may effectively disclose that person's diagnosis. Linkage. Synthetic records that preserve combinations of quasi-identifiers can sometimes be linked to external datasets, especially for people whose combinations are unique. The most influential systematic study of these risks was published by Theresa Stadler, Bristena Oprisanu and Carmela Troncoso at the USENIX Security Symposium in 2022 under the title "Synthetic Data – Anonymisation Groundhog Day". Using a framework for evaluating privacy gains against specific attacks, they found that synthetic data generated without formal privacy guarantees offered unpredictable protection: for some target records it protected well, and for others, particularly outliers whose records stood out from the population, it offered little protection against membership inference. When they added differential privacy to protect outliers, the synthetic data lost much of its utility for exactly those outliers. Their conclusion was that synthetic data does not escape the fundamental trade-off between privacy and utility that affects older anonymisation methods. It changes the shape of the trade-off without abolishing it. This finding matters because the people most at risk in a dataset are usually those who are unusual: the patient with a rare disease, the very old, the person with an unusual combination of characteristics. These are also, often, the people whose data is most valuable for the rare-case applications that motivate synthetic data in the first place. There is no free lunch. A generator that faithfully reproduces the rare patient's pattern is the one most likely to expose that patient. Differential privacy The strongest available tool for bounding these risks is differential privacy, a mathematical definition introduced by Cynthia Dwork, Frank McSherry, Kobbi Nissim and Adam Smith in 2006. A process is differentially private if its output would be almost equally likely whether or not any single person's record was included in its input. The degree of "almost" is governed by a parameter, usually called epsilon, where smaller values mean stronger privacy. Differential privacy does not depend on assumptions about what an attacker knows, and it composes predictably: the privacy losses from several releases can be added up. Synthetic data generators can be made differentially private in several ways. Noise can be added to the gradients during training, as in DP-SGD and the DP-GAN variants mentioned in Chapter 3. Training can be routed through a private aggregation scheme, as in PATE-GAN. Or the generator can be built from a set of noisy statistics, typically low-dimensional tables of counts, from which synthetic records are then sampled. This last approach has performed particularly well in competitions run by the US National Institute of Standards and Technology, where methods based on carefully chosen noisy marginal tables often beat deep generative models on tabular data at meaningful privacy levels. Differential privacy has costs. It reduces utility, and the reduction falls hardest on small groups and rare patterns, because a small group's statistics are more affected by the noise needed to hide any one member. Choosing epsilon is a policy decision without a universally accepted answer. Published deployments have used a wide range of values, and values large enough to preserve utility may provide weaker guarantees than the word "private" suggests. The US Census Bureau's adoption of differential privacy for the 2020 Census, though it did not involve a deep generative model, showed both the power of the approach and the controversy it can generate when users see the effect of the noise on small-area statistics. Even so, differential privacy is the only approach that provides a guarantee that does not depend on anticipating every attack. For synthetic data intended for broad or public release, a differentially private generator with a clearly documented epsilon is far stronger evidence of anonymity than any number of similarity checks. Practical assessment Without formal guarantees, organisations assess the privacy of synthetic data empirically. Common checks include the distance to closest record, which measures how near each synthetic record is to its nearest real training record and flags any that are suspiciously close, and comparisons of these distances with those for a held-out set of real records not used in training. If synthetic records are systematically closer to training records than to held-out records, the generator has memorised. These checks are useful as screens but weak as proof. A synthetic dataset can pass a distance check while remaining vulnerable to membership inference, because the attacker does not need an exact copy; a subtle excess of density around the target is enough. Stronger assessments simulate specific attacks, such as membership inference against chosen high-risk records, and measure how much better than chance the attacker does. Open-source frameworks for this kind of evaluation now exist, and some regulators and standards bodies have begun to discuss expectations. Context matters as much as technique. The same synthetic dataset may be acceptable for release to a vetted research team under a data sharing agreement that prohibits re-identification attempts, and unacceptable for publication on the open internet. Organisational controls, contracts and access restrictions are part of the anonymisation assessment, not separate from it. That is the logic of the EDPS v SRB judgment and of the California approach summarised in Table 3: who receives the data and what they are bound to do with it change the risk. A realistic place for synthetic data in privacy Seen soberly, synthetic data has several valuable roles in privacy-sensitive work. It is excellent for development and testing. Engineers building software that consumes patient records, payment data or customer files can work with synthetic data that has the right structure and realistic statistical properties, without access to real records. The risk is low because the data does not need high fidelity to serve this purpose, and the Simulacrum model described in Chapter 2, where synthetic data is used to develop analysis code that is then run on the real data by authorised staff, captures this well. It can support broader access for exploratory analysis and education, particularly when generated with differential privacy and released with clear documentation of its limits. It can reduce, though not eliminate, the risk of sharing data between institutions, and in some cases may make sharing possible where it would otherwise not be. It is a poor substitute for real data when the analysis depends on rare subgroups, unusual individuals or fine-grained relationships, because those are exactly what privacy protection must blur. And it is never, by itself, a way to escape legal obligations. The source data remains regulated. The generator may be regulated. The output is regulated unless and until a defensible assessment shows that people cannot reasonably be identified from it, and that assessment must be revisited as attacks improve. Organisations that treat "synthetic" as a synonym for "anonymous" are not bypassing privacy law. They are, in all likelihood, breaking it, and exposing the very people whose data made the synthetic dataset possible. CHAPTER 7 Edge Cases on Demand: Synthetic Data for Automated Driving No application of synthetic data is as demanding, or as necessary, as the development of automated driving. A system that drives a car must perceive a cluttered, changing world through cameras, lidar and radar; predict what every other road user will do; and plan a safe path, many times a second, in conditions that vary with weather, lighting, geography, culture and chance. Most of the time, driving is uneventful. The rare events, the ones that the system must handle without error, are so rare and so varied that no amount of real-world driving can cover them. Synthetic data is how the industry tries to close the gap. The long tail of the road Engineers speak of the long tail of driving: the vast collection of unusual situations, each individually rare, that together make up a meaningful share of the risk. A mattress falls off a van ahead. A police officer directs traffic through a red light with hand signals. A child in a Halloween costume steps out between parked cars. A lorry carrying a large mirror reflects the road behind. A set of traffic lights is mounted on a vehicle for roadworks. A flooded underpass makes depth impossible to judge. A cyclist signals one way and turns the other. Each of these may occur once in millions of kilometres. Collectively they occur all the time, and a system deployed at scale will meet many of them every day. The difficulty is not only that they are rare but that they are open-ended. No list of edge cases is ever complete, because the world keeps inventing new ones. As Chapter 1 noted, the RAND study by Kalra and Paddock showed in 2016 that demonstrating statistically that an automated vehicle is safer than human drivers would require hundreds of millions to billions of miles of driving, far beyond what any test fleet could achieve before deployment. Their conclusion pointed towards supplementary methods, and simulation has become the central one. Waymo reported in 2019 that its software had driven ten billion miles in simulation, and the company has continued to describe simulation as a core part of its validation process. Every serious developer of automated driving now relies on simulation at scale. But simulation is a means, not an end. A billion simulated miles of uneventful driving prove nothing. What matters is which situations are simulated, how faithfully, and whether the system's behaviour in simulation predicts its behaviour on the road. Each of these is a distinct problem, and each draws on different sources of knowledge. Scenarios: deciding what to simulate A scenario is a description of a driving situation: the road layout, the other road users and their behaviour, the weather and lighting, and the task facing the automated vehicle. Scenario-based testing has become the organising framework for safety validation in the industry and among regulators. The German PEGASUS project, which ran from 2016 to 2019 with participation from carmakers, suppliers and research institutes, developed an influential methodology for identifying relevant scenarios, describing them in a structured way and assessing systems against them. Industry standards followed. The ASAM OpenSCENARIO standard defines a format for describing dynamic scenarios so that they can be exchanged between tools. ISO 34502, published in 2022, provides a framework for scenario-based safety evaluation of automated driving systems. ISO 21448, known as SOTIF (Safety of the Intended Functionality), addresses hazards that arise not from component faults but from the limitations of the system's intended functions, such as a perception system that fails to recognise an unusual object, and calls for systematically identifying and reducing the unknown unsafe situations. UL 4600, a standard for the safety of autonomous products, requires a structured safety case that addresses, among other things, how the developer handles rare and novel situations. Regulators have moved in the same direction. The UNECE regulation on automated lane-keeping systems, adopted in 2020 as the first binding international regulation for a Level 3 automated driving function, was accompanied by work on a multi-pillar assessment approach that combines audits of the developer's processes with simulation, track testing and real-world testing. Simulation is recognised as one pillar, not a replacement for the others. Where do scenarios come from? There are four main sources, each embodying a different kind of knowledge, and Table 4 sets them alongside the methods for rendering them into sensor data, discussed later in this chapter. The first source is expert knowledge. Engineers and safety analysts write scenarios based on their understanding of what could go wrong, often guided by hazard analyses, traffic rules and accident statistics. Many regulatory test protocols, such as those for emergency braking, are of this kind. Expert scenarios are precise and interpretable, and they cover situations that experts know to be important. They do not cover situations experts did not think of. The second source is accident and naturalistic driving data. Databases of real crashes, such as national crash investigation studies, and recordings of everyday driving can be mined for situations that actually occur and actually lead to harm. Parameters such as speeds, distances and timings can be extracted and their distributions estimated, so that scenarios can be generated with realistic variation. This grounds testing in observed reality but is limited by what has been recorded. The third source is perturbation of real drives. A developer with a large fleet records every drive. Interesting moments, such as a near-miss or a disengagement where the safety driver took control, can be reconstructed in simulation and then varied: what if the other car had been two metres per second faster, or the pedestrian had started half a second earlier? Waymo described an approach of this kind, which it called Carcraft, to journalists at The Atlantic in 2017, explaining how each interesting real event could be turned into thousands of simulated variations. Perturbation multiplies real situations into families of related ones, which is an excellent use of synthetic data's power to recombine and extrapolate from observed knowledge. The fourth source is search. Rather than specifying scenarios, an algorithm searches the space of possible scenarios for ones in which the system fails or comes close to failing. This is sometimes called falsification or adversarial scenario generation. Optimisation methods, reinforcement learning and importance sampling have all been used to steer simulated traffic towards challenging situations. A notable 2023 paper in Nature by Shuo Feng, Henry Liu and colleagues at the University of Michigan described dense deep reinforcement learning for this purpose: training simulated background vehicles to create safety-critical situations far more often than they occur naturally, while preserving enough statistical structure that the results could be translated back into estimates of real-world risk. They reported that this could accelerate evaluation by several orders of magnitude compared with naturalistic simulation. Search-based methods are powerful because they find failures nobody anticipated. They also have a characteristic weakness. An optimiser looking for scenarios that cause failure will happily find physically impossible or absurdly unlikely ones: a car that accelerates at ten times the plausible rate, a pedestrian who teleports. Constraining search to realistic scenarios requires a model of what is realistic, which brings back the question of where that knowledge comes from. Table 4. Sources of synthetic driving data compared. Method Where its knowledge comes from Main strength Main limitation Expert-written scenarios Engineers, regulations, hazard analysis Precise, interpretable, auditable Covers only what experts foresee Perturbed real drives Fleet recordings Grounded in real events; multiplies them Variations may drift beyond realism Adversarial search Optimiser plus behaviour constraints Finds unanticipated failures Can produce implausible scenarios Game-engine rendering Hand-built assets and physics Full control and exact labels Visible reality gap in sensor data Neural reconstruction Recorded sensor data of real places Photorealistic replay with new viewpoints Degrades far from the recorded path Generative world models Large corpora of driving video Diverse, novel scenes on demand Physical and causal errors; hard to verify Behaviour: making other road users realistic Every scenario involves other road users, and their behaviour determines whether the test is meaningful. Early simulators populated scenes with agents that followed simple rules: stay in lane, keep a safe distance, obey signals. Such agents are too polite and too predictable. Real drivers merge aggressively, hesitate, make mistakes, and react to the automated vehicle itself. A system tested only against rule-following agents may behave well in simulation and poorly when a human cuts in unexpectedly. The response has been to learn behaviour models from data. Large public datasets of recorded traffic, such as the Waymo Open Motion Dataset, have enabled research into sim agents: learned models that control simulated road users so that, collectively, they behave like real traffic. Waymo has run public challenges in which researchers compete to build sim agents whose behaviour, when rolled out in simulation, most closely matches the statistics of real recorded behaviour. These models draw on many of the same generative techniques described in earlier chapters, including diffusion models applied to trajectories rather than images. Learned behaviour models make simulation more realistic, but they inherit the limits of their data. A model trained on recorded traffic in Phoenix may not behave like traffic in Mumbai or Naples. A model trained on normal driving may not know how people behave in emergencies, which are, by definition, rare in its training data. The long tail of behaviour is as hard to learn as the long tail of situations. Sensors: closing the reality gap A scenario specifies what happens. To test a perception system, the scenario must be rendered into the raw data the vehicle's sensors would produce: camera images, lidar point clouds and radar returns. This is where the reality gap of Chapter 2 bites hardest. Game-engine rendering, as used in CARLA and commercial simulators, provides full control and exact labels. Its images, however, differ from real camera footage in ways that perception networks notice: lighting, materials, reflections, motion blur, lens effects and sensor noise are all approximations. Lidar can be simulated reasonably well by casting rays into the scene, though effects such as reflections from wet surfaces, returns from rain and dust, and the properties of different materials are hard to model. Radar is harder still, because its returns depend on complex interactions of radio waves with objects and surfaces. Two newer approaches have narrowed the gap considerably. Neural reconstruction builds a three-dimensional model of a real scene from recorded sensor data, using techniques such as neural radiance fields, introduced in 2020, and 3D Gaussian splatting, introduced in 2023. Once a scene has been reconstructed, it can be re-rendered from new viewpoints, with objects moved, added or removed, producing sensor data that looks like real recordings because it is derived from them. Waabi's UniSim, presented in 2023, reconstructed driving logs into neural scenes that could be modified and rendered for camera and lidar, allowing closed-loop testing where the automated vehicle drives differently from the original recording. The limitation is that reconstruction quality degrades as the virtual camera moves away from where the real sensors were. Swerving into an adjacent lane may reveal parts of the scene the recording vehicle never saw. Generative world models go further, generating entire driving videos from learned models of how the world looks and behaves. Wayve introduced GAIA-1 in 2023, a generative model trained on large quantities of its driving video that could produce realistic driving scenes conditioned on text descriptions and vehicle actions, and followed it with GAIA-2 in 2025, with support for multiple cameras and finer control. NVIDIA released its Cosmos family of world foundation models in January 2025, intended in part for generating synthetic data for autonomous vehicles and robots. These models can produce novel scenes that never existed, varying weather, lighting, traffic and geography on demand. They are, in effect, large diffusion and related models applied to video, and they inherit both the strengths and the weaknesses described in Chapter 4. Their great strength is diversity and realism of appearance. Their great weakness is that their physical and causal behaviour is learned rather than specified, and it can be wrong. Objects may change shape or disappear between frames. Vehicles may move in ways that violate physics. Cause and effect may not be respected: braking may not slow the car, or another vehicle may not react to the automated vehicle's move. For training a perception system, such errors may be tolerable if they are rare. For validating safety, where the point is to test what happens in a precise situation, they are a serious problem, because the test result may reflect a flaw in the world model rather than in the system under test. Training versus validation This leads to a distinction that runs through the whole of synthetic data for driving and is often blurred: the difference between using synthetic data to train a system and using it to validate one. For training, synthetic data needs to be useful, not perfect. Synthetic examples of rare objects, unusual weather or difficult lighting can teach a perception network features it would otherwise lack, even if the images have some unrealistic details. Mixing synthetic data with real data, using domain randomisation, or translating synthetic images to look more realistic with generative models can all improve performance on real roads. The test of success is whether the trained system performs better on real data, and that can be measured. For validation, synthetic data must be trustworthy. The claim being made is that the system will behave in reality as it behaves in simulation. That claim requires evidence that the simulator is faithful in the respects that matter for the decision being tested. Developers address this by correlating simulation with reality: running the same scenarios on a test track and in simulation and comparing results, checking that perception outputs on simulated sensor data match those on real data for the same scene, and characterising where the simulator is known to be inaccurate. Standards such as UL 4600 expect developers to justify the validity of their simulation tools as part of the safety case. The more a simulator relies on learned generative models, the harder this justification becomes, because the model's errors are not documented assumptions but unknown artefacts of training. A physics engine's friction model can be inspected and checked against measurements. A world model's implicit understanding of friction cannot. This does not rule out learned simulators for validation, but it places a heavy burden on the evidence that they are faithful. What synthetic edge cases achieve The automated driving industry has demonstrated, more convincingly than any other field, both what synthetic data can do and where its limits lie. It can multiply real events into families of variations, as in log perturbation, extending the coverage of real-world testing by orders of magnitude. It can search for failures that engineers did not anticipate, as in adversarial scenario generation. It can produce sensor data for situations too dangerous to stage, at a scale and with labels that real collection cannot match. And it can render the familiar world under unfamiliar conditions, recombining learned elements into combinations that were never recorded. What it cannot do is guarantee coverage of situations that nobody has observed or imagined. Every source of synthetic driving data draws on some source of knowledge: experts, records, physics, or learned models of past driving. A genuinely novel situation, one outside all of these, will be outside the synthetic data as well. That is why the industry's safety frameworks combine simulation with real-world testing, careful monitoring after deployment, and processes for learning from every incident and feeding it back into the scenario library. Synthetic data is the engine that makes each lesson from the real world go further. It is not a substitute for the real world's lessons. CHAPTER 8 Knowing Whether It Worked Every synthetic data project eventually faces the same question: is this data any good? The question is harder than it looks, because "good" means different things depending on the purpose. A synthetic dataset for testing software needs the right structure and plausible values. One for training a classifier needs to improve that classifier on real data. One for sharing in place of sensitive records needs to support the same analyses as the original while protecting the people in it. One for validating a safety-critical system needs to be faithful in exactly the respects that the validation depends on. No single measure captures all of this, and a dataset that scores well on one can fail badly on another. The field has converged on three broad dimensions along which synthetic data should be judged: fidelity, how closely it resembles the real data; utility, how well it serves the intended task; and privacy, how little it reveals about the individuals in the source data. These three pull against each other. Perfect fidelity is achieved by copying the real data, which has zero privacy. Perfect privacy is achieved by generating random noise, which has zero utility. Every real synthetic dataset sits somewhere in between, and the art lies in choosing where. Fidelity: does it look like the real thing? Fidelity measures compare the synthetic data to the real data directly, without reference to any particular task. For tabular data, the simplest checks compare the distribution of each column, its range, average, spread and shape, between real and synthetic sets. Next come comparisons of pairs of columns: correlations for numerical variables, cross-tabulations for categorical ones. These marginal checks are quick and interpretable, and they catch gross failures, but they can miss problems in the interactions among three or more variables, which is often where the interesting structure lies. A more holistic approach is the propensity score method, developed for statistical disclosure control and set out by Joshua Snoke and colleagues in 2018. Combine the real and synthetic records, label each by its origin, and train a classifier to tell them apart. If the classifier cannot do better than chance, the synthetic data is, in the classifier's eyes, indistinguishable from the real data. If it can, its accuracy measures how distinguishable they are, and inspecting what it relies on reveals where the synthetic data falls short. This is, in effect, a discriminator of the kind used in GAN training, used after the fact as an auditor. For images, the standard measure has been the Fréchet Inception Distance, introduced by Martin Heusel and colleagues in 2017. It passes real and synthetic images through a pre-trained image recognition network, summarises each set by the average and spread of the network's internal features, and computes a distance between the two summaries. Lower values mean the synthetic images are more similar to the real ones in the features the network attends to. FID is useful for comparing generators but has known limits: it depends on a network trained on everyday photographs, which may not capture what matters in medical or industrial images; it compresses everything into a single number; and it does not separate two different failures, producing unrealistic images and failing to cover the real variety. That separation was addressed by precision and recall for generative models, formalised in an influential version by Tuomas Kynkäänniemi and colleagues in 2019. Precision measures the proportion of synthetic samples that fall within the region occupied by real data, a measure of realism. Recall measures the proportion of real data that is covered by the region of synthetic samples, a measure of diversity. A generator with mode collapse has high precision and low recall. A generator producing noisy, unrealistic samples has low precision. Ahmed Alaa and colleagues extended this idea in 2022 with measures they called alpha-precision and beta-recall, together with an authenticity score that estimates how many synthetic samples are genuinely new rather than near-copies of training data, bringing a privacy dimension into the fidelity assessment. Recall matters particularly for the rare-case applications that motivate this booklet. A generator that produces beautiful samples of the common cases and nothing of the rare ones may score well on FID while failing at the job it was hired for. Measuring recall separately for each subgroup or class of interest, rather than for the dataset as a whole, is the way to catch this. Utility: does it do the job? Fidelity is a proxy. What usually matters is whether the synthetic data serves its purpose, and the most direct way to find out is to try. The canonical utility test for synthetic training data is train on synthetic, test on real, often abbreviated TSTR and popularised in a 2017 paper on medical time series by Cristóbal Esteban, Stephanie Hyland and Gunnar Rätsch. Train a model on the synthetic data, evaluate it on held-out real data, and compare its performance with a model trained on real data and evaluated on the same held-out set. If the two perform similarly, the synthetic data has preserved what the model needs. The variant most relevant to augmentation is to train on real plus synthetic and test on real, comparing with training on real alone, which directly measures whether the synthetic data adds anything. For synthetic data intended for statistical analysis rather than model training, utility is assessed by running the analyses of interest on both datasets and comparing the results: regression coefficients, confidence intervals, subgroup estimates. Measures of confidence interval overlap, which check whether the interval estimated from the synthetic data overlaps substantially with that from the real data, have been used in official statistics for this purpose. The analyses chosen for this check should be the ones users will actually run, which is often hard to know in advance for a dataset released for general use. Utility tests share one critical requirement with the evaluation advice of Chapter 5: the real data used for testing must not have been used to train the generator. Otherwise the synthetic data may simply carry the test answers. Table 5 summarises the main measures under each dimension and what each one catches. Table 5. Measures for evaluating synthetic data. Dimension Measure What it detects What it can miss Fidelity Marginal and pairwise comparisons Wrong distributions and correlations Higher-order interactions Fidelity Propensity score (real vs synthetic classifier) Any learnable difference Why the difference matters Fidelity FID; precision and recall Image realism; mode collapse Domain-specific correctness Utility Train on synthetic, test on real Loss of task-relevant information Failures outside the test distribution Utility Analysis replication (estimates, intervals) Biased statistical conclusions Analyses not anticipated Privacy Distance to closest record Near-copies of training rows Subtler membership signals Privacy Simulated membership and attribute attacks Leakage for specific records Attacks not simulated Privacy Differential privacy accounting Bounded influence of any record Nothing, within its assumptions, but utility cost is high Purpose decides the weighting The three dimensions cannot all be maximised, so the purpose of the dataset must decide how they are weighted. Two contrasting cases make this concrete. A software team building a new claims-processing system for an insurer needs data to test it. The data must have the right columns, valid formats, plausible ranges and the edge cases the software must handle: missing fields, unusual characters in names, claims that span a year end. Its statistical relationships barely matter; nobody will draw conclusions about the insured population from it. Privacy, on the other hand, matters a great deal, because test environments are typically less protected than production ones and are accessed by more people. The right choice is low fidelity, purpose-specific utility, and very strong privacy: a rule-based generator, or a heavily privacy-protected learned one, with edge cases added by hand. A research team studying whether a treatment's effect differs between age groups needs the opposite. If the synthetic data blurs the interaction between age and treatment, the analysis will be wrong, and wrong in a direction nobody can detect from the synthetic data alone. Here high fidelity on specific relationships is essential, and the privacy protection must be achieved by other means: access controls, a trusted research environment, or the validation-server model in which results from synthetic data are confirmed against the real data before publication. Most real projects fall between these extremes, and the decision about where to place them should be explicit. A synthetic dataset released without a stated purpose will be used for every purpose, including ones its trade-offs make it unfit for. The expert in the loop There is a dimension of quality that none of these measures captures well: correctness. A synthetic chest X-ray may be statistically indistinguishable from real ones by every automated metric and yet contain an anatomical detail that no real chest could have. A synthetic patient record may preserve every correlation in the source data and yet describe a drug prescribed for a condition it is contraindicated for. A synthetic driving scene may look entirely real and yet show a shadow falling the wrong way. These are errors of meaning rather than of statistics, and catching them requires people who understand the domain. In medical imaging, a common protocol is a blinded reader study: radiologists or pathologists are shown a mix of real and synthetic images and asked to identify which is which and to judge clinical plausibility. In driving, safety engineers review scenarios and sensor outputs. In finance, investigators review synthetic fraud cases. Expert review is slow and expensive, and it cannot cover every sample. But reviewing a well-chosen sample, especially of the rare and unusual cases where generators are least reliable, is the only way to detect a class of error that automated measures miss by construction. Model collapse: when synthetic data feeds on itself A risk that has received intense attention since 2023 is what happens when models are trained on data generated by other models, which are in turn trained on data generated by other models. In a 2024 paper in Nature titled "AI models collapse when trained on recursively generated data", Ilia Shumailov and colleagues showed that when generative models are trained repeatedly on the outputs of previous generations, the resulting models progressively lose information about the tails of the original distribution. Rare events become rarer, then vanish; the distribution narrows and drifts; eventually the outputs bear little resemblance to the original data. They demonstrated the effect in language models, variational autoencoders and simple statistical models, and argued that it was a general consequence of the statistical and approximation errors that every generator makes. Sina Alemohammad and colleagues reported a similar phenomenon in image generators, which they described as models "going MAD", for Model Autophagy Disorder, and found that it could be slowed if enough fresh real data was included in each generation. Later work clarified the conditions under which collapse occurs. Matthias Gerstgrasser and colleagues showed in 2024 that if synthetic data is accumulated alongside the original real data, rather than replacing it, the degradation can be avoided in the settings they studied. Collapse is primarily a consequence of discarding real data in favour of synthetic data, not of using synthetic data at all. The lesson connects directly to the central argument of this booklet. Each round of generation can only preserve or lose knowledge from the previous round; it cannot add knowledge about the world. Errors compound, and the first casualties are the rare events, exactly those that synthetic data is often meant to help with. Real data acts as an anchor, continually reintroducing information that generators would otherwise lose. A practical rule follows: keep the real data, keep using it, and track the provenance of every dataset so that synthetic data never silently replaces the real data it was derived from. As synthetic content spreads across the internet and into the training sets of future models, this rule becomes harder to follow and more important. Synthetic data for language models The same principles apply to the large language models that now generate a large share of new text. Developers routinely use language models to generate synthetic training data for other models: instruction-following examples, question-answer pairs, reasoning traces, code exercises. A notable example was Microsoft Research's 2023 paper "Textbooks Are All You Need", which described a small code model, phi-1, trained largely on synthetic textbook-style material and exercises generated by a larger model, achieving strong results on coding benchmarks relative to its size. Synthetic text works for the same reason synthetic images do: a large teacher model holds broad knowledge, and well-designed generation can transfer the relevant parts of that knowledge to a smaller or more specialised student, in a form that is cleaner and more focused than raw internet text. It fails for the same reasons too. The student inherits the teacher's errors and biases. Narrowly prompted generation produces repetitive, stereotyped outputs that lack the variety of real text. And without checks, mistakes propagate. The most successful uses of synthetic text pair generation with verification, for example by running generated code against tests or checking generated mathematical solutions against known answers, so that only outputs that pass an independent check are kept. Verification is the step that supplies knowledge from outside the generator, and it is what turns synthetic data from an echo into a signal. Documentation and governance Synthetic datasets travel. A dataset generated for one purpose is shared with another team, uploaded to a repository, used for a different model, and eventually its origins are forgotten. A synthetic dataset whose provenance is lost is dangerous: someone may mistake it for real data, use it to draw conclusions it cannot support, or train a generator on it and start the cycle of collapse. Good practice is to document every synthetic dataset as carefully as a real one, and in some respects more carefully. The Datasheets for Datasets framework proposed by Timnit Gebru and colleagues provides a useful template. For synthetic data, the documentation should record, at minimum: what real data the generator was trained on and under what legal basis; which generator was used, with what settings and version; what the synthetic data is intended for and what it should not be used for; the results of fidelity, utility and privacy evaluations, including results for important subgroups; any formal privacy guarantee, such as a differential privacy budget; and a clear, persistent marking that the data is synthetic. Some organisations embed this marking in the data itself, for example in a column or file header, so that it cannot be separated from the records. Governance also means deciding in advance who may generate synthetic data from sensitive sources, who may receive it and under what conditions, and how often its privacy assessment will be revisited as attack techniques evolve. These decisions belong with the same people who govern access to the real data, because the risks, while reduced, are of the same kind. A short checklist The evaluation of synthetic data can be distilled into a handful of questions that should be answered, in writing, before a synthetic dataset is relied upon. What is it for, and what measure of success follows from that purpose? Was the test data held out before the generator was trained? Does the synthetic data cover the rare cases and subgroups it is meant to cover, as measured separately for each? Have domain experts reviewed a sample, especially of the unusual cases? Does a model trained with it perform better on real data from an independent source than a strong baseline trained without it? What privacy evaluation was performed, against what attacks, and is there a formal guarantee? Is its provenance recorded and its synthetic nature clearly marked? None of these questions is technically difficult. All of them are routinely skipped. Answering them honestly is the difference between synthetic data that moves real knowledge to where it is needed and synthetic data that manufactures confidence. Conclusion: Knowledge Has to Come From Somewhere The chapters of this booklet have followed synthetic data through three very different problems: the classifier that ignores a rare class, the dataset that cannot be shared because it describes real people, and the driving system that must be ready for situations nobody has recorded. In each, the same pattern has held. Synthetic data succeeds when it moves real knowledge to where it is needed and preserves that knowledge on the way. It fails when it is asked to supply knowledge that was never there, or when the movement distorts what it carries. That principle has practical consequences that go beyond any particular technique, and they are worth drawing out, because the techniques will change. The GANs of 2018 have largely given way to the diffusion models of 2022, and those are already being joined by world models trained on video, by tabular foundation models, and by language models that write the training data for their successors. Whatever comes next will be more capable. The questions that decide whether it is useful will be the same. Locate the knowledge before generating anything The first question in any synthetic data project should be where the knowledge is supposed to come from. There are only a few possibilities. It can come from the real training data, in which case synthetic data can redistribute it, recombine it and disguise it, but not add to it. It can come from a large pre-trained model that has learned from a much wider corpus, in which case synthetic data is a channel for transferring that broader knowledge into a narrower task, with all of that model's provenance, biases and blind spots. It can come from human experts, encoded as rules, simulators, physical models or scenarios, in which case it is only as good as the experts' understanding and can be inspected and argued over. Or it can come from an external check, such as a test suite, a physical measurement or an expert review, that filters what a generator produces. When none of these sources contains the knowledge a task needs, no generator will create it. The forty rare lung scans from the introduction do not contain information about how the condition appears on a scanner nobody has used, and a generator trained on them will not know. A large medical imaging model trained on many scanners might. A radiologist who has seen the condition on several scanners certainly does. The decision about which tool to use follows from the decision about where the knowledge lives. This framing also explains why the best results in the field so often combine sources. Driving programmes that use real logs, perturbed by expert-designed variations, rendered with neural reconstructions of real places, and validated against track tests are drawing on four sources of knowledge at once, each checking the others. Medical imaging studies that adapt large pre-trained generators to small clinical datasets and then have radiologists review the output are doing the same. Language models trained on generated code that has passed tests are anchored to an external truth. Synthetic data works best as connective tissue between sources of knowledge, not as a source in itself. Treat synthetic data as a hypothesis, not a fact Every synthetic sample embodies a claim: this is what the world could look like. For training, that claim can be loose; a classifier can learn useful features from examples that are imperfect. For validation and for statistical inference, the claim must be tight, because conclusions are drawn directly from it. The degree of scrutiny a synthetic dataset deserves scales with the weight that will rest on it. This means the evaluation discipline of the previous chapter is not optional. The test data must be held out before generation. Rare cases must be measured separately. Experts must review samples for correctness, not only for realism. Gains must be demonstrated against strong baselines on real data from independent sources. These steps are tedious, and the literature is full of studies that skipped them. Many of the most impressive claims for synthetic data dissolve when they are applied, and the ones that survive are worth far more for having been tested. Privacy is a property to be demonstrated, not a label On privacy, the conclusion is equally firm. Synthetic data is a genuine privacy-enhancing technique. It can make sensitive data far safer to work with, enable development and testing without access to real records, and under the right conditions produce datasets that are no longer personal data. But it is not a way around the law, and it does not make privacy obligations disappear. The source data remains regulated, the act of generation is processing, the generator itself may retain personal data, and the output is anonymous only if people cannot reasonably be identified from it, a judgement that depends on the specific data, the specific generator, the specific recipients and the state of attack techniques at the time. The people most exposed by synthetic data are the unusual ones, and those are often the people whose data matters most for the rare-case applications that motivate the effort. There is no technique that gives full fidelity for outliers and full protection for them at the same time. Differential privacy offers the clearest account of the trade-off, and where data is to be released broadly, it should be the default. Where data is shared under contract with known recipients, organisational controls can carry part of the load. In every case, the honest position is that synthetic data reduces risk; it does not abolish it. Keep the real data The research on model collapse adds a final, structural lesson. A world in which models are trained on the outputs of other models will gradually lose the rare and the unusual unless real data is kept and continually reintroduced. This is true within a single organisation, where synthetic datasets must never silently replace the real data they were derived from, and it is true at the scale of the whole information ecosystem, where generated content is accumulating faster than anyone can label it. The practical implication is that investment in synthetic data should be accompanied, not replaced, by investment in real data: targeted collection of rare cases, better labelling, data sharing agreements, secure research environments, and post-deployment monitoring that captures the situations a system actually meets. Synthetic data multiplies the value of real data. It cannot substitute for the flow of new observations from the world. What remains unsettled Several questions remain open and will shape the field over the next few years. The first is how to validate learned simulators. World models trained on video can generate driving scenes of extraordinary realism, but establishing that a system's behaviour in such a model predicts its behaviour on the road is an unsolved problem. Until there are accepted methods for characterising where a learned simulator is faithful, its role in safety cases will remain limited, however impressive its output. The second is how the law will treat trained generators. The European Data Protection Board's position that AI models trained on personal data are not automatically anonymous puts the burden on developers to show that personal data cannot be extracted. How that burden will be met in practice, what tests regulators will accept, and how this will interact with the more relative concept of personal data in recent case law, are questions still being worked out. The third is how to measure correctness at scale. Automated metrics capture statistical resemblance; human experts capture meaning but cannot review millions of samples. Methods that combine the two, using models to flag samples that are likely to be wrong and experts to adjudicate, are emerging but immature. The fourth is provenance. As synthetic data becomes common, distinguishing it from real data, and tracking which models were trained on what, becomes essential to avoid collapse and to support accountability. Watermarking, content credentials and dataset documentation all play a part, but none yet provides a complete answer. A closing principle Synthetic data is one of the most useful tools in modern machine learning, and its usefulness will grow. It allows teams to give rare cases the attention they deserve, to work with sensitive data more safely, and to test systems against situations that would be dangerous or impossible to arrange in reality. Used well, it makes models fairer, safer and more widely available. Used carelessly, it produces models that are confidently wrong about exactly the cases that matter, datasets that expose the people they were meant to protect, and safety claims that rest on simulations nobody has checked. The difference between the two is rarely the sophistication of the generator. It is whether the people using it asked where the knowledge came from, checked that it arrived, and kept the real world in the loop. Notes Chapter 1 1. Andrea Dal Pozzolo, Olivier Caelen, Reid A. Johnson and Gianluca Bontempi, "Calibrating Probability with Undersampling for Unbalanced Classification", IEEE Symposium on Computational Intelligence and Data Mining, 2015. Source of the European credit card fraud dataset released by the Université Libre de Bruxelles machine learning group. 2. Nidhi Kalra and Susan M. Paddock, Driving to Safety: How Many Miles of Driving Would It Take to Demonstrate Autonomous Vehicle Reliability? RAND Corporation, RR-1478-RC, 2016. Chapter 2 1. Nitesh V. Chawla, Kevin W. Bowyer, Lawrence O. Hall and W. Philip Kegelmeyer, "SMOTE: Synthetic Minority Over-sampling Technique", Journal of Artificial Intelligence Research 16 (2002): 321–357. 2. Donald B. Rubin, "Discussion: Statistical Disclosure Limitation", Journal of Official Statistics 9, no. 2 (1993): 461–468. 3. Neha Patki, Roy Wedge and Kalyan Veeramachaneni, "The Synthetic Data Vault", IEEE International Conference on Data Science and Advanced Analytics, 2016. 4. Jason Walonoski et al., "Synthea: An Approach, Method, and Software Mechanism for Generating Synthetic Patients and the Synthetic Electronic Health Care Record", Journal of the American Medical Informatics Association 25, no. 3 (2018): 230–238. 5. Alexey Dosovitskiy, German Ros, Felipe Codevilla, Antonio López and Vladlen Koltun, "CARLA: An Open Urban Driving Simulator", Conference on Robot Learning, 2017. 6. Josh Tobin, Rachel Fong, Alex Ray, Jonas Schneider, Wojciech Zaremba and Pieter Abbeel, "Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World", IEEE/RSJ International Conference on Intelligent Robots and Systems, 2017. 7. Waymo's figure of ten billion simulated miles was reported in July 2019, for example by TechCrunch, "Waymo has now driven 10 billion autonomous miles in simulation", 10 July 2019. Chapter 3 1. Ian Goodfellow et al., "Generative Adversarial Nets", Advances in Neural Information Processing Systems 27, 2014. 2. Martin Arjovsky, Soumith Chintala and Léon Bottou, "Wasserstein Generative Adversarial Networks", International Conference on Machine Learning, 2017. 3. Tero Karras, Samuli Laine and Timo Aila, "A Style-Based Generator Architecture for Generative Adversarial Networks", IEEE/CVF Conference on Computer Vision and Pattern Recognition, 2019. 4. Mehdi Mirza and Simon Osindero, "Conditional Generative Adversarial Nets", arXiv:1411.1784, 2014. 5. Phillip Isola, Jun-Yan Zhu, Tinghui Zhou and Alexei A. Efros, "Image-to-Image Translation with Conditional Adversarial Networks", CVPR, 2017; Jun-Yan Zhu, Taesung Park, Phillip Isola and Alexei A. Efros, "Unpaired Image-to-Image Translation Using Cycle-Consistent Adversarial Networks", ICCV, 2017. 6. Maayan Frid-Adar et al., "GAN-Based Synthetic Medical Image Augmentation for Increased CNN Performance in Liver Lesion Classification", Neurocomputing 321 (2018): 321–331. 7. Lei Xu, Maria Skoularidou, Alfredo Cuesta-Infante and Kalyan Veeramachaneni, "Modeling Tabular Data Using Conditional GAN", Advances in Neural Information Processing Systems 32, 2019. 8. Jinsung Yoon, Daniel Jarrett and Mihaela van der Schaar, "Time-series Generative Adversarial Networks", Advances in Neural Information Processing Systems 32, 2019. 9. James Jordon, Jinsung Yoon and Mihaela van der Schaar, "PATE-GAN: Generating Synthetic Data with Differential Privacy Guarantees", International Conference on Learning Representations, 2019. 10. Tero Karras et al., "Training Generative Adversarial Networks with Limited Data", Advances in Neural Information Processing Systems 33, 2020. Chapter 4 1. Jascha Sohl-Dickstein, Eric Weiss, Niru Maheswaranathan and Surya Ganguli, "Deep Unsupervised Learning Using Nonequilibrium Thermodynamics", International Conference on Machine Learning, 2015. 2. Yang Song and Stefano Ermon, "Generative Modeling by Estimating Gradients of the Data Distribution", Advances in Neural Information Processing Systems 32, 2019. 3. Jonathan Ho, Ajay Jain and Pieter Abbeel, "Denoising Diffusion Probabilistic Models", Advances in Neural Information Processing Systems 33, 2020. 4. Prafulla Dhariwal and Alex Nichol, "Diffusion Models Beat GANs on Image Synthesis", Advances in Neural Information Processing Systems 34, 2021. 5. Jonathan Ho and Tim Salimans, "Classifier-Free Diffusion Guidance", arXiv:2207.12598, 2022. 6. Robin Rombach, Andreas Blattmann, Dominik Lorenz, Patrick Esser and Björn Ommer, "High-Resolution Image Synthesis with Latent Diffusion Models", CVPR, 2022. 7. Akim Kotelnikov, Dmitry Baranchuk, Ivan Rubachev and Artem Babenko, "TabDDPM: Modelling Tabular Data with Diffusion Models", International Conference on Machine Learning, 2023. 8. Ruifei He et al., "Is Synthetic Data from Generative Models Ready for Image Recognition?", International Conference on Learning Representations, 2023. 9. Shekoofeh Azizi, Simon Kornblith, Chitwan Saharia, Mohammad Norouzi and David J. Fleet, "Synthetic Data from Diffusion Models Improves ImageNet Classification", Transactions on Machine Learning Research, 2023. 10. Brandon Trabucco, Kyle Doherty, Max Gurinas and Ruslan Salakhutdinov, "Effective Data Augmentation with Diffusion Models", International Conference on Learning Representations, 2024. 11. Nataniel Ruiz et al., "DreamBooth: Fine Tuning Text-to-Image Diffusion Models for Subject-Driven Generation", CVPR, 2023; Edward J. Hu et al., "LoRA: Low-Rank Adaptation of Large Language Models", International Conference on Learning Representations, 2022. 12. Nicholas Carlini et al., "Extracting Training Data from Diffusion Models", USENIX Security Symposium, 2023; Gowthami Somepalli et al., "Diffusion Art or Digital Forgery? Investigating Data Replication in Diffusion Models", CVPR, 2023. Chapter 5 1. Yotam Elor and Hadar Averbuch-Elor, "To SMOTE, or Not to SMOTE?", arXiv:2201.08528, 2022. 2. Guillaume Lemaître, Fernando Nogueira and Christos K. Aridas, "Imbalanced-learn: A Python Toolbox to Tackle the Curse of Imbalanced Datasets in Machine Learning", Journal of Machine Learning Research 18 (2017): 1–5. Chapter 6 1. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 4(1) and Recital 26. 2. Article 29 Data Protection Working Party, Opinion 05/2014 on Anonymisation Techniques, WP216, 10 April 2014. 3. Court of Justice of the European Union, Case C-582/14, Breyer v Bundesrepublik Deutschland, 19 October 2016; Case C-413/23 P, EDPS v SRB, 4 September 2025. 4. European Data Protection Board, Opinion 28/2024 on Certain Data Protection Aspects Related to the Processing of Personal Data in the Context of AI Models, 17 December 2024. 5. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 10(5). 6. US Department of Health and Human Services, HIPAA Privacy Rule de-identification standard, 45 CFR 164.514(a)–(b). 7. Reza Shokri, Marco Stronati, Congzheng Song and Vitaly Shmatikov, "Membership Inference Attacks Against Machine Learning Models", IEEE Symposium on Security and Privacy, 2017. 8. Theresa Stadler, Bristena Oprisanu and Carmela Troncoso, "Synthetic Data – Anonymisation Groundhog Day", USENIX Security Symposium, 2022. 9. Cynthia Dwork, Frank McSherry, Kobbi Nissim and Adam Smith, "Calibrating Noise to Sensitivity in Private Data Analysis", Theory of Cryptography Conference, 2006. Chapter 7 1. ISO 21448:2022, Road Vehicles – Safety of the Intended Functionality; ISO 34502:2022, Road Vehicles – Test Scenarios for Automated Driving Systems – Scenario Based Safety Evaluation Framework; ANSI/UL 4600, Standard for Safety for the Evaluation of Autonomous Products. 2. UN Regulation No. 157, Automated Lane Keeping Systems, adopted by UNECE WP.29 in 2020. 3. Alexis C. Madrigal, "Inside Waymo's Secret World for Training Self-Driving Cars", The Atlantic, August 2017. 4. Shuo Feng et al., "Dense Reinforcement Learning for Safety Validation of Autonomous Vehicles", Nature 615 (2023): 620–627. 5. Ze Yang et al., "UniSim: A Neural Closed-Loop Sensor Simulator", CVPR, 2023. 6. Anthony Hu et al., "GAIA-1: A Generative World Model for Autonomous Driving", arXiv:2309.17080, 2023. Chapter 8 1. Joshua Snoke, Gillian M. Raab, Beata Nowok, Chris Dibben and Aleksandra Slavković, "General and Specific Utility Measures for Synthetic Data", Journal of the Royal Statistical Society: Series A 181, no. 3 (2018): 663–688. 2. Martin Heusel et al., "GANs Trained by a Two Time-Scale Update Rule Converge to a Local Nash Equilibrium", Advances in Neural Information Processing Systems 30, 2017. 3. Tuomas Kynkäänniemi, Tero Karras, Samuli Laine, Jaakko Lehtinen and Timo Aila, "Improved Precision and Recall Metric for Assessing Generative Models", Advances in Neural Information Processing Systems 32, 2019. 4. Ahmed M. Alaa, Boris van Breugel, Evgeny Saveliev and Mihaela van der Schaar, "How Faithful Is Your Synthetic Data? Sample-Level Metrics for Evaluating and Auditing Generative Models", International Conference on Machine Learning, 2022. 5. Cristóbal Esteban, Stephanie L. Hyland and Gunnar Rätsch, "Real-Valued (Medical) Time Series Generation with Recurrent Conditional GANs", arXiv:1706.02633, 2017. 6. Ilia Shumailov et al., "AI Models Collapse When Trained on Recursively Generated Data", Nature 631 (2024): 755–759. 7. Sina Alemohammad et al., "Self-Consuming Generative Models Go MAD", International Conference on Learning Representations, 2024. 8. Matthias Gerstgrasser et al., "Is Model Collapse Inevitable? Breaking the Curse of Recursion by Accumulating Real and Synthetic Data", arXiv:2404.01413, 2024. 9. Suriya Gunasekar et al., "Textbooks Are All You Need", arXiv:2306.11644, 2023. 10. Timnit Gebru et al., "Datasheets for Datasets", Communications of the ACM 64, no. 12 (2021): 86–92. Further Reading Ian Goodfellow, Yoshua Bengio and Aaron Courville, Deep Learning (MIT Press, 2016).** The standard textbook on deep learning, with a clear chapter on deep generative models including the adversarial approach co-invented by its first author. It predates diffusion models but remains the best grounding in the underlying machinery. Kevin P. Murphy, Probabilistic Machine Learning: Advanced Topics (MIT Press, 2023).** A comprehensive and current treatment of generative models, including variational autoencoders, GANs and diffusion models, written from a probabilistic perspective. Demanding but authoritative, and freely available online from the author. Khaled El Emam, Lucy Mosquera and Richard Hoptroff, Practical Synthetic Data Generation: Balancing Privacy and the Broad Availability of Data (O'Reilly, 2020).** A practitioner's guide to generating and evaluating synthetic data for sharing, written by authors with long experience in health data de-identification. Strong on utility and privacy assessment. Cynthia Dwork and Aaron Roth, The Algorithmic Foundations of Differential Privacy (Now Publishers, 2014).** The definitive introduction to differential privacy by one of its originators. Mathematical, but the opening chapters explain clearly why formal guarantees matter and why ad hoc anonymisation fails. Theresa Stadler, Bristena Oprisanu and Carmela Troncoso, "Synthetic Data – Anonymisation Groundhog Day" (USENIX Security Symposium, 2022). The most important single paper on the privacy limits of synthetic data. Essential reading for anyone asked to judge whether a synthetic dataset is anonymous. Nidhi Kalra and Susan M. Paddock, Driving to Safety (RAND Corporation, 2016).** A short, readable report that sets out why real-world test driving alone cannot establish the safety of automated vehicles, and why simulation and other methods are indispensable. Ilia Shumailov et al., "AI Models Collapse When Trained on Recursively Generated Data" (Nature, 2024). The paper that brought model collapse to wide attention, with a lucid explanation of why recursive training on generated data erodes the tails of a distribution. Hashtags: #SyntheticDataGeneration #SyntheticData #GenerativeAI #ArtificialIntelligence #MachineLearning #DataScarcity #DataAugmentation #GenerativeAdversarialNetworks #GANs #DiffusionModels #SyntheticTrainingData #DataScience #DeepLearning #ImbalancedDatasets #ClassImbalance #SMOTE #MinorityClassOversampling #FewShotLearning #PrivacyPreservingAI #DifferentialPrivacy #SyntheticMedicalData #HealthcareAI #FraudDetection #AutonomousDriving #SimulationBasedTraining #DomainRandomization #SimToReal #DataQualityAssessment #ModelEvaluation #ResponsibleAI

Download the Book (PDF): Introduction Most React Native performance problems are not caused by React Native being slow. They are caused by teams not knowing where the work in their app actually happens. A list stutters because a component re-renders four hundred rows on every keystroke. A screen takes two seconds to open because an analytics module synchronously reads a large file from disk during startup. Memory climbs from 180 megabytes to 900 over a twenty-minute session because an image cache has no ceiling and an event listener holds a reference to a screen that was dismissed long ago. None of these are framework defects. All of them are failures to understand the boundaries inside a React Native application: which thread a piece of work runs on, what it costs to move data between JavaScript and native code, and who owns a given block of memory. That is the argument of this book. A React Native app at scale is a system of boundaries, and its performance is decided by the traffic across them. Between the JavaScript thread and the main thread. Between your JavaScript code and the native modules that do what JavaScript cannot. Between the JavaScript heap, managed by a garbage collector, and the native heaps on iOS and Android, managed by reference counting and by a different garbage collector respectively. The teams that ship fast, stable React Native apps are the ones that design those boundaries deliberately, keep the traffic across them narrow and typed, and measure on the devices their users actually own. The framework itself has changed underneath this argument in ways that matter. For most of its life, React Native connected JavaScript and native code through an asynchronous bridge: every call from one side to the other was serialized to JSON, queued, and delivered later on another thread. That design made certain things impossible, such as reading a view's size synchronously during layout, and made other things expensive, such as streaming large amounts of data from a sensor to JavaScript. The replacement, known as the New Architecture, swaps the bridge for a C++ interface called JSI that lets JavaScript hold direct references to native objects and call them synchronously. It brings a new native module system (TurboModules), a new renderer (Fabric), a build-time code generator (Codegen) that turns typed JavaScript specifications into native interfaces, and an event loop modeled on the web's. The transition took years. The New Architecture became the default for new projects in React Native 0.76, released in October 2024. With 0.82, in October 2025, it became the only architecture: the flags that used to switch it off are now ignored. Version 0.84, in February 2026, began physically removing legacy code paths from the builds and made Hermes V1, a substantially rebuilt version of React Native's own JavaScript engine, the default on both platforms. As this book goes to press in autumn 2026, the current stable line is 0.87, released in August, and the project ships a new minor version roughly every two months while supporting the latest three. Anyone still maintaining an app on the old architecture is now maintaining it on unsupported versions of the framework. So the question this book answers is not whether to adopt the New Architecture. It is how to use it well, and how to get a large existing codebase onto it without breaking the product along the way. Who this book is for The reader I have in mind already ships React Native code. You know React, you have written components and hooks, you have probably run pod install more times than you would like, and you have at least once opened Xcode or Android Studio to find out why a build failed. What you may not yet have is a working model of the runtime: what the JavaScript thread is doing when a frame is dropped, why one native module call costs nanoseconds and another costs milliseconds, how a heap snapshot from Hermes relates to the memory figure that the operating system uses to decide whether to kill your app. You may also be the person on your team who has been handed a specific problem. A product that has grown to hundreds of screens and dozens of third-party native libraries, and now needs to move to the New Architecture before the next framework upgrade. A custom Swift or Kotlin SDK from a payments provider or a hardware vendor that must be exposed to JavaScript. A low-end Android device in the test lab that drops frames on the home feed while every engineer's flagship phone renders it perfectly. This book is written to be useful to that person. It assumes no prior knowledge of Swift, Kotlin, Objective-C++, or C++ beyond the ability to read code in a C-family language. Where those languages appear, the snippets are short and the important lines are explained. How the book is organized The chapters move from model to practice, and from the JavaScript side of the boundary to the native side and back. Chapter 1 builds the runtime model: the threads a React Native app runs on, what Hermes does with your JavaScript before and during execution, and the frame budget that every other chapter is ultimately negotiating with. Chapter 2 explains what the New Architecture actually changed, piece by piece, and what it did not change, because a surprising number of performance problems survive the migration untouched. Chapters 3 through 5 are about native modules. Chapter 3 treats the module interface as a design problem: what belongs in a spec, when a method should be synchronous, how to shape data so that crossing the boundary is cheap, and how errors and events should flow. Chapter 4 implements modules in Swift on iOS, including the Objective-C++ adapter layer that Swift still requires and the threading rules that keep it safe. Chapter 5 does the same in Kotlin on Android, with attention to coroutines, lifecycle, and the context leaks that are the most common source of native memory problems in React Native apps. That chapter also compares the main ways of authoring modules, including the Expo Modules API, which many teams now prefer for new work. Chapter 6 turns to the JavaScript thread: rendering cost, list virtualization, animation, startup, and the specific patterns that keep the thread responsive. Chapter 7 covers native views under the Fabric renderer, where the rules for custom UI components changed most. Chapters 8 and 9 are about measurement. Chapter 8 covers CPU, frame, and startup profiling with React Native DevTools, the platform profilers, and production telemetry. Chapter 9 is devoted to memory: reading heap snapshots, finding native leaks on both platforms, and understanding how the operating system judges your app's footprint. Chapter 10 is a migration playbook for large codebases moving to the New Architecture, built around inventory, staged rollout, and the behavioral differences that cause real regressions. The Conclusion draws out what all of this implies for how teams should organize performance work. A note on versions and evidence React Native moves quickly, and books about it age. I have tried to write in a way that survives the next few releases by explaining mechanisms rather than listing flags. Where specific versions matter, such as when a capability arrived or a legacy path was removed, the version is named and is drawn from the project's own release notes. Where performance numbers appear, they come from published sources, and I name them. Many widely repeated claims about React Native performance are anecdotes that have hardened into folklore; where I cannot trace a number to a source, I describe the mechanism instead and leave you to measure it in your own app, which is what you should do anyway. One habit runs through every chapter and is worth stating plainly at the start. Profile release builds, on real hardware, at the low end of your user base. Debug builds of React Native run JavaScript differently, include extra validation, and on Android can run several times slower than release builds; the project's own notes for 0.82 described a new optimized debug build type on Android that reached roughly 60 frames per second where a standard debug build managed about 20. A performance conclusion drawn from a debug build on a recent flagship phone tells you almost nothing about what a user on a three-year-old mid-range Android device experiences. Most of the mistakes I have seen in React Native performance work begin there. The boundaries in your app are already there whether you design them or not. The rest of this book is about designing them. Chapter 1: The Runtime Model Before you can optimize a React Native app you need a picture of what is running, where, and in what order. Most performance advice for React Native is a list of tricks: memoize this, virtualize that, use the native driver. The tricks are useful, but without a model of the runtime they are applied by superstition, and superstition does not scale to a codebase with two hundred contributors. This chapter builds the model. It is deliberately mechanical, because every later chapter depends on it. Threads and what they own A React Native app is a native app. On iOS it is a process with a UIApplication and a main thread running a run loop; on Android it is a process with an Activity and a main thread running a Looper. Everything the platform considers user interface, from touch delivery to view drawing to accessibility, happens on that main thread, which React Native documentation usually calls the UI thread. This is not a React Native decision. Both UIKit and the Android view system require that views be created, mutated, and measured on the main thread, and both will crash or misbehave if you do otherwise. React Native adds a JavaScript runtime to that process. The runtime, which is Hermes in almost every modern app, executes on its own dedicated thread, conventionally called the JavaScript thread. Your components, your hooks, your state management, your business logic, your network response parsing, and every callback you pass to a Pressable run there. The JavaScript thread is single-threaded in exactly the way a browser tab's main thread is: one task at a time, run to completion. The third participant is layout. React Native uses Yoga, a C++ implementation of a subset of Flexbox, to compute the position and size of every element. Under the New Architecture's renderer, Fabric, layout is computed on whatever thread commits the tree, which for ordinary React updates is the JavaScript thread, and can be a background thread or the UI thread in other cases. The important point is that layout is not done by UIKit's Auto Layout or Android's ViewGroup.onMeasure; it is done in C++ by Yoga, and the results are handed to the platform views as fixed frames. Native modules add a fourth category. A native module method may execute on the JavaScript thread itself, if it is synchronous; on the main thread, if it touches UI; or on a queue or thread pool that the module chooses. The choice of where a module's work runs is one of the most consequential decisions a native module author makes, and chapters 4 and 5 return to it in detail. The model to hold in your head is this. The UI thread owns the screen and must never be blocked. The JavaScript thread owns your application logic and must be kept free enough to respond. Everything else, including disk, network, image decoding, cryptography, and heavy computation, belongs on other threads, and the art of React Native performance is largely the art of making sure it ends up there. The frame budget Displays refresh at a fixed rate. On a 60 Hz screen, a new frame is due every 16.7 milliseconds. On a 120 Hz screen, which is now common on both premium iPhones and mid-range Android devices, the interval halves to about 8.3 milliseconds. If the work required to produce a frame is not finished by the deadline, the previous frame is shown again. The user perceives this as a stutter, or, in the language of profilers, a dropped or janky frame. React Native has two frame budgets, not one. The UI thread must finish its work for each frame on time, or native scrolling, native animations, and touch feedback stutter. The JavaScript thread does not draw frames itself, but anything that depends on JavaScript, such as a state update that changes what is on screen or a JavaScript-driven animation, can only update as fast as the JavaScript thread can produce new trees. A useful way to describe this is two frame rates. A screen can have a perfect UI frame rate while the JavaScript frame rate collapses: scrolling feels smooth because it is handled natively, but a tap on a button does nothing for 400 milliseconds because the JavaScript thread is busy parsing a large JSON response. The reverse also happens: a tight JavaScript animation loop is fine, but the UI thread is blocked by a native module decoding an image synchronously, and everything freezes. When someone on your team says a screen is slow, the first diagnostic question is always which thread is over budget. The tools in chapter 8 answer that directly, but the habit of asking it comes first. How a frame is produced under Fabric Fabric, the New Architecture renderer, describes its work in three phases, and the vocabulary is worth learning because the profilers use it. The first phase is render. When React state changes, React calls your component functions on the JavaScript thread and produces a tree of React elements. Fabric's React renderer then creates or clones the corresponding nodes in a C++ structure called the shadow tree. Each shadow node carries the props and layout information for one host component, such as a View, Text, or Image. The shadow tree is immutable: an update produces a new tree that shares unchanged nodes with the old one, which is what makes it safe to read from multiple threads. The second phase is commit. The new shadow tree is laid out by Yoga, which computes the frames of every node, and then the tree is promoted to become the next tree to be mounted. Layout is the expensive part of commit, and its cost scales with the number of nodes that changed and their position in the hierarchy. A change at the root of a deep tree can force layout across a large fraction of it. The third phase is mount. The renderer computes the difference between the previously mounted tree and the new one, producing a list of mutations: create this view, update these props, insert that child, delete this one. Those mutations are applied to real platform views on the UI thread. Three consequences follow. First, the JavaScript thread's per-update cost is the cost of re-running component functions plus the cost of building the shadow tree; reducing re-renders reduces both. Second, the UI thread's per-update cost is proportional to the number of mutations, not to the size of the React tree, so a large tree that changes in one place is cheap to mount. Third, because the shadow tree lives in C++ and is immutable, Fabric can perform layout synchronously when JavaScript needs to read it, which is why useLayoutEffect and synchronous measurement work properly under the New Architecture. Under the old renderer, measurement was always asynchronous, and code that positioned a tooltip relative to a button rendered a frame in the wrong place before correcting itself. Fabric also applies an optimization called view flattening. Many View elements in a React tree exist purely for layout: they have no background, no border, no touch handling, and no accessibility role. Fabric identifies these and does not create corresponding native views for them, attaching their children directly to the nearest ancestor that must exist. On Android this had long been done by the old renderer; Fabric brought it to iOS as well. The practical effect is that a deeply nested React layout does not necessarily produce a deeply nested native view hierarchy, which matters for both memory and drawing cost. Hermes: what happens to your JavaScript Hermes is a JavaScript engine built by Meta specifically for React Native. It became the default engine in React Native 0.70 and is now effectively universal. Its design is unusual among JavaScript engines, and the differences explain several of its performance characteristics. Most JavaScript engines, including V8 in Chrome and JavaScriptCore in Safari, receive JavaScript source at runtime, parse it, compile it to bytecode, and then compile hot functions to machine code with a just-in-time (JIT) compiler. Hermes moves the parsing and bytecode compilation to build time. When you produce a release build, Metro bundles your JavaScript, and the Hermes compiler turns the bundle into Hermes bytecode, which ships inside the app. At startup, the engine does not need to parse anything; it maps the bytecode file into memory and starts executing. Because the file is memory-mapped, pages of bytecode that are never executed may never be read from storage at all. This is the main reason Hermes improved startup time over JavaScriptCore so substantially when it was introduced: parsing and compiling a multi-megabyte bundle is a large fixed cost that Hermes removes from the device. The trade-off is that the classic Hermes engine has no JIT. Hot loops run in the bytecode interpreter rather than as optimized machine code, so CPU-bound JavaScript, such as a heavy cryptographic routine or an image filter written in JavaScript, runs slower than it would in a JIT-enabled engine. On iOS this trade-off matters less than it seems, because third-party apps cannot use JIT compilation anyway outside of Apple's own web content processes. On Android it is a genuine trade, which the Hermes team chose deliberately in favor of startup speed and memory footprint. Hermes V1, which became the default in React Native 0.84, is a new bytecode compiler and a new virtual machine. It emerged from the Static Hermes research project, but it is important to be precise about what it is. Software Mansion, which worked on the integration, described it plainly: Hermes V1 does not compile your bundle into a native binary, does not use the type information in your code, and does not enable JIT. What it brings is a better compiler, a faster VM, and native support for language features, including ES6 classes, let and const, and async functions, that previously had to be transpiled by Babel into older, larger, and slower forms. The React Native team reported results from Expensify's production app when Hermes V1 was still experimental in 0.82: bundle load time improved by about 9 percent on iOS and about 3 percent on low-end Android, and total time to interactive improved by 7.6 percent on Android and 2.5 percent on iOS. These are meaningful but not transformative numbers, which is the right expectation to set. An engine upgrade does not fix an app that does too much work. Hermes also manages the JavaScript heap with its own garbage collector. The current collector, called Hades, is generational and does most of its work concurrently on a background thread, which keeps the pauses on the JavaScript thread short. Generational means it assumes that most objects die young and collects the young generation frequently and cheaply, promoting survivors to an old generation that is collected less often. The design keeps GC pauses small, but it does not make allocation free. A render path that creates thousands of short-lived objects per frame still pays for those allocations, and the collector still runs more often as a result. Chapter 9 returns to the heap in detail. The event loop The New Architecture introduced a formal event loop on the JavaScript thread, modeled on the HTML standard's. Understanding its ordering helps explain several subtle behaviors. Work on the JavaScript thread is organized into tasks. A task might be a timer callback, a native event such as a touch, the delivery of a network response, or a callback from a native module. After each task, the runtime drains the microtask queue, which holds promise continuations and callbacks queued with queueMicrotask. Only after microtasks are drained does the event loop perform a rendering update, in which React's pending updates are flushed into the renderer. Two consequences matter in practice. First, a long chain of promise continuations runs to completion before anything renders. Code that processes a large array with an async function that awaits on each element, believing that await yields to the UI, does not yield in the sense that matters: each continuation is a microtask, and the whole chain can run without a single render. To actually give the renderer and other tasks a turn, you must schedule a new task, for example with setTimeout, or use React's own scheduling through startTransition. Second, because events are processed in a defined order with rendering steps between tasks, React can prioritize user input over less urgent rendering, which is what makes concurrent features such as transitions work in React Native as they do on the web. React Native 0.87 removed the long-deprecated InteractionManager API, which developers once used to defer work until animations finished, and points to requestIdleCallback instead. The change reflects the same model. Deferral is a scheduling concern of the event loop, and the web's scheduling primitives now apply. Startup as a sequence Startup deserves its own model because it is where many large apps lose the most user-visible time, and because every phase has a different owner. The sequence on a cold launch runs roughly as follows. The operating system creates the process and loads the app's native binary and its dynamic libraries. Native application initialization runs: the app delegate on iOS, the Application subclass on Android, plus any SDKs initialized there. React Native's host is created, the Hermes runtime is initialized, and the bytecode bundle is loaded. The bundle's top-level code executes, which means every module that the entry point imports, and every module those import, runs its top-level statements. Then React renders the first screen, Fabric commits and mounts it, and the user sees content. Each phase can be the bottleneck, and the profiling tools for each differ. Native initialization is measured in Xcode Instruments or Android Studio; bundle execution and first render are measured in the JavaScript profiler. The most common startup problem in large React Native apps is not the engine at all but eager module evaluation: an entry point that imports a barrel file that imports every screen, every screen's dependencies, and a set of SDKs that do real work at import time. Hermes's memory-mapped bytecode makes loading cheap, but executing the top-level code of two thousand modules is not. Chapter 6 covers the techniques, such as inline requires and lazy screen registration, that move that work out of the startup path. What the model predicts A good model makes predictions, and this one makes several that the rest of the book tests. It predicts that the most expensive mistakes are those that put the wrong work on the wrong thread: disk access on the UI thread, JSON parsing of a large payload on the JavaScript thread during an interaction, layout-thrashing state updates during a scroll. It predicts that reducing the number of React re-renders helps the JavaScript thread but does little for the UI thread unless the number of native mutations also drops. It predicts that an engine upgrade will produce single-digit percentage improvements while architectural changes to how an app loads and renders can produce improvements measured in multiples. And it predicts that native module design matters a great deal, because a native module is the one place where your code chooses explicitly which thread does the work and what data crosses between runtimes. That last prediction is where the New Architecture changed the rules most, and it is the subject of the next chapter. Chapter 2: From Bridge to JSI The New Architecture is often described as a performance upgrade, and that description causes trouble. Teams migrate expecting their app to become faster and find that most screens feel exactly the same. Some screens get faster. A few get slower, usually because a library is now running through a compatibility layer. The reason is that the New Architecture is primarily a change in what is possible across the JavaScript-native boundary, and only secondarily a change in how fast existing code runs. To use it well, you need to understand precisely what the old boundary was, what replaced it, and what stayed the same. What the bridge was In the original architecture, JavaScript and native code lived in separate worlds connected by a message queue called the bridge. When JavaScript called a native module method, React Native serialized the module name, method name, and arguments into a JSON-compatible structure, appended it to a batch, and at some later point flushed the batch to the native side. The native side deserialized the batch, looked up each module and method by name, converted the arguments into native types, and invoked the method, typically on a background queue. If the method needed to return a value, it did so by invoking a callback or resolving a promise, which sent another message back across the bridge in the opposite direction. UI worked the same way. The old renderer's JavaScript side computed which views to create and update and sent those operations across the bridge to a native UIManager module, which executed them. Touch events traveled the other way, serialized from native into messages delivered asynchronously to JavaScript. This design had real virtues. It was simple to reason about, the two sides could never deadlock each other, and it let the same JavaScript run against very different native implementations. But it imposed three costs that grew with app size. The first cost was serialization. Every argument and every return value was converted to an intermediate representation and back. For small messages this was negligible. For large ones, such as an array of ten thousand coordinate pairs from a mapping SDK or a base64-encoded image, it dominated. Teams worked around it by avoiding the bridge for heavy data, which often meant duplicating logic on both sides. The second cost was asynchrony. Nothing could be read from native code synchronously. You could not ask a native view its size during render, query a native key-value store during module initialization without a promise, or respond to a touch in the same frame it occurred if the response required JavaScript. Workarounds for this produced an entire genre of visible glitches: content that rendered in the wrong position for a frame, keyboards that pushed layouts a beat late, gestures that lagged their finger. The third cost was eager initialization. The bridge needed to know about every native module at startup so that JavaScript could address it by name. In practice this meant that native modules were instantiated at launch whether or not the app would use them in that session, which in a large app with dozens of third-party SDKs added measurable startup time. JSI and the four pieces The New Architecture rests on JSI, the JavaScript Interface. JSI is a C++ API that abstracts over a JavaScript engine. It lets C++ code create JavaScript values, call JavaScript functions, and, crucially, expose C++ objects to JavaScript as if they were ordinary JavaScript objects. Such an object is called a host object. When JavaScript reads a property or calls a method on a host object, the engine invokes C++ code directly, on the JavaScript thread, with no serialization and no queue. Everything else in the New Architecture is built on this capability. A TurboModule is a host object whose methods call into native code. The Fabric renderer is a C++ component that JavaScript talks to through JSI. Libraries that need extremely high-throughput communication with native code, such as those for animation, storage, and camera frame processing, use JSI directly. It is worth being clear about what JSI does not do. It does not make native code run on the JavaScript thread unless you call it synchronously. It does not make data free: converting a large JavaScript array into a std::vector still costs time proportional to its length, though far less than the old JSON round trip. And it does not remove the need to think about threads. A host object's methods run on the JavaScript thread by default, so a slow synchronous method blocks JavaScript exactly as a slow function written in JavaScript would. The four pieces The React Native team describes the New Architecture as four parts, each replacing a part of the old system. The first is the new native module system, TurboModules. Modules are defined by a typed specification in TypeScript or Flow, implemented natively, and exposed to JavaScript through JSI. They load lazily: a module is instantiated the first time JavaScript requests it, not at startup. They can expose synchronous methods that return values directly. And because their interfaces are generated from the spec, the type contract between JavaScript and native is checked at build time rather than discovered at runtime. The second is the new renderer, Fabric, described in the previous chapter. Its core is written in C++ and shared across platforms. It maintains an immutable shadow tree, supports multiple trees in progress at different priorities, which is what allows React's concurrent rendering to work, and permits synchronous layout reads from JavaScript. The third is the event loop, also described in the previous chapter, which gives JavaScript execution a well-defined order of tasks, microtasks, and rendering updates, and lets React interrupt low-priority rendering to process urgent events. The fourth is bridgeless mode, which removes the bridge from the runtime entirely. Initialization, error reporting, and module access all go through the new systems. Bridgeless mode improved startup and error reporting, and it is now the only way the runtime operates. Codegen ties these together. It is a build-time tool that reads the typed specs for modules and components and generates the native scaffolding: Java or Kotlin abstract classes on Android, Objective-C protocols and C++ JSI glue on iOS, and C++ shared code for both. Codegen runs as part of the Gradle build on Android and during pod install on iOS. Its existence is why the New Architecture can promise type safety across the boundary, and why the shape of your spec file matters so much, which is the subject of the next chapter. The differences between the old and new systems are summarized in Table 1. Table 1. How the legacy and New Architecture boundaries differ. Concern Legacy architecture New Architecture JS-native transport Asynchronous JSON bridge Direct C++ calls via JSI Module loading All modules at startup Lazy, on first use Synchronous calls Not supported in practice Supported, return values directly Type contract Runtime, by method name Build-time, generated by Codegen Renderer Platform-specific, async layout reads Shared C++ core, sync layout reads Concurrent React Not supported Transitions, Suspense, automatic batching Three things the bridge could not do Abstract descriptions of synchronous access undersell it. Three ordinary product problems show what changed. The first is persisted state at launch. Most apps restore something from local storage before showing their first screen: the signed-in user, a theme preference, the last open tab, a cached feed. With the bridge, every storage read was asynchronous, so the first render had to show a placeholder, wait for the read, and then render again with the real data. Users saw a flash of the wrong theme or an empty screen for a few frames. Libraries that expose a key-value store through JSI, MMKV-based storage being the best-known example, made the read synchronous: the root component reads the persisted values during its first render, and the first frame the user sees is the correct one. The same pattern now works with any TurboModule that exposes a small synchronous getter backed by an in-memory cache. The second is positioning relative to other elements. A tooltip, a popover, a dropdown menu, or a coach mark needs to know where its anchor is on screen. Under the bridge, measuring a view meant sending a request across the bridge and receiving the answer in a callback, after at least one frame had already been drawn. The workaround was to render the overlay invisibly, measure, and then reveal it, which added a frame of latency and a visible jump if anything moved. Under Fabric, the layout is readable synchronously in a layout effect, and the overlay is positioned correctly in the frame in which it first appears. The third is gesture response. A drag that moves a view under the user's finger needs each touch movement to produce a position update within the same frame. Under the bridge, the touch event was serialized to JavaScript, the handler ran, the new position was serialized back, and the update was applied, with at least two queue hops in between. Under load, this produced the familiar feeling of a view lagging behind the finger. Modern gesture and animation libraries use JSI to run the response logic on the UI thread itself, or to communicate synchronously, which is why the same gesture now tracks the finger closely even when the JavaScript thread is busy. None of these is a throughput improvement in the benchmark sense. Each removes a frame or two of latency and a visible artifact from an interaction the user performs constantly. Across an app, that is most of what users mean when they say a React Native app feels native. The timeline that matters The New Architecture was a multi-year transition, and the version history determines what you can still do on any given app. It was available as an opt-in for years, but the decisive release was 0.76, in October 2024, which enabled it by default for new and upgraded projects. At that point the React Native team reported that more than 850 libraries were compatible, including every library with more than 200,000 weekly downloads, and that Meta was already running it in the Facebook and Instagram apps. Version 0.76 also introduced an automatic interoperability layer, which let most libraries written for the old architecture run unmodified. In June 2025, version 0.80 formally froze the legacy architecture: no new features or fixes would be made to it. Version 0.81 was the last release in which the New Architecture could be turned off. Version 0.82, in October 2025, made the New Architecture the only option; setting newArchEnabled=false in Android's Gradle properties or RCT_NEW_ARCH_ENABLED=0 when installing pods on iOS is now simply ignored. Version 0.84, in February 2026, began removing legacy code: on iOS, legacy architecture code is excluded from builds by default, which the release notes say reduces both build time and app size, and on Android fourteen legacy classes, including the old CxxModuleWrapper and the bridge's development support manager, were deleted. By 0.87, released in August 2026, even the feature flag that once toggled TurboModules had been removed, because there is nothing left to toggle. The practical meaning for a team in late 2026 is simple. If your app runs on React Native 0.81 or earlier, you are on an unsupported version, since the project supports only the three most recent minor releases. To get onto a supported version, you must run on the New Architecture. Chapter 10 treats that migration as a project in its own right. Interop layers and their limits The interoperability layers deserve particular attention because they are the reason migrations are possible and the reason some migrated apps do not improve. For modules, the interop layer lets a native module written against the old RCTBridgeModule protocol on iOS or the old ReactContextBaseJavaModule pattern on Android be loaded and called from JavaScript under the New Architecture. The module behaves much as it did: asynchronous methods, arguments converted dynamically. It does not gain synchronous access, typed contracts, or the reduced conversion overhead of a generated TurboModule. For views, the renderer interop layer lets native UI components written for the old renderer be displayed by Fabric. It handles the common cases, but it cannot provide features that depend on Fabric's internals. A legacy component cannot participate in concurrent rendering correctly, cannot use custom shadow nodes, and may depend on old APIs, such as directly calling UIManager methods or using setNativeProps, that behave differently or are unsupported. The React Native team has said from the start that the interop layers are a bridge to be crossed, not a place to live, and that they will eventually be removed. A library that is still running only through interop in 2026 is a maintenance risk regardless of whether it works today. What did not change The most useful thing to understand about the New Architecture is what it left alone, because these are the places where migrated apps still have the same problems. It did not change React. Re-rendering a large component tree on every keystroke costs as much CPU time on the JavaScript thread as it did before; the cost lives in your component functions, not in the bridge. If your app's main problem was excessive rendering, the migration will not fix it. It did not change image decoding, network latency, disk I/O, or the cost of native SDKs. A payments SDK that blocks the main thread for 300 milliseconds during initialization still does so. It did not change the cost of JavaScript itself. Parsing a two-megabyte JSON response on the JavaScript thread takes as long under JSI as it did under the bridge, because JSI was never involved in that parse. It did not change memory ownership rules. JavaScript objects are still garbage collected, native objects are still reference counted on iOS and garbage collected by a separate collector on Android, and an object that crosses between them can still be kept alive by references the other side does not know about. JSI makes it easier, not harder, to create such references, because host objects can hold native resources whose lifetime is now tied to a JavaScript garbage collector that has no idea how large they are. And it did not change the rule that slow work must not happen on the UI thread or the JavaScript thread. If anything, it made that rule easier to break. Under the bridge, every native module call was asynchronous whether you liked it or not, which forced work onto other threads. Under the New Architecture, a synchronous method is a single line in a spec file, and nothing stops you from writing one that reads a file from disk while JavaScript waits. Where the gains actually come from The gains from the New Architecture are real, but they arrive in specific places. They show up in startup, through lazy module loading and bridgeless initialization, particularly in apps with many native modules. They show up in high-frequency communication, such as gesture handling, animation, sensor streams, and frame processors, where the bridge's serialization and queueing were the bottleneck. They show up in layout correctness, through synchronous measurement, which eliminates whole categories of visual glitches. And they show up in responsiveness under load, through concurrent rendering, which allows urgent updates to preempt expensive renders. To get those gains, your own native code must be written for the New Architecture, not merely run under it. A module that goes through the interop layer, or a TurboModule that is designed as if the bridge still existed, collects the costs of the migration and few of the benefits. The next three chapters are about writing modules that collect the benefits. Chapter 3: Designing Native Module Interfaces A native module is an API, and like any API its quality is decided mostly by its interface. The implementation can be rewritten; the interface, once fifty screens depend on it, is much harder to change. Under the New Architecture the interface is a literal file, the spec, from which Codegen generates the native scaffolding on both platforms. This makes interface design more concrete than it used to be, and also more consequential. A poorly designed spec produces poorly shaped native code on two platforms at once. This chapter treats the spec as a design problem. The implementation details for Swift and Kotlin follow in chapters 4 and 5. Anatomy of a spec A TurboModule spec is a TypeScript or Flow file whose name begins with Native, placed in a directory that the project's Codegen configuration points to. It declares an interface that extends TurboModule and exports the module looked up from the registry. Here is a spec for a module that wraps a device's secure hardware-backed key storage, a realistic case for a fintech or health app: // specs/NativeSecureStore.ts import type {TurboModule, CodegenTypes} from 'react-native'; import {TurboModuleRegistry} from 'react-native'; export type StoreOptions = { requireBiometrics: boolean; accessGroup?: string; }; export interface Spec extends TurboModule { readonly getConstants: () => {maxValueBytes: CodegenTypes.Int32}; isHardwareBacked(): boolean; setItem(key: string, value: string, options: StoreOptions): Promise; getItem(key: string, options: StoreOptions): Promise; deleteItem(key: string): Promise; readonly onKeyInvalidated: CodegenTypes.EventEmitter; } export default TurboModuleRegistry.getEnforcing('NativeSecureStore'); The project's package.json then contains a codegenConfig block naming the spec library, setting its type to modules, pointing jsSrcsDir at the directory, and supplying platform details such as the Java package name for Android and, on iOS, a modulesProvider map from the module name to the Objective-C class that implements it. When the Android build runs, or when pod install runs on iOS, Codegen reads every spec and generates a NativeSecureStoreSpec abstract class for Kotlin, a NativeSecureStoreSpec protocol for Objective-C, and a C++ class, NativeSecureStoreSpecJSI, that does the actual conversion between JSI values and native types. Every line in that spec is a decision. The rest of this chapter goes through the decisions. Types are the contract Codegen only accepts types it knows how to convert. Primitive types map straightforwardly: string becomes NSString on iOS and String on Android; boolean becomes BOOL and Boolean; number becomes a double on both platforms unless you narrow it with CodegenTypes.Int32 or CodegenTypes.Float. Object type aliases, such as StoreOptions above, generate typed structures on the native side. Arrays of known types are allowed. Nullable and optional values are expressed with | null and ?. Promises, callbacks, and event emitters have their own dedicated mappings. There is an escape hatch, CodegenTypes.UnsafeObject, which maps to an untyped dictionary on iOS and a ReadableMap on Android. Treat it the way you would treat any in TypeScript. It is occasionally necessary, for example when forwarding an arbitrary JSON payload to a third-party SDK, but every use of it moves a type check from build time to runtime, on two platforms, in code that is harder to debug than JavaScript. Precise types are not pedantry. They determine what the generated C++ glue does. A parameter declared as StoreOptions is converted field by field into a typed native structure, and a missing required field produces a clear error. A parameter declared as UnsafeObject is converted into a generic dictionary, and your native code must then look up keys by string, cast values, and handle the case where a key is missing or has the wrong type. On a team where JavaScript and native code are written by different people, the typed spec is also the documentation. It is the one artifact both sides read. Two rules follow. Type every structure explicitly, including nested ones. And prefer narrow, closed types, such as a string union for a mode or an Int32 for a count, over wide ones, because the narrower the type the more of your validation Codegen does for you. Synchronous or asynchronous The single most important design decision in a spec is which methods are synchronous. Under the old bridge there was no choice. Under the New Architecture, a method that returns a plain value rather than a Promise is synchronous: JavaScript calls it, the JavaScript thread blocks, native code runs on that same thread, and the value comes back directly. Synchronous methods are a genuine improvement for the cases they suit. They eliminate the promise overhead and the extra tick of latency for values that are cheap to compute. They allow a module to be used during render, or in a place where an await is awkward. And they remove an entire class of race conditions in which JavaScript reads stale state because the asynchronous answer has not arrived yet. They are also the easiest way to wreck the JavaScript thread's frame budget, because the cost of the native work is now paid directly by JavaScript. The rule I use is simple and strict. A method may be synchronous only if its worst-case execution time, on the slowest supported device, is well under a millisecond, and it touches no disk, no network, no inter-process communication, no locks that another thread may hold for long, and no main-thread-only API. In the spec above, isHardwareBacked is synchronous because it reads a capability flag that the module computes once at initialization and caches. getItem is asynchronous, even though reading a short string from the keychain is usually fast, because on iOS a keychain read that requires biometrics presents system UI and can take seconds, and on Android a hardware-backed keystore operation can take tens of milliseconds on lower-end devices. The phrase "usually fast" is the trap. Synchronous calls must be fast in the worst case, not the median. The keychain read that takes 2 milliseconds on a developer's phone takes 40 on a device under memory pressure with a cold secure enclave, and if that read sits in a render path, it drops two frames on every screen that uses it. Constants are a special case. Values that never change during a session, such as a maximum payload size, a platform capability, or an SDK version, belong in getConstants. They are computed once, when the module is first loaded, and cached on the JavaScript side, which is cheaper than any method call. Granularity and the shape of traffic Even with JSI, crossing the boundary has a cost. Each call involves looking up the method, converting arguments from JSI values into native types, invoking the native method, and converting the result back. For a single call this is measured in microseconds. For ten thousand calls in a loop it is measured in frames. The design principle that follows is to make interfaces chunky rather than chatty. If JavaScript needs to store twenty preferences, a setItems(entries: Array) method that crosses once is better than twenty setItem calls. If native code produces a stream of values, such as accelerometer readings at 100 Hz, delivering each reading as its own event costs a conversion and an event dispatch per sample; batching them into an array every 100 milliseconds cuts the dispatches by a factor of ten, at the cost of 100 milliseconds of latency that most consumers do not need. The opposite mistake is also common: a single method that returns an enormous payload. A module that returns the user's entire photo library metadata as one array of fifty thousand objects will spend much of its time converting those objects into JavaScript, allocating them on the JavaScript heap, and then forcing the garbage collector to deal with them. A paged interface, such as getAssets(offset, limit), or a cursor-style interface returns only what the current screen needs. The underlying model is that cost is roughly proportional to the number of crossings plus the total volume of data converted. Design the interface so that both are proportional to what the user is actually looking at. Ownership: who holds the state Many native modules wrap a stateful native object: a database connection, a Bluetooth peripheral, a media player, a camera session. The question of where the canonical state lives is a design decision, and getting it wrong produces bugs that are almost impossible to reproduce. The safest default is that native code owns native state and JavaScript holds handles to it. A media player module, for example, returns an opaque identifier when a player is created, and every subsequent call passes that identifier. The native side keeps a table from identifier to player. JavaScript does not mirror the player's state in its own variables; it subscribes to events when the state changes. When the screen that created the player unmounts, it calls an explicit release(id) method, and the native side removes the entry and frees the player. Two failure modes are worth naming. The first is duplicated state, in which JavaScript keeps its own copy of whether the player is playing and the two copies drift, typically when a system interruption such as a phone call pauses playback natively without JavaScript being told. The second is leaked handles, in which JavaScript forgets to release a resource and the native table grows without bound. Explicit release methods, called from effect cleanups, and native-side logging of the table size in debug builds catch most of these problems early. Libraries that use JSI directly sometimes go further and expose native objects as host objects, which JavaScript holds as ordinary values. This can be elegant, but it ties the native object's lifetime to the JavaScript garbage collector, which does not know how much native memory the object holds and may not collect it promptly. Chapter 9 returns to this problem. For most modules, explicit handles and explicit release are more predictable. Errors and events Errors should cross the boundary as data, not as crashes. An asynchronous method should reject its promise with a stable error code and a human-readable message. The codes form part of the API: E_BIOMETRIC_CANCELLED, E_KEY_NOT_FOUND, and E_HARDWARE_UNAVAILABLE let JavaScript respond correctly, while a generic rejection with a localized system message forces JavaScript to parse strings. Define the codes in one place, export them from the JavaScript wrapper, and keep the native implementations on both platforms consistent with them. Synchronous methods are harder, because there is no promise to reject. A native exception thrown from a synchronous method surfaces as a JavaScript exception, but the details of how it is converted differ between platforms and versions, and an uncaught Objective-C exception or a Kotlin exception in the wrong place can crash the process. The safest design is for synchronous methods never to fail: return a nullable value, or a result object with an explicit error field, rather than throwing. Events, declared in recent React Native versions with CodegenTypes.EventEmitter in the spec, give native code a typed way to push values to JavaScript. Codegen generates an emitOnKeyInvalidated method on the native side, and JavaScript subscribes by calling NativeSecureStore.onKeyInvalidated(callback), receiving a subscription whose remove() method must be called on cleanup. The typed emitter replaces the older pattern of a separate NativeEventEmitter keyed by string event names, and its main benefit is the same as every other typed element of the spec: the payload shape is checked at build time. Every subscription is a reference from native code to a JavaScript function, and through its closure, to whatever that function captured. A subscription created in a screen component and never removed keeps that screen's state alive for the rest of the session. The cleanup function in useEffect is not optional. A thin JavaScript wrapper The spec file is not the public API of your module. It is the boundary. Most well-designed modules put a small JavaScript wrapper in front of it that converts between idiomatic JavaScript and the boundary's constraints. The wrapper can turn error codes into typed error classes, add default options, batch calls made in quick succession, cache values that are expensive to fetch, and provide a hook such as useSecureItem(key) that handles subscription and cleanup correctly. The wrapper is also where you put the mock for tests. Jest runs in Node, where no native module exists, so TurboModuleRegistry.getEnforcing would throw. Mocking the wrapper, or the spec module path, with an in-memory implementation lets the rest of the app be tested without a device. Teams that skip the wrapper end up mocking the raw native module in dozens of test files with slightly different behavior in each. A worked redesign The principles are easier to see applied to a real shape of module. Consider an in-house analytics module of a kind found in many large apps, written years ago for the bridge. Its JavaScript API has four methods: track(eventName, properties), called on almost every interaction; setUserProperty(key, value), called a dozen times at sign-in; getSessionId(), which returns a promise; and flush(), called when the app goes to the background. The native side forwards each call to a vendor SDK. Profiling shows three problems. On busy screens, track is called dozens of times per second during scrolling, because impression events fire as cards become visible, and each call converts a properties object of twenty or thirty fields. getSessionId is awaited at the top of several screens, each of which renders a loading state for a frame while it resolves. And setUserProperty is called twelve times in sequence at sign-in, each crossing the boundary separately and each triggering a disk write in the vendor SDK. The redesigned spec keeps the same capabilities with a different shape. track becomes trackBatch(events: Array), where AnalyticsEvent is a typed object with a name, a timestamp, and a properties field. The JavaScript wrapper keeps the old track signature for call sites, appends events to an in-memory queue, and flushes the queue to native every 500 milliseconds or when it reaches fifty events, whichever comes first. Impression events during a scroll now cross the boundary twice a second instead of dozens of times, and the conversion cost is paid in one place, off the interaction path. getSessionId becomes a synchronous method, because the native side generates the session identifier once at startup and holds it in memory, so returning it costs microseconds; the loading states disappear. setUserProperty becomes setUserProperties(properties: UserProperties), typed with the known fields and one optional free-form map for extensions, so sign-in makes one call and one disk write. flush stays asynchronous and returns a promise, because it may perform network I/O. The properties field of each event deserves a note. Analytics properties are genuinely open-ended, so this is one of the rare places where UnsafeObject is defensible. The redesign confines it to that single field, and the wrapper validates properties in development builds, warning when a property is a nested object or a function that the vendor SDK will silently drop. Nothing in this redesign is clever. It applies four rules from this chapter: batch high-frequency calls, make cheap reads synchronous, type everything that can be typed, and leave genuinely slow operations asynchronous. The result is a module whose cost scales with what the user does rather than with how often the code happens to call it. Versioning the boundary In a large app, native code and JavaScript can drift apart. Over-the-air update services, which push new JavaScript bundles to installed apps without a store release, make this concrete: a new bundle may run against an old binary whose native modules lack a method the new JavaScript expects. Calling a method that does not exist on a TurboModule fails at runtime. The defense is to treat the spec as a versioned interface. Additive changes, such as new optional parameters or new methods, are safe only if JavaScript checks for them before calling. A constant exposed through getConstants, such as an integer interface version, gives JavaScript a cheap way to know which capabilities the binary has. Breaking changes require a new binary and must be gated so that the JavaScript that depends on them never ships to binaries that cannot support them. Teams that use over-the-air updates seriously maintain a mapping between JavaScript releases and the minimum native build each requires, and enforce it in their release tooling. The spec is small, but it is the most leveraged file in a native module. Get it right and the platform implementations are straightforward. The next two chapters write them. Chapter 4: Bridging Swift on iOS Most iOS code written today is Swift. Most of React Native's core is C++, and its iOS integration layer is Objective-C and Objective-C++. That mismatch shapes how you write native modules on iOS, and pretending it does not exist produces modules that are harder to build, harder to debug, and slower to compile than they need to be. This chapter shows the pattern that works, then spends most of its length on the parts that cause real trouble in production: threads, memory, and the interaction between Swift concurrency and React Native's own scheduling. Why Swift needs an adapter Codegen produces two things for an iOS TurboModule: an Objective-C protocol, such as NativeSecureStoreSpec, listing the methods the module must implement, and a C++ class, NativeSecureStoreSpecJSI, that performs the JSI conversions. The module class that conforms to the protocol must also return an instance of that C++ class from a method called getTurboModule:. That method's signature involves C++ types, std::shared_ptr and React Native's ObjCTurboModule::InitParams, which Swift cannot express. Apple has been building direct interoperability between Swift and C++ for several years, but React Native's own documentation says frankly that it is not good enough for React Native's core headers, and recommends a thin Objective-C++ adapter. The pattern has three files. A Swift class holds the actual implementation, marked with @objc so Objective-C can call it. An Objective-C++ file, with the .mm extension, declares the class that conforms to the generated protocol, owns an instance of the Swift class, implements getTurboModule:, and forwards each method call to Swift. And, inside an app target, a bridging header exposes any Objective-C headers the Swift code needs; inside a library, the generated -Swift.h header does the reverse. The Swift side looks like ordinary Swift with an Objective-C surface: import Foundation import LocalAuthentication @objcMembers public final class SecureStoreImpl: NSObject { public private(set) var hardwareBacked: Bool = false public override init() { super.init() hardwareBacked = SecureEnclave.isAvailable } public func getItem(_ key: String, requireBiometrics: Bool, completion: @escaping (String?, NSError?) -> Void) { Task.detached(priority: .userInitiated) { do { let value = try await Keychain.read(key, biometrics: requireBiometrics) completion(value, nil) } catch { completion(nil, error as NSError) } } } } The Objective-C++ adapter is mechanical: // RCTSecureStore.mm #import "RCTSecureStore.h" #import "MyApp-Swift.h" @implementation RCTSecureStore { SecureStoreImpl *_impl; } - (instancetype)init { if (self = [super init]) { _impl = [SecureStoreImpl new]; } return self; } + (NSString *)moduleName { return @"NativeSecureStore"; } - (std::shared_ptr)getTurboModule: (const facebook::react::ObjCTurboModule::InitParams &)params { return std::make_shared(params); } - (NSNumber *)isHardwareBacked { return @(_impl.hardwareBacked); } - (void)getItem:(NSString *)key options:(JS::NativeSecureStore::StoreOptions &)options resolve:(RCTPromiseResolveBlock)resolve reject:(RCTPromiseRejectBlock)reject { [_impl getItem:key requireBiometrics:options.requireBiometrics() completion:^(NSString value, NSError error) { if (error) { reject(@"E_KEYCHAIN", error.localizedDescription, error); } else { resolve(value); } }]; } @end A few details are worth noticing. Typed spec objects such as StoreOptions arrive in Objective-C++ as generated C++ structs, accessed through methods like options.requireBiometrics(), which is one more reason the adapter is written in Objective-C++ rather than Swift. Synchronous methods returning a boolean are bridged through NSNumber. And the adapter contains no logic. Every decision is made in Swift, which keeps the Objective-C++ surface small enough that a Swift-only iOS engineer can maintain the module without learning C++. Packaging and build settings When the module lives inside the app, the Swift and Objective-C++ files simply join the app target. When it is a library, it needs a podspec, and modern React Native provides a helper, install_modules_dependencies, that a library's podspec calls to pull in the correct React Native dependencies and compiler flags. Without it, libraries often fail to compile with missing header errors, or compile against the wrong configuration. React Native 0.84 made precompiled iOS binaries the default, so pod install now downloads React Native's core as prebuilt .xcframework binaries instead of compiling it from source, and 0.87 added experimental Swift Package Manager support as an alternative to CocoaPods. Both changes speed up builds considerably, and both make it more important that your modules declare their dependencies correctly, because there is no longer a large source build to paper over a missing header search path. If a module compiles in a teammate's environment but not in continuous integration, mismatched dependency declarations are the first thing to check. Which thread am I on? Threading is where iOS modules most often go wrong, and the rules under the New Architecture are worth stating precisely. A synchronous method runs on the JavaScript thread. Always. Any work done inside it blocks JavaScript for its duration, and any call from it to a main-thread-only API, such as UIApplication.shared, UIScreen, or most of UIKit, is unsafe. Accessing UIApplication.shared.applicationState from a synchronous TurboModule method is a classic example: it appears to work in testing and then triggers Main Thread Checker warnings or worse under certain timing. An asynchronous method is invoked off the JavaScript thread, on a queue the infrastructure manages for the module. You should not rely on what that queue is. If the method must touch UIKit, dispatch to the main queue explicitly. If it does disk or network work, it is already off the JavaScript thread, but it may be on a serial queue shared by every method of the module, so a long-running call blocks every other call to the same module until it finishes. A module that performs a 3-second network request and a 5-millisecond cache read through the same serial queue will make the cache read wait 3 seconds. Dispatching long-running work to its own queue or task, as the Swift example above does with Task.detached, avoids the convoy. Promise blocks, RCTPromiseResolveBlock and RCTPromiseRejectBlock, are safe to call from any thread, and must be called exactly once. Calling neither leaks the JavaScript promise and everything awaiting it. Calling both, or calling one twice, is a bug that some versions of React Native log and others crash on. In Swift, the most reliable way to guarantee exactly-once semantics is to structure the implementation so that every code path ends in a single completion call, and to put a debug assertion behind a flag that tracks whether it has fired. Swift concurrency and React Native Swift's structured concurrency, with async functions, Task, and actors, fits well with React Native's asynchronous methods, but there are three points of friction. The first is that Task { } created inside a method inherits the actor context of its caller. If the caller is on the main actor, the task's synchronous portions run on the main thread. Because React Native calls your adapter from a background queue, a plain Task usually starts off the main actor, but code that is later refactored to be called from a @MainActor context silently changes behavior. Using Task.detached with an explicit priority, or calling into a dedicated actor, makes the threading explicit. The second is UIKit. Any method that presents UI, such as a biometric prompt, a document picker, or a share sheet, must run on the main actor. Marking the Swift function @MainActor and awaiting it from a detached task is the cleanest pattern, because the compiler then enforces the rule. The third is cancellation. A JavaScript promise cannot be cancelled, but a screen can unmount while a native operation is in progress. If the operation is expensive, such as a large upload or a long-running image process, the module should expose an explicit cancel method that takes a request identifier, keep a dictionary of in-flight Task handles keyed by identifier, and call cancel() on the right one. Swift's cooperative cancellation then propagates through any await points that check for it. Memory on iOS iOS manages native memory with automatic reference counting (ARC). Every strong reference increments a count; when the count reaches zero, the object is freed immediately. There is no cycle collector. Two objects that hold strong references to each other will never be freed. Native modules create cycles in a few recurring ways. Closures are the most common. A Swift closure captures the variables it references strongly by default, including self. A module that stores a closure in a property, for example a callback registered with a third-party SDK, and refers to self inside it creates a cycle between the module and the closure. Capturing [weak self] breaks it. Observers registered with NotificationCenter using the block-based API have the same problem, and also continue to fire until they are removed, which means a module that registers on initialization and never removes the observer receives notifications for the life of the process. Delegates are the second source. Most UIKit and Apple framework delegate properties are declared weak, but third-party SDKs are not always so careful. If an SDK holds its delegate strongly and your module holds the SDK strongly, the pair leaks. The third source is specific to React Native: the module's own lifetime. TurboModules are created lazily and, in normal operation, live until the React Native host is torn down. In development, a reload tears down the host and creates a new one. In production, apps that host React Native inside a larger native app may create and destroy React Native hosts as users navigate. A module that registers global observers, starts timers, or holds open hardware sessions must release them when its host is invalidated. Conforming to the RCTInvalidating protocol and implementing invalidate gives the module a hook for that. Modules that skip it work fine in a pure React Native app and leak a full set of resources every time a brownfield host is recreated. Chapter 9 covers how to find these leaks with Instruments. The design-time defense is simpler: every registration has an unregistration, every strong reference to a long-lived object is questioned, and every module that acquires a system resource implements invalidate. Delivering events from Swift Events need a little more plumbing than methods, because the generated emit method, such as emitOnKeyInvalidated:, belongs to the Objective-C++ class that conforms to the spec, not to the Swift implementation. The clean pattern is for the Swift class to expose a callback property, and for the adapter to set it during initialization to a block that calls the generated emitter. The Swift code then raises events by invoking the callback, without knowing anything about React Native. In the secure storage example, the keychain can invalidate a biometric-protected key when the user enrolls a new fingerprint or face. The Swift implementation detects this on the next access and calls onKeyInvalidated?(key). The adapter's block, set up in init with a weak reference to the adapter to avoid a cycle, forwards the key to emitOnKeyInvalidated:. The JavaScript wrapper subscribes in a hook and prompts the user to re-authenticate. Two cautions apply. Events can be emitted from any thread, but a burst of them from a background queue arrives at the JavaScript thread as a burst of tasks, so throttle or coalesce on the native side when the source is noisy. And events emitted before JavaScript has subscribed are lost; a module whose events represent state, rather than moments, should also expose a method that returns the current state, so a newly mounted screen can read it rather than wait for the next event. Debugging iOS modules Most of the defects described in this chapter are invisible in normal testing and obvious under the right diagnostic tool. Xcode's scheme settings expose several that every native module author should turn on during development. The Main Thread Checker, enabled by default in debug builds, flags calls to UIKit and certain other frameworks made from a background thread. In a React Native app it catches the synchronous-method-touches-UIKit mistake immediately, as long as the warnings are not drowned out; teams that let Main Thread Checker warnings accumulate lose the tool's value. The Thread Sanitizer detects data races, such as a dictionary of in-flight requests mutated from two queues without synchronization, which is a common bug in modules that accept concurrent calls. It slows execution considerably, so it is a tool for targeted test runs rather than everyday development. The Address Sanitizer detects memory errors in C and C++ code, which matters if the module includes any C++ or links a C library. Debugging across the boundary is easier than it used to be. You can attach Xcode to the running app and set breakpoints in Swift while React Native DevTools is attached to the JavaScript runtime with its own breakpoints. Pausing in one will stall the other, which is expected; the useful technique is to set a breakpoint in the Swift method, trigger it from JavaScript, and inspect the converted arguments to confirm that the spec's types arrived as expected. Many subtle bugs turn out to be a number that arrived as a double when the native code expected an integer, or an optional field that arrived as nil when the JavaScript caller believed it had set it. Data conversion costs The JSI conversion layer is efficient, but iOS adds a second conversion in many modules. Codegen converts JSI values into Objective-C objects, such as NSString, NSArray, and NSDictionary, which Swift then bridges to its own String, Array, and Dictionary. For small values this double conversion costs nothing worth measuring. For large collections it is visible: an array of thousands of dictionaries is converted from JSI to Foundation objects and then again to Swift values, allocating at each step. When a module genuinely needs to move large data, there are three options. Reduce the data, as chapter 3 argued, by paging or summarizing on the native side. Keep the data in Foundation types in the hot path and convert lazily. Or, for the rare case of very high-throughput data such as audio buffers or camera frames, write that part of the module as a C++ TurboModule, which operates on JSI values directly and avoids Objective-C entirely; some popular libraries for camera frame processing and storage take this approach for exactly this reason. The Expo Modules alternative There is another way to write iOS native modules in Swift, and for many teams it is now the better default: the Expo Modules API. It is part of the Expo SDK but usable in any React Native app that installs the expo package's module infrastructure, and it lets you define a module entirely in Swift using a declarative syntax: import ExpoModulesCore public class SecureStoreModule: Module { public func definition() -> ModuleDefinition { Name("SecureStore") Constants(["maxValueBytes": 2048]) Function("isHardwareBacked") { SecureEnclave.isAvailable } AsyncFunction("getItem") { (key: String, biometrics: Bool) -> String? in try await Keychain.read(key, biometrics: biometrics) } Events("onKeyInvalidated") } } There is no Objective-C++ adapter and no separate spec file; the module definition is the interface, and arguments are converted to Swift types, including records and enums you define, by the Expo runtime. Function defines a synchronous method and AsyncFunction an asynchronous one, with async Swift functions supported directly. The Expo modules infrastructure is built on JSI and the New Architecture, so these modules are not a legacy compatibility path. Expo SDK 56, released in May 2026, added inline modules that let native code live directly in an app's project structure, along with tooling to generate TypeScript types from native module definitions. The trade-off is that the type contract runs in the opposite direction from Codegen. With Codegen, TypeScript is the source of truth and native code is generated to match it; with Expo Modules, native code is the source of truth and TypeScript types are written or generated to match. Teams whose native engineers outnumber their JavaScript engineers often prefer the Expo direction. Chapter 5 compares the approaches more fully once the Android side is in view. Whichever API you choose, the substance of this chapter applies unchanged. The adapter or the definition is the easy part. Threads, lifetimes, and the cost of what crosses the boundary are where native modules succeed or fail. Chapter 5: Bridging Kotlin on Android Android modules are simpler to wire up than iOS modules, because Codegen generates Java-compatible abstract classes that Kotlin can extend directly, with no adapter layer. They are harder to get right in production, because Android's lifecycle model is more complicated than iOS's, its device population is far more varied, and its most common memory leak, holding a reference to an Activity after it is destroyed, is easy to create from a native module and hard to see until users report crashes on low-memory devices. This chapter covers implementation briefly and then spends its length on threading, lifecycle, and memory, before comparing the main ways of authoring native modules on both platforms. Implementing the generated spec For the secure storage spec from chapter 3, Codegen generates an abstract class, NativeSecureStoreSpec, in the Java package named in codegenConfig. It extends React Native's base module class and implements the TurboModule interface, and it declares an abstract method for every method in the spec, with parameter types mapped from TypeScript. A Kotlin implementation extends it: class SecureStoreModule(context: ReactApplicationContext) : NativeSecureStoreSpec(context) { private val scope = CoroutineScope(SupervisorJob() + Dispatchers.IO) private val hardwareBacked: Boolean = KeystoreProbe.isStrongBoxAvailable(context) override fun getName() = NAME override fun isHardwareBacked(): Boolean = hardwareBacked override fun getItem(key: String, options: ReadableMap, promise: Promise) { val biometrics = options.getBoolean("requireBiometrics") scope.launch { try { promise.resolve(SecureStorage.read(reactApplicationContext, key, biometrics)) } catch (e: KeyNotFoundException) { promise.reject("E_KEY_NOT_FOUND", e.message, e) } catch (e: Exception) { promise.reject("E_KEYSTORE", e.message, e) } } } override fun invalidate() { scope.cancel() super.invalidate() } companion object { const val NAME = "NativeSecureStore" } } The module is registered through a package class. Modern React Native expects modules to be provided by a subclass of BaseReactPackage, which implements getModule(name, context) to return the module when its name is requested, and getReactModuleInfoProvider() to describe the module to the runtime, including the flag that marks it as a TurboModule. The package is then added to the list returned by the app's MainApplication. Because modules are created lazily under the New Architecture, getModule is not called until JavaScript first touches the module, which is a meaningful startup saving in apps with many modules but also means that any initialization side effects in a module's constructor now happen at an unpredictable time. Constructors should be cheap and side-effect free, with expensive initialization deferred to first use or moved to a background coroutine. React Native 0.87 raised the minimum Kotlin version to 2.0 and added support for version 9 of the Android Gradle Plugin, with recommended opt-outs for some of AGP 9's new defaults. Libraries that pin old Kotlin or Gradle versions are a frequent source of build failures after upgrades, and auditing them is part of any upgrade plan. Threads on Android Synchronous methods run on the JavaScript thread, exactly as on iOS. The same rule applies: worst-case sub-millisecond, no I/O, no main-thread-only APIs. On Android, main-thread-only APIs include anything that touches views, most of the window and display APIs, and, by convention, many third-party SDKs that are not documented as thread-safe. For asynchronous methods, do not assume anything about the invoking thread beyond the fact that it is not yours to block. The safest pattern is the one in the example: the method's body does nothing but validate arguments and hand the work to a coroutine scope owned by the module, using a dispatcher appropriate to the work. Dispatchers.IO is sized for blocking I/O and is right for disk, keystore, and network operations. Dispatchers.Default is sized to the number of CPU cores and is right for computation such as image processing or parsing. Work that must run on the main thread goes through Dispatchers.Main or React Native's UiThreadUtil.runOnUiThread. The scope uses a SupervisorJob, so that one failed operation does not cancel every other operation running in the module, and is cancelled in invalidate(), which React Native calls when the host that owns the module is destroyed. Without that cancellation, coroutines launched by the module continue running after the React Native instance is gone and may resolve promises belonging to a runtime that no longer exists. In a pure React Native app this mainly happens during development reloads; in a brownfield app, where React Native screens are embedded in a larger native app and hosts are created and destroyed, it happens in production. Promise semantics match iOS. Resolve or reject exactly once. The most common Android bug here is an exception thrown after the promise has already been resolved, typically in a finally block or a callback from an SDK that fires twice, which leads to a second reject that React Native logs or ignores depending on version. Treat it as a bug either way. Lifecycle and the Activity problem On Android, an Activity is the component that owns a window and its views. Activities are destroyed and recreated frequently: on configuration changes such as rotation, when the system reclaims memory from a backgrounded app, and when the user navigates. React Native apps usually run in a single activity, but that activity is still destroyed and recreated on configuration changes unless the app opts out, and some apps open additional activities for flows like authentication or payments. Native modules often need an activity: to show a system dialog, to start an intent for a result, to request a permission. The ReactApplicationContext passed to the module provides currentActivity, and the trap is storing it. A module that saves the activity in a property during one call and uses it later holds a reference that keeps the activity alive after the system destroys it. A destroyed activity holds its entire view hierarchy, every bitmap those views reference, and every object those views' listeners capture. On a device with a small heap, a single leaked activity can be tens of megabytes, and repeated rotations can leak one per rotation. The rules are straightforward. Read currentActivity at the moment you need it and do not store it. If an asynchronous operation must call back into an activity later, hold it through a WeakReference and check it is still present and not finishing before use. To react to the activity's lifecycle, register a LifecycleEventListener with the React context, which delivers host resume, pause, and destroy callbacks, and unregister it in invalidate(). To receive activity results, register an ActivityEventListener and unregister it the same way. The same reasoning applies to views. A module that stores a reference to a native view, for example to read its bounds later, keeps that view and its whole parent chain alive after React unmounts it. Native components under Fabric, discussed in chapter 7, give you correct hooks for view lifetime; modules should not hold views at all. Memory on Android Android runs Kotlin and Java code on the Android Runtime, which has its own garbage collector. Unlike ARC on iOS, it collects reference cycles, so two objects that refer to each other are freed once nothing else refers to them. Leaks on Android are therefore not cycles; they are unexpected paths from a garbage collection root, such as a static field, a running thread, or a registered system listener, to an object that should have died. Native modules create those paths in a handful of ways. A companion object or top-level property that holds a context, a view, or a callback is a static root. A listener registered with a system service, such as a sensor manager or connectivity manager, and never unregistered is held by the system service. A coroutine or thread that is still running holds everything its lambda captured. A callback passed to a third-party SDK that keeps it in a static registry is held for the life of the process. The heap that matters for these leaks is the Java heap, which has a per-app limit set by the device manufacturer; on lower-end devices it is much smaller than on flagships. When the Java heap is exhausted, the app throws OutOfMemoryError and crashes. Native allocations, including those made by Hermes for the JavaScript heap, by image libraries for decoded bitmaps on modern Android versions, and by C++ code in your modules, do not count against the Java heap limit, but they do count toward the total memory the system uses to decide which processes to kill under pressure. Chapter 9 shows how to see both. LeakCanary, Square's open-source leak detection library, is the single most effective tool for Android native module leaks. Installed in debug builds, it watches objects that should be garbage collected, such as destroyed activities, detached fragments, and cleared views, and when they are not, it dumps the heap and shows the reference chain that is keeping them alive. Running it during ordinary QA of the native screens in a React Native app routinely finds leaks that no profiling session would. Catching mistakes early on Android Android has its own set of development-time tools that catch native module mistakes before they reach users, and most teams under-use them. StrictMode is a developer tool built into Android that detects accidental disk and network access on the main thread, as well as leaked closeable resources such as unclosed cursors and streams. Enabled in debug builds from the Application class, it can log violations, flash the screen, or crash the app, depending on the policy you choose. In a React Native app, turning it on with a logging policy and then looking through the output usually finds a handful of SDKs and in-house modules reading preferences files or databases on the main thread during startup, each costing a few milliseconds that add up. Fixing them is one of the cheapest startup improvements available. The Android Studio debugger can attach to a React Native app's process while React Native DevTools is attached to JavaScript, just as on iOS. Breakpoints in Kotlin code reveal the thread each call arrives on, which is the quickest way to confirm the threading assumptions described above rather than trusting documentation that may describe a different version. Instrumented tests, which run on a device or emulator, can exercise a module's Kotlin implementation directly, without React Native, if the implementation is separated from the React Native glue in the way the iOS chapter recommended for Swift. A SecureStorage class that knows nothing about promises or ReadableMap can be tested with ordinary Android testing tools, and the module class that adapts it to React Native becomes thin enough to need little testing of its own. That separation also makes it possible to reuse the same Kotlin code in a native Android screen, which matters in brownfield apps. Sharing native logic with C++ Some module logic is identical on both platforms: a binary protocol parser for a Bluetooth device, a rules engine, a compression routine, an offline search index. Writing it twice, once in Swift and once in Kotlin, doubles the code and guarantees that the two versions will eventually disagree. C++ is the common language both platforms can call, and React Native's own core is built that way. On Android, Kotlin reaches C++ through the Java Native Interface (JNI), and React Native uses a helper library, fbjni, that makes JNI considerably less error-prone. A C++ Turbo Module, the second option in the comparison below, skips the Kotlin layer entirely for the shared logic: the module is implemented in C++ against the generated spec, and both platforms load the same compiled code. Platform-specific needs, such as reading a file from the Android asset system or the iOS bundle, are handled by small platform layers that the C++ code calls. The cost is real. C++ code must be built with the Android NDK as well as Xcode, crashes in C++ produce native crash reports that require symbol files to read, and memory errors that would be impossible in Kotlin become possible. Teams that choose C++ for shared module logic should invest in sanitizer builds and native crash symbolication from the start. Native code and 16 KB pages Many React Native apps include C++ code, both React Native's own libraries and those of third-party modules that use JSI directly. Android is moving to support devices with a 16 KB memory page size, up from 4 KB, which affects how native libraries must be aligned. Google's published guidance requires that apps targeting Android 15 or higher support 16 KB pages on 64-bit devices, and states that from February 1, 2027, updates that do not will be rejected from Google Play. React Native added 16 KB support in version 0.77; the remaining risk lies in third-party native libraries and prebuilt SDKs, which must be rebuilt with appropriate alignment by their maintainers. Android Studio's APK analyzer flags unaligned libraries, and checking it should be part of any release process. Choosing an authoring approach By late 2026 there are four serious ways to write a native module for React Native, and the choice is worth making deliberately at the start of a project, because migrating between them later costs nearly as much as writing the module again. Their differences are summarized in Table 2. Table 2. Four ways to author native modules. Approach Source of truth Native languages Best suited to Turbo Native Module TypeScript spec via Codegen Kotlin; Swift with Obj-C++ adapter Core-aligned libraries, no extra dependency C++ Turbo Module TypeScript spec via Codegen C++, shared across platforms Shared logic, high-throughput data Expo Modules API Swift and Kotlin definitions Swift, Kotlin Teams led by native engineers, Expo apps Nitro Modules TypeScript spec via Nitrogen Swift, Kotlin, C++ Libraries needing many fast native objects The Turbo Native Module path, which this chapter and the last have used, is React Native's own. It adds no dependency, tracks the framework's evolution exactly, and is what most core-adjacent libraries use. Its costs are the Objective-C++ adapter on iOS and the somewhat verbose registration on Android. C++ Turbo Modules use the same spec and Codegen but are implemented once in C++ and compiled for both platforms. They are the right choice when the logic is genuinely shared and platform-independent, such as a parser, a compression routine, a cryptographic primitive, or a data structure, or when the data volume is large enough that avoiding the Objective-C and Java object layers matters. Their cost is that C++ is a harder language to staff and to debug, and that anything platform-specific still needs a native layer. The Expo Modules API, introduced in chapter 4, lets you write modules declaratively in Swift and Kotlin with no adapter layer, and has strong support for Swift and Kotlin idioms such as records, enums, and async functions. It requires the Expo modules infrastructure, which is a small dependency in a bare React Native app and already present in an Expo app. On Android the definition looks almost identical to the Swift version, with Name, Function, AsyncFunction, and Events declared inside a definition() block. Nitro Modules, from the consultancy Margelo, are a community framework that generates native interfaces from TypeScript with its own code generator, Nitrogen, and builds modules out of what it calls hybrid objects: native objects that JavaScript can hold and call directly through statically compiled JSI bindings. It is aimed at libraries that create many native objects or need very low per-call overhead. It is a third-party dependency with its own release cadence, which is the main consideration for teams that value staying close to the core framework. My recommendation for most product teams is simple. For modules that wrap a platform SDK and will be maintained by native engineers, use the Expo Modules API. For modules that belong in a public library intended for the widest possible audience, use Turbo Native Modules. For shared, compute-heavy logic, use a C++ Turbo Module. Reach for a third-party framework when a measured requirement, not a benchmark in someone's blog post, demands it. Whichever you choose, the decisions from chapter 3 dominate: what crosses the boundary, how often, and on which thread. The authoring API only changes how much code it takes to express them. Chapter 6: Keeping the JavaScript Thread Free The JavaScript thread is where most React Native apps spend most of their performance budget, and where most of the recoverable time is. It runs your components, your state management, your effects, your event handlers, your data transformations, and the top-level code of every module you import. It does all of this one task at a time. When it is busy for 200 milliseconds, every tap, every state-driven animation, and every navigation transition that depends on JavaScript waits 200 milliseconds. The goal of this chapter is not to make every piece of JavaScript fast. It is to make sure the thread is available when the user needs it. That distinction matters, because the most effective techniques are often about moving or deferring work rather than optimizing it. Rendering is the main workload In a typical product app, the largest consumer of JavaScript thread time during interaction is React rendering: calling component functions, comparing their output, and producing shadow tree updates. The cost of a render is roughly the number of components that re-render multiplied by the cost of each. Both factors are under your control. Components re-render when their state changes, when their parent re-renders, or when a context they consume changes. The second and third causes are where large apps lose time. A state update high in the tree, such as a search query stored in a screen-level component, re-renders every descendant that is not explicitly prevented from re-rendering. A context provider whose value is a new object on every render notifies every consumer, even those that use a field that did not change. In a screen with a header, a filter bar, and a list of a hundred cards, a keystroke in the search box can re-render several hundred components when only the list's data actually changed. The first remedy is structural: keep state as close as possible to the components that use it. A search box that owns its own text and publishes a debounced query to the list re-renders itself on each keystroke, not the screen. A global store accessed through selectors, as in Redux's useSelector or Zustand's selector hooks, re-renders only the components whose selected slice changed, provided the selector returns a stable value. Contexts are best reserved for values that change rarely, such as theme and authentication, or split into several narrow contexts so that a change in one does not fan out to consumers of the others. The second remedy is memoization: React.memo to skip re-rendering a component when its props are unchanged, and useMemo and useCallback to keep props referentially stable. Manual memoization works, but it is laborious and fragile in a large codebase; one inline arrow function passed as a prop defeats a memo boundary, and nobody notices until a profiler shows the list re-rendering. The React Compiler, which reached version 1.0 in October 2025, automates this. It is a build-time tool that analyzes components and hooks and inserts memoization where it is safe, following the rules of React. In a codebase that already follows those rules, enabling it removes most of the need for hand-written useMemo, useCallback, and memo, and usually reduces re-renders in places nobody had thought to optimize. In a codebase that violates the rules, for example by mutating props or reading refs during render, the compiler skips the offending components, and its diagnostics are a useful audit of where those violations are. The compiler does not change the structure of your state. A screen that puts rapidly changing state at the root still re-renders the root on every change; the compiler just makes the descendants cheaper to skip. Structure first, memoization second. Lists Long lists are the most common place where React Native performance problems become visible, because they combine rendering cost, layout cost, image decoding, and memory in one scrolling view. The built-in FlatList is a virtualized list: it renders only the items within a window around the visible area and unmounts those far outside it. Its performance depends heavily on configuration. Providing getItemLayout when items have a known fixed height lets the list compute positions without measuring, which makes scrolling to an index instant and avoids layout work during fast scrolls. A stable keyExtractor lets React match items across updates instead of re-creating them. Item components should be memoized, and the renderItem function should not create new closures for each item's handlers. The window size and batch parameters, such as windowSize, maxToRenderPerBatch, and initialNumToRender, trade memory and blank areas during fast scrolling against JavaScript work; the defaults are reasonable, and changing them should be driven by measurement. FlatList unmounts and remounts items as they leave and enter the window, which means every newly visible item pays the full cost of rendering a component tree and creating native views. Shopify's FlashList takes a different approach: it recycles item views, keeping a pool of mounted cells and re-rendering them with new data as they scroll into view, much as native UITableView and RecyclerView do. Re-rendering an existing component tree with new props is substantially cheaper than mounting a new one. FlashList version 2 was a ground-up rewrite for the New Architecture; it supports only the New Architecture and removed the item size estimates that version 1 required, because Fabric's synchronous layout lets it measure items directly. For long, heterogeneous feeds, it is now the usual choice. Recycling has one consequence that catches teams out. Because a cell's component instance is reused for a different item, any local state inside an item component, such as an expanded flag or a loaded image, persists into the next item unless it is reset or keyed. Items in recycled lists should either be stateless or derive their state from the item's data. Images inside lists deserve their own attention. Displaying a 4000-pixel-wide photo in a 120-point thumbnail decodes the full image into memory, costing tens of megabytes for a single bitmap, and the decode itself takes time. Requesting images at the size they will be displayed, from a server or CDN that can resize them, is the most effective list optimization many apps never make. Image libraries with memory and disk caching, prefetching, and downsampling, such as expo-image, handle much of this when configured correctly. Animation off the JavaScript thread An animation driven from JavaScript requires the JavaScript thread to compute a new value every frame and pass it to the renderer. If the thread is busy, the animation stutters. The remedy is to run animations somewhere else. React Native's Animated API supports a native driver. With useNativeDriver: true, the animation's configuration is sent to native code once, and the native side computes and applies each frame without involving JavaScript. Historically the native driver supported only non-layout properties such as opacity and transform, which meant that animating width, height, or position required JavaScript. React Native 0.85 introduced a new animation backend, built with Software Mansion, which moves core animation update logic into React Native itself and allows layout properties to be animated with the native driver; it was experimental and opt-in at release. Reanimated, from Software Mansion, takes the idea further with worklets: small JavaScript functions that are copied to a separate JavaScript runtime running on the UI thread and executed there each frame. A gesture handler written as a worklet can respond to a finger's movement in the same frame, regardless of what the main JavaScript thread is doing. Reanimated's current major version requires the New Architecture, and its worklet engine has been split into a separate package, react-native-worklets, which other libraries can also use to run JavaScript off the main JavaScript thread. The discipline that makes these tools effective is to keep animation-critical state out of React. A scroll position mirrored into React state on every scroll event re-renders the component on every frame. A scroll position held in a Reanimated shared value updates the UI thread directly and never touches React. Heavy work: defer, split, or move Some work is simply large: parsing a large API response, transforming thousands of records for display, computing a search index, diffing two datasets. When that work runs during an interaction, the thread is unavailable. There are three strategies. Defer the work until the user is not interacting. React's transitions are the primary tool here. Wrapping a state update in startTransition marks the resulting render as non-urgent, so that React can interrupt it to process a keystroke or tap and resume it afterward. useDeferredValue does the same for a value: a list filtered by a search query can render against the deferred query, so the text input updates immediately while the expensive filtered render lags behind and is abandoned if the query changes again. These features depend on the New Architecture's concurrent rendering support and simply did not work under the old renderer. For work that does not involve rendering, requestIdleCallback, which replaced InteractionManager in React Native 0.87, schedules a callback for when the thread is idle. Split the work into chunks. A loop over ten thousand records can be split into batches of a few hundred, each scheduled as a separate task with setTimeout, so that the event loop can process input and render between batches. As chapter 1 explained, await alone does not achieve this, because promise continuations run as microtasks before any render. Move the work off the JavaScript thread. Some work belongs in native code: a native module that parses a large file and returns only the summary the screen needs moves both the parse and the allocation of thousands of intermediate objects out of the JavaScript heap. Other work can run in a separate JavaScript runtime using worklet-based libraries, keeping the code in JavaScript but off the main JavaScript thread. And some work belongs on the server: an API that returns forty fields when the client renders four is an API problem, and fixing it removes work from every client at once. The data layer is part of the render path A large share of JavaScript thread time in data-heavy apps goes not into React but into what happens before React sees the data: parsing responses, normalizing them into a store, deriving view models, and writing caches. This work is easy to overlook because it does not show up in the React Profiler, but it appears clearly in the Performance panel's flame chart as long tasks just after network responses arrive. Three practices keep it under control. First, shape responses for the screen. An endpoint that returns a list of products with full details, reviews, and related items, when the list screen displays a name, a price, and a thumbnail, forces the client to parse and allocate everything. GraphQL fragments or purpose-built list endpoints that return only what is rendered reduce both parse time and the number of objects the garbage collector must later reclaim. Second, avoid repeated derivation. A selector that filters and sorts a thousand-item collection on every render, or a component that maps raw API objects into display objects inside its render function, redoes that work each time anything nearby changes. Derive once when the data arrives, store the result, and memoize selectors so they recompute only when their inputs change. Libraries for server state, such as TanStack Query, cache responses and deduplicate requests made by several components for the same resource, which prevents the common situation in which three components on one screen each fetch and parse the same payload. Third, schedule non-urgent data work. Prefetching the next page of a feed, warming a cache for a likely next screen, or writing a large response to persistent storage are all valuable, and none of them needs to happen during a scroll or a transition. Running them from requestIdleCallback, or after a navigation transition completes, keeps them out of the way. Startup Startup is a JavaScript thread problem more often than teams expect. After the native host initializes and Hermes loads the bytecode, the bundle's top-level code executes, and every module imported by the entry point, transitively, is evaluated. In a large app this can mean thousands of modules, many of which belong to screens the user will not visit in this session. Inline requires are the main remedy. With Metro's inlineRequires transform option enabled, each import is rewritten so that the module is evaluated when one of its exports is first used, rather than when the importing module loads. This defers evaluation of everything not needed for the first screen. It changes the order in which module side effects run, so code that depends on an import executing for its side effect, such as registering a polyfill, needs an explicit early import. Barrel files, which re-export dozens of modules from a single index.ts, defeat lazy evaluation unless the bundler can see through them, because importing one export from the barrel can evaluate them all. Large apps benefit from importing from specific module paths in startup-critical code, and from enforcing that with lint rules. Navigation libraries support lazily defined screens, which keeps each screen's module graph out of the startup path until the user navigates there. Third-party SDKs that initialize at import time, such as analytics, crash reporting, feature flags, and A/B testing, should be audited individually: which of them must run before the first render, and which can initialize after the first screen is interactive? The answer is usually that crash reporting must run first and almost everything else can wait. Finally, measure startup in release builds with the profiling techniques of chapter 8, and set a budget. A startup time that is not tracked against a target will regress, one harmless import at a time. Small things that add up A few smaller patterns recur often enough in large codebases to be worth naming. console.log calls in production are not free: each one formats its arguments and, depending on configuration, forwards them to native logging. A Babel plugin that strips them from release builds is standard practice. Timers and intervals created in components and never cleared keep running after unmount, consuming thread time and holding references. JSON serialization of large objects into storage on every state change, a common pattern with persisted stores, can cost more than the render that triggered it; persist on a debounce or in the background. And deeply nested inline styles created on every render produce new objects for the renderer to compare; StyleSheet.create or a styling library that hoists static styles avoids that. None of these is dramatic on its own. In an app with five hundred screens and a hundred contributors, they are the difference between a JavaScript thread that is usually idle and one that is usually busy. Chapter 7: Native Views and the Fabric Renderer Native modules expose behavior. Native components expose views: a map, a video surface, a chart drawn with a platform graphics API, a camera preview, a rich text editor built on a platform text engine. They are where React Native's promise of using real platform UI is most literal, and they are where the New Architecture changed the rules most. A native component written for the old renderer can usually be displayed by Fabric through the interop layer, but it misses Fabric's capabilities and inherits its constraints. This chapter explains what Fabric expects of a component, how to write one on both platforms, and the performance and correctness traps specific to views. How Fabric sees a component To Fabric, a native component is three things. It is a set of props, defined in a typed spec, that React passes down. It is a shadow node in the C++ shadow tree, which participates in Yoga layout and holds the component's props. And it is a platform view, a UIView subclass on iOS or an Android View, that Fabric creates on the UI thread during mount and updates when props change. The spec for a component is a TypeScript or Flow file, typically named with a NativeComponent suffix, that declares the props type and calls codegenNativeComponent. A component that displays a vector map tile layer might be specified like this: // specs/MapLayerNativeComponent.ts import type {ViewProps, CodegenTypes, HostComponent} from 'react-native'; import {codegenNativeComponent} from 'react-native'; type RegionEvent = Readonly<{ latitude: CodegenTypes.Double; longitude: CodegenTypes.Double; zoom: CodegenTypes.Float; }>; export interface NativeProps extends ViewProps { styleUrl: string; showsUserLocation?: CodegenTypes.WithDefault; onRegionChange?: CodegenTypes.DirectEventHandler; } export default codegenNativeComponent( 'MapLayerView', ) as HostComponent; The project's codegenConfig lists this spec with type components, or all if the library contains both modules and components. Codegen then generates C++ props and event emitter classes shared across platforms, an interface and delegate for the Android view manager, and the types the iOS component view uses to read props. Several spec features have no equivalent in modules. WithDefault declares a default value that Codegen bakes into the native props class, so native code never sees an undefined value. DirectEventHandler declares an event that is delivered only to the component that emitted it, while BubblingEventHandler declares one that propagates up through ancestors like a touch event. Imperative operations that cannot sensibly be expressed as props, such as animating a map camera to a location or seeking a video, are declared separately as commands with codegenNativeCommands, which generates typed command methods that JavaScript calls on a ref and native code implements. Implementing on Android On Android, a Fabric component consists of a view class and a view manager. The view is an ordinary Android View or ViewGroup subclass. The view manager, typically extending SimpleViewManager for a leaf view, creates instances of the view, applies props to it, and declares its events and commands. Codegen generates a manager interface listing a setter for every prop, and a delegate that dispatches incoming props to those setters. The manager implements the interface and returns the delegate, which means a typo in a prop name, or a missing setter, is a compile error rather than a silently ignored prop. The setters are called on the UI thread, during mount, every time the corresponding prop changes. That is the first performance consideration: a setter that does heavy work, such as reloading a map style from the network when styleUrl changes, must start that work asynchronously and return immediately. A setter that does moderate work, such as rebuilding a path or re-laying out child content, is acceptable when the prop changes rarely and a problem when it changes on every frame. If JavaScript needs to drive a property continuously, such as a progress value during playback, consider whether that value should be computed on the native side instead, or delivered through a command at a lower rate. Events are dispatched from the view through React Native's event dispatcher, and they arrive in JavaScript as calls to the component's event handler props. Each event crosses the boundary and is processed as a task on the JavaScript thread. A map that emits onRegionChange on every frame of a pan gesture generates sixty or more events per second, each of which runs a JavaScript handler, and if that handler sets React state, each of which triggers a render. Throttling events at the source, for example emitting region changes only when the gesture ends or at most every 100 milliseconds, is often the largest performance improvement available to a native component. Implementing on iOS On iOS, a Fabric component is a subclass of RCTViewComponentView, written in Objective-C++, because it reads props from generated C++ structures. Its core method is updateProps:oldProps:, which receives the new and old props as C++ objects and applies whatever changed to the underlying UIView. A typical implementation compares each field of interest between old and new props and acts only on those that differ. As with modules, the Objective-C++ class can be a thin shell around a Swift view that holds the real implementation, keeping the C++ surface small. iOS Fabric introduces a behavior that does not exist on Android and that causes some of the hardest component bugs to diagnose: view recycling. When a component view is unmounted, Fabric on iOS may keep the UIView instance in a pool and reuse it later for another instance of the same component type, rather than destroying it and creating a new one. The component is notified through prepareForRecycle, and it is responsible for resetting itself to a clean state. A video component that does not stop playback and release its player in prepareForRecycle can resurface on a different screen still playing the previous video's audio. A text field that does not clear its content reappears with stale text. Any state kept in the view that is not driven entirely by props must be reset there, and components that hold expensive resources should release them there too, since a recycled view may sit in the pool for a long time. The iOS component also declares its props with the component descriptor generated by Codegen, and registers itself so that Fabric can find the class for a given component name. In libraries, the class is listed in the codegenConfig so that the app's generated component provider includes it automatically. Layout, measurement, and custom shadow nodes By default, a native component is laid out entirely by Yoga based on its style props. Yoga decides its size from flex rules, explicit width and height, and its parent's constraints. The native view simply receives a frame. This works for components that fill a box: a map, a video, a camera preview. It does not work for components whose size depends on their content, such as a custom text renderer, a tag cloud, or a view that wraps platform content of variable height. For those, Yoga needs to ask the component how large it wants to be given the available space. In the old architecture, this was done through a platform-specific shadow view mechanism. In Fabric, it is done with a custom shadow node in C++: a subclass of the generated shadow node that implements a measure function, called by Yoga during layout with the available width and height and returning the desired size. Because Fabric's layout runs in C++ and may run off the UI thread, the measure function cannot call into UIKit or the Android view system directly; it must compute size from data it holds, often by calling platform text measurement APIs that are safe off the main thread, or by using state that native code updates through Fabric's state mechanism. This is the most significant limitation of the interop layer. Legacy components that relied on custom shadow views to size themselves cannot have that behavior reproduced through interop, which is why some legacy components render with zero height or wrong size under Fabric until they are migrated properly. Synchronous layout and DOM-like refs On the JavaScript side, Fabric changed what you can learn about native views and when. Because the shadow tree is in C++ and layout can be computed synchronously, JavaScript can read a component's layout during a layout effect, before the frame is painted. React Native 0.82 went further, making refs to native components return DOM-like nodes that implement a subset of the web's DOM API: parentNode, children, and getBoundingClientRect() among others. Code that positions a tooltip or a popover relative to an anchor can measure the anchor in useLayoutEffect and render in the right place on the first frame, eliminating the flicker that was unavoidable with the old asynchronous measure callback. Version 0.83 added canary support for IntersectionObserver, the web API for detecting when an element enters or leaves an ancestor's visible area. For features such as tracking which items in a feed were actually viewed, or starting video playback when a card scrolls into view, it offers a more direct and potentially cheaper mechanism than computing visibility from scroll offsets in JavaScript. As a canary feature it should be used with care in production, but its presence signals the direction the framework is heading: more of the web platform's layout and observation APIs, implemented over Fabric's C++ tree. One old pattern loses ground under Fabric: setNativeProps, the escape hatch for mutating a native view's props directly from JavaScript without a React render. It was widely used for performance, for example to update a text input's value or a view's opacity during a gesture without re-rendering. Under Fabric, direct mutation bypasses the shadow tree, so a later React render may overwrite the change or a commit may be inconsistent with what is on screen. The better tools are now Reanimated shared values for continuous updates, the native animation driver, and commands for imperative operations. A worked example: wrapping a video player Wrapping a platform video player, AVPlayer on iOS or Media3's ExoPlayer on Android, as a Fabric component exercises almost every rule in this chapter, which is why it is worth walking through. Start with the interface. Props describe the desired state: the source URL, whether playback is paused, whether it is muted, the resize mode. Commands describe imperative operations that are not state: seek to a position, or enter full screen. Events report what happened: loaded with a duration, progress, buffering started and ended, playback ended, error. The temptation is to make the current position a prop, so that JavaScript can control it; that turns every progress update into a render-and-prop-update round trip and fights the player's own clock. Position belongs in a seek command going down and a progress event coming up. Next, the progress event's rate. Players can report position many times per second. If the JavaScript side displays a progress bar, it needs perhaps four updates per second to look smooth with interpolation, and far fewer if it only shows elapsed time as text. The native side should emit progress at a fixed, modest interval, and a native progress bar driven directly by the player, rather than by JavaScript, is better still for smoothness. Then the setters. Changing the source is expensive: it tears down the current item, creates a new one, and starts loading. The setter must do this asynchronously and must ignore redundant updates, because a parent re-render can pass the same URL again. Comparing old and new props in updateProps:oldProps: on iOS, or tracking the last applied value in the Android view, prevents a reload on every render. Then lifetime. On iOS, prepareForRecycle must pause and release the player item, remove time observers, and clear any overlays, or the recycled view will carry audio and state into its next use. On both platforms, the player and its decoder buffers are large native allocations; releasing them when the view is detached, rather than relying on eventual deallocation, keeps a feed of autoplaying videos from exhausting memory. A player that holds a hardware decoder can also block other players from acquiring one, so prompt release matters for correctness, not only memory. Finally, threading. Player callbacks arrive on various threads depending on the platform API. Events can be dispatched from any of them, but any mutation of the view, such as showing a poster image when playback ends, must hop to the main thread. A video component that follows these rules feels native because, apart from its interface, it is native. JavaScript decides what should play; native code does the playing. Native components without Codegen The Expo Modules API, discussed in chapters 4 and 5, also supports views. A module definition can declare a View block naming a Swift or Kotlin view class, and declare its props with Prop closures that are called when the prop changes, and its events with Events. The Expo infrastructure handles the Fabric integration. For many product teams, this is the fastest way to wrap a native SDK's view, such as a payment card entry field or a vendor's video player, and it avoids writing Objective-C++ entirely. The same performance principles apply regardless of authoring method. Keep prop setters cheap. Throttle events at the source. Reset recycled views completely. Do not mutate native views behind React's back. Embedding React Native in native apps A final case deserves mention because it is common in large organizations: brownfield apps, in which React Native renders some screens inside an existing native app. Here the native app creates a React Native host, attaches a root view for a particular component, and destroys or keeps the host as navigation proceeds. The decisions that matter are how many hosts to create and how long to keep them. Creating a new host for every React Native screen means paying the runtime initialization and bundle execution costs each time, and risks the module lifecycle problems described in chapters 4 and 5 every time a host is destroyed. Creating one shared host at app launch and reusing it for every React Native screen amortizes those costs, keeps JavaScript state across screens, and makes navigation into React Native screens fast, at the cost of the memory the host holds while unused. Most large brownfield apps settle on a single long-lived host, created either at launch or on first use and then kept, which aligns with how React Native's lifecycle is designed and minimizes surprises. Views are where users touch your app. The renderer's job is to make the path from a React update to a pixel as short as possible, and the component author's job is to avoid putting anything heavy on that path. Chapter 8: Measuring What Matters Performance work without measurement is guesswork, and guesswork in a large codebase is expensive, because every guess becomes a pull request that someone reviews, merges, and maintains. The preceding chapters made many claims about where time goes. This chapter is about verifying those claims in your own app: which tools answer which questions, how to set up measurement so that it reflects what users experience, and how to turn one-off investigations into a process that prevents regressions. First, measure the right build on the right device Two decisions determine whether any measurement is meaningful, and both are made before a profiler is opened. The build must be a release build or something close to it. Debug builds of React Native run with development-only checks, warnings, and instrumentation; on Android, a standard debug build also compiles native code without optimization. The gap is large. The React Native team's notes for version 0.82 introduced a debugOptimized build type for Android, which keeps JavaScript debugging available while compiling C++ with optimizations, and reported that it reached roughly 60 frames per second in a scenario where the standard debug build managed about 20. That is a threefold difference caused by build configuration alone. Profiling a debug build will send you chasing problems that do not exist in production and miss ones that do. For JavaScript profiling, a release build with profiling enabled, or the optimized debug variant, is the minimum; for native profiling with Instruments or Android Studio, use a release build with symbols. The device must represent your users. The performance gap between a current flagship phone and a three-year-old mid-range Android device is not a few percent; on CPU-bound JavaScript workloads it can be several times. Your analytics will tell you which devices your users actually own. Keep a small set of physical devices that sit at the 10th or 25th percentile of that distribution, and do your performance work on them. A screen that is acceptable on the slow device will be excellent on the fast one; the reverse is not true. A map of the tools The tools fall into three groups: React Native's own DevTools, which see JavaScript and React; the platform profilers, which see native code and the operating system; and production telemetry, which sees what real users experience. Each answers different questions, and Table 3 summarizes which tool to reach for first. Table 3. Which profiling tool answers which question. Question First tool What it shows Why did this interaction feel slow? DevTools Performance panel JS execution, React tracks, network on one timeline Which components re-rendered and why? DevTools React Profiler Per-commit render times and causes Is the UI thread dropping frames? Perfetto or Android Studio; Instruments Native thread activity, frame timing What does startup spend time on? Instruments App Launch; Perfetto Process start through first frame What do real users experience? Performance APIs, MetricKit, Android vitals Field timings, hangs, slow frames React Native DevTools React Native DevTools is the official debugging and profiling tool, introduced as the default debugger in version 0.76 and built on the same foundations as Chrome's DevTools. It connects to the Hermes runtime through the Chrome DevTools Protocol and provides panels for the console, sources and breakpoints, memory, React component inspection, and React profiling. Version 0.83 added two panels that changed how JavaScript performance work is done, along with a standalone desktop app that does not require a browser. The Performance panel records a session and displays, on a single timeline, JavaScript execution as a flame chart, React's own performance tracks showing render and commit phases, network events, and custom timings you add with the User Timing API. This combination is what makes it useful. A slow tap can now be traced from the touch event, through the event handler, through the state update and the React render it triggered, to the network request that the render started, without switching tools or aligning timestamps by hand. When someone reports that a screen is slow, a recording in the Performance panel is almost always the right first step. The React Profiler panel answers a narrower question: which components rendered in each commit, how long each took, and why each rendered. Its "why did this render" information, which identifies whether props, state, hooks, or a parent caused the render, is the fastest way to find unnecessary re-renders of the kind chapter 6 described. Record the interaction, look for commits that took longer than a frame, and inspect which components rendered in them that had no reason to. The Network panel, also added in 0.83, shows requests made through fetch, XMLHttpRequest, and Image, with timings, headers, response previews, and an initiator view that shows which code started each request. For performance work its main value is spotting waterfalls, in which one request waits for another unnecessarily, and redundant requests, in which several components fetch the same resource. Expo apps use a separate network panel provided by Expo, which at the time of 0.83 lacked the initiator view and the performance timeline integration. Version 0.85 allowed multiple simultaneous connections to the debugging protocol, so that an editor, React Native DevTools, and automated tools can attach to the same app at once, which makes it practical to collect traces from scripted test runs while a developer watches. User timings and the Performance APIs React Native 0.83 made a set of web Performance APIs stable: performance.now() and performance.timeOrigin for high-resolution time; performance.mark() and performance.measure() for user timings; and PerformanceObserver with support for event timing and long task entries. These matter in two ways. During development, marks and measures appear in the DevTools Performance panel. Placing a mark when a screen begins loading and a measure when its content is interactive turns a vague sense of "slow" into a named span on the timeline that you can compare across recordings. In production, PerformanceObserver works in release builds. An observer subscribed to long tasks reports every task on the JavaScript thread that exceeds the long-task threshold, and an observer for event timing reports how long user interactions took to be processed. Sending a sample of those entries to your telemetry backend gives you a field measure of JavaScript thread responsiveness, by screen and device class, which no amount of lab testing can replace. const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { telemetry.record('js_long_task', { duration: entry.duration, screen: currentScreenName(), }); } }); observer.observe({entryTypes: ['longtask']}); Sample this rather than recording every entry from every user, and attach enough context, such as screen and device model, to make the data actionable. Platform profilers The JavaScript tools do not see the UI thread, native modules, image decoding, or the operating system. For those, use the platform profilers. On Android, Perfetto is the system-wide tracing tool, and Android Studio's profiler is built on it. A system trace shows every thread in your process, including the main thread, the JavaScript thread, and the render thread, with their activity over time and the frame deadlines they hit or missed. React Native and Hermes emit trace sections that appear in these traces, so you can see JavaScript execution and React Native's internal phases alongside native activity. A dropped frame on Android is diagnosed by finding the frame in the trace, looking at what the main thread and render thread were doing during it, and following the chain back: a long main-thread section labeled with a view manager's prop update, for example, points at an expensive setter. On iOS, Xcode Instruments provides the Time Profiler for CPU sampling across threads, an Animation Hitches instrument for frame timing, a Hangs instrument for main-thread stalls, and an App Launch template that breaks startup into phases. Native modules can add their own intervals with the os_signpost API, which appear in Instruments alongside the system's own, the native counterpart to performance.mark in JavaScript. Two practical points apply on both platforms. Symbolication matters: a profile of a release build without symbols shows addresses rather than function names, so make sure your profiling builds include them. And sampling profilers show where time is spent, not why; a function that appears hot may be called far more often than it should be, which is a design problem rather than an optimization opportunity. A diagnosis, step by step Tools are easier to use with a method. Here is the sequence I follow for the most common complaint in large apps, a list that stutters while scrolling on lower-end Android devices. First, reproduce it on the reference device in a release build, and confirm it is real. Turn on the developer option that overlays frame rendering bars, or simply record the screen at a high frame rate. If the stutter appears only in a debug build, stop; the problem is the build. Second, determine which thread is over budget. Record a system trace with Perfetto while scrolling. Find the janky frames, which the trace marks as missing their deadline, and look at the main thread and the render thread during them. If the main thread is busy for most of each janky frame, the problem is native: view creation, prop application, image decoding, or a module doing work on the main thread. If the main thread is mostly idle while the frames still miss their deadline, look at the render thread, where overdraw, large shadows, and complex clipping show up. If both are idle but content appears late, with blank cells during fast scrolling, the bottleneck is the JavaScript thread failing to render new items quickly enough. Third, if the JavaScript thread is the problem, switch to React Native DevTools. Record the same scroll in the Performance panel. Look at the React tracks for long renders and at the flame chart for what JavaScript is doing between them. Typical findings are item components that are expensive to render because they compute derived data inline, list items re-rendering when unrelated state changes, impression tracking or analytics running synchronously on each item mount, and image components doing work in JavaScript per item. Fourth, if the main thread is the problem, the trace sections usually name it. Long sections for view creation suggest that cells are being mounted rather than recycled, which points toward a recycling list. Long sections inside a native module's methods point at that module. Image decoding on the main thread points at an image library configuration that decodes synchronously, or at full-resolution images being decoded for thumbnails. Fifth, fix one thing and measure again with the same procedure. Performance problems in lists usually have more than one cause, and the order in which you fix them matters less than confirming that each fix moved the measurement. A change that does not move the trace is not a fix, however reasonable it looked in review. This sequence takes perhaps an hour once the tools are set up, and it replaces days of speculative changes. The essential discipline is the second step: deciding which thread is over budget before touching any code. Startup measurement Startup deserves its own measurement because it spans native and JavaScript phases and because it is the metric users and app stores notice first. Define startup precisely. "Time to first frame" is when the first React Native content is drawn; "time to interactive" is when the first screen is showing real content and responds to input. The second is what users experience and the one to track. Mark it explicitly in JavaScript, with a performance.mark when the home screen's data is rendered, and record the duration from process start, which native code can supply. Measure cold starts, in which the process does not exist, separately from warm starts, in which it does. Measure them on the slow device, in a release build, repeated enough times to see the distribution rather than a single number; startup times vary considerably from run to run because of disk caching, CPU frequency scaling, and background activity. Tools such as Flashlight, an open-source performance measurement tool for Android apps, and Android's Macrobenchmark library can automate repeated launches and collect statistics. Then use the profilers to attribute the time. Instruments' App Launch template and a Perfetto trace of a cold start show native initialization, SDK setup, runtime initialization, bundle loading, and first render in sequence. In large apps, the surprises are usually in native SDK initialization, which happens before React Native starts, and in top-level module evaluation, which chapter 6 addressed. Production telemetry Lab measurements tell you what is possible; field measurements tell you what is happening. Both platforms provide field performance data with no code at all. Android vitals in the Google Play Console report slow and frozen frame rates, application-not-responding events, and startup times across your user base, broken down by device. Apple's MetricKit delivers aggregated launch times, hang rates, and memory metrics to your app daily, and Xcode's Organizer shows similar data. These are coarse, but they are free and they cover everyone. On top of them, instrument what is specific to your app: time to interactive for key screens, interaction latency for key actions, long tasks from the JavaScript thread, and frame rates during key scrolls. Many crash reporting and monitoring products include React Native performance features that collect such data. Whatever you use, segment by device class and app version, because an average across all devices hides the low-end experience, and an average across all versions hides regressions. From investigation to process Individual investigations fix individual problems. Keeping a large app fast requires a process that catches regressions before users do. Set budgets. Choose a handful of metrics that matter, such as cold start time to interactive, home feed scroll frame rate, and time to open the most common detail screen, and set targets for each on your reference device. Budgets give regressions a definition. Automate measurement. Scripted flows using an end-to-end testing tool such as Maestro or Detox, run on a physical reference device in continuous integration, can collect startup and interaction timings on every merge to the main branch and alert when a metric moves beyond its noise band. For render performance specifically, Reassure, an open-source library from Callstack, runs component render benchmarks in Jest and compares them against the base branch, catching increases in render count or duration in pull requests before they merge. Attribute regressions quickly. A metric that degrades by 8 percent over a month, one small change at a time, is very hard to fix after the fact. A metric that is checked on every merge makes the offending change obvious. Measurement is not the glamorous part of performance work, but it is the part that determines whether the work lasts. Chapter 9: Memory Profiling and Leak Hunting Memory problems in React Native apps are slower to show themselves than CPU problems and harder to attribute. A dropped frame happens in front of you. A memory leak happens over twenty minutes of use, on a device you do not have, and ends in the operating system silently terminating your app in the background, or in a crash report with a stack trace that points at whatever unlucky allocation happened to come last. Users experience it as an app that "restarts by itself" or loses their place. This chapter explains how memory is organized in a React Native process, how the operating systems judge it, and how to find and fix the leaks and bloat that matter. Four kinds of memory in one process A React Native app's memory is not one pool, and the first step in any investigation is knowing which pool you are looking at. The first is the JavaScript heap, managed by Hermes. Every object, array, string, and closure your JavaScript creates lives here, and Hermes's garbage collector reclaims those that are no longer reachable. This is the heap that a Hermes heap snapshot shows, and it is often smaller than developers expect, frequently tens of megabytes even in large apps. The second is the platform's managed heap. On iOS, this is Objective-C and Swift objects managed by automatic reference counting. On Android, it is the Java heap, managed by the Android Runtime's garbage collector, with a per-process limit set by the device. Native modules, view managers, platform views, and third-party SDKs allocate here. The third is the native heap: memory allocated by C and C++ code with malloc or new. React Native's C++ core, including Fabric's shadow trees, lives here, as does the memory Hermes itself obtains from the operating system to hold the JavaScript heap. So do many image decoders and the internal buffers of media, map, and database libraries. The fourth is graphics memory: decoded image bitmaps, GPU textures, and the backing stores for layers and surfaces. On modern Android versions, bitmap pixel data is allocated in native memory rather than on the Java heap; on iOS, image buffers and layer backing stores are accounted to the process in ways that can make a few large images dominate its footprint. Each pool has its own tools, and a leak in one is invisible in the tools for another. A JavaScript heap snapshot that looks perfectly stable tells you nothing about an Activity leaking on the Java heap, and a clean LeakCanary run says nothing about a cache of decoded bitmaps growing in native memory. How the operating system judges you Neither iOS nor Android cares which pool your memory is in. They care about your total footprint, and both will terminate your process when it is too large. On iOS, the measure is the process's physical footprint: the memory that is actually resident and attributable to your app, including compressed memory. When the system runs short, it sends memory warnings to running apps, and if pressure continues, a kernel mechanism known as jetsam terminates processes, starting with background apps and, if necessary, the foreground app. Each device has a limit beyond which the foreground app is terminated, and on older devices with less RAM that limit is low. A jetsam termination does not produce a normal crash report, which is why these deaths often go unnoticed by crash reporting tools; Apple's MetricKit and Xcode's Organizer report them separately as memory terminations. On Android, the low memory killer terminates processes based on their importance and the system's overall memory state. A foreground app is rarely killed, but a backgrounded one, when the user switches to the camera or a messaging app and back, is a common casualty. The user returns to find the app restarting from its launch screen. Separately, the Java heap has a hard limit, and exceeding it throws OutOfMemoryError regardless of how much system memory remains. Both platforms tell you when memory is tight. iOS delivers memory warnings through UIApplication.didReceiveMemoryWarningNotification; Android delivers onTrimMemory callbacks with levels indicating severity. React Native forwards some of these signals, and native modules that hold caches should listen for them and release what they can. A cache that is never trimmed in response to pressure is a cache that turns into a termination. Reading Hermes heap snapshots React Native DevTools' Memory panel takes heap snapshots of the Hermes JavaScript heap and records allocation timelines, using the same interface as Chrome's memory tools. The snapshot lists every object on the heap grouped by constructor, with its shallow size, the memory the object itself occupies, and its retained size, the memory that would be freed if the object were collected. The retainers view for any object shows the chain of references keeping it alive. A single snapshot is rarely informative. The technique that works is comparison. Take a snapshot at a stable baseline, such as the home screen after launch. Perform the suspect action, for example opening a detail screen and returning, several times. Trigger garbage collection, then take a second snapshot. Repeat the action the same number of times and take a third. Objects that grow by the same increment between the second and third snapshots, in proportion to the number of repetitions, are leaking. Filtering the comparison view to objects allocated between the first two snapshots and still present in the third isolates them, and their retainer chains show what is holding them. The retainer chains in React Native apps tend to end in a small number of places. A subscription callback registered with a native module event emitter, a global event bus, or a store, and never removed, retains its closure and everything the closure captured, which often includes a component's props and state. A module-level cache, such as a Map at the top level of a file used to memoize results, grows forever unless it has an eviction policy. A timer or interval that was never cleared retains its callback. A navigation library that keeps previous screens mounted in a stack retains those screens' entire component trees and state, which is correct behavior but can surprise teams whose detail screens hold large datasets. And a data fetching library's cache retains query results for its configured lifetime, which is usually what you want but can be a lot of memory if responses are large and the lifetime is long. Allocation timelines answer a different question: not what is leaking, but what is allocating. Recording an allocation timeline while scrolling a list shows which code allocates the most objects per frame. High allocation rates do not leak, but they make the garbage collector work harder and, on the JavaScript thread, contribute to the time each frame takes. Finding native leaks on iOS On iOS, Xcode offers two complementary tools. The memory graph debugger, available from the debug bar while the app is running, pauses the app and displays every live object with its references. It flags objects that are part of reference cycles not reachable from any root, the classic ARC leak, and lets you inspect any object's incoming references. After dismissing a screen backed by native views or a native module, searching the graph for the module's classes and their views should find nothing that ought to be gone. Instruments' Allocations template measures memory over time and supports a technique called generation analysis. You mark a generation at a baseline, perform an action, return to the baseline state, and mark another generation. Repeating this several times, allocations that persist in every generation after the baseline are growth. Allocations reports native objects, including Objective-C and Swift objects and C++ allocations, with the stack trace at which each was allocated, so persistent growth can be traced to the code that created it. The Leaks instrument detects unreachable memory automatically, but many real leaks are reachable, held by a cache or a forgotten observer, and Leaks will not flag them; generation analysis will. The patterns from chapter 4 recur here: closures capturing self strongly, block-based notification observers never removed, strong delegate references in third-party SDKs, and modules that do not release resources in invalidate. Finding native leaks on Android On Android, LeakCanary, discussed in chapter 5, is the first line of defense for Java heap leaks, because it detects them automatically during normal use and reports the reference chain. For investigation beyond that, Android Studio's memory profiler captures Java heap dumps, showing instances by class with their retained sizes and references, and can record Java and Kotlin allocations over time. For native memory, the profiler can record native allocations using the system's heap profiler, which attributes malloc allocations to native call stacks; this is how to investigate growth in C++ code, including JSI libraries and React Native's own native core. The Android-specific pattern to look for first is a destroyed Activity still on the heap. Searching a heap dump for your activity class after rotating the device several times should find exactly one instance. If it finds several, follow their references; the chain almost always leads to a native module, an SDK, or a static field holding a context. Images: the largest single consumer In most React Native apps that are terminated for memory, the cause is images. A decoded bitmap occupies roughly four bytes per pixel, regardless of how small the file was on disk. A photo from a modern phone camera at 4032 by 3024 pixels decodes to about 48 megabytes. A feed that displays twenty such photos at thumbnail size, without downsampling, can consume close to a gigabyte of decoded image memory, and the operating system will terminate the app long before that. The remedies are well understood and often neglected. Request images at display size from the server, so that the decoded bitmap matches the pixels on screen. Use an image library that downsamples on decode when the source is larger than needed. Configure memory cache limits explicitly rather than relying on defaults that may assume a high-end device. Clear the memory cache in response to memory warnings and trim callbacks. And in lists, prefer libraries that release images for cells far outside the visible window. JSI and memory the collector cannot see The New Architecture introduces a subtle memory risk that did not exist with the bridge. A JSI host object is a JavaScript value backed by a native object. The JavaScript garbage collector sees a small object on its heap and has no inherent knowledge that it may be holding a 30-megabyte native buffer. Because the collector decides when to run based on the JavaScript heap's growth, it may feel no pressure to collect the small handle while native memory climbs. Libraries that expose images, audio buffers, camera frames, or database result sets as host objects are where this shows up. The defenses are the same as those chapter 3 recommended at the design stage. Prefer explicit release methods for objects that hold significant native resources, so that their lifetime does not depend on garbage collection timing. Where a library exposes host objects, read its documentation on disposal, and call its release methods when you are done. Keep large native data on the native side and pass small handles or summaries to JavaScript. Bloat is not a leak, and it can be worse Not every memory problem is a leak. Some apps have no leaks at all and are still terminated regularly, because their steady-state footprint is simply too high for the devices their users own. Bloat is harder to find than a leak, because nothing grows; the memory is just always there. The common sources of bloat in React Native apps are predictable. Navigation stacks keep every previous screen mounted, so a user who drills from a feed to a product to a seller to another product holds four full screens, with their data and their decoded images, in memory. For deep flows, replacing rather than pushing screens, or unmounting the contents of screens that are far down the stack, bounds that cost. Caches sized for a flagship device, whether for images, API responses, or computed data, are oversized on a device with a third of the RAM; reading the device's memory class at startup and sizing caches from it is a small amount of code with a large effect. Multiple copies of the same data, held in a normalized store, a query cache, and component state simultaneously, triple the footprint of large datasets. And native SDKs, particularly maps, video, and machine learning libraries, can reserve tens of megabytes when first used and keep them for the rest of the session. The way to find bloat is to measure the steady-state footprint of common journeys on the reference device and compare it with the budget the platform gives you. On iOS, the footprint figure in Xcode's memory gauge and in Instruments' VM Tracker approximates what jetsam uses. On Android, the memory profiler's breakdown into Java, native, graphics, and code categories shows where the total comes from. A team that sets a footprint budget for its main journeys, for example a ceiling for the home feed after five minutes of scrolling on the reference device, can track it like any other performance metric, and will notice when a new SDK or a larger image size pushes it up. Memory soak tests The most reliable way to find memory problems before users do is a soak test: a scripted flow that repeats a common user journey many times while recording the app's memory footprint. Open a detail screen and go back fifty times. Scroll the feed to the bottom and back ten times. Play and stop a video thirty times. A healthy app's footprint rises during the first repetitions as caches fill, then plateaus. A leaking app's footprint keeps rising, roughly linearly with repetitions. Soak tests are easy to automate with the same end-to-end tools used for performance flows, and their output is a simple chart of memory over iterations that anyone can read. Run them on the low-memory reference device, and run them after framework upgrades as well as feature changes. Engine and library upgrades can change memory behavior in ways that release notes do not capture until afterward; Expo's own SDK 56 notes, for example, disclosed a memory regression under Hermes V1 affecting apps that used Reanimated and its worklets library, which was resolved in a later SDK patch. Teams with soak tests found it in their own pipelines. Teams without them found it in user reports. Memory is the resource with the least forgiving failure mode. CPU problems make an app slow; memory problems make it disappear. That asymmetry is the argument for measuring memory routinely, not only when something has already gone wrong. Chapter 10: Migrating a Large App to the New Architecture For a small app with a handful of well-maintained dependencies, moving to the New Architecture is an upgrade like any other: bump the version, rebuild, test, ship. For a large app with hundreds of screens, dozens of native dependencies, in-house native modules written over many years, and a release train that cannot stop, it is a project, and it fails in predictable ways when it is treated as an upgrade. This chapter is a playbook for the project. It assumes an app still on the legacy architecture, or one that has upgraded its React Native version but is running significant code through interop layers, and it is organized around the phases that have worked for the teams that have published accounts of doing it. Where you are starting from The version history from chapter 2 sets the constraints. Since React Native 0.82 the New Architecture cannot be disabled, and the project supports only its three most recent minor releases. An app on 0.81 or earlier is therefore on an unsupported version, and the only route back to a supported one goes through the New Architecture. The React Native team's own advice, in the 0.82 release notes, was to migrate to the New Architecture on 0.81 first, while it can still be toggled, and only then upgrade further. That is the right sequence for large apps. On 0.81 you can build the same commit with and without the New Architecture, compare them, and fall back if necessary. On 0.82 and later, that safety net is gone. An app on a much older version should first upgrade to 0.81 on the legacy architecture, as a separate, ordinary upgrade project, and then begin the migration. Combining a large version jump with an architecture change makes every regression ambiguous: was it the upgrade, or the architecture? The community-maintained Upgrade Helper, which shows the diff between the template projects of any two React Native versions, is the standard tool for the version upgrade itself, and working through it one or two minor versions at a time is slower but far easier to debug than jumping across many at once. Preparing the codebase Phase one: inventory The migration's size is determined by its native dependencies, and the first task is to know exactly what they are. Every package in the app that contains iOS or Android code goes on a list, along with every in-house native module and native component. For each third-party library, establish its status. The React Native Directory, at reactnative.directory, records whether libraries support the New Architecture, and its data is a good starting point but not a final answer; check the library's own changelog and issue tracker. Each library falls into one of four groups. It supports the New Architecture natively, in which case upgrade it to a version that does. It works through the interop layer, in which case it may function but will not gain any benefits and remains a risk when interop is eventually removed. It is broken under the New Architecture, typically because it relies on APIs that interop cannot reproduce, such as custom shadow views, direct UIManager calls, or bridge internals. Or it is unmaintained, which in practice means it is broken or will become so. For the last two groups, there are three choices. Replace the library with a maintained alternative that offers the same capability. Fork it and migrate it yourself, which is often less work than expected for a small library and more than expected for a large one. Or remove the feature it supports, if the feature is no longer worth its maintenance cost. Large migrations usually involve all three. The inventory is also an opportunity to remove dependencies that are no longer used, which in long-lived apps is a surprisingly long list. For in-house modules, the inventory records each module's methods, which screens use it, and who owns it. That ownership matters, because migrating a native module requires someone who understands what it does on both platforms, and in long-lived codebases that person may have left. Phase two: migrate your own native code In-house modules and components should be migrated to the New Architecture's native APIs directly, rather than left on interop, because they are the code you control and the code most tied to your app's critical paths. For each module, write a spec that matches the existing JavaScript API, so that call sites do not change. Keep the module name identical. Then implement the generated spec on each platform, as chapters 4 and 5 showed, replacing the legacy export macros on iOS and the legacy annotated methods on Android. This is also the right moment to apply chapter 3's design rules, but resist redesigning the interface during the migration. Change the plumbing first, verify parity, and improve the interface afterward in a separate change. Mixing the two makes every behavioral difference a mystery. Native components require more work, because Fabric's component model differs more from the old one than the module model does. Components that size themselves from their content need custom shadow nodes, as chapter 7 described. Components that used setNativeProps or direct UIManager commands need typed commands. And on iOS, every component must handle view recycling correctly, which legacy components never had to consider. Expect some modules to be easier to rewrite with the Expo Modules API than to migrate in place, particularly those written in Swift or Kotlin that wrap a single SDK. That is a reasonable choice, provided the JavaScript API is preserved. Phase three: find the behavioral differences The New Architecture changes behavior in ways that are correct by design but break code that depended on the old behavior. Large apps encounter the same categories repeatedly, and searching for them proactively is far cheaper than discovering them in production. Shopify Engineering published a detailed account of migrating two large apps, Shopify Mobile and its Point of Sale app, which together had hundreds of screens and more than forty native modules. Their list of problems is a good map of what to look for. State batching changed. React 18's automatic batching, which the New Architecture enables, batches state updates that the old renderer applied one at a time. Code that relied on observing an intermediate state value, for example setting a loading flag and reading it back before a second update, behaves differently. Searching for components that set several pieces of state in sequence and depend on the order is worthwhile. View flattening affected refs and tests. Because Fabric does not create native views for layout-only View elements, a ref to such a view may not correspond to a native view, and test identifiers attached to flattened views may not be findable by end-to-end test tools. Marking such views with collapsable={false} keeps them as real native views when that is required. Direct UIManager manipulation broke. Code, often inside native modules, that reached into the old UIManager to find or mutate views by tag produced blank screens or did nothing. These call sites must be replaced with Fabric-compatible mechanisms such as commands or proper component props. Main thread work moved into view. Shopify reported application-not-responding errors during launch caused by legacy modules blocking the main thread, problems that the new timing of module initialization exposed. Lazy module loading changes when constructors run, and code that was harmless at one point in startup can be harmful at another. Some components got slower. Shopify reported load time increases of up to 20 percent on some complex components involving animation, which required specific investigation and fixes. The migration does not uniformly improve performance, and a measurement baseline from before the migration is the only way to know which screens regressed. Beyond Shopify's list, look for code that called measure or measureInWindow and assumed the callback fired asynchronously after layout, code that depended on findNodeHandle returning a numeric tag, and layout differences caused by Fabric's stricter handling of certain style combinations. Snapshot tests of key screens, compared between legacy and New Architecture builds, find layout differences mechanically. Rolling out Phase four: staged rollout The rollout is where large migrations most often go wrong, usually by being too fast. The principle is to expose the New Architecture build to progressively larger audiences while watching the metrics that would reveal a problem, with a fast way back. Table 4 lays out a sequence that reflects how large teams have approached this. Table 4. A phased migration plan for a large app. Phase Audience Exit criterion Inventory and upgrade None All native deps classified; app on 0.81 Dual builds Developers, CI Both architectures pass the full test suite Internal dogfood Employees No open crash or layout regressions Staged production 1% rising to 100% Crash-free, ANR, startup within budget Cleanup and upgrade Everyone Interop use removed; app on supported version During the dual-build phase, the same commit is built with and without the New Architecture, and both run in continuous integration. This is where behavioral differences surface without risking users. Shopify maintained compatibility with both architectures throughout development and continued shipping weekly releases, using feature flags to disable functionality that was not yet compatible rather than pausing feature work. That approach kept the migration from becoming a long-running branch, which in a fast-moving codebase is the single most reliable way for a migration to fail. During staged production rollout, the metrics to watch are crash-free sessions, application-not-responding rates on Android, hang rates and memory terminations on iOS, startup time, and the key screen timings from chapter 8. Compare them between the two architectures at the same time, rather than against historical values, because seasonal traffic and other releases move them independently. Both app stores support phased releases, and a remote configuration or a separate build variant controls exposure. Shopify's rollout moved Android from 8 percent to 30 percent to 100 percent over three days, with iOS following more cautiously from 1 percent, and they reported that stability initially dipped below their target before recovering over the following weeks as fixes shipped. Their eventual results included launch times about 10 percent faster on Android and 3 percent faster on iOS. Your numbers will differ, but the shape is typical: an initial period of fixes, then parity, then modest gains in the places the architecture helps. Running the migration as a team The technical phases are only half the plan. Large migrations stall for organizational reasons more often than technical ones, and a few practices make the difference. Name an owner, and give the owner time. A migration that is everyone's side project is nobody's project. Large teams that have done this well typically had a small group, two to four engineers with both JavaScript and native experience, dedicated to it, with a mandate to change any code in the app and a clear path to the owners of each area when they needed help. Make the migration visible. A shared tracker listing every native dependency and in-house module, with its status, its owner, and what is blocking it, turns an amorphous project into a burn-down that product leadership can follow. It also makes it obvious when one unmaintained library is blocking the whole effort, which is the moment to decide whether to fork, replace, or drop it. Protect feature work. If the migration requires a freeze on new native code or on dependency changes, the business will feel it and will push back. Dual builds and feature flags, as Shopify used, avoid a freeze; the cost is the discipline of keeping both builds green, which is usually cheaper than the political cost of stopping product work. Agree on the metrics before the rollout. Deciding in advance that the rollout halts if crash-free sessions drop by a certain margin, or if startup time on the reference device regresses by more than a set percentage, prevents arguments during the rollout about whether a regression is acceptable. It also gives the team permission to proceed when the metrics are within bounds, rather than waiting for perfection. Apps built with Expo follow the same phases with different mechanics. Expo's managed workflow generates native projects from configuration, using config plugins for native customizations, so the inventory focuses on libraries and config plugins rather than hand-edited native code, and the Expo SDK version determines which React Native version, and therefore which architecture rules, apply. Expo's tooling for checking library compatibility and its own modules, which were built on JSI, make the library audit shorter for most Expo apps, but the behavioral differences in phase three apply equally. Phase five: clean up and move forward Once the New Architecture is at 100 percent, the work is not quite done. Remove the code paths and flags that supported the legacy build. Track the remaining libraries running through interop and plan their replacement, because interop will not last forever and each one blocks the benefits that motivated the migration. Then upgrade to a supported React Native version, now an ordinary upgrade again. From there, keeping current is cheaper than catching up. React Native ships roughly every two months, and recent releases, starting with 0.83 and again with 0.86, have explicitly aimed for no user-facing breaking changes. An app that upgrades with each release, or every other release, stays within the support window with small, routine changes. An app that falls three or four versions behind faces a project again. What the migration buys It is worth being clear-eyed about what a large team gets from all this. It gets back onto a supported framework, which is reason enough. It gets lazy module loading and bridgeless startup, which typically produce modest launch improvements. It gets synchronous layout, which removes a class of visual glitches. It gets concurrent React features, which let it keep interactions responsive during expensive renders. It gets typed, generated contracts for native code. And it gets access to the libraries that now require the New Architecture, a list that includes current versions of widely used animation and list libraries. It does not automatically get a faster app. The places where a large app is slow, as the earlier chapters argued, are mostly in its own rendering, its own startup work, its own native modules, and its own memory use. The migration makes those problems more tractable. Solving them is still the team's job. Conclusion The old bridge was slow, and it was also a guardrail. Because every call across it was asynchronous and serialized, it was very hard to block the JavaScript thread from native code, very hard to tie native memory to a JavaScript object's lifetime, and very hard to make a component depend on the exact timing of a layout pass. Many of the bridge's limitations were, in effect, rules that the framework enforced on your behalf. The New Architecture removed those rules along with the bridge. A synchronous method is now one line in a spec. A host object can hold a native buffer the garbage collector does not know about. A layout effect can read geometry in the middle of a commit. Each of these is a genuine capability, and each is a way to hurt yourself that did not exist before. That is the central consequence of everything in this book: in a React Native app at scale, discipline has to replace the constraints the framework used to impose. The teams that benefit most from the New Architecture are the ones that write those constraints down as their own rules and enforce them in review, in tooling, and in measurement. The rules worth writing down The preceding chapters suggest a short list, and it is worth stating as policy rather than advice, because policy is what survives a team of a hundred engineers and a decade of turnover. Synchronous native methods must have a worst-case cost well under a millisecond on the slowest supported device, and must never touch disk, network, locks, or main-thread APIs. Every synchronous method in a spec should be questioned in code review on exactly these grounds. High-frequency traffic across the boundary must be batched or throttled at its source, whether it is analytics calls going down or map region changes coming up. Volume, not latency, is what overwhelms the JavaScript thread. Every native resource has an explicit owner and an explicit release. Subscriptions are removed in effect cleanups, native handles are released when screens unmount, modules release what they hold in invalidate, recycled views reset themselves completely. Garbage collection is not a lifetime policy for native memory. Performance claims require a release build on a reference device. A change justified by a debug build or a flagship phone is not justified. And budgets exist for the metrics that users feel, tracked automatically, with a named owner who is expected to act when one is exceeded. None of these is novel. What the New Architecture changes is that they are no longer optional, because the framework no longer enforces them for you. React Native teams need native engineers A second consequence is organizational. For years, React Native was sold, and often bought, as a way to build mobile apps with web engineers. That was never entirely true at scale, and it is less true now. The work that most determines whether a large app performs well, from module interface design to thread selection, lifetime management, Fabric components, view recycling, heap analysis on two platforms, and migration of legacy native code, requires people who are fluent in Swift or Kotlin and comfortable reading C++. The JavaScript side of a React Native codebase can be written by engineers who know only React. The boundary cannot. The teams that do this well treat native expertise as a core competency rather than a specialist service to be called in when builds break. They have engineers who own the native layer, review every spec, and maintain the platform-level tooling for profiling and leak detection. Teams that lack them tend to accumulate unexamined native dependencies, discover their memory problems in user reviews, and find migrations far more painful than they expected. What remains unsettled Several questions about where React Native goes next were open as this book went to press, and each affects the advice here. The interop layers will eventually be removed, but the timeline is not fixed. Every library still running through interop is therefore a deferred cost of unknown due date. The prudent assumption is that the cost will come due within the lifetime of any app being actively developed. Hermes V1 is a better engine than its predecessor, but it is not yet the engine that the Static Hermes project promised. Ahead-of-time compilation to native code and use of type information for optimization remain unrealized in the default engine. If they arrive, the cost model for CPU-bound JavaScript changes substantially, and some work that today belongs in native modules may reasonably move back into typed JavaScript. Until they arrive, the advice in this book stands: heavy computation belongs off the JavaScript thread. Native module authoring is fragmenting. Codegen-based Turbo Native Modules, C++ Turbo Modules, the Expo Modules API, and third-party frameworks such as Nitro all coexist, with different sources of truth and different trade-offs. Healthy competition has produced better tools, but a large app that uses all four, as many will through their dependencies, carries four sets of build machinery and four sets of failure modes. Whether the ecosystem converges on one model, or stabilizes around a deliberate division of labor, will shape how libraries are written for years. The Objective-C++ adapter that Swift modules require exists only because Swift's interoperability with C++ is not yet good enough for React Native's headers. If that improves, the iOS side of native module authoring becomes considerably simpler. Swift Package Manager support, experimental in 0.87, points the same way, toward an iOS toolchain without Ruby, CocoaPods, or Objective-C glue. And the framework is steadily adopting web platform APIs: DOM-like nodes, IntersectionObserver, the Performance APIs, requestIdleCallback in place of InteractionManager. The direction is clearly toward a React Native that behaves more like a browser for the purposes of layout, observation, and scheduling. That convergence will make knowledge transfer between web and mobile easier. It will also import the web's own performance pathologies, such as observer callbacks that do too much and scheduling primitives misused as a substitute for doing less. What to do differently If there is a single practical change to take from this book, it is to treat every boundary in your app as a design surface with an owner. The boundary between the JavaScript thread and the UI thread belongs to whoever owns rendering performance; they decide what animates natively and what may run during a scroll. The boundary between JavaScript and native modules belongs to whoever reviews specs; they decide what is synchronous, what is batched, and what holds native resources. The boundary between the app and the operating system's memory limits belongs to whoever runs the soak tests; they decide the budgets. When those owners exist and the rules are explicit, React Native scales well, to hundreds of screens, many teams, and a long product life, on hardware far below the flagship. When they do not, the New Architecture's capabilities become liabilities, and the app gets slower one reasonable change at a time. The framework has done its part. What remains is ours. Further Reading Official documentation and release notes • React Native documentation, "The New Architecture" and "Native Modules" sections (reactnative.dev/docs). The canonical guides to Turbo Native Modules, Fabric native components, Codegen configuration, custom events, and the Swift adapter pattern. Read the version of the docs that matches your app; behavior changes between releases. • React Native blog, release posts for 0.76 through 0.87 (reactnative.dev/blog). The 0.76 post, "The New Architecture is here," explains the four parts of the architecture and the interop layers. The 0.82 post documents the end of the legacy architecture; 0.83 introduces the Performance and Network panels and stable Web Performance APIs; 0.84 makes Hermes V1 the default and removes legacy code; 0.85 introduces the new animation backend; 0.87 makes the strict TypeScript API the default and removes InteractionManager. • React Native DevTools documentation (reactnative.dev/docs/react-native-devtools). Panel-by-panel reference for the console, sources, memory, performance, network, and React tools. • React Native Releases overview (reactnative.dev/docs/releases). The support policy and schedule, useful for planning upgrades within the supported window. Engines, renderers, and runtimes • Hermes engine repository and documentation (github.com/facebook/hermes). Design notes on bytecode precompilation, the Hades garbage collector, and the engine's profiling hooks. • Software Mansion, "Welcoming the next generation of Hermes" (swmansion.com/blog). A clear account of what Hermes V1 is and is not relative to Static Hermes, with measured results from a production app. • React Compiler documentation and the "React Compiler v1.0" announcement (react.dev). How automatic memoization works, its assumptions about the rules of React, and how to adopt it incrementally. Native module authoring • Expo Modules API documentation (docs.expo.dev/modules). The reference for writing modules and views declaratively in Swift and Kotlin, including inline modules and type generation. • Expo SDK changelogs (expo.dev/changelog). The SDK 56 and 57 notes are worth reading for their candid reporting of Hermes V1 memory and startup regressions and their fixes. • Nitro Modules documentation (nitro.margelo.com). The hybrid object model and the Nitrogen code generator, for teams evaluating alternatives to Codegen. Performance and memory • Shopify Engineering, "Migrating to React Native's New Architecture" (shopify.engineering). The most detailed public account of a large-scale migration, with the specific breakages encountered, the rollout schedule, and measured outcomes. • Shopify Engineering, "FlashList v2" (shopify.engineering). Explains the rewrite of FlashList for the New Architecture and why synchronous layout removed the need for size estimates. • Android Developers, "Support 16 KB page sizes" and the Perfetto documentation (developer.android.com, perfetto.dev). Platform requirements for native libraries and the system tracing tool used for frame and startup analysis on Android. • Apple Developer documentation for Instruments, MetricKit, and the Xcode memory graph debugger (developer.apple.com). The native tools for CPU, hang, launch, and memory analysis on iOS. • LeakCanary documentation (square.github.io/leakcanary). How the library detects retained objects and how to read its reference chains. • Callstack, "The Ultimate Guide to React Native Optimization" (callstack.com). A practitioner's guide, periodically updated, covering many of the JavaScript-side techniques in this book in more depth. Glossary Codegen. React Native's build-time code generator. It reads typed TypeScript or Flow specs for native modules and components and generates the native interfaces and C++ conversion code that implementations must conform to. Commit. The second phase of Fabric rendering, in which a new shadow tree is laid out by Yoga and promoted to be the next tree mounted on screen. Fabric. The New Architecture's renderer. Its core is written in C++, shared across platforms, and maintains an immutable shadow tree that supports synchronous layout reads and concurrent rendering. Hermes. The JavaScript engine built for React Native. It compiles JavaScript to bytecode at build time. Hermes V1, the default since React Native 0.84, is a new compiler and virtual machine with native support for modern language features. Host object. A C++ object exposed to JavaScript through JSI, which JavaScript code can call as if it were an ordinary JavaScript object. Interop layer. Compatibility code that allows native modules and components written for the legacy architecture to run under the New Architecture, without gaining its capabilities. Jetsam. The iOS kernel mechanism that terminates processes when the system runs short of memory, including the foreground app if it exceeds its device-specific limit. JSI (JavaScript Interface). A C++ API that lets native code interact directly with the JavaScript engine: creating values, calling functions, and exposing host objects, with no serialization. Mount. The third phase of Fabric rendering, in which the differences between the old and new shadow trees are applied to real platform views on the UI thread. Shadow tree. Fabric's C++ representation of the host components on screen, holding their props and layout. Each update produces a new immutable tree that shares unchanged nodes with the previous one. TurboModule. A native module under the New Architecture: defined by a typed spec, loaded lazily, accessed through JSI, and able to expose synchronous methods. View recycling. Fabric's reuse, on iOS, of native component views from a pool after they unmount, which requires components to reset their state in prepareForRecycle. Hashtags: #ReactNative #ReactNativeDevelopment #ReactNativeAtScale #ReactNativePerformance #MobileAppOptimization #CrossPlatformDevelopment #NativeModules #TurboModules #ReactNativeNewArchitecture #JSI #FabricRenderer #HermesEngine #HermesV1 #ReactNativeCodegen #BridgelessArchitecture #JavaScriptPerformance #NativePerformance #SwiftDevelopment #KotlinDevelopment #iOSDevelopment #AndroidDevelopment #ExpoModules #MemoryOptimization #MemoryLeakDetection #PerformanceProfiling #ListVirtualization #AppStartupOptimization #UIThreadOptimization #ReactNativeMigration #MobileAppArchitecture

Download the Book (PDF): Introduction A housefly weighs less than a grain of rice. It can take off in a fraction of a second, correct its course in mid-air faster than a human can blink, land upside down on a ceiling and escape a swatting hand that it registers only when the hand is already moving toward it. It does all of this on a brain of well under a million neurons, powered by the sugar in a crumb. The best small drones of 2026, by contrast, carry flight controllers, cameras, inertial units and embedded processors that together draw several watts, and most of them still struggle to dodge an object thrown at them across a room. That gap is not mainly a matter of better algorithms waiting to be written. It is a gap in how sensing and computation are organised. The fly's eye does not take pictures. Its photoreceptors and the neurons behind them respond to change: a shadow edge sweeping across the visual field, a sudden brightening, a pattern of motion that signals looming. Its brain does not run on a clock that ticks through every neuron at fixed intervals. Neurons fire when they have something to say, and are silent otherwise. Silence is cheap. Most of the fly's neurons are silent most of the time, and that is a large part of why it can do so much on so little. Conventional machines are built the other way. A standard camera samples every pixel at every frame, whether or not anything in the scene has changed, and ships the result across a bus to a processor. The processor, following the architecture John von Neumann described in 1945, fetches weights and activations from memory, multiplies them, writes results back, and repeats, on a schedule set by a global clock. A deep neural network processing that video stream performs the same enormous number of operations on a frame of a motionless wall as on a frame of a ball flying toward the lens. In a data centre this is an expensive habit. On a palm-sized drone with a battery the weight of a few coins, it is a hard ceiling on what the machine can do. Neuromorphic engineering is the attempt to build sensors and processors that work more like the fly. The term was coined by Carver Mead at Caltech in the late 1980s, and the field's first famous device, the silicon retina that Misha Mahowald and Mead described in 1991, already contained the central move: let the hardware report changes rather than states. Three decades later that idea has matured into two families of real, purchasable technology. The first is the event camera, a sensor in which every pixel independently watches its own brightness and emits a tiny digital message, an event, whenever that brightness changes by more than a set fraction. The second is the neuromorphic processor, a chip that runs spiking neural networks, in which artificial neurons accumulate input over time and communicate by sending brief, discrete pulses only when an internal threshold is crossed. Intel's Loihi chips, IBM's TrueNorth, the University of Manchester's SpiNNaker and its successor SpiNNaker2, the analogue BrainScaleS systems from Heidelberg, and a growing set of small commercial devices from companies such as SynSense, BrainChip and Innatera all belong to this second family. Sony and Prophesee, Samsung, and iniVation make sensors in the first. This book is about what those technologies are actually good for, and why. Its argument can be put in one sentence. Neuromorphic hardware earns its advantages only when sparsity and timing are preserved across the whole loop, from the sensor through the network to the actuator, and the place where that whole-loop discipline pays off most clearly today is in small, fast, power-starved machines that must react to a changing world: drones and agile robots. Break the chain anywhere, by accumulating events into frames so that a conventional network can digest them, by converting a dense network to spikes without changing what it computes, or by bolting a microwatt chip to a system whose idle power is a thousand times larger, and most of the promised benefit leaks away. Keep the chain intact and the results can be striking: obstacle avoidance with a few milliseconds of latency, vision-based flight control running on milliwatts, and perception that keeps working in glare and darkness that blind ordinary cameras. That argument cuts in two directions, and both matter. It explains why neuromorphic demonstrations are so often impressive in the lab and disappointing when someone tries to drop them into an existing product. It also explains where to look for real wins. The question to ask of any proposed neuromorphic application is not "is this brain-inspired?" but "where does the information arrive sparsely in time, where does the decision have to be made fast, and can the whole pipeline stay sparse between those two points?" What the chapters do The first chapter sets out the cost of the clock: why frame-based sensing and clocked, memory-bound computation spend most of their energy on information that has not changed, and what the brain's energy budget tells us about doing better. It introduces Mead's founding argument and the physical facts, about the cost of moving data versus computing on it, that make that argument stronger today than when he made it. The second chapter opens up the event camera. It explains, in circuit-level terms but without equations, how a pixel decides to fire, what an event contains, why such sensors achieve microsecond timing and a dynamic range above 120 decibels, and what they get wrong: noise, flicker, threshold mismatch, and the awkward fact that a perfectly still camera looking at a perfectly still scene sees nothing at all. It traces the sensor from the 128-by-128-pixel device that Patrick Lichtsteiner, Christoph Posch and Tobi Delbruck published in 2008 to the stacked 1280-by-720 sensor that Sony and Prophesee brought to market. The third chapter asks what one does with a stream of events. It covers the main families of event-processing algorithm, from the event-by-event filters that preserve timing to the contrast-maximisation methods that recover motion directly from event geometry, and the learned methods that reconstruct video or estimate optical flow. It names the central temptation of the field, which is to pile events into frames and hand them to conventional deep networks, and explains exactly what that costs. The fourth chapter turns to spiking neural networks: how a leaky integrate-and-fire neuron works, how information can be carried in spike timing and spike counts, why the all-or-nothing spike is both the source of efficiency and the obstacle to training, and how the field got around that obstacle with surrogate gradients, network conversion, local learning rules and evolutionary search. The fifth chapter surveys the silicon: the major neuromorphic processors, digital and analogue, research and commercial, and what each was designed to do. The sixth chapter does the energy arithmetic that marketing materials leave out, showing when a spiking chip really saves energy against a well-used conventional accelerator, and when the comparison is rigged or irrelevant. The seventh chapter is the heart of the applications case: drone navigation. It works through a sequence of real experiments, from a quadrotor that dodges a ball thrown at ten metres per second with three and a half milliseconds of perception latency, to the 2024 demonstration from Delft in which a spiking network running on Intel's Loihi controlled a drone's flight directly from raw event-camera input. The eighth chapter widens the view to ground robots, manipulators, tactile sensing, humanoid platforms and automotive perception. The ninth chapter is for the practitioner who wants to build something now: what toolchains exist, how to decide whether an application is a good fit, and the specific failure modes that sink projects. Who this book is for The reader I have in mind is an engineer, researcher, technical manager or informed generalist who knows roughly what a neural network is and has heard the word neuromorphic, but wants to know what lies behind it and whether it matters for their own work. No equations are required. Where a mechanism matters, it is explained in prose and, where useful, with a worked numerical example. Where a figure is quoted, it comes from a published paper, a manufacturer's datasheet or an institutional announcement named in the notes, and where a number is uncertain or contested, the text says so. A word on scope. "Neuromorphic" has been stretched to cover a very wide range of things, including memristor crossbars, in-memory analogue computing for conventional deep learning, and photonic neural networks. Some of these share ideas with the systems described here, and they are mentioned where the connection is real. But the focus throughout is on the pairing that defines the field's most practical work at present: event-based sensors feeding spiking or event-driven processors, applied to machines that move. That pairing is where the ideas are most fully tested, and where the difference between a good demonstration and a useful product is most clearly visible. The technology is not mature. Event cameras are still expensive relative to ordinary image sensors, toolchains are fragmented, and no neuromorphic processor has yet become a mass-market component in the way that GPUs or smartphone neural engines have. Several companies in the space have had to restructure or narrow their ambitions. Against that, the underlying physics has not changed: moving data costs more than computing on it, and most of the world, from one moment to the next, stays the same. A machine that exploits those two facts will always have an advantage over one that ignores them. The rest of this book is about how that advantage is captured, and how it is lost. CHAPTER 1 The Cost of the Clock Every engineered vision system begins with a decision so familiar that it rarely looks like a decision at all. The designer picks a frame rate. Thirty frames per second for a webcam, sixty for a phone, a few hundred for a racing drone's camera, several thousand for a laboratory high-speed camera. Once that number is fixed, everything downstream inherits it. The sensor reads out every pixel at that rate. The interface carries every pixel at that rate. The processor wakes up, at that rate, to examine every pixel, and the controller receives updated estimates of the world at that rate or slower. The world, meanwhile, does not care what rate was chosen. Some of it changes much faster than the frame rate and is smeared or missed. Most of it does not change at all between frames and is measured again anyway. This chapter is about the cost of that decision and of its twin in computing, the global clock that marches every circuit forward in lockstep. Neither is wrong. Frames and clocks are the reason modern imaging and computing are so cheap, so predictable and so easy to program. But they carry a hidden tax that grows with resolution, with speed and with the gap between how fast a machine must react and how little energy it has to do it. Understanding that tax is the starting point for understanding why anyone would build hardware that works differently. Sampling a world that mostly stands still Consider an ordinary scene from a drone hovering in a warehouse aisle. Shelves, a concrete floor, a few boxes, overhead lights. Over the course of one second at thirty frames per second, a 1280-by-720 monochrome camera reads out 921,600 pixels thirty times: about 27.6 million pixel values, or 27.6 megabytes at eight bits each. If the drone holds still and nothing moves, the overwhelming majority of those values are, apart from sensor noise, identical from one frame to the next. The information content of the second frame, given the first, is close to zero. The cost of acquiring, transmitting and processing it is exactly the same as the cost of the first. Engineers have known this for a long time, and the video industry has an elaborate answer to it: compression. Codecs such as H.264 and its successors exploit temporal redundancy by encoding only the differences between frames, along with motion vectors that describe how blocks of pixels have shifted. That is why a two-hour film fits on a disc. But compression happens after the fact. The sensor still reads out every pixel, the analogue-to-digital converters still convert every value, and the encoder still has to examine every pixel in order to discover that most of them have not changed. The redundancy is removed at the end of the pipeline, after the energy to produce it has already been spent. Now make the drone move. It yaws to look down the aisle, and a forklift crosses its path. Suddenly the problem inverts. Every pixel changes, and the interesting changes, the edge of the forklift, the shelf edges sweeping across the field of view, happen faster than the frame rate can follow cleanly. Within a single exposure the image of a moving edge smears across several pixels: motion blur. Between frames, an object moving quickly across the field of view can jump tens of pixels, which makes it harder for tracking algorithms to associate what they saw before with what they see now. The fixed frame rate is simultaneously too fast for the static parts of the scene and too slow for the dynamic ones. There is also a latency cost that matters more for machines that move than for anything else. At thirty frames per second, a new frame arrives every 33 milliseconds. An event that happens just after one frame is captured cannot be seen until the next, so the sampling alone adds up to 33 milliseconds of delay, on top of exposure time, readout, transfer and processing. A drone flying at ten metres per second covers 33 centimetres in 33 milliseconds. If an obstacle appears in its path just after a frame, the drone has travelled a third of a metre before its camera even registers the fact, and more before its processor has decided what to do. Raising the frame rate shrinks this delay, but every doubling of frame rate doubles the data, and therefore roughly doubles the bandwidth and the computation. A 1280-by-720 camera running at 1,000 frames per second produces over 900 megabytes of raw data per second, a stream that no small embedded processor can analyse in real time with a modern neural network. A related limit is dynamic range, the ratio between the brightest and darkest intensities a sensor can capture in the same image. A typical frame-based CMOS image sensor manages somewhere in the region of 60 to 70 decibels in a single exposure, a ratio of roughly a thousand or a few thousand to one. Multiple-exposure HDR modes extend this, but at the cost of more readout and more risk of artefacts when the scene moves. A drone flying out of a dark barn into sunlight, or a car emerging from a tunnel, faces a scene whose brightness spans a far wider range. For a frame camera, a single global exposure setting must be chosen for every pixel at once, and some part of the scene is either crushed to black or blown out to white. This is not an incidental flaw. It follows directly from the decision to integrate light at every pixel for the same fixed interval and read the result out on a global schedule. The price of moving a bit The second half of the problem lives in the processor. In 2014, Mark Horowitz of Stanford gave a keynote at the International Solid-State Circuits Conference titled "Computing's energy problem (and what we can do about it)", which has since become one of the most cited references in hardware design. Its central table gave approximate energy costs, for a 45-nanometre process, of the basic operations a processor performs. An 8-bit integer addition cost about 0.03 picojoules. A 32-bit floating-point multiplication cost about 3.7 picojoules. Reading 32 bits from a small on-chip SRAM cost about 5 picojoules. Reading 32 bits from off-chip DRAM cost about 640 picojoules. The exact numbers shift with each process generation, but the ratios have held stubbornly. Fetching a number from external memory costs on the order of a hundred times more than doing arithmetic with it, and thousands of times more than a simple integer addition. A deep neural network running on a conventional processor spends much of its energy not on multiplying, but on moving weights and activations between memory and the arithmetic units. This is the modern face of what John Backus, in his 1977 Turing Award lecture, called the von Neumann bottleneck: the narrow channel between a processor and its memory, through which every operand must pass. Clocks add their own costs. A synchronous digital circuit distributes a clock signal to every flip-flop on the chip, and the clock network itself, a tree of wires and buffers charging and discharging billions of times per second, can consume a substantial fraction of a chip's dynamic power. More importantly, a clocked architecture encourages a style of computation in which every unit does work on every cycle whether or not its inputs have changed. Modern processors fight this with clock gating, power gating and dynamic voltage scaling, and they fight it well. But the default is activity, and silence has to be engineered in. Put the camera and the processor together and the waste compounds. A conventional pipeline acquires a dense frame, moves the whole frame into memory, then streams it through a convolutional network whose weights are fetched from memory for each layer, performing multiply-accumulate operations for every pixel location whether that location contains an informative edge or a patch of blank wall. Graphics processors and neural accelerators are extremely good at this, precisely because the work is regular, dense and predictable. They achieve their efficiency by batching: processing many frames or many samples together so that each weight fetched from memory is reused as many times as possible. For a server answering millions of queries, batching is natural. For a drone that must react to the single frame it has just captured, batching is not available. Every inference is a batch of one, and the memory traffic per useful result rises accordingly. None of this makes conventional hardware inefficient in absolute terms. A modern neural processing unit in a smartphone can run an image classifier in a few milliseconds on a fraction of a watt. The point is narrower and more important. The energy spent by a frame-and-clock system scales with the number of pixels times the frame rate times the size of the network, regardless of how much is actually happening in the scene. For a machine that needs fine temporal resolution and has a power budget measured in milliwatts, that scaling is the wrong one. Twenty watts The comparison that launched neuromorphic engineering, and that is still invoked in nearly every paper in the field, is with the brain. The adult human brain consumes roughly 20 watts, about a fifth of the body's resting energy budget, while containing on the order of 86 billion neurons, a figure established by Suzana Herculano-Houzel and colleagues in 2009 using a technique that dissolves brain tissue and counts cell nuclei. Each neuron connects to thousands of others. By any count of raw connections the brain is a vast machine, and it runs on the power of a dim light bulb. The comparison is easy to overstate. The brain does not compute in the same way a digital processor does, its "operations" are not directly comparable to floating-point multiplications, and it is far worse than a pocket calculator at arithmetic. What it is good at, perceiving and acting in an unpredictable world in real time, it achieves through mechanisms that are only partly understood. But some of those mechanisms are well enough understood to be borrowed, and the most important one is sparsity. Neurons communicate chiefly by action potentials, or spikes: brief electrical pulses about a millisecond long, all of roughly the same shape. Generating a spike, and restoring the ion gradients afterwards, costs energy. In 2001 David Attwell and Simon Laughlin published an energy budget for the grey matter of the rodent brain and found that signalling, spikes and the synaptic transmission they trigger, accounts for the large majority of its energy use. Two years later Peter Lennie, working through the same kind of arithmetic for the human cortex, concluded that the energy available to the brain can support only a small fraction of its neurons being substantially active at any one time; his estimate was on the order of one percent. Average firing rates in cortex are low, often a few spikes per second or less, and a great many neurons are nearly silent most of the time. The brain's efficiency is not primarily that each spike is cheap. It is that there are so few of them. This low activity is not a defect of brains but a design principle. A neuron that fires only when its input changes in a way it is tuned to detect transmits information in its silences as well as its spikes, because silence tells the receiving neuron that nothing relevant has happened. Retinal ganglion cells, the neurons that carry signals from the eye to the brain, are a classic case. Many of them respond strongly to changes in light, to onsets, offsets and moving edges, and adapt quickly to steady illumination. The retina compresses the visual world before it ever reaches the brain, transmitting a stream of signals that emphasises change and largely discards constancy. The optic nerve, about a million fibres in a human, carries what is effectively an event stream. Two further properties of biological computation matter for engineering. The first is that memory and computation are co-located. A synapse stores a connection strength and applies it to incoming signals in the same physical place, so the brain has no equivalent of the bus between processor and DRAM. The second is that time is continuous and asynchronous. There is no global clock. Each neuron integrates its inputs in continuous time and fires when it fires, and the precise timing of spikes can itself carry information. A system built this way spends energy roughly in proportion to how much is happening, rather than in proportion to how much it could in principle observe. Mead's wager In October 1990 Carver Mead published a paper in the Proceedings of the IEEE titled "Neuromorphic electronic systems". Mead was already one of the most influential figures in microelectronics. He had helped formalise the methodology of very-large-scale integration that made modern chip design possible, and he had popularised the observation that came to be known as Moore's law. In the 1980s he had turned his attention to a different question: what could be learned from building electronic circuits that imitated the structure of nervous systems? His argument in that paper was physical rather than metaphorical. A MOS transistor operated in its subthreshold region, with a gate voltage below the level at which it normally switches fully on, passes a current that depends exponentially on the gate voltage. The same exponential relationship governs the flow of ions through the channels in a neuron's membrane, because both arise from the statistics of charged particles crossing an energy barrier. Mead argued that this was not a coincidence to be admired but a resource to be exploited. Analogue circuits running in the subthreshold regime could perform operations such as summation, multiplication, exponentiation and integration directly with the physics of a handful of transistors, using currents of nanoamperes, where a digital circuit would need many transistors switching at full voltage. He estimated that brains were vastly more energy efficient than the digital computers of the day, by many orders of magnitude, and argued that a large part of that gap could be closed by adopting nature's representations and organisation. The most famous product of this programme was the silicon retina, built by Mead's doctoral student Misha Mahowald and described for a general audience in a 1991 Scientific American article. It was a chip in which each pixel contained photoreceptor circuitry and connections to its neighbours, implementing in analogue electronics a model of the outer layers of the vertebrate retina. Its outputs emphasised spatial and temporal change, just as biological retinas do. Mahowald also developed, with colleagues in the same period, the address-event representation, a way of communicating spikes between chips in which each spike is transmitted as a digital address identifying the neuron that fired, sent over a shared bus only at the moment of firing. The address-event representation is still, in essence, how every event camera and most neuromorphic processors communicate today. Mahowald died in 1996 at the age of 33. The Misha Mahowald Prize for Neuromorphic Engineering, established in 2016, is named in her honour. Mead's wager, then, had three parts. First, that the physics of silicon could emulate the physics of neurons efficiently. Second, that representations based on change and on discrete events would be more efficient than representations based on sampled states. Third, that systems built on these principles would excel at exactly the tasks brains excel at: real-time perception and control in a messy physical world. Thirty-five years on, the record is mixed in instructive ways. The first part of the wager has been only partly vindicated. Analogue subthreshold circuits are efficient, but they are also noisy, sensitive to temperature, and subject to manufacturing variation, so that no two transistors behave quite alike. Building large, programmable, reliable systems from them has proved hard, and most of the neuromorphic processors in use today are digital, borrowing the brain's organisation, its spikes, its sparsity and its co-located memory, while implementing them with conventional logic. The analogue tradition survives in research systems such as Heidelberg's BrainScaleS, in the front ends of event cameras and in several small commercial chips, but it is not the mainstream. The second part of the wager has been vindicated more completely than Mead could have demonstrated in 1990, because the cost structure of computing has moved in its favour. In 1990 a logic operation was expensive and moving data was comparatively cheap. Today, as Horowitz's figures show, the arithmetic is nearly free and the data movement dominates. An architecture that avoids moving data that has not changed, and that keeps memory next to the computation that uses it, gains more from that design choice now than it would have three decades ago. Meanwhile the end of Dennard scaling in the mid-2000s, the point at which shrinking transistors stopped automatically reducing their power density, means that efficiency gains must increasingly come from architecture rather than from process technology alone. The third part of the wager is what this book is mostly about. The tasks where event-driven, spiking systems show the clearest advantages are, as Mead predicted, those that involve reacting quickly to change in the physical world with limited power: tracking a fast-moving object, stabilising a flying platform, detecting a collision before it happens, recognising a gesture or a spoken keyword while drawing almost no current. These are not the tasks that dominate today's artificial intelligence industry, which is concerned mostly with large language models and image generation on servers, where dense computation and enormous batching suit conventional accelerators extremely well. They are the tasks of small machines that move. That observation sets the frame for everything that follows. A neuromorphic system is not a faster or cheaper general-purpose computer. It is a different bet about where the information is. It bets that information arrives sparsely, in time, as change, and that a machine which processes only change, at the moment it occurs, will be faster and more frugal than one which processes everything on a schedule. When that bet is right, as it often is for a drone dodging an obstacle or a robot catching a ball, the gains are large. When it is wrong, as it is for analysing a static photograph or generating text, the neuromorphic machine has no advantage and may be at a disadvantage. The next two chapters look at the first half of the machine, the sensor that makes the bet at the very first stage, and at what happens to the information it produces. CHAPTER 2 Pixels That Report Change An event camera looks like any other machine-vision camera: a small metal housing, a lens mount, a USB or MIPI connector. Point it at a person sitting still at a desk and display its output, and the screen stays almost blank. Ask the person to wave, and their hand appears as a crisp outline of bright and dark dots that trails the motion like a sparkler, while the motionless background stays empty. Tilt the camera, and the whole scene springs into view in outline, every edge of the desk and the window frame drawn in points, for exactly as long as the camera is moving. That behaviour follows from a single design decision made at the level of each pixel. A conventional image sensor asks every pixel the same question on the same schedule: how much light did you collect during the exposure? An event camera asks each pixel to answer a different question, continuously and independently: has the light you are seeing changed by more than a set fraction since the last time you spoke? When the answer becomes yes, and only then, the pixel sends a message. This chapter explains how that works in silicon, what the messages contain, what properties follow, and what goes wrong. Inside the pixel The classic event-camera pixel, descended directly from the design that Patrick Lichtsteiner, Christoph Posch and Tobi Delbruck published in the IEEE Journal of Solid-State Circuits in 2008, contains three stages. The first is a photoreceptor. Light falling on a photodiode produces a tiny current, proportional to the light intensity. Rather than integrating that current onto a capacitor for a fixed exposure time, as a conventional pixel does, the event-camera photoreceptor feeds it through a transistor operating in the subthreshold regime that Carver Mead had championed. Because the voltage across such a transistor depends on the logarithm of the current through it, the photoreceptor's output voltage tracks the logarithm of the light intensity, continuously, with no exposure window. A doubling of brightness produces the same voltage step whether the scene is a dim room or a sunlit car park. The second stage is a change detector. The pixel stores, on a small capacitor, the photoreceptor voltage at the moment it last reported an event: a reference level. A differencing amplifier continuously compares the current log-intensity with that stored reference. The output of this stage is, in effect, the change in log-intensity since the pixel last spoke. The third stage is a pair of comparators. One fires if the change has risen above a positive threshold, meaning the pixel has become sufficiently brighter. The other fires if it has fallen below a negative threshold, meaning the pixel has become sufficiently darker. When either fires, the pixel generates an event of the corresponding polarity, conventionally called ON for brightening and OFF for darkening, and the reference level is reset to the current value. The pixel then waits for the next sufficient change. A short refractory period after each event limits how fast any one pixel can fire. Because the comparison is made on the logarithm of intensity, the threshold corresponds to a fixed relative change in brightness: a contrast threshold. If the threshold is set so that an event fires for a change of roughly fifteen percent in brightness, then an edge that brightens a pixel from 100 to 115 units of light triggers one event, and an edge that brightens a pixel from 10,000 to 11,500 also triggers one event. Thresholds are programmable through bias settings and are commonly tuned somewhere between about ten and fifty percent, trading sensitivity against noise. The message itself is tiny. Each event consists of the pixel's coordinates, a timestamp, and a single polarity bit: in the notation used throughout the literature, a tuple of x, y, t and p. The timestamp is typically assigned with microsecond resolution as the event is read off the chip. The encoding on the wire varies between manufacturers. Prophesee's formats, for example, compress events by sending a time base occasionally and then only the low-order bits of time and position for subsequent events, so that the average cost per event can be a small number of bytes or less. The result is not an image but a stream: a list of where and when change occurred, in the order it occurred. Getting events off the chip requires machinery that ordinary sensors do not need. Pixels fire at unpredictable times and in unpredictable places, so the sensor cannot simply scan rows in sequence. Early designs used asynchronous arbiters, circuits that receive requests from firing pixels, grant them access to a shared output bus one at a time, and transmit each pixel's address. This is the address-event representation that Misha Mahowald and colleagues pioneered for communication between neuromorphic chips, applied to a sensor. Later high-resolution designs, including the stacked sensors described below, use hybrid schemes that scan for active rows or regions quickly and read out groups of events at once, trading some timing precision for much higher throughput. Either way, the readout is driven by activity: when nothing changes, almost nothing is transmitted. What follows from the design Four properties of event cameras follow almost directly from the pixel design, and between them they explain most of the applications in this book. The first is temporal resolution and latency. Because each pixel watches its own intensity continuously and fires as soon as its threshold is crossed, the delay between a change in the scene and an event leaving the chip can be very short. The 2008 sensor, whose title advertised its headline numbers, was "a 128x128 120 dB 15 µs latency asynchronous temporal contrast vision sensor". Fifteen microseconds is more than two thousand times shorter than the frame interval of a thirty-frame-per-second camera. The latency is not fixed, however. It depends on illumination, because the photoreceptor's bandwidth falls as the photocurrent falls: in dim light, the pixel responds more slowly and latencies can stretch to milliseconds. This is a point that datasheets state in small print and that practitioners learn quickly. The second property is dynamic range. Each pixel adapts independently, responding to relative changes in its own log-intensity, so there is no single global exposure setting to be wrong. A pixel looking at the sun and a pixel looking into a shadowed doorway can both report changes at the same moment. Event cameras routinely specify dynamic ranges of 120 decibels or more, a ratio of a million to one, compared with the 60 to 70 decibels typical of a single exposure from a conventional sensor. In practice this means event cameras keep working when a vehicle drives out of a tunnel into sunlight, or when a drone flies from a dark room towards a bright window. The third property is the absence of motion blur. Motion blur arises because a conventional pixel integrates light over an exposure window during which the scene moves. An event-camera pixel does not integrate over a window; it reports a threshold crossing at an instant. A fast-moving edge therefore produces a sharp, narrow trail of events whose timestamps record exactly when the edge crossed each pixel, rather than a smear. The fourth property is data efficiency, and here the claims need the most care. When the scene is mostly static and the camera is still, an event camera produces very little data: a trickle of noise events and responses to whatever is moving. When something small moves, it produces data in proportion to the edges of that moving thing. This is the regime in which event cameras deliver enormous savings over frame cameras, which keep reading out the static background at full rate. But when the camera itself moves rapidly through a richly textured scene, every edge in the field of view is crossing pixels, and the event rate can climb to tens or hundreds of millions of events per second. Sony and Prophesee's IMX636 sensor is specified for a peak readout rate of around a billion events per second. At such rates an event camera can produce more data than a conventional camera of the same resolution running at a modest frame rate. Event cameras do not guarantee less data. They guarantee data in proportion to change, which is a very good bargain when change is sparse and a much less good one when it is not. What goes wrong Every one of those advantages comes with a corresponding weakness, and anyone building a system around an event camera has to design for them. The most fundamental is that an event camera does not measure absolute brightness. A stationary camera looking at a stationary scene produces no signal at all, apart from noise, and a uniform surface moving across the field of view generates events only at its edges. For tasks that need to know what something looks like rather than how it moves, recognising a road sign, reading text, judging colour, the pure event stream is impoverished. Two families of sensor address this. The Asynchronous Time-based Image Sensor, or ATIS, described by Christoph Posch, Daniel Matolin and Rainer Wohlgenannt in 2011, adds to each change-detecting pixel a second circuit that, whenever a change event fires, measures the new absolute intensity by timing how long the photocurrent takes to charge a capacitor to a threshold. The Dynamic and Active-pixel Vision Sensor, or DAVIS, published by Christian Brandli, Raphael Berner, Minhao Yang, Shih-Chii Liu and Tobi Delbruck in 2014, takes a more pragmatic route: each pixel shares its photodiode between an event-generating circuit and a conventional active-pixel circuit, so that the same sensor can output an event stream and ordinary greyscale frames, aligned pixel for pixel. The second weakness is noise. Even in darkness, transistor leakage currents and the random arrival of photons cause pixels to fire occasionally, producing what the literature calls background activity: a sprinkling of spurious events across the array. In bright light this is mostly negligible. In dim light, where real signals are weaker and the photoreceptor is slower, it can dominate. Some pixels, because of manufacturing defects, fire far more often than others; these hot pixels are usually masked out. Simple filters that discard events with no supporting neighbour in space and time remove much of the background activity, at a small cost in latency and processing. The third weakness is mismatch. Because the threshold of each pixel is set by analogue circuitry, and no two sets of transistors are identical, the effective contrast threshold varies from pixel to pixel and drifts with temperature. Two pixels seeing exactly the same change may produce different numbers of events. Algorithms that assume a single known threshold, for example to reconstruct intensity by counting events, accumulate errors as a result. The fourth is flicker. Many artificial light sources, including fluorescent tubes and many LED fixtures, flicker at twice the mains frequency, 100 or 120 times per second, too fast for a human to notice but very visible to a sensor that responds to change. Under such lighting an event camera can fill with events from every surface lit by the flickering source, burying the motion of interest. Manufacturers have introduced on-chip anti-flicker filters that detect and suppress periodic activity in specified frequency bands, and the IMX636 includes such filtering. Flicker also turns into a useful signal in some applications, for instance identifying LED beacons by their blink frequency. The fifth is bandwidth saturation. When the event rate exceeds what the readout can handle, events queue, their timestamps become less accurate, and some may be dropped. During fast camera motion in a cluttered scene, exactly the situation in which a drone most needs its vision, the sensor can approach this limit. Designers respond by restricting the active region of interest, raising thresholds, or using on-chip event-rate controllers that discard events when the rate climbs too high, which protects latency at the cost of information. None of these weaknesses is fatal, and several of them have conventional-camera counterparts: conventional sensors also have noise, fixed-pattern variation and flicker problems. But they mean that an event camera is not a drop-in replacement for an ordinary camera with better specifications. It is a different instrument, with a different failure profile, and it rewards systems designed around it. From laboratory chip to stacked sensor The path from Lichtsteiner, Posch and Delbruck's sensor to today's commercial devices runs through a handful of landmark designs, set out in Table 1. The trend is clear: pixel pitch has shrunk by nearly a factor of ten, resolution has risen from about sixteen thousand pixels to around a million, and the technology has moved from university clean rooms into the production lines of the world's largest image-sensor manufacturer. Table 1. Landmark event-based vision sensors. Sensor Year Resolution Pixel pitch Notable feature DVS128 2008 128 x 128 40 µm First practical DVS ATIS 2011 304 x 240 30 µm Adds absolute intensity DAVIS240 2014 240 x 180 18.5 µm Events plus frames Samsung DVS 2020 1280 x 960 4.95 µm Megapixel-class array Sony IMX636 2021 1280 x 720 4.86 µm Stacked; over 120 dB Source: Lichtsteiner, Posch and Delbruck (2008); Posch, Matolin and Wohlgenannt (2011); Brandli and colleagues (2014); Suh and colleagues (2020); Finateu and colleagues (2020) and Prophesee IMX636 documentation. Years are publication dates; the IMX636 product followed its 2020 conference paper. The decisive engineering step in the most recent generation was stacking. A conventional event-camera pixel is crowded: the photodiode has to share space with the photoreceptor, differencing amplifier, comparators and communication logic, so only a small fraction of the pixel area collects light. In the Sony–Prophesee design, described by Thomas Finateu and colleagues at the 2020 International Solid-State Circuits Conference, the photodiodes sit on one silicon wafer, illuminated from the back, and the change-detection and readout circuitry sits on a second wafer bonded beneath it, with connections at each pixel. This allowed a pixel 4.86 micrometres across, comparable to ordinary machine-vision sensors, with much better light collection than earlier event pixels. Sony released the IMX636 and its smaller sibling the IMX637 in 2021. Prophesee's documentation lists typical power consumption for the IMX636 of 50 to 70 milliwatts, a peak below 100 milliwatts, and operation from minus 40 to plus 85 degrees Celsius, the kind of numbers that place it alongside conventional industrial sensors rather than research curiosities. Samsung's work, from its 640-by-480-pixel sensor presented by Bongki Son and colleagues in 2017 to the 1280-by-960-pixel design described by Yunjae Suh and colleagues in 2020, showed that a second major semiconductor company considered the technology worth developing, though Samsung's sensors have been less visible in the open research market than Sony's. Other manufacturers have contributed further designs, including the Chinese company CelePixel and the Zurich spin-off iniVation, founded by Delbruck's group to commercialise the DAVIS family. At the low-power end, Prophesee introduced in 2023 a 320-by-320-pixel sensor, the GenX320, aimed at battery-powered and wearable devices such as eye-tracking for augmented-reality glasses, where a small array and very low standby power matter more than resolution. The commercial ecosystem has grown more slowly than the sensor technology. Industrial camera makers, including IDS and Lucid Vision Labs, have offered event-camera models built on the Sony sensors, and Prophesee has supplied evaluation kits and an extensive software development kit. In 2023 Prophesee announced a collaboration with Qualcomm to bring event sensing to Snapdragon mobile platforms, with the aim of using event data to deblur photographs taken by conventional phone cameras. Applications in industry have tended to cluster where the sensor's unique properties are decisive and conventional alternatives are clumsy: monitoring vibration in machinery by watching the motion of edges at microsecond resolution, counting and sizing fast-moving particles, tracking objects on high-speed production lines, and observing satellites and space debris against a dark sky, a use pursued by researchers at Western Sydney University among others. Prices for event cameras remain far higher than for conventional sensors of similar resolution, reflecting small production volumes rather than any intrinsic cost of the technology, and the companies involved have had to navigate a market that has been slower to arrive than early enthusiasm suggested. Choosing to use one The sensor alone does not settle whether a system should use events. A designer weighing an event camera against a conventional alternative should be honest about what the competition offers. Global-shutter sensors eliminate the rolling-shutter distortion that plagues fast motion in cheap cameras. High-frame-rate sensors running at several hundred frames per second, with short exposures, reduce blur and latency considerably, at the cost of light sensitivity and data rate. Multi-exposure HDR sensors widen dynamic range. A good conventional camera paired with a good inertial measurement unit can handle a great deal of fast motion. The event camera's case is strongest when several of its advantages are needed at once: high temporal resolution and high dynamic range and low data rates in sparse scenes and low power. A drone flying in mixed lighting that must react within a few milliseconds to a small moving obstacle needs all of these. A smartphone photographing a still life needs none of them. Most real applications lie somewhere in between, and in many of them the best design, as later chapters will show, combines an event camera with a conventional one rather than replacing it. What the event camera unambiguously provides is a different kind of data. Instead of a sequence of snapshots, it delivers a stream of timestamped changes, sparse in space and time, with timing precision measured in microseconds. That stream is, in form, very close to the spike trains that neurons exchange. The question the rest of the pipeline must answer is whether to respect that form, processing events as events, or to convert it into something more familiar. That choice is the subject of the next chapter, and it turns out to decide most of what is gained or lost. CHAPTER 3 Making Sense of Events A conventional computer-vision engineer handed an event camera for the first time usually does the same thing within the hour. They collect the events that arrive over, say, ten milliseconds, plot them as white and black dots on a grey canvas, and look at the result. It looks like a pencil sketch of the moving parts of the scene. Then they feed a stack of such sketches into a convolutional neural network borrowed from ordinary image processing, and it works, more or less. The temptation to stop there is strong, and much of the published work on event-based vision has not resisted it. This chapter is about the alternatives, and about why the choice between them matters so much. An event stream can be processed event by event, as a continuous flow of timestamped changes; it can be processed in small groups that preserve timing information; or it can be packed into frames and handed to conventional methods. Each choice gives up something. Understanding what is given up, and where in the system the loss falls, is the most practical skill a designer of event-based systems can have. Representing a stream Guillermo Gallego and a large group of co-authors, including Tobi Delbruck, Davide Scaramuzza and many of the field's leading researchers, published a survey titled "Event-based Vision: A Survey" in IEEE Transactions on Pattern Analysis and Machine Intelligence in 2022, having circulated it from 2019. It remains the standard reference, and it organises event-processing methods partly by the representation they operate on. The main families are worth knowing, because nearly every system uses one of them. At one extreme is processing individual events. Each event, as it arrives, updates some state: a filter estimate, a tracked feature, the membrane potential of a spiking neuron. Nothing waits for anything else. This is the purest expression of the sensor's character, it preserves the full timing precision, and it gives the lowest possible latency. Its difficulty is that a single event carries very little information, one bit of polarity at one place and time, so useful processing requires either a carefully maintained state that accumulates evidence across events or a network of many simple units, which is exactly what a spiking neural network provides. Next come event packets or point sets. A batch of events from a short window is treated as a set of points in a three-dimensional space whose axes are x, y and time. Methods borrowed from 3D point-cloud processing, or graph neural networks that connect nearby events, can operate on this set without discarding timing. Graph-based approaches, such as the asynchronous graph networks developed by Simon Schaefer, Daniel Gehrig and Davide Scaramuzza and presented in 2022, can even update their outputs incrementally as each new event arrives, recomputing only the parts of the graph that the event touches. A third family uses time surfaces. A time surface is a two-dimensional map that records, at each pixel, the timestamp of the most recent event there, often passed through an exponential decay so that recent events appear bright and older ones fade. Xavier Lagorce, Garrick Orchard, Ryad Benosman and colleagues built a hierarchical recognition model on this idea, called HOTS, published in 2017. A time surface is a compact summary of recent motion that preserves the order and approximate age of events while presenting them in an image-like layout. A fourth family uses voxel grids. The time window is divided into a small number of bins, and each event's polarity is distributed between the two nearest bins in proportion to its exact timestamp, producing a stack of two-dimensional slices that a convolutional network can digest. Alex Zihao Zhu and colleagues used such grids for unsupervised learning of optical flow and ego-motion in 2019, and they have become a common input format for learned methods because they retain more temporal detail than a single accumulated frame. At the other extreme are event frames: images formed by counting events, or summing polarities, at each pixel over a fixed window. They are trivial to compute and compatible with any image-processing method, and they throw away almost all timing information within the window. Daniel Gehrig, Antonio Loquercio, Konstantinos Derpanis and Davide Scaramuzza showed in 2019 that the conversion step need not be hand-designed: a small network can learn the best way to turn raw events into a grid, trained end to end with whatever task follows. Their experiments found that richer representations, preserving more of the timing, consistently beat simple event counts on recognition and flow tasks. That result points in a useful direction. The information in the timing is real and measurable, and every representation that collapses it pays for doing so in accuracy as well as in latency. Geometry straight from the stream Some of the most elegant event-based methods do not use neural networks at all. They exploit a simple geometric fact: when an edge moves across the image, the events it generates do not land randomly in space and time. They trace out a surface in the three-dimensional space of x, y and t. An edge moving at constant velocity sweeps out a tilted plane, and the tilt of that plane encodes the edge's speed and direction. Ryad Benosman and colleagues used exactly this idea in 2014 to compute event-based optical flow: for each new event, fit a small plane to recent neighbouring events in space-time and read the local velocity from its slope. The computation is local, cheap and updated with each event. A more general and powerful idea is contrast maximisation, set out by Guillermo Gallego, Henri Rebecq and Davide Scaramuzza at the 2018 Conference on Computer Vision and Pattern Recognition. Suppose a set of events was generated by edges moving according to some motion model, a rotation of the camera, say, or a translation of an object. If you knew the true motion, you could warp every event back along its trajectory to a single reference time, and all the events generated by the same edge would pile up on the same pixels, producing a sharp image of edges. If you guess the motion wrong, the warped events spread out and the image is blurred. So you can estimate the motion by searching for the warp that makes the image of warped events as sharp as possible, as measured by its contrast. This one principle, the authors showed, unifies methods for estimating rotation, optical flow, depth and the motion of independently moving objects. It turns the absence of motion blur from a sensor property into an estimation tool. The same geometric reasoning underpins event-based visual odometry and simultaneous localisation and mapping, the problem of estimating a camera's motion while building a map of its surroundings. Hanme Kim, Stefan Leutenegger and Andrew Davison demonstrated real-time three-dimensional reconstruction and six-degree-of-freedom tracking with a single event camera in 2016. Henri Rebecq and colleagues at Zurich presented EVO, an event-based visual odometry pipeline, in 2017. In 2018 Antoni Rosinol Vidal, Henri Rebecq, Timo Horstschaefer and Davide Scaramuzza published a paper whose title asked "Ultimate SLAM?", combining events, standard frames and inertial measurements. They reported that the combination was markedly more accurate than frame-and-inertial systems alone in high-speed and high-dynamic-range scenarios, and they demonstrated it running on board a quadrotor. The practical lesson of that work recurs throughout the field: events, frames and inertial sensors fail in different circumstances, so a system that fuses them is more robust than one that relies on any single modality. Underneath odometry and mapping sits a more basic operation: finding distinctive points in the image and following them over time. Conventional pipelines detect corners in each frame and match them between frames. Event-based pipelines can detect corners directly in the stream. Elias Mueggler, Chiara Bartolozzi and Davide Scaramuzza presented in 2017 a corner detector that operates on the time surface around each incoming event, testing whether the most recent timestamps around the pixel form the pattern a moving corner would produce, and running fast enough to keep up with the sensor's output. Tracking can then proceed event by event, updating each feature's position as new events arrive near it. Daniel Gehrig, Henri Rebecq, Guillermo Gallego and Davide Scaramuzza's EKLT tracker, published in the International Journal of Computer Vision in 2020, combined the two sensor types elegantly: it extracted features and their appearance from conventional frames and then tracked them between frames using events, predicting what pattern of events each feature's appearance should produce as it moved and adjusting the feature's estimated motion until prediction matched observation. Feature tracks produced this way stay accurate between frames, at rates far above the frame rate, which is exactly what fast motion estimation needs. These geometric methods share a property that is easy to overlook. They are cheap. A plane fit, a time-surface test or an incremental feature update involves a handful of arithmetic operations per event, and the total work scales with the number of events, not with the number of pixels. For a robot or drone whose processor has to do many other things, a geometric event pipeline that uses a few percent of a small CPU can be more valuable than a learned pipeline that is somewhat more accurate but needs a dedicated accelerator. Learning from events The rise of deep learning in conventional vision created a strong pull for event-based vision to follow. The obstacle at first was data. Deep networks need large labelled datasets, and event cameras were rare and their outputs unfamiliar. Early event datasets were often made by pointing an event camera at a screen displaying an existing image dataset while moving the camera or the image slightly. The N-MNIST and N-Caltech101 datasets, released by Garrick Orchard and colleagues in 2015, were produced this way, using a camera mounted on a pan-tilt unit making small saccade-like movements in front of a monitor. These datasets were useful for benchmarking spiking networks, but they had a serious weakness: the motion was artificial and identical across samples, so a classifier could succeed without learning anything about the real dynamics of event data. The DVS Gesture dataset, recorded by Arnon Amir and colleagues at IBM and presented in 2017 alongside a gesture-recognition system running on the TrueNorth chip, was more natural: twenty-nine people performing eleven hand and arm gestures under different lighting conditions, recorded directly with an event camera. For robotics and driving, larger real-world datasets followed. The Multi Vehicle Stereo Event Camera dataset, MVSEC, released by Alex Zihao Zhu and colleagues in 2018, combined stereo event cameras with lidar, inertial sensors and motion capture on drones, cars and a motorbike. DSEC, from Mathias Gehrig and colleagues in 2021, provided stereo event data and stereo conventional images for driving in difficult lighting. Prophesee released large automotive detection datasets, including one recorded with a one-megapixel sensor and labelled with millions of bounding boxes, described by Etienne Perot and colleagues at the 2020 NeurIPS conference. With data in hand, learned methods quickly produced impressive results. Zhu and colleagues' EV-FlowNet, in 2018, learned optical flow from events with self-supervision, using the conventional frames recorded alongside events to provide a training signal without manual labels. Henri Rebecq, René Ranftl, Vladlen Koltun and Davide Scaramuzza's E2VID, presented in 2019, trained a recurrent network to reconstruct ordinary video from events alone. Its outputs were striking: sharp, high-dynamic-range video, at frame rates of thousands per second if desired, from a sensor that records no absolute brightness. A practical consequence was that off-the-shelf image-recognition networks could be run on the reconstructed video. That is useful, and it is also a warning sign, because it means the pipeline has turned the event stream back into frames. The frame temptation Converting events into frames, whether event-count images, voxel grids or reconstructed video, and then running conventional deep networks on them has real advantages. It gives access to the entire toolbox of modern computer vision: pre-trained models, mature training software, efficient GPU and NPU implementations. It often gives the best accuracy on benchmarks. For many tasks it is the right engineering choice. But it is worth being precise about what it costs, because the costs fall on exactly the properties that made the event camera attractive. The first cost is latency. A frame built from a ten-millisecond window cannot be processed until the window closes, so the system's response to a change at the start of the window is delayed by up to ten milliseconds plus the network's processing time. The microsecond latency of the sensor has been converted into a frame rate. If the network takes twenty milliseconds to run on an embedded processor, the effective latency is no better than that of a fifty-frame-per-second conventional camera. The second cost is sparsity. An event frame is mostly empty pixels, but a standard convolutional network does not know that. It performs the same multiply-accumulate operations at every location, whether there were events there or not. All the computational savings that event sparsity could have offered are thrown away at the moment of conversion. Nico Messikommer, Daniel Gehrig, Antonio Loquercio and Davide Scaramuzza addressed this at the 2020 European Conference on Computer Vision with asynchronous sparse convolutional networks, which perform convolution only at active sites and update their outputs incrementally as new events arrive. They reported large reductions in computation compared with dense processing of the same inputs. The idea is sound, but sparse computation is poorly supported by GPUs, which are designed for dense, regular work, so the theoretical savings do not always translate into wall-clock speed on conventional hardware. The third cost is temporal precision. Within each window, the order and timing of events is either discarded or quantised into a few bins. For tasks such as tracking a fast object or estimating the time to contact with an approaching surface, that fine timing is precisely the information needed. A simple calculation shows how large the gap can be. Consider a convolutional layer with 32 input channels, 32 output channels and three-by-three kernels, applied to a 320-by-320 input. Run densely, it performs about 320 × 320 × 32 × 32 × 9 multiply-accumulates, roughly 944 million. If only two percent of input locations contain events in a given window, a sparse implementation that computes only at active locations and their immediate neighbours might need a few percent of that, tens of millions of operations rather than nearly a billion. Over a deep network, and on hardware that can actually skip the inactive work, the savings compound. On hardware that cannot, they vanish. That last clause is the bridge to the second half of the book. The way an event stream is represented is constrained by the hardware it will run on. Dense frames suit GPUs. Sparse, asynchronous, stateful processing suits hardware designed for it, which conventional processors are not. The most natural way to process a stream of discrete, timestamped events, without accumulating them into frames, is a network of units that themselves receive discrete, timestamped inputs, maintain a state that evolves in time, and emit discrete outputs only when that state crosses a threshold. That is the definition of a spiking neural network. Before turning to such networks, it is worth noting the most influential compromise in recent years, which is to keep the frame camera and the event camera both, and to divide the work between them. Daniel Gehrig and Davide Scaramuzza, writing in Nature in 2024, described a hybrid object detector for cars that runs a conventional convolutional network on a 20-frame-per-second colour camera and uses an event camera, processed by an efficient asynchronous graph neural network, to update detections between frames. They reported that the hybrid system matched the latency of a 5,000-frame-per-second camera while using the bandwidth of a 45-frame-per-second camera, without compromising accuracy. That result, discussed further in Chapter 8, captures the pragmatic state of the art. The frame camera supplies rich appearance at low rate; the event camera supplies change at high rate; and the computation on the event side is designed to stay sparse rather than to imitate a frame pipeline. The guiding principle that emerges from a decade of event-based vision research is not that frames are bad, but that every conversion from events to frames should be a deliberate choice with a known cost. A designer who accumulates events into frames should be able to say what latency and sparsity that costs, and why the application can afford it. A designer who wants the full benefit of the sensor needs a computational substrate that can consume events as events. The next chapter describes that substrate. CHAPTER 4 Neurons That Compute in Time The artificial neuron at the heart of modern deep learning is a static function. It receives a list of numbers, multiplies each by a weight, adds them up, passes the sum through a simple nonlinearity, and outputs another number. It has no memory of what it received a moment ago and no notion of when its inputs arrived. Time, in a conventional network, exists only if the designer builds it in from outside, by feeding in sequences and adding recurrent connections. A spiking neuron is a different kind of object. It has an internal state that evolves continuously in time. It receives inputs as discrete pulses arriving at particular moments. It outputs a pulse only when its state crosses a threshold, and it is otherwise silent. In 1997 Wolfgang Maass, in a paper in Neural Networks titled "Networks of spiking neurons: the third generation of neural network models", argued that such networks were computationally at least as powerful as the threshold and sigmoidal networks that preceded them, and that for some functions they needed fewer units. The theoretical point mattered less, in the end, than the practical one. Spiking networks are a natural fit for event data and for hardware in which computation happens only when something arrives. This chapter explains how they work, how information is encoded in them, and how the field solved the problem that held them back for two decades: training them. The leaky integrate-and-fire neuron Most engineering work with spiking networks uses a model whose essentials were proposed by the French physiologist Louis Lapicque in 1907, long before anyone knew how neurons generated their electrical pulses. In its modern form, the leaky integrate-and-fire neuron, usually abbreviated LIF, has one main state variable: its membrane potential, a number standing for the voltage across a real neuron's membrane. Three rules govern it. First, integration: when a spike arrives at one of the neuron's input synapses, the membrane potential jumps by an amount equal to that synapse's weight. Positive weights push the potential up, negative weights, representing inhibitory connections, push it down. Second, leak: in the absence of input, the membrane potential decays exponentially back towards a resting value, with a characteristic time constant, often a few to a few tens of milliseconds. Third, fire and reset: if the potential reaches a threshold, the neuron emits a spike, which is delivered to every neuron it connects to, and its potential is reset, either to the resting value or by subtracting the threshold. A worked example makes the behaviour concrete. Take a neuron with a threshold of 1.0, a resting potential of zero and a leak time constant of 20 milliseconds, which means that its potential loses about 63 percent of its value every 20 milliseconds when no input arrives. It has an input synapse with weight 0.4. If three input spikes arrive one millisecond apart, the potential climbs to about 0.4, then roughly 0.78, then roughly 1.14, crossing the threshold on the third spike: the neuron fires and resets. If the same three spikes arrive 40 milliseconds apart instead, the potential climbs to 0.4, decays to about 0.05 before the next spike arrives, climbs to 0.45, decays again, and never comes near the threshold. The neuron does not fire. The same inputs, with different timing, produce different outputs. A LIF neuron is a detector of coincidence: it responds to inputs that arrive close together in time and ignores those that are spread out. This sensitivity to timing is exactly what a static artificial neuron lacks, and it is what makes spiking networks suited to processing streams such as events from a camera. Many refinements exist. A more detailed variant gives each synapse its own decaying current, so that an input spike produces a smooth rise and fall in the membrane potential rather than an instantaneous jump. Adaptive LIF neurons raise their own threshold each time they fire and let it relax slowly, which allows them to hold information for hundreds of milliseconds or more; Guillaume Bellec, Wolfgang Maass and colleagues showed in 2018 that networks of such neurons could match the performance of LSTM networks on some sequence tasks. At the other end of the spectrum, Eugene Izhikevich's 2003 model reproduces a wide repertoire of biological firing patterns with only two state variables, and Alan Hodgkin and Andrew Huxley's 1952 equations, derived from the squid giant axon and awarded a Nobel Prize in 1963, model the ion channels themselves. For hardware and engineering, the LIF neuron and its close relatives dominate because they are cheap to compute: one multiply for the decay, an addition for each incoming spike, and a comparison. That last point is the computational heart of the matter. In a conventional network, each connection performs a multiply-accumulate on every input, every time the network runs. In a spiking network, a connection does work only when a spike travels along it, and the work is an addition of the weight to the target's potential, not a multiplication, because a spike carries no magnitude beyond its presence. If only a small fraction of neurons spike in each time step, then only a small fraction of connections do any work. Spiking networks inherit their efficiency from the same source as the brain: not from cheap operations, though their operations are cheap, but from doing few of them. How spikes carry information A spike is binary: it happens or it does not. So how does a network of spiking neurons represent a quantity like the speed of a moving edge or the probability that an image contains a pedestrian? Neuroscience offers several answers, and engineering has adopted most of them. The simplest is rate coding. A quantity is represented by how many spikes a neuron fires in a window of time: a high value, many spikes; a low value, few. Rate coding is robust and easy to reason about, and it was the basis of most early methods for building spiking networks from conventional ones. Its weakness is that it is slow and expensive. To represent a value with ten levels of precision, a neuron must be given time to fire up to ten spikes, and every spike costs energy. A network that encodes everything as firing rates can easily end up spiking more, and spending more energy, than the dense network it replaced. Temporal codes use the timing of spikes rather than their number. In time-to-first-spike coding, a stronger input causes a neuron to fire earlier, so that a single spike per neuron can carry a graded value. Simon Thorpe and colleagues argued in the 1990s that the speed of human visual recognition, with responses to complex images in as little as 150 milliseconds, left time for only one or two spikes per neuron at each processing stage, and proposed that the order in which neurons fire, a rank-order code, carries the information. Temporal codes can be extremely sparse, but they are sensitive to timing noise and harder to train. Delta or change coding is the scheme most natural for event cameras. A neuron spikes when its input has changed by more than a threshold since its last spike, exactly as an event-camera pixel does. If the input is constant, the neuron is silent; if it changes, the neuron reports the change. A network built from such units does work in proportion to how much its inputs are changing, which for video of a mostly static scene can be very little. Intel's Loihi 2 chip supports a variant of this idea, the sigma-delta neuron, in which units transmit changes in their activation as "graded spikes" carrying a small integer value rather than a single bit. This sacrifices some of the purity of binary spiking in exchange for representing values precisely without many spikes. Population codes spread a value across many neurons, each tuned to a different part of the range, so that the pattern of activity across the population represents the value. This is how the brain appears to represent many quantities, such as the direction of a planned arm movement, and it is robust to the failure or noise of individual neurons. In practice, engineered spiking networks mix these schemes. The input layer may receive events from a camera, which are already a delta code. Hidden layers may use sparse temporal patterns that emerged during training rather than any scheme a designer chose. The output may be read as a spike count or as the membrane potential of non-spiking output neurons. What matters for efficiency is the total number of spikes the network produces to reach a decision, and a large part of modern training practice consists of finding ways to keep that number low. The training problem For most of the 2000s and early 2010s, spiking networks lagged far behind conventional deep networks in accuracy, and the reason was training. Deep learning rests on backpropagation: computing, for every weight, how a small change in that weight would change the network's error, and nudging each weight in the direction that reduces it. Backpropagation requires that each neuron's output be a differentiable function of its inputs. A spiking neuron's output is not. Its spike is an all-or-nothing event triggered by a threshold, and the derivative of a step function is zero everywhere except at the step itself, where it is infinite. Feed that into backpropagation and the gradients are either zero, so nothing learns, or undefined. A second problem is time. Because spiking neurons carry state, the network's output at any moment depends on its whole input history. Training must account for how a weight change now affects outputs many time steps later, which means backpropagating through time, as is done for recurrent networks, with memory costs that grow with the length of the sequence. The field found four broad ways around these problems, compared in Table 2. They are not mutually exclusive, and practical systems often combine them. Table 2. Principal approaches to training spiking neural networks. Approach Core idea Strengths Weaknesses ANN-to-SNN conversion Train a conventional network, then map its activations to spike rates Reuses mature deep-learning tools; high accuracy on static tasks Needs many time steps; rate codes spike heavily; ignores timing Surrogate-gradient training Replace the spike's derivative with a smooth stand-in during backpropagation through time Trains directly for sparse, temporal behaviour; works with standard frameworks Memory-hungry on long sequences; training happens off-chip Local plasticity rules Adjust each synapse from locally available signals such as spike timing Can learn on the chip, online, with little energy Usually less accurate on complex tasks; hard to scale Evolutionary and other black-box search Mutate and select networks or parameters by their performance No gradients needed; can optimise whole closed-loop behaviour Expensive; practical mainly for small networks or single layers Source: compiled from the methods literature cited in the Notes for this chapter. Conversion was the first approach to reach competitive accuracy on standard image benchmarks. Yongqiang Cao, Yang Chen and Deepak Khosla showed in 2015 how to convert a trained convolutional network into a spiking one; Peter Diehl and colleagues the same year introduced normalisation of weights to keep firing rates in range; and Bodo Rueckauer, Iulia-Alexandra Lungu, Yuhuang Hu, Michael Pfeiffer and Shih-Chii Liu in 2017 extended conversion to modern architectures with batch normalisation and max-pooling. The idea is simple: in a network whose nonlinearity is a rectified linear unit, a neuron's activation is approximately proportional to the firing rate of a corresponding integrate-and-fire neuron driven by the same input. Converted networks can approach the accuracy of their originals, but only if run for enough time steps to let firing rates settle, often tens to hundreds of steps per input. They also inherit the dense computation of the original network spread across time rather than eliminated. Conversion is the route by which most early "spiking" benchmark results were produced, and much of the scepticism about spiking networks' efficiency arose from examining converted networks, which frequently spent more energy than the conventional networks they came from. Surrogate gradients changed the field. The trick, set out clearly in a 2019 tutorial article in IEEE Signal Processing Magazine by Emre Neftci, Hesham Mostafa and Friedemann Zenke, is to keep the true step-function spike in the forward pass, so that the network really does spike, but to substitute a smooth, bump-shaped function for its derivative during the backward pass. The surrogate tells the learning algorithm, roughly, "if this neuron's potential had been a little closer to threshold, it would have been a little more likely to spike." That is enough for gradient descent to make progress. Zenke and Surya Ganguli's SuperSpike, Sumit Bam Shrestha and Garrick Orchard's SLAYER, both published in 2018, and many later variants developed the idea. Because surrogate-gradient training treats a spiking network as a particular kind of recurrent network, it can be implemented in standard deep-learning frameworks. Open-source libraries such as snnTorch, described by Jason Eshraghian and colleagues in a 2023 Proceedings of the IEEE article, SpikingJelly, from Wei Fang and colleagues at Peking University, and Norse, from researchers in Heidelberg and Stockholm, made the technique accessible to anyone familiar with PyTorch. Crucially, surrogate-gradient training can include the number of spikes in the loss function, explicitly rewarding the network for reaching the right answer with few spikes. It trains networks to be sparse in time, which conversion cannot do. Local plasticity takes inspiration more directly from biology. In spike-timing-dependent plasticity, documented experimentally by Guo-qiang Bi and Mu-ming Poo in 1998, a synapse strengthens if the input neuron tends to fire just before the output neuron, and weakens if it fires just after. Such rules are local, requiring only information available at the synapse, so they can run on the chip during operation. Peter Diehl and Matthew Cook showed in 2015 that a network trained with spike-timing-dependent plasticity, with no labels during learning, could classify handwritten digits with about 95 percent accuracy. Local rules have so far struggled to match gradient-based training on complex tasks, but they matter for on-device adaptation. Guillaume Bellec and colleagues' e-prop, published in Nature Communications in 2020, approximates the gradients of backpropagation through time with quantities that can be computed locally and forward in time, pointing towards learning rules that are both effective and implementable on neuromorphic hardware. Evolutionary and black-box methods optimise networks by trial and error rather than by gradients. They scale poorly to large networks, but they have one decisive advantage for robotics: they can optimise a controller for its actual behaviour in a closed loop, including the dynamics of the robot and its environment, without needing those dynamics to be differentiable. The Delft drone described in Chapter 7 used evolution to train the final control layer of its spiking network in simulation. What spiking networks are and are not After a decade of progress in training, it is possible to state fairly what spiking networks offer. They are not more accurate than conventional networks. On static image classification, the best spiking networks now come close to conventional networks of similar size, but they do not surpass them, and for many tasks a conventional network trained with the same effort will be slightly better. They are not automatically efficient. A spiking network that fires densely, or that needs hundreds of time steps per decision, can cost more energy than a conventional network, especially on hardware not designed to exploit its sparsity. The energy advantage depends on low activity, on hardware that skips inactive work, and on inputs that are themselves sparse. What they are is a natural computational model for temporal, streaming, sparse data. A spiking network's state carries memory of recent inputs without explicit recurrence, its neurons respond to coincidences and changes, and its activity, if trained to be sparse, tracks how much is happening in the input. Fed by an event camera, it can process each event as it arrives, maintain an estimate of motion or of an object's position that is continuously updated, and emit output spikes, and thus control signals, at the moment evidence crosses a threshold rather than at the next tick of a clock. There is also a strong case for hybrid designs. Many effective systems use spiking or event-driven layers where the data is sparse and temporal, near the sensor, and conventional dense layers where the representation has become compact and the computation regular. Loihi 2's graded spikes, sigma-delta networks and the recurrent state-space models now being run on neuromorphic hardware all blur the line between spiking and conventional computation. The useful distinction in 2026 is less between "spiking" and "non-spiking" than between computation that is driven by events and sparse in time, and computation that is clocked and dense. A network of the first kind needs hardware built to match it, and that hardware is the subject of the next chapter. CHAPTER 5 Silicon Brains A spiking neural network can run on any computer. Researchers simulate them on laptops and GPUs every day, and much of the training described in the previous chapter happens on conventional hardware. But running a spiking network on a GPU is like running a postal service by sending every letter carrier down every street every hour, whether or not they have mail to deliver. The GPU is built for dense, synchronous arithmetic. It processes every neuron at every time step, checks every potential against its threshold, and handles the resulting sparse, irregular spike traffic awkwardly. The efficiency that spiking networks promise can only be realised on hardware that, like the event camera, does work only when something happens. Neuromorphic processors are that hardware. This chapter describes the main designs, what they share, how they differ, and what each was built to do. The field has two broad lineages, one aiming to simulate brains for neuroscience and one aiming to run efficient computation for applications, and a third, commercial lineage that has emerged more recently, aimed at tiny, always-on devices at the edge. Common principles Despite large differences in implementation, nearly every neuromorphic processor shares a handful of architectural choices. The first is many small cores with local memory. Instead of a few powerful processors sharing a large external memory, the chip is divided into dozens to hundreds of cores, each holding the state of its neurons and the weights of their synapses in its own on-chip SRAM. When a spike arrives at a core, the weights it needs are already there. There is no trip to DRAM, which, as Chapter 1 showed, is where most of the energy in conventional neural network inference goes. The price is capacity: on-chip SRAM is expensive in area, so the size of network a chip can hold is limited, and large networks must be spread across many chips. The second is communication by spike packets. Cores exchange spikes over a network-on-chip, a mesh of routers that carries small packets from core to core, each packet identifying the neuron that fired. This is the address-event representation, the same scheme event cameras use, carried inside the chip and across chip boundaries. A spike sent to a thousand target neurons on different cores does not need a thousand wires; the routers deliver copies to the cores that need them, and each core looks up which of its neurons connect to the source and with what weights. The third is event-driven activity. Cores that receive no spikes do little or no work. In digital designs this is achieved with asynchronous logic, which has no global clock and in which circuits switch only when their inputs change, or with aggressive gating of clocked logic. In analogue designs it follows from the physics: a circuit with no input current draws almost no power. The fourth, often overlooked by newcomers, is time-multiplexing. A digital neuromorphic core does not contain one physical circuit per neuron. It contains a small amount of processing logic that updates many neurons in turn, reading each neuron's state from memory, updating it, and writing it back. A core that "has" a thousand neurons is really a tiny specialised processor that keeps a thousand neurons' worth of state and updates them as spikes arrive. This is far more area-efficient than dedicating circuitry to each neuron, and it means that the neuron count of a digital neuromorphic chip is a statement about memory capacity, not about parallel hardware. The fifth, in many designs, is on-chip learning: circuitry that can update synaptic weights during operation according to programmable local rules, so that the network can adapt without returning to a host computer for retraining. The research chips Table 3 sets out the major neuromorphic processors in use or under active development, and the following paragraphs describe what distinguishes them. Table 3. Major neuromorphic processors and systems. System (developer, year) Design Scale Distinctive trait TrueNorth (IBM, 2014) Digital, 28 nm 1M neurons per chip Very low power; no on-chip learning SpiNNaker (Manchester, 2018) ARM cores, software neurons About 1M cores Real-time brain simulation Loihi (Intel, 2018) Digital async, 14 nm About 130k neurons per chip Programmable on-chip learning Loihi 2 (Intel, 2021); Hala Point (2024) Digital async, Intel 4 1M neurons per chip; 1.15B in Hala Point Programmable neurons; graded spikes BrainScaleS-2 (Heidelberg, 2022) Analogue, digital control 512 neurons per chip 1,000 times faster than biology SpiNNaker2 / SpiNNcloud (TU Dresden, 2025) 152 ARM cores per chip, 22 nm 35,000 chips, 5M+ cores Mixes spiking and conventional nets Source: Merolla and colleagues (2014); Furber and colleagues (2014); Davies and colleagues (2018, 2021); Intel (2024); Pehle and colleagues (2022); TU Dresden (2025). TrueNorth, from IBM's Almaden research centre under Dharmendra Modha and published by Paul Merolla and colleagues in Science in 2014, was the first neuromorphic chip to reach a million neurons. Its 4,096 cores, built from 5.4 billion transistors in a 28-nanometre Samsung process, each implemented 256 neurons with a crossbar of 256 by 256 binary synapses. Operating on real-time video, the chip drew power on the order of 70 milliwatts, an extraordinary figure for its size at the time. TrueNorth's design made strong simplifying choices: a fixed neuron model, low-precision synaptic weights, and no learning on the chip. Networks had to be trained elsewhere and then mapped onto its constraints. It was used for gesture recognition with event cameras in the DVS Gesture work described in Chapter 3, and for a range of defence and research applications. IBM did not develop it into a product line. Its successor, NorthPole, published in Science in 2023, abandoned spikes entirely: it is a digital inference accelerator with 22 billion transistors and 256 cores, which keeps TrueNorth's principle of putting all memory on the chip next to the arithmetic but runs conventional low-precision neural networks. IBM reported that on the ResNet-50 image benchmark it was about 25 times more energy efficient, in frames per joule, than common GPUs on a comparable process node. NorthPole is a telling development. It suggests that, for conventional dense networks, the biggest gains from brain-inspired design come from co-locating memory and computation rather than from spiking as such. SpiNNaker, the Spiking Neural Network Architecture led by Steve Furber at the University of Manchester, took the opposite approach. Rather than build fixed neuron circuits, SpiNNaker uses large numbers of small, low-power ARM processor cores, eighteen per chip, each running neuron models in software, connected by a custom packet-switching network optimised for delivering huge numbers of tiny spike messages. Its goal was flexibility: neuroscientists can define any neuron model they like and simulate large networks in biological real time. The full machine, with about a million cores, was switched on in 2018 as part of the European Human Brain Project. SpiNNaker's successor, SpiNNaker2, developed in collaboration between Manchester and Christian Mayr's group at TU Dresden, packs 152 ARM cores per chip in a 22-nanometre process, adds accelerators for exponential functions, random numbers and the multiply-accumulate operations of conventional neural networks, and supports dynamic scaling of voltage and frequency so that idle cores draw very little. In April 2025 TU Dresden put into operation a SpiNNcloud system with 35,000 SpiNNaker2 chips and more than five million cores, built by the spin-off company SpiNNcloud Systems. Its explicit ambition is to serve both brain simulation and AI workloads that mix spiking and conventional computation. Loihi, from Intel Labs, is the chip most associated with neuromorphic applications research. The first Loihi, described by Mike Davies and colleagues in IEEE Micro in 2018, was built in Intel's 14-nanometre process with 128 neuromorphic cores, three embedded x86 cores for management, and a total of about 130,000 neurons and 130 million synapses. It used asynchronous digital logic throughout. Its most distinctive feature was a programmable learning engine in each core, which could apply a wide family of local learning rules, including spike-timing-dependent plasticity and rules modulated by reward signals, while the chip ran. Intel built systems from many Loihi chips, including Pohoiki Springs in 2020, with 768 chips and about 100 million neurons, and made them available to a research community, the Intel Neuromorphic Research Community, that grew to include well over a hundred groups worldwide. Loihi 2, announced in 2021 and fabricated on a pre-production version of the Intel 4 process, raised the capacity to as many as a million neurons per chip in a smaller die. More importantly, it made the neuron model itself programmable: each core runs short microcode programs defining how neurons update, so researchers are no longer confined to variants of the LIF model. It added graded spikes, carrying small integer payloads, which make sigma-delta and other change-based networks efficient, and faster chip-to-chip interfaces for scaling. In April 2024 Intel announced Hala Point, a system of 1,152 Loihi 2 chips deployed at Sandia National Laboratories, with 1.15 billion neurons, 128 billion synapses and a maximum power consumption of 2,600 watts. Intel's announcement claimed efficiency exceeding 15 trillion eight-bit operations per second per watt on conventional deep neural networks, and, for some workloads, energy savings of up to a hundred times and speed-ups of up to fifty times relative to CPU and GPU architectures. Those claims refer to specific workloads chosen to suit the architecture, a point Chapter 6 takes up in detail. BrainScaleS, developed at Heidelberg University under Karlheinz Meier, who died in 2018, and later Johannes Schemmel, stayed closest to Mead's original analogue vision. Its neurons and synapses are physical analogue circuits whose voltages evolve according to the same differential equations as model neurons, but with time constants about a thousand times shorter than biology, so the system runs a thousand times faster than real time. A second-generation chip, BrainScaleS-2, described by Christian Pehle and colleagues in 2022, holds 512 adaptive exponential integrate-and-fire neurons and about 130,000 synapses per chip, with embedded digital processors that implement flexible plasticity rules. The acceleration makes BrainScaleS-2 attractive for studying learning over long biological timescales, but it makes it awkward for robots, which live in real time. Analogue mixed-signal designs have also come from Giacomo Indiveri's group at the Institute of Neuroinformatics in Zurich, whose DYNAP chips use subthreshold circuits operating in real time and whose work fed directly into the startup SynSense. The edge chips The research chips were never meant to be sold in volume. A different set of devices has emerged from startups aiming at a much narrower target: always-on sensing in battery-powered products, where a few milliwatts is the entire budget and the task is small, such as detecting a spoken keyword, a gesture, a person's presence or an abnormal vibration. SynSense, founded in Zurich in 2017 as a spin-off from Indiveri's institute and now operating in both Switzerland and China, makes Speck, a chip that integrates a 128-by-128-pixel event-camera array directly with a spiking convolutional processor on the same die. Speck's documentation describes nine configurable computing layers and up to about 320,000 spiking neurons. The integration matters because it removes the most expensive link in a conventional vision system, the interface between sensor and processor. Events go straight from pixels into the first layer of a spiking network without being serialised onto a bus. SynSense also makes Xylo, a family of low-power spiking processors for audio and other one-dimensional sensor signals. BrainChip, an Australian-listed company, makes the Akida line of digital event-based neural processors and licenses the design as intellectual property for others to include in their own chips. Akida converts conventional networks into event-based form and runs them in a way that skips computation on zero-valued activations. It attracted attention in 2022 when Mercedes-Benz said it had used Akida in its Vision EQXX concept car to run voice-command keyword detection, reporting a substantial efficiency gain over conventional approaches. Innatera, a Dutch company spun out of Delft University of Technology, launched Pulsar in May 2025, describing it as the first commercially available neuromorphic microcontroller. According to IEEE Spectrum's report on the launch, Pulsar combines twelve digital spiking cores and four analogue spiking cores with accelerators for conventional convolutional networks and fast Fourier transforms, and a 32-bit RISC-V processor running at up to 160 megahertz, on a die about 2.8 by 2.6 millimetres. The company quoted power figures of 600 microwatts for radar-based presence detection and 400 microwatts for audio scene classification. These chips sit in a different place from Loihi or SpiNNaker. They are small, cheap, and designed to be dropped into consumer products alongside conventional microcontrollers. They typically run small networks trained off-chip, often with limited or no on-chip learning, and they compete not with GPUs but with the low-power neural accelerators that conventional microcontroller vendors have begun adding to their own parts. Their case rests on achieving lower power for always-on tasks, and on handling time-series data from sensors such as microphones, radars, accelerometers and event cameras in a naturally streaming way. Beyond these chips lies a further line of research that is often grouped with neuromorphic computing: devices in which memory elements themselves compute. Resistive memories, phase-change memories and other so-called memristive devices can store a synaptic weight as a physical conductance, and a grid of them can perform a whole matrix-vector multiplication in one step, by letting currents sum along wires according to the laws of electrical circuits. Such in-memory computing attacks the data-movement problem of Chapter 1 directly. It is still largely in the research stage for spiking networks, beset by device variability and limited endurance, and most of its demonstrations so far target conventional dense neural networks rather than event-driven ones. It is worth watching, because if it matures it could provide the dense synaptic storage that digital neuromorphic chips currently pay for in SRAM area. Whatever the chip, using it means mapping a trained network onto its resources, and this step shapes what can be built. A network must be partitioned into groups of neurons that fit the capacity of each core, with weights quantised to the precision the core supports and fan-in kept within its limits. Neurons that communicate heavily should be placed on the same or neighbouring cores to reduce traffic across the mesh, much as a city planner places factories near their suppliers. Compilers in the vendors' toolchains automate much of this, but their constraints feed back into network design: a layer that is too wide for a core must be split, a weight matrix that is too dense may exceed memory, and a network whose activity bunches into bursts can overload the routers. Designers who know the target hardware train networks that map onto it cleanly; designers who do not often discover that a network which ran well in simulation needs to be reshaped before it will fit. What a neuromorphic chip is good at Looking across these designs, a consistent picture emerges of the kinds of workload they suit. They suit small to medium networks that fit in on-chip memory. A network with a few hundred thousand neurons and some millions of synapses fits comfortably on a single Loihi 2 or Speck. A network with billions of parameters, the scale of a modern language model, does not fit on any single neuromorphic chip, and spreading it across thousands of chips in a system like Hala Point incurs communication costs that can erode the advantages. They suit sparse, temporal activity. When few neurons fire per time step and inputs arrive as events, cores spend most of their time idle and the chip's energy tracks activity. When activity is dense, the event-driven machinery adds overhead compared with a dense accelerator that simply streams through matrices. They suit batch-of-one, low-latency operation. Because state and weights are local, a single input can propagate through the network as soon as it arrives, with no need to gather a batch. This is the regime of a robot reacting to its sensors, and the opposite of a data-centre server processing thousands of requests at once. And they suit stateful, recurrent computation: problems in which the network must integrate information over time, track something, or settle into a solution through its own dynamics. Mike Davies and colleagues' 2021 review of results from the Loihi research community, published in the Proceedings of the IEEE, found that the clearest gains came not from feedforward deep networks converted to spikes, which often showed little or no advantage, but from recurrent networks, sparse coding, constraint satisfaction, search problems and closed-loop control. That last finding is the most important thing to know about neuromorphic processors. They are not general accelerators for deep learning that happen to use spikes. They are machines for a particular style of computation, sparse, stateful, event-driven and local, and their benefits appear when the problem has that style. For a drone or a robot processing a live event stream, it often does. The next chapter examines how large those benefits actually are when measured honestly. CHAPTER 6 The Energy Arithmetic Every neuromorphic announcement comes with a number. A hundred times less energy. A thousand times more efficient. Microwatts instead of watts. Some of these numbers are accurate, some are accurate but irrelevant, and some compare a carefully chosen neuromorphic implementation with a carelessly chosen conventional one. For anyone deciding whether to build a product around this technology, learning to read such claims is as important as understanding the technology itself. This chapter works through the arithmetic. It shows where the energy in a spiking system actually goes, under what conditions a spiking network on neuromorphic hardware genuinely beats a conventional network on a conventional accelerator, how system-level costs can swamp the savings of a frugal chip, and how to recognise a comparison that has been set up to flatter. The conclusion is not that neuromorphic efficiency claims are false. It is that they are conditional, and the conditions are specific enough to be checked. Counting operations honestly Start with the simplest possible comparison: a single fully connected layer with 1,000 inputs and 1,000 outputs, which has a million weights. In a conventional network, each inference requires one multiply-accumulate for every weight: a million MACs. Each MAC needs the weight, so a million weight reads, unless the weights can be kept in registers and reused, which for a batch of one they mostly cannot. In a spiking network with the same connectivity, run for T time steps per inference, the work depends on how many input neurons spike. If a fraction r of the inputs spike at each step, the layer performs r × T × 1,000,000 synaptic operations, each of which is an accumulate rather than a multiply-accumulate, because a binary spike multiplies its weight by one. Each synaptic operation also needs the weight. In addition, every output neuron's membrane potential must be updated at every time step, or at least whenever an input arrives: up to 1,000 × T neuron updates, which are small compared with the synaptic work. Using the energy figures from Mark Horowitz's 2014 table for a 45-nanometre process, an 8-bit multiplication costs about 0.2 picojoules and an 8-bit addition about 0.03 picojoules, so an 8-bit MAC costs about 0.23 and an accumulate about 0.03. The arithmetic of a spiking synaptic operation is therefore roughly seven or eight times cheaper than that of a MAC. For the spiking network to win on arithmetic alone, r × T must be less than about seven or eight: across all its time steps, each input neuron must fire fewer than seven or eight spikes on average per inference. That sounds achievable, and it often is. But consider a network converted from a conventional one using rate coding, run for 100 time steps so that firing rates can represent values precisely. If the average firing probability per step is 0.1, then r × T is 10, and the spiking network does more arithmetic work than the conventional one, not less. This is the trap that caught much of the early spiking-network literature and that led Steven Davidson and Steve Furber, in a 2021 study in Frontiers in Neuroscience, and Manon Dampfhoffer and colleagues, in a 2023 hardware-aware analysis in IEEE Transactions on Emerging Topics in Computational Intelligence, to conclude that spiking networks offer energy savings on digital hardware only when their activity is genuinely very sparse and their number of time steps small. The arithmetic, however, is the cheap part. Horowitz's table puts a 32-bit read from a small on-chip SRAM at about 5 picojoules and from off-chip DRAM at about 640. Memory access dominates both kinds of network. Here the spiking network has a structural advantage that the operation count understates: it only needs to read the weights of synapses that receive a spike. If 95 percent of inputs are silent in a given step, 95 percent of weight reads are skipped. A conventional network with a batch size of one must read every weight on every inference, whether the corresponding input is informative or zero. Hardware that exploits activation sparsity in conventional networks, which some modern accelerators do, narrows this gap, but the event-driven architecture builds it in from the start. And because neuromorphic chips keep all weights in on-chip SRAM, the reads they do perform are the cheap kind, not the 640-picojoule kind. There is a further subtlety in the time steps. A spiking network with T steps per inference has to keep each neuron's membrane potential in memory between steps and update it. If the hardware updates every neuron at every step, as a simple clocked implementation would, those updates can dominate when activity is sparse. Asynchronous neuromorphic designs update a neuron only when it receives input, with leak computed lazily from the time since its last update, so silent neurons cost almost nothing. This is one reason that running spiking networks on GPUs rarely shows energy benefits: the GPU updates everything every step. Pulling these threads together, a spiking network on purpose-built hardware saves energy when four conditions hold together. Inputs are sparse, so few synapses are active. Activity stays sparse through the network, so hidden layers do not fill up with spikes. The number of time steps per decision is small, or the network runs continuously on a stream so that "per decision" is not even the right frame. And the weights fit on the chip, so that no off-chip memory traffic is needed. Event-camera input processed by a network trained with an explicit penalty on spike count, running continuously on a chip like Loihi 2 or Speck, can meet all four. A converted image classifier processing static photographs typically meets none. The system around the chip Suppose all four conditions hold and the chip is genuinely frugal. The next question is how much of the total system's energy the chip accounts for. The answer is frequently: very little. The Delft drone experiment discussed in the next chapter provides an unusually honest illustration, because its authors reported the numbers. Their spiking network, running on Intel's original Loihi chip, consumed between 7 and 12 milliwatts while processing event-camera input and producing control commands. The Loihi board on which it ran had an idle power of about 0.94 watts. The network's own consumption was around one percent of the board's. Most of the energy went to keeping the board, its interfaces and its management processors alive. This is not a criticism of the experiment, which was a research demonstration on a research chip never designed for low system power. It is a demonstration that the neuromorphic core's efficiency can be completely masked by everything around it. It is worth working through what a well-designed system would need to look like for the network's frugality to show. Suppose a future version of the same drone carried an event sensor drawing 50 milliwatts, a neuromorphic processor whose idle power was 20 milliwatts rather than nearly a watt, a direct parallel or MIPI connection between them in place of USB, and a small flight-control microcontroller drawing 50 milliwatts. Add the network's 10 milliwatts and the perception-and-control electronics total about 130 milliwatts. The same functions on a small embedded GPU module, which typically draws several watts when active, would cost twenty or thirty times more. In that hypothetical system, the neuromorphic advantage is real at the system level, but notice what produced it: the integration of sensor, processor and controller on low-idle-power hardware, not the network alone. The research result shows that the network can be frugal; turning that into a frugal product is a hardware design problem that sits mostly outside the neuromorphic core. The same pattern appears throughout real systems. An event camera such as the IMX636 consumes 50 to 70 milliwatts. A USB interface to carry its events to a processor consumes more. A conventional microcontroller or application processor managing the system draws power whenever it is awake. Radios, inertial sensors, power regulators and motor drivers all have their own budgets. A neuromorphic processor drawing a few milliwatts saves very little if it sits on a board whose other components draw a watt. The power budget of the platform also matters. A small consumer quadrotor weighing a few hundred grams spends tens of watts or more simply staying in the air. Even the tiny Crazyflie research drone, at under thirty grams, flies for about seven minutes on a battery holding less than one watt-hour, which implies average power consumption of several watts. On such platforms, reducing the vision processor's power from 1 watt to 10 milliwatts barely changes flight time. The case for neuromorphic processing on such a drone must rest primarily on latency, weight, and the ability to run perception at all within the platform's limits, not on energy. Only at the very smallest scales does the computational budget become comparable to the propulsion budget. Harvard's RoboBee X-Wing, which Noah Jafferis and colleagues reported in Nature in 2019 as the lightest vehicle to achieve sustained untethered flight, weighs about 90 milligrams and flies on solar power of the order of a hundred milliwatts or so. At that scale every milliwatt of computation competes directly with lift, and a conventional vision pipeline is out of the question. That is the regime where neuromorphic sensing and processing become not merely advantageous but enabling. Between these extremes lies a broad and commercially important class of devices for which energy really is decisive: always-on sensors that spend most of their lives waiting for something to happen. A smart doorbell that must detect a person, a wearable that listens for a keyword, a vibration monitor on an industrial machine, a wildlife camera in the field. Such devices are usually idle, and their battery life is set by their standby power plus the cost of waking up. Here a neuromorphic front end that watches continuously at sub-milliwatt power and wakes the rest of the system only when something relevant occurs can multiply battery life. This is precisely the market that Innatera, SynSense and BrainChip target. Innatera's quoted figures of 400 to 600 microwatts for audio and radar tasks only make sense in this frame: the point is not that the chip computes faster, but that it can compute continuously while everything else sleeps. Reading a benchmark Given how conditional neuromorphic advantages are, the comparisons used to establish them deserve scrutiny. Several recurring patterns should prompt questions. The first is the baseline. A neuromorphic chip compared with a desktop CPU running unoptimised Python code will look spectacular. The meaningful comparison is with the best conventional hardware for the same job at the same scale: a modern edge neural processor, an optimised embedded GPU, or a microcontroller with a neural accelerator, running a network designed with comparable effort. Peter Blouw and colleagues at Applied Brain Research made a useful early attempt at this in 2019, benchmarking a keyword-spotting network on Loihi against the same task on a CPU, a GPU, Intel's Movidius neural compute stick and an NVIDIA Jetson TX1. They found Loihi used the least energy per inference among those platforms. The study's value lay as much in its method as its result: same task, same accuracy target, energy measured on real hardware rather than estimated. The second is batch size. GPUs achieve their efficiency by processing many inputs together. Comparing a neuromorphic chip processing one input with a GPU forced to process one input is fair if the application genuinely requires batch-of-one operation, as a robot does. It is unfair if the application could batch, as a server classifying uploaded photographs could. Intel's Hala Point announcement explicitly framed its advantage around the absence of batching, which is the right frame for real-time streams and the wrong one for offline processing. The third is what is counted. Some papers report synaptic operations rather than energy, or estimate energy by multiplying operation counts by per-operation figures, ignoring memory access, static power, communication and the input encoding. Others report only the power of the neuromorphic core, excluding the board, interface and host. Each of these can understate real system energy by large factors. The fourth is accuracy. A spiking network that uses a tenth of the energy of a conventional network but makes three times as many errors has not demonstrated an efficiency advantage; it has demonstrated a different point on the accuracy-energy trade-off curve. Fair comparisons hold accuracy fixed or present the whole curve. The fifth is the task. Neuromorphic hardware is, as Chapter 5 concluded, best at sparse, temporal, stateful problems. Benchmarks drawn from static image classification tend to show small or negative advantages; benchmarks drawn from streaming sensor data, recurrent dynamics or optimisation problems tend to show large ones. Both are honest, but they answer different questions. The sixth is the process node. Chips built on newer semiconductor processes use less energy per operation, other things being equal, simply because their transistors are smaller and switch at lower voltages. The first Loihi was built in a 14-nanometre process; TrueNorth in 28 nanometres; current GPUs and smartphone neural processors in processes of five nanometres or smaller. A comparison between chips several process generations apart mixes the effect of architecture with the effect of manufacturing technology, and can flatter either side. IBM's NorthPole paper was careful on this point, comparing its 12-nanometre chip against GPUs on a similar node as well as against more advanced ones. A neuromorphic result that beats an older conventional chip on an older node says little about how it would fare against a current one, and a conventional chip that beats a neuromorphic research prototype may owe its win to the foundry rather than the design. A seventh, subtler issue is what the comparison holds constant across time. A spiking network running continuously on a stream does not produce "inferences" in the way a frame-based network does; it produces outputs whenever evidence accumulates. Converting its energy into a per-inference figure requires choosing an inference rate, and the choice can swing the result. A conventional network evaluated at 30 frames per second and a spiking network evaluated at an equivalent "30 decisions per second" may not deliver the same latency or the same quality of tracking. The most meaningful figure for a streaming system is often energy per second of operation at a required level of performance, latency included, rather than energy per inference. None of these traps implies bad faith. They arise naturally because neuromorphic and conventional systems are built on different assumptions about what a unit of work is, and every comparison between them has to translate between those assumptions somehow. The reader's job is to notice where the translation was made and to ask whether it suits the application in question. The field has recognised these problems. NeuroBench, a framework developed by a large community of academic and industrial researchers and published in Nature Communications in 2025 by Jason Yik and colleagues, defines standard tasks, from keyword spotting and gesture recognition to event-camera object detection and chaotic time-series prediction, along with standard metrics: accuracy, model footprint, activation sparsity, synaptic operations broken down by type, and, where hardware is measured, actual energy and latency. Its existence reflects a maturing of the field. Claims made against NeuroBench tasks, with its metrics reported in full, are much easier to evaluate than claims made against custom setups. Latency is energy too One further point complicates the arithmetic in neuromorphic systems' favour, and it is often missed. Latency and energy are not independent quantities in a machine that moves. A drone that perceives an obstacle in 3 milliseconds rather than 40 can fly faster with the same safety margin, or fly at the same speed with a smaller margin, which can mean shorter, more efficient trajectories. A robot arm that detects slip within a few milliseconds of contact can grip with less force, and so use less motor current. A system that reacts quickly to disturbances can use less aggressive feedback gains, smaller actuators, lighter structures. In each case, the saving appears not on the processor's power meter but in the mechanical design and the energy spent on motion. Conversely, a system that achieves low processing power by running slowly, accumulating events for 50 milliseconds so that a small conventional processor can keep up, has paid for its energy savings in latency, and the cost of that latency must be counted elsewhere in the machine. The most useful way to think about neuromorphic efficiency, then, is not "how many joules per inference?" but "what is the whole machine's energy and capability for a given task, given the latency the perception system provides?" Put that way, the question can only be answered at the level of a specific application. The next two chapters look at the applications where it has been answered most thoroughly: drones first, then robots more broadly. CHAPTER 7 Flight on a Milliwatt Budget If neuromorphic engineering needed a single application to prove its worth, the small autonomous drone would be the natural candidate. A drone is unstable by design: a quadrotor left without control for even a fraction of a second begins to tip and fall. It moves fast relative to its size, so the time between seeing an obstacle and hitting it is short. It operates in lighting that changes abruptly, from shade to sun, indoors to outdoors. It carries everything it uses, so every gram of sensor and every milliwatt of computation is paid for in flight time. And it has a biological counterpart, the flying insect, that already solves the same problems with event-driven sensing and a tiny spiking brain. This chapter follows the line of experiments that has taken event-driven flight from laboratory curiosity to a working demonstration of fully neuromorphic control. It shows where events helped on conventional processors, where spiking networks took over, and what still stands between those demonstrations and drones that people can buy. What insects already know Biologists have studied insect flight control for more than a century, and some of their findings map directly onto engineering problems. Insects do not, as far as anyone can tell, build detailed three-dimensional maps of their surroundings before deciding how to move. They rely heavily on optic flow, the pattern of apparent motion that the world makes across the eye as the animal moves. Mandyam Srinivasan and colleagues showed in a series of experiments on honeybees, beginning in the 1990s, how much can be done with optic flow alone. Bees flying down a tunnel centre themselves by balancing the speed of image motion on their left and right eyes. They regulate their flight speed by holding the overall rate of image motion roughly constant, so they slow down automatically in narrow passages where nearby walls create fast flow. When landing on a flat surface, bees hold the angular speed of the ground beneath them constant as they descend, which causes their forward and downward speed to fall in proportion to their height, so that both approach zero at touchdown, without the bee ever needing to know its height or speed. A related cue is the expansion of the image as a surface approaches. When a camera moves straight toward a wall, features on the wall spread outward from the point it is heading for, and the rate of this expansion, called divergence, is inversely related to the time remaining before contact. A controller that keeps divergence constant produces a smooth, exponentially slowing approach, which is how many animals land. Neither cue requires depth sensing, mapping or object recognition. Both require precise, low-latency measurement of image motion, which is exactly what event cameras provide and what frame-based cameras, with their blur and their fixed sampling interval, make difficult at high speed. These biological strategies gave robotics a design pattern: compute simple motion quantities directly from the visual stream and feed them straight into control, with as little intermediate representation as possible. Guido de Croon's group at Delft University of Technology, whose work on flapping-wing drones and optic-flow control stretches back more than a decade, has been one of the most consistent developers of this pattern, and it set the stage for the neuromorphic experiments described below. Events on conventional processors The first wave of event-camera drone work kept the processing conventional. It used the event camera for its speed and dynamic range, and ran carefully designed algorithms on an ordinary onboard computer. Even so, the results showed how much the sensor alone could change. The most widely cited demonstration came from Davide Scaramuzza's Robotics and Perception Group at the University of Zurich. In a paper published in Science Robotics in March 2020, Davide Falanga, Kevin Kleber and Davide Scaramuzza described a quadrotor that could dodge objects thrown at it. The method was elegant in its economy. When a drone moves, the static background generates events too, so the first step was to use the drone's inertial measurements to compensate for its own rotation and separate events caused by the drone's motion from those caused by an independently moving object. Events that remained after this compensation were clustered to locate the incoming object, and its trajectory was estimated, using one camera for objects of known size and a stereo pair for objects of unknown size. A simple avoidance controller, inspired by artificial potential fields, then pushed the drone away from the predicted collision point. The perception pipeline ran with a latency of about 3.5 milliseconds. The team reported that the drone avoided a ball thrown from about three metres at roughly ten metres per second more than 90 percent of the time. To put 3.5 milliseconds in perspective, a ball travelling at ten metres per second moves 3.5 centimetres in that time. A thirty-frame-per-second camera would see the ball only every 33 centimetres of its flight, and a typical frame-based detection pipeline on embedded hardware would add tens of milliseconds more. Across a three-metre throw, which takes about three tenths of a second, the difference between a few milliseconds and several tens of milliseconds of perception latency is the difference between having time to react and not. A second Zurich study, by Sihao Sun, Giovanni Cioffi, Coen de Visser and Davide Scaramuzza, published in IEEE Robotics and Automation Letters in 2021, tackled a different emergency: the loss of a rotor. A quadrotor that loses one of its four propellers can still be controlled, but only by spinning rapidly about its vertical axis, which makes visual state estimation extremely difficult because the camera's view whirls continuously. The researchers compared frame-based and event-based vision for estimating the drone's position under these conditions. With good lighting, frames sufficed; as light levels fell, motion blur made frame-based estimation fail, while the event camera continued to work. The paper's subtitle, "frames vs. events", summarises its value: a controlled comparison showing exactly where each sensor's advantages lie. These and other studies established that event cameras could deliver millisecond-scale perception on flying platforms and that their dynamic range and freedom from blur mattered in practice. What they did not do was reduce the computational burden. The algorithms ran on conventional processors, often small computers drawing several watts, and they handled events in software, one at a time or in small batches. The next step was to move the computation onto neuromorphic hardware. Spiking networks in the loop Putting a spiking network into a drone's control loop raises problems that offline benchmarks never encounter. The network must run in real time, at a fixed or bounded latency. Its outputs must be stable enough not to destabilise the vehicle. It must cope with noise and with conditions it was not trained on. And it must be trained somehow, which for a flying robot cannot mean millions of real-world crashes. An early step was taken by Antonio Vitale, Alpha Renner, Celine Nauer, Davide Scaramuzza and Yulia Sandamirskaya, who presented at the 2021 International Conference on Robotics and Automation a system in which an event camera fed a spiking network on Intel's Loihi that detected the horizon line and controlled the roll of a drone constrained to rotate about a single axis. The network both perceived the line and implemented a proportional-derivative controller in spiking neurons, closing the loop entirely on the neuromorphic chip. The task was deliberately simple, but the demonstration showed that perception and control could be co-located on the chip with low latency. At the same conference, Julien Dupeyroux, Jesse Hagenaars, Federico Paredes-Vallés and Guido de Croon of Delft presented neuromorphic control for landing a drone using optic-flow divergence. A small spiking network running on Loihi took a measure of divergence as input and produced thrust commands to bring the drone down smoothly in the manner of an insect. The network was trained by evolutionary optimisation in simulation and transferred to a real quadrotor. Here the perception step, estimating divergence, was still conventional, but the controller was spiking. In parallel the same group tackled perception. Jesse Hagenaars, Federico Paredes-Vallés and Guido de Croon showed at the 2021 NeurIPS conference that spiking neural networks could be trained, using surrogate gradients and a self-supervised loss based on contrast maximisation, to estimate optical flow from raw event-camera data. The self-supervision was crucial. Rather than requiring ground-truth flow, which is hard to obtain in the real world, the network was trained to produce flow that, when used to warp events back in time, made the resulting edge image as sharp as possible. This is the contrast-maximisation principle from Chapter 3, turned into a training signal. These strands came together in a paper by Federico Paredes-Vallés, Jesse Hagenaars, Julien Dupeyroux, Stein Stroobants, Yingfu Xu and Guido de Croon, published in Science Robotics in May 2024 under the title "Fully neuromorphic vision and control for autonomous drone flight". Their drone carried an event camera and Intel's Loihi chip. A spiking network with five layers and about 28,800 neurons in its vision part took the raw event stream and estimated the drone's ego-motion; a single decoding layer turned that estimate into control commands. The vision network was trained with self-supervision on real event data recorded from the drone. The control layer was trained with an evolutionary algorithm in a drone simulator. The whole network then ran on Loihi on board the real drone, at 200 executions per second, and the drone was able to hover, land, and manoeuvre sideways, even while yawing, following commanded ego-motion setpoints. The team reported that it flew under lighting conditions from dark to bright and even under flickering light. The authors also reported the numbers discussed in Chapter 6. The network consumed 7 to 12 milliwatts on Loihi, against an idle power of about 0.94 watts for the chip's board. On the neuromorphic processor it could execute between 274 and 1,600 times per second, compared with about 25 times per second for the same task on a small embedded GPU, a speed advantage of roughly ten to sixty-four times. Running in flight, the neuromorphic implementation used about three times less energy than the GPU implementation. Table 4 places this result alongside the other demonstrations discussed in this chapter. Table 4. Selected event-driven drone demonstrations. Work Sensing and compute Task Reported result Falanga et al., 2020 Event cameras, onboard CPU Dodging thrown objects 3.5 ms latency; over 90% avoidance at about 10 m/s Sun et al., 2021 Frames vs events, CPU Flight after rotor failure Events worked in low light where frames failed Vitale et al., 2021 Event camera, Loihi Horizon tracking, one-axis roll Perception and control closed on chip Dupeyroux et al., 2021 Divergence input, Loihi Optic-flow landing Evolved spiking controller worked on real drone Paredes-Vallés et al., 2024 Event camera, Loihi Hover, land, sideways flight 200 Hz; 7 to 12 mW network; about 3x less energy than GPU Source: the papers named in the Notes for this chapter. What the Delft result shows, and what it does not The 2024 demonstration matters because it closed the loop end to end. Events from the sensor went into a spiking network without first being converted into frames, the network ran on neuromorphic hardware, and its outputs drove the vehicle. It is the clearest existing example of the whole-loop discipline this book argues for, and its numbers show the payoff: a perception-and-control pipeline that runs an order of magnitude faster than an embedded GPU equivalent, on a few milliwatts. The training approach is as important as the hardware. Self-supervised learning on real event data sidestepped the gap between simulated and real event cameras, which is notoriously hard to close because real sensors have noise, mismatch and latency characteristics that simulators struggle to reproduce. Evolutionary training of the control layer in simulation, by contrast, exploited the fact that a single decoding layer is small enough to evolve and that flight dynamics are simulated well. Dividing the problem this way, learning perception from real data and control from simulation, is a pattern other teams are likely to follow. But the limits of the demonstration are just as instructive. The task was ego-motion control: estimating how the drone itself was moving and following commanded motions. It did not include obstacle avoidance, navigation to a goal, mapping or recognition of objects. The scene was a controlled indoor environment. The network was small, and the vision part had to be designed so that it fit on a first-generation Loihi chip. The board's idle power swamped the network's consumption. And the drone was a conventional quadrotor whose propulsion consumed far more power than any of its electronics, so the energy savings, though real, were not what limited flight time. None of this diminishes the result. It locates it. The 2024 drone showed that fully neuromorphic perception and control is possible and that it delivers the latency and per-inference energy that theory predicts. It did not show that neuromorphic hardware is yet ready to replace conventional autonomy stacks on commercial drones. The road to insect-scale flight Where does event-driven flight go from here? Three directions stand out. The first is richer tasks on the same principles. Obstacle avoidance from optic flow, gap detection, wall following and landing on moving platforms can all, in principle, be expressed as mappings from event-derived motion cues to control commands, the kind of mapping that small spiking networks have shown they can learn. Each extends the Delft approach rather than replacing it. The second is better hardware integration. The biggest inefficiency in the 2024 demonstration was not in the network but in the system: a separate camera, a USB connection, a research board with high idle power. Sensors with integrated processing, such as SynSense's Speck with its event-camera pixels feeding a spiking processor on the same die, point toward systems in which the event stream never leaves the chip that produces it. Combine that with a small neuromorphic microcontroller and a lightweight flight controller, and the entire perception-and-control electronics of a small drone could plausibly fit in a power budget of tens of milliwatts. The third is scale. At the size of a palm-sized quadrotor, neuromorphic processing mostly buys latency. At the size of an insect, it buys the possibility of autonomous vision at all. Flapping-wing micro air vehicles such as Delft's DelFly and Harvard's RoboBee have demonstrated flight at gram and sub-gram scales, but their autonomy has been severely limited by what they can carry and power. A camera and processor drawing even a watt is out of the question for a vehicle whose entire power budget is measured in tens or hundreds of milliwatts. An event sensor and spiking processor drawing a few milliwatts between them would fit. Whether such vehicles become practical depends on many things beyond vision, including actuators, batteries and mechanical robustness, but it is difficult to imagine autonomous insect-scale flight without event-driven, sparse computation at its core. What all three directions share is the principle that made the Delft drone work: sparse sensing feeding sparse computation feeding control, with as few conversions between representations as possible. Every conversion, from events to frames, from spikes to dense tensors and back, from on-chip to off-chip, costs latency and energy, and the smaller and faster the platform, the less of either it can afford. Drones are the sharpest test of that principle, but they are not the only one. Robots on the ground, arms that grasp and touch, and vehicles on the road face versions of the same problem. Some of them are where neuromorphic technology is closest to practical deployment, and they are the subject of the next chapter. CHAPTER 8 Robots That Feel Time Drones make the case for neuromorphic hardware in its starkest form, but most robots do not fly. They roll across warehouse floors, reach into bins, assemble parts, walk on legs, and increasingly drive on public roads. Their power budgets are larger, their dynamics usually slower, and their tasks richer. It would be natural to assume that the arguments of the previous chapter apply to them only weakly. The reality is more interesting. Ground robots and manipulators have their own fast loops, the reflexes of catching, balancing and gripping, where milliseconds decide success, and their own sensors that naturally produce events. They also have slow loops, planning, mapping and recognition, where conventional computation is well suited and hard to beat. The emerging pattern in robotics is not wholesale replacement of conventional systems with neuromorphic ones, but a layered architecture in which event-driven sensing and spiking computation handle the fast periphery, where change matters most, while conventional processors handle deliberation. This chapter traces that pattern through ball-catching robots, artificial touch, humanoid platforms, mobile robots and cars. Reflexes and touch Some of the earliest and most persuasive demonstrations of event cameras in robotics were reflexes: tasks where the robot must respond to a fast change in its environment within a few milliseconds. In 2009 Jörg Conradt and colleagues at the Institute of Neuroinformatics in Zurich built a robot that balanced an ordinary pencil upright on its tip, using a pair of event cameras to track the pencil and a small actuated table beneath it to keep it balanced. Balancing a pencil is a classic test of fast feedback, because a pencil falls quickly and any delay in the control loop is amplified. The event cameras' low latency allowed the controller to correct the pencil's tilt using estimates updated as each event arrived, with little computation. In 2013 Tobi Delbruck and Manuel Lang published in Frontiers in Neuroscience a description of a robotic goalkeeper. An event camera watched balls rolled or flicked towards a goal, and a simple robotic arm blocked them. The title stated the results: "Robotic goalie with 3 ms reaction time at 4% CPU load using event-based dynamic vision sensor". The ball tracking ran on an ordinary laptop processor, but because the event camera produced data only where the ball and arm were moving, the tracking consumed only a few percent of the processor's capacity. A frame-based system achieving the same reaction time would have needed a high-speed camera and much more computation. These systems were not neuromorphic in the processing sense. They ran clever event-by-event algorithms on conventional computers. But they established a principle that later work built on: for reflex tasks, the combination of a sensor that reports only change and an algorithm that processes each change as it arrives delivers both very low latency and very low computational load, because the work is focused on the small part of the scene that matters. Touch Vision is not the only sense in which events arise naturally. Touch may be an even better fit. Human fingertips contain several types of mechanoreceptor, each connected to nerve fibres that send spikes to the spinal cord and brain. Roland Johansson and Randall Flanagan, in a widely cited 2009 review in Nature Reviews Neuroscience, described how these signals underpin dexterous manipulation. Some of the receptors respond mainly to changes, firing bursts when contact is made or broken, or when an object begins to slip, and falling silent during steady pressure. The timing of the first spikes across a population of receptors encodes information about the direction of force and the shape of the contact surface quickly enough to adjust grip within about a tenth of a second, before conscious awareness intervenes. The tactile system is, in effect, an event sensor. Robotic touch has traditionally been built the opposite way, with arrays of pressure sensors scanned row by row at a fixed rate, just like a frame camera. As arrays grow larger and more dense, covering whole hands or arms, scanning becomes slow and wiring becomes a bottleneck. Wang Wei Lee, Benjamin Tee and colleagues at the National University of Singapore described in Science Robotics in 2019 a different approach, the Asynchronously Coded Electronic Skin, in which each tactile sensor transmits its own spike-like pulses over a shared conductor when stimulated, with a distinct signature that identifies it. The result is an artificial skin whose readout latency does not grow with the number of sensors, because sensors that are not being touched transmit nothing. The same Singapore group, together with Harold Soh's group, built on this in a 2020 paper presented at the Robotics: Science and Systems conference by Tasbolat Taunyazov and colleagues. They combined an event-based tactile sensor, called NeuTouch, with an event camera on a robot gripper, and processed both streams with a spiking neural network running on Intel's Loihi. The system classified the contents of containers by how they felt and looked when lifted, and detected rotational slip of a grasped object. Slip detection is a quintessential event problem: what matters is the moment a grasped object begins to move, and the earlier the robot detects it, the less it has to squeeze to recover. A system that processes tactile changes as they happen, rather than polling pressure arrays on a schedule, can respond in the window before the object is lost. Touch illustrates a general point about the fit between neuromorphic hardware and robotics. Many robotic sensors, not only cameras and skins but microphones, motor encoders, force-torque sensors and inertial units, produce signals that are mostly predictable and occasionally informative. The useful events are contacts, collisions, slips and sudden accelerations. A processing architecture that idles cheaply and responds instantly to such events matches the structure of the information. Humanoids, mobile robots and the moving observer The longest-running effort to build a whole robot around event-driven sensing is at the Italian Institute of Technology in Genoa, where Chiara Bartolozzi's group has equipped the iCub humanoid robot with event cameras and event-driven tactile sensing. iCub, a child-sized open-source humanoid developed through a European project in the late 2000s, is used by research laboratories worldwide. The event-driven iCub work has explored attention, in which the robot directs its gaze towards salient changes; stereo vision, in which events from two eyes are matched by their timing; and tracking of moving objects in cluttered environments while the robot's own head and eyes move. In a 2022 perspective in Nature Communications titled "Embodied neuromorphic intelligence", Bartolozzi, Giacomo Indiveri and Elisa Donati argued that the full benefits of neuromorphic computing will only appear in systems where sensing, computation and action are designed together, in a body interacting with an environment, rather than in disembodied benchmarks. That argument is, in essence, the argument of this book applied to robotics as a whole. Mobile robots present a different set of problems. Their core tasks, localisation, mapping and path planning, are traditionally performed with probabilistic algorithms and dense computation on conventional processors. A handful of studies have shown that pieces of this pipeline can run efficiently on neuromorphic hardware. Guangzhi Tang, Arpit Shah and Konstantinos Michmizos at Rutgers University demonstrated in 2019 a spiking network on Loihi that performed simultaneous localisation and mapping along one dimension, using a model inspired by the head-direction and grid cells that rodents use to keep track of where they are, and reported that it consumed far less energy than the same computation on a conventional processor. The same group later trained spiking networks with population coding for continuous control in reinforcement learning tasks. These remain research demonstrations on reduced problems. Full localisation and mapping in large, changing environments has not yet been done on neuromorphic hardware in a way that competes with conventional systems. Where neuromorphic approaches have been most useful on mobile robots is closer to the sensor: event-based visual odometry, which estimates the robot's motion from events in conditions where frame-based methods fail, and fast obstacle detection, which watches for anything moving into the robot's path. Both feed conventional planners rather than replacing them. The problem of a moving observer Mobile robots expose a difficulty that stationary demonstrations such as the robotic goalie conveniently avoid, and any honest account of event-driven robotics has to face it. An event camera is sparse when the world is mostly still relative to the camera. On a robot that moves, the world is never still relative to the camera. Every time the robot drives forward, turns or tilts its head, every edge in the field of view sweeps across pixels and generates events. The sparsity that made the goalie so cheap to compute is partly a property of a fixed camera watching a few moving objects, and it shrinks as soon as the camera itself starts to move. The size of the effect is easy to estimate. Suppose a robot's camera, with a field of view of about 60 degrees spread across 640 pixels, rotates at 60 degrees per second, an unremarkable turning rate for a mobile robot. Image features then sweep across the sensor at about 640 pixels per second. If ten percent of the image consists of edges strong enough to cross the contrast threshold, and each edge pixel produces roughly one event every time it moves onto a new pixel, then the event rate is the number of edge pixels multiplied by the speed. For a sensor of 640 by 480 pixels, about 30,000 edge pixels moving at 640 pixels per second generate on the order of twenty million events per second, more if strong edges trigger several events each as they pass. A conventional VGA camera at 30 frames per second, by comparison, produces about nine million pixel values per second. In that situation the event camera is no longer the sparser sensor. Robotics researchers have developed three broad responses, and each says something about how event-driven systems need to be designed. The first is to subtract the predictable part. A robot knows, from its inertial sensors and wheel encoders, how it is moving. Events caused purely by its own rotation can be predicted and compensated, as the Zurich group did for the dodging drone described in Chapter 7. What remains after compensation are events caused by independently moving objects and by translation through a three-dimensional scene, which are the informative ones. This turns the robot's self-knowledge into a filter on its own sensory stream, much as animal nervous systems use internal copies of motor commands, which neuroscientists call efference copies, to cancel the sensory consequences of their own movements. The second is to stabilise the sensor. Animals with mobile eyes, including humans, hold their gaze steady on the world while their heads and bodies move, using fast reflexes driven by the vestibular system, and then shift gaze in rapid jumps. During steady fixation, the retina sees mostly still images and responds strongly to anything that moves. Robots can do the same with gimballed or actively controlled cameras, and the iCub work has explored exactly this, using eye movements to keep the event stream sparse except when the robot deliberately shifts its gaze. A stabilised event camera on a moving robot recovers much of the sparsity of a fixed one. The third is to embrace the dense stream as signal. When the robot moves, the events generated by the static scene encode its motion and the scene's structure. Event-based visual odometry and the contrast-maximisation methods of Chapter 3 exploit exactly these events, and in this role their microsecond timing and freedom from blur are what matter, not their sparsity. In this mode the system's advantage over a frame camera is accuracy under fast motion and difficult lighting, not lower data rate or lower computation. The lesson for system design is that event-driven robots need a model of their own motion as a first-class part of the perception pipeline. Sparsity is not simply a property of the sensor. It is a property of the sensor, the scene and the robot's motion together, and the designer has tools, compensation, stabilisation and attention, to keep it high. A robot that ignores its own motion will find its event camera producing torrents of data at exactly the moments it most needs to react. Cars The most commercially consequential robotic application of event cameras may turn out to be in cars, where the questions are about safety rather than power. An advanced driver-assistance system must detect pedestrians, cyclists and vehicles quickly and reliably in all lighting conditions. Conventional automotive cameras typically run at around 30 to 60 frames per second. At 50 kilometres per hour a car travels about 46 centimetres in a 33-millisecond frame interval, and the delay between a pedestrian stepping out and the system seeing it can stretch to several frame intervals once processing is included. Raising the frame rate raises bandwidth and computation in proportion, which is costly in a vehicle that may carry many cameras. And the transition from a dark tunnel into sunlight is a familiar failure mode for frame-based exposure control. Daniel Gehrig and Davide Scaramuzza's 2024 paper in Nature, "Low-latency automotive vision with event cameras", introduced in Chapter 3, addressed exactly this. Their system combined a 20-frame-per-second colour camera with a Prophesee event camera. A conventional convolutional network processed each colour frame to detect objects. Between frames, an efficient asynchronous graph neural network processed the event stream to update those detections continuously, so that a pedestrian appearing between frames was detected from events within milliseconds rather than waiting for the next frame. The authors reported that the hybrid system achieved the same latency as a 5,000-frame-per-second camera while using the bandwidth of a 45-frame-per-second camera, without compromising accuracy. They also released a dataset recorded with this setup in driving conditions. Several features of this design deserve attention, because they show what a mature event-based system looks like. It does not abandon frames; it uses them for what they are good at, which is rich appearance information at low rate. It does not accumulate events into frames for a conventional network; it uses a network designed to update incrementally with each new batch of events, preserving sparsity and latency. And it frames its claims in exactly the terms that matter for the application: latency and bandwidth at fixed accuracy, not raw operation counts. The automotive industry adopts sensors slowly, with long qualification cycles, strict temperature and reliability requirements, and intense cost pressure. Event cameras face additional hurdles in cars: the flicker of LED headlights, tail lights and road signs, which pulse at frequencies that event cameras detect vividly; the relative scarcity of large labelled driving datasets; and the need to integrate with perception stacks built entirely around frames. The IMX636's specified operating range of minus 40 to plus 85 degrees Celsius shows that the sensors themselves can be built to automotive-grade environmental standards, but a sensor is only the beginning of an automotive product. Event cameras have also been explored for monitoring inside the cabin, for instance tracking a driver's eye movements and blinks, where their speed and low data rates suit the task well. As of 2026, event cameras in cars remain more prominent in research and pre-development than in vehicles on sale, but the Gehrig and Scaramuzza result has given the industry a concrete, quantified reason to take them seriously. The layered robot Across these applications, a common architecture is emerging. At the bottom are fast reflex loops, catching, dodging, slip detection, collision warning, in which event-driven sensors feed sparse, low-latency computation that can trigger actions within milliseconds. These loops are where neuromorphic hardware is most at home: small networks, sparse inputs, batch-of-one operation, a premium on latency and on always-on low power. Above them sit slower loops of perception and planning, recognising objects, building maps, deciding where to go, which need rich representations and benefit from the full power of conventional deep learning on GPUs and neural processors. Between the two, signals pass upward as events, a detection, a contact, a slip, and commands pass downward as goals and setpoints. This mirrors the organisation of animal nervous systems, in which spinal reflexes and brainstem circuits handle fast responses to sensory events while the cortex handles deliberation, and it suggests a realistic adoption path. Neuromorphic components do not need to replace a robot's main computer to be valuable. They need to handle the fast periphery better than conventional components can, and pass the result upward. Building such systems is an engineering challenge in its own right, with toolchains, interfaces and design decisions that the research literature often glosses over. The next chapter turns to those practicalities. CHAPTER 9 Building With Neuromorphic Hardware Today The previous chapters described what event cameras and spiking processors are, how they work, and where they have shown their worth in drones and robots. This chapter is for the engineer, team lead or researcher who is considering using them in a real project. It covers how to decide whether a problem is a good fit, what tools exist, what a realistic development workflow looks like, and the specific mistakes that most often turn a promising neuromorphic project into an expensive detour. The overall advice can be stated in advance. Neuromorphic technology in 2026 is mature enough to build working systems with, but not mature enough to be chosen casually. It rewards teams that pick problems whose structure matches its strengths, that measure the whole system rather than the chip, and that plan for an ecosystem still in flux. Is this a neuromorphic problem? The single most useful thing a team can do before buying hardware is to test its application against the conditions that recur throughout this book. Five questions capture most of them. First, does the information arrive as change? If the useful signal in the application is mostly in motion, onsets, contacts, transients or deviations from a steady state, event-based sensing fits. If it is mostly in static appearance, such as reading a label, judging colour or inspecting a still part under constant lighting, a conventional camera is almost certainly better. Second, does latency matter at the millisecond scale? If the system must react within a few milliseconds, as a drone dodging an obstacle or a gripper catching a slip must, the event-driven pipeline's latency advantage is decisive. If a response within a hundred milliseconds is adequate, conventional systems can usually provide it more cheaply. Third, is power the binding constraint, and is the neuromorphic part a large share of it? If the device runs on a small battery and spends most of its life waiting, an always-on neuromorphic front end can transform battery life. If the device is a vehicle whose motors draw hundreds of watts, saving a watt on vision changes little, and the case must rest on latency or capability instead. Fourth, can the computation be small? Neuromorphic chips hold networks of up to roughly a million neurons per chip at the high end, and far fewer on the edge devices. A task that needs a large vision transformer or a language model does not fit; a task that needs a few layers of event-driven convolution or a small recurrent network does. Fifth, can the pipeline stay sparse end to end? This is the question this book has returned to most often. If the plan involves capturing events, converting them to frames, running a conventional network on a GPU and then converting outputs to spikes for a neuromorphic chip, the team should ask what each conversion is for. If the honest answer is that it lets them use familiar tools, they should consider whether a conventional pipeline would serve them better outright. An application that answers yes to most of these questions is a strong candidate. One that answers no to most of them should stay conventional, however appealing the technology. Many applications land in the middle, and for those the hybrid designs of the previous chapter, an event camera alongside a frame camera, or a neuromorphic front end that wakes a conventional processor, are often the right answer. Tools and workflow The toolchain The software ecosystem around neuromorphic hardware has improved greatly since the late 2010s, when using a research chip meant learning a bespoke programming model with few users. It remains fragmented, with each hardware vendor supporting its own stack, but the pieces now connect through common foundations, mostly in Python and mostly building on PyTorch. Table 5 lists the main tools a team is likely to meet. Table 5. Principal software tools for event-based and spiking systems. Tool Maintainer Purpose Main targets Metavision SDK Prophesee Event-camera capture, recording and algorithms Prophesee and Sony-based sensors dv-processing iniVation Event-camera capture and processing iniVation cameras Lava and Lava-DL Intel Labs and open-source community Building and training spiking applications Loihi 2; CPU simulation snnTorch, SpikingJelly, Norse Academic open-source projects Surrogate-gradient training in PyTorch GPUs and CPUs; export to hardware Sinabs and Rockpool SynSense Training and deploying spiking networks Speck and Xylo chips Neuromorphic Intermediate Representation (NIR) Multi-institution community Common format for exchanging spiking models Many simulators and chips Source: project documentation and the Notes for this chapter. On the sensor side, Prophesee's Metavision SDK and iniVation's libraries handle the basics of reading events from cameras, recording and replaying them, setting the biases that control thresholds and filtering, and running classical event algorithms such as noise filtering, optical flow and tracking. The Tonic library, developed by Gregor Lenz and colleagues, provides loaders and transforms for most public event datasets, much as torchvision does for images. On the network side, the training libraries described in Chapter 4 let a developer define a spiking network in PyTorch, train it with surrogate gradients on a GPU, and inspect its spiking activity. A minimal example shows how close this is to ordinary deep learning: import torch, snntorch as snn from snntorch import surrogate # events binned into 2 polarity channels of 64 x 64 pixels fc = torch.nn.Linear(2 64 64, 10) lif = snn.Leaky(beta=0.9, spike_grad=surrogate.fast_sigmoid(slope=25)) def run(event_bins): # shape: [time, batch, 2*64*64] mem = lif.init_leaky() spikes = [] for x_t in event_bins: # one step per time bin spk, mem = lif(fc(x_t), mem) spikes.append(spk) return torch.stack(spikes) # output spike trains The loop over time is the only structural difference from a conventional network: the neuron's membrane potential carries over between steps, and the surrogate gradient lets backpropagation pass through the spike. A loss function can then combine task error with a penalty on the total number of spikes, training for sparsity directly. The gap between such a model and a deployed system is where the hardware-specific tools come in. Each chip imposes constraints: limited weight precision, often eight bits or fewer; a maximum number of inputs per neuron; a fixed set of neuron models; a maximum number of neurons per core; particular ways of representing time. Intel's Lava framework, open-sourced in 2021, provides an abstraction of communicating processes for building applications that run on Loihi 2 or in simulation, with Lava-DL handling deep-learning-style training. SynSense's Sinabs and Rockpool map PyTorch models onto Speck and Xylo. Innatera's Talamo kit, also built on PyTorch, targets Pulsar. The Neuromorphic Intermediate Representation, NIR, described by Jens Egholm Pedersen and a large group of collaborators in Nature Communications in 2024, is the most important recent step towards reducing fragmentation. It defines a common format for spiking network models, built around a small set of computational primitives such as leaky integrators and integrate-and-fire units, so that a model trained in one framework can be exported and run in another simulator or on a different chip. Its authors demonstrated interoperability across a range of simulators and several hardware platforms. NIR does not eliminate the hardware constraints, but it means that a team's training code need not be rewritten for every target. A realistic workflow Projects that succeed with neuromorphic hardware tend to follow a recognisable sequence, and those that fail tend to skip steps in it. Start with the sensor, in the real environment. Before designing any network, record event data with the intended sensor in the intended conditions. Event cameras' behaviour depends heavily on bias settings, lighting, flicker and the motion of the platform. A team that trains on public datasets recorded with a different sensor under different conditions will discover the mismatch late. Recording also reveals the actual event rates the system must handle, which determine interface bandwidth and processor load. Use simulation, but know its limits. Simulators that generate synthetic events from rendered scenes or from conventional video, such as ESIM from the Zurich group and v2e from Yuhuang Hu, Shih-Chii Liu and Tobi Delbruck, make it possible to produce large training sets with ground truth. They model the ideal pixel well and the real sensor's noise, mismatch and latency less well. The Delft drone's division of labour, training perception on real event data with self-supervision and training control in simulation, is a good template: use simulation where its fidelity is high and real data where it is not. Train for sparsity from the start. A network trained only for accuracy will usually spike more than necessary. Adding a penalty on spike counts to the loss, and monitoring activity per layer during training, keeps the network in the regime where hardware gains appear. It is much harder to make a dense network sparse after the fact. Train with the hardware's constraints in the loop. Quantise weights to the target precision during training rather than after it, respect the chip's limits on fan-in and neuron count, and model the hardware's time discretisation. Quantisation-aware training, standard practice for conventional edge accelerators, matters equally here, and the gap between a model's accuracy in floating-point simulation and on the chip is a frequent source of disappointment. Measure the whole system. Measure power at the supply rail of the entire perception subsystem, sensor, interface, neuromorphic processor and host, in realistic operating conditions, including idle periods. Measure latency from physical event to actuator command, not from chip input to chip output. Compare against a conventional baseline built with comparable effort on the best available conventional hardware for the same budget. Without these measurements the team will not know whether it has gained anything, and will not be able to persuade anyone else. Close the loop early. For robotic applications, run the network in closed loop on the real platform as soon as possible, even with a crude model. Closed-loop behaviour reveals problems, oscillations from latency, sensitivity to noise, failure in unexpected lighting, that open-loop accuracy metrics hide. A worked design: gesture wake-up for a wearable To make the screening questions and the workflow concrete, consider a design problem of the kind that edge neuromorphic chips are aimed at: smart glasses that should wake their main processor and display when the wearer makes a deliberate hand gesture in front of them, and otherwise stay asleep to preserve battery life. The numbers that follow are design assumptions chosen to illustrate the reasoning, not specifications of any product. The five questions come out well. The information arrives as change: a gesture is motion, and a static hand or background carries no signal. Latency matters moderately: the wearer expects a response within perhaps a tenth of a second, which is not as demanding as a drone's reflexes but rules out duty-cycling a conventional camera at a slow rate. Power is the binding constraint: a pair of glasses carries a small battery, and the wake-up function must run all day. The computation can be small: distinguishing a handful of gestures from background motion is a task that networks of a few thousand to a few tens of thousands of neurons have handled on datasets such as DVS Gesture. And the pipeline can stay sparse: a small event sensor can feed a spiking classifier directly, with no frames involved. Now the arithmetic. Suppose the conventional alternative is a small, low-resolution camera running continuously at 15 frames per second, feeding a microcontroller with a neural accelerator that runs a compact convolutional network on every frame. Even if the camera draws a few milliwatts and each inference costs only a millijoule, fifteen inferences per second add about 15 milliwatts, and the microcontroller cannot sleep between them for long. Suppose instead that a small event sensor in a low-power mode, together with a spiking processor on the same board, draws on the order of a milliwatt while the wearer's surroundings are quiet, rising only when motion occurs. Over a day in which the wearer's hands are in view and moving perhaps ten percent of the time, the average draw of the event-driven front end is dominated by its quiet-state consumption, while the conventional front end pays its full cost all the time. If the glasses' battery holds about one watt-hour, a 15-milliwatt always-on load consumes over a third of it in a day, while a one-milliwatt load consumes a few percent. That difference determines whether the feature is viable at all. The arithmetic also shows where the design could fail. If the wearer walks through a busy street, the event sensor sees continuous motion from the scene and from head movement, the quiet-state assumption collapses, and the front end runs near its peak most of the time. The design must therefore include the countermeasures of the previous chapter: compensation using the glasses' inertial sensor, a region of interest restricted to where hands appear, and a classifier trained to ignore background motion. And if the board's interfaces, regulators and host microcontroller together draw several milliwatts while "asleep", the front end's savings disappear into the system budget, which is the idle-power trap of Chapter 6 in miniature. This is what a neuromorphic design looks like when done well: a specific task whose information is change, a power budget in which the front end dominates, a pipeline kept sparse from pixel to decision, and an explicit account of the conditions under which sparsity breaks down. Failure modes and access The commonest ways neuromorphic projects go wrong are predictable, and each corresponds to a broken link in the whole-loop chain. The frame relapse. Under deadline pressure, the team accumulates events into frames and runs a conventional network, intending to "neuromorphise" later. The system works, but its latency and power are those of a conventional pipeline with a more expensive sensor. Later rarely comes. The converted network. A conventional network is converted to spikes with rate coding and deployed on a neuromorphic chip. It needs many time steps per inference, spikes densely, and saves little or no energy compared with running the original network on an edge accelerator. The conclusion drawn, that neuromorphic hardware does not deliver, is about the method rather than the hardware. The idle-power surprise. The neuromorphic core consumes milliwatts, but the development board, USB interface, host processor and sensor together consume a watt. The system-level gain is negligible. This can be fixed only by designing the hardware around the low-power core, which usually means moving from development kits to custom boards. Bias and flicker blindness. An event-camera system trained and tested in one building fails in another because of different lighting flicker, or fails outdoors because thresholds tuned for indoor light produce too many or too few events. Systematic testing across lighting conditions, with anti-flicker filtering configured, is essential. Timing mismatch. Event timestamps, inertial measurements and control commands live on different clocks. A system that fuses them without careful synchronisation produces errors that grow with platform speed, and the advantages of microsecond event timing are lost to millisecond clock skew. The orphaned platform. Research chips may never become products, and small companies may change strategy or fail. IBM did not commercialise TrueNorth. Intel's Loihi chips have been available mainly to members of its research community rather than for general purchase. Several event-sensor and neuromorphic startups have had to restructure. A team building a product should ask what happens if its chosen chip is discontinued, and should prefer architectures in which the trained model can be retargeted, which is one practical argument for exchange formats such as NIR. Getting access Access routes to the technology vary by type. Event cameras can be bought outright from Prophesee, iniVation and industrial camera makers including IDS and Lucid, at prices typically in the thousands of dollars for evaluation and industrial units. Intel's Loihi 2 systems are available to members of the Intel Neuromorphic Research Community, which includes academic, government and corporate groups, including through remote cloud access. SpiNNaker and BrainScaleS systems have been made available to researchers through the European EBRAINS research infrastructure that grew out of the Human Brain Project. SynSense, BrainChip and Innatera sell development kits for their edge chips. University courses and summer schools, notably the long-running Telluride Neuromorphic Cognition Engineering Workshop in Colorado and the CapoCaccia workshop in Sardinia, remain important places where newcomers learn the craft from practitioners. The skills required are a blend that few engineers have in full: comfort with deep-learning frameworks, an understanding of sensor physics and analogue behaviour, familiarity with embedded systems and power measurement, and enough neuroscience to understand the design choices behind the hardware. Teams that combine these skills, or that partner with research groups that have them, do far better than teams that treat a neuromorphic chip as a drop-in accelerator. That, finally, is the practical form of this book's central argument. The advantages of neuromorphic hardware are properties of whole systems, and only teams that design whole systems will capture them. Conclusion The chapters of this book have moved from pixels to processors to flying and walking machines, and at each step the same pattern has appeared. Event cameras deliver microsecond timing, wide dynamic range and data in proportion to change, and much of that is lost the moment their output is packed into frames. Spiking networks compute in proportion to activity, and that advantage disappears when they are converted from dense networks and allowed to fire freely. Neuromorphic chips run such networks on milliwatts, and that saving vanishes on a board that idles at a watt. The 2024 Delft drone worked because its designers kept the chain unbroken from sensor to actuator. Most disappointing neuromorphic projects failed because someone broke it. Several conclusions follow from that, and they could not have been drawn from any single chapter on its own. The unit of analysis is the loop The first is that the question "is neuromorphic hardware efficient?" has no answer as posed. Efficiency is a property of a closed loop: a sensor, a representation, a computation, an action and the world that responds to it. A spiking chip is efficient in a loop where information arrives sparsely and must be acted on quickly, and inefficient, or merely irrelevant, in a loop where information is dense and time is plentiful. Comparisons that isolate the chip from its loop, counting synaptic operations, quoting core power or benchmarking on static images, measure something real but not the thing that decides whether a product should use the technology. This changes how claims should be read and how projects should be judged. A team evaluating neuromorphic technology should insist on latency measured from physical event to actuator command and on power measured at the supply rail of the whole perception subsystem, against a conventional baseline built with equal care. A researcher publishing results should report those numbers, as the Delft group did when it disclosed the gap between its network's 7 to 12 milliwatts and its board's 0.94 watts. That candour is more useful to the field than any headline ratio. Neuromorphic hardware will arrive from the edges The second conclusion concerns how the technology will spread. Neuromorphic processors are not going to displace GPUs in data centres, and they are not going to become the main computer in most robots. Large models, dense workloads and offline batch processing are where conventional accelerators excel, and the arithmetic of Chapter 6 gives no reason to expect that to change. IBM's own trajectory, from the spiking TrueNorth to the non-spiking NorthPole, suggests that for dense deep learning the most transferable lesson of brain-inspired design is co-locating memory with computation, not spiking as such. Where neuromorphic technology fits is at the periphery: in sensors that process their own output before it leaves the chip, in always-on front ends that wake larger systems only when something happens, and in the fast reflex layers of robots and vehicles. That is where the five conditions of Chapter 9 are most often met. It is also where products are most cost-sensitive, so the decisive developments in the coming years are likely to be unglamorous ones: event sensors produced in volume at prices close to conventional sensors, sensor-processor integration in the mould of SynSense's Speck, neuromorphic microcontrollers such as Innatera's Pulsar finding design wins in doorbells, wearables and industrial monitors, and boards designed around low idle power rather than research flexibility. A neuromorphic industry built on these components would look less like a revolution in computing and more like a quiet change in how sensors are made. That is a plausible and valuable outcome. The line between spiking and conventional is dissolving The third conclusion is that the categories the field started with are blurring, and that this is healthy. Loihi 2's graded spikes carry integers, not single bits. Sigma-delta networks transmit changes in conventional activations. Asynchronous graph networks and sparse convolutions process events on conventional hardware without spikes at all. State-space sequence models developed for language and audio are being mapped onto neuromorphic chips because their recurrent, stateful structure suits them. Meanwhile, conventional accelerators are learning to skip zero-valued activations. What survives this convergence is not the spike as a sacred unit, but the principles that the spike embodied: compute only when inputs change, keep state and memory local, communicate sparsely, and let time be part of the computation. A system can follow those principles with binary spikes, graded events or sparse tensors. The interesting engineering question is no longer whether a design is "truly neuromorphic" but how well it preserves sparsity and timing across the whole loop. Practitioners who adopt that framing will find useful ideas on both sides of an increasingly artificial divide. What remains open Several important questions are unsettled, and honesty about them is part of taking the field seriously. In January 2025 Dhireesha Kudithipudi and more than twenty co-authors from universities, national laboratories and industry argued in Nature, under the title "Neuromorphic computing at scale", that the field had reached a critical juncture, and that progress now depended on building larger systems, exploiting sparsity more aggressively, and creating software that lowers the barrier to entry for people outside the specialist community. Their roadmap is a reasonable statement of the consensus. The questions it leaves open are the ones that will decide where the technology goes. It is not yet clear how much on-chip learning matters. Loihi was built around programmable plasticity, and adaptive robots that learn from their own experience are an appealing vision, but almost every deployed application so far trains networks off-chip and runs them fixed. Whether local learning rules such as e-prop can make on-device adaptation reliable enough for products is an open research question. It is not clear whether analogue computation will return to the mainstream. Mead's original wager on subthreshold physics has been carried forward by BrainScaleS, by Indiveri's group and by the analogue cores in Innatera's chip, and the theoretical efficiency is compelling. The practical problems of mismatch, drift and programmability are equally real. It is not clear how far training methods will scale. Surrogate gradients made spiking networks competitive, but backpropagation through time is memory-hungry, and the networks deployed on neuromorphic hardware remain small. Training large, sparse, temporal networks efficiently, and closing the gap between simulated and real event data, are both live problems. And it is not clear which application will first carry the technology to scale. Drones and robots are the most persuasive demonstrations, but they are small markets compared with smartphones, cars or consumer electronics. The Prophesee and Qualcomm collaboration on deblurring phone photographs, driver monitoring in cars, eye tracking for augmented-reality glasses and always-on audio in wearables are all candidates. The history of computing suggests the eventual answer will be something few people predicted. What to do differently For an engineer or team lead, the practical upshot is to treat neuromorphic technology as a specialised instrument rather than a general upgrade. Use the five questions of Chapter 9 to screen applications. Where the answers point to it, build the whole loop around it from the start, record with the real sensor in the real conditions, train for sparsity, and measure the system. Where the answers do not, stay conventional without regret. For a researcher, the upshot is to publish in the currency that decides adoption: whole-system latency and power, honest baselines, standard benchmarks such as NeuroBench, and closed-loop results on real platforms. The field has enough demonstrations that a spiking network can perform a task. It needs more demonstrations that a whole system performs it better than the alternative. For a manager or investor, the upshot is to discount claims made at the level of operations or chip cores, to ask what idle power and interface costs look like, and to look for products in which the neuromorphic component sits at the boundary between a physical sensor and the rest of the system, where its advantages are structural rather than incidental. Carver Mead's founding argument was that nature had found a better way to compute in a world of change. Thirty-five years later, that argument has been confirmed in a narrower form than he hoped, and a sharper one. Machines that let silence be cheap and act at the moment something happens really do outperform machines that sample everything on a schedule, provided that every stage between sensing and action respects the same principle. The fly has always worked that way. The engineering task now is to build machines that do so from end to end. Notes Introduction 1. Carver Mead, "Neuromorphic electronic systems," Proceedings of the IEEE 78, no. 10 (1990): 1629–1636. 2. Misha Mahowald and Carver Mead, "The silicon retina," Scientific American 264, no. 5 (1991): 76–82. 3. Federico Paredes-Vallés, Jesse J. Hagenaars, Julien Dupeyroux, Stein Stroobants, Yingfu Xu and Guido C. H. E. de Croon, "Fully neuromorphic vision and control for autonomous drone flight," Science Robotics 9, no. 90 (2024): eadi0591. Chapter 1 1. Mark Horowitz, "Computing's energy problem (and what we can do about it)," IEEE International Solid-State Circuits Conference Digest of Technical Papers (2014): 10–14. 2. John Backus, "Can programming be liberated from the von Neumann style? A functional style and its algebra of programs," Communications of the ACM 21, no. 8 (1978): 613–641 (the 1977 Turing Award lecture). 3. Frederico A. C. Azevedo, Suzana Herculano-Houzel and colleagues, "Equal numbers of neuronal and nonneuronal cells make the human brain an isometrically scaled-up primate brain," Journal of Comparative Neurology 513, no. 5 (2009): 532–541. 4. David Attwell and Simon B. Laughlin, "An energy budget for signaling in the grey matter of the brain," Journal of Cerebral Blood Flow and Metabolism 21, no. 10 (2001): 1133–1145. 5. Peter Lennie, "The cost of cortical computation," Current Biology 13, no. 6 (2003): 493–497. 6. Mead, "Neuromorphic electronic systems" (1990); Mahowald and Mead, "The silicon retina" (1991). Chapter 2 1. Patrick Lichtsteiner, Christoph Posch and Tobi Delbruck, "A 128×128 120 dB 15 µs latency asynchronous temporal contrast vision sensor," IEEE Journal of Solid-State Circuits 43, no. 2 (2008): 566–576. 2. Christoph Posch, Daniel Matolin and Rainer Wohlgenannt, "A QVGA 143 dB dynamic range frame-free PWM image sensor with lossless pixel-level video compression and time-domain CDS," IEEE Journal of Solid-State Circuits 46, no. 1 (2011): 259–275. 3. Christian Brandli, Raphael Berner, Minhao Yang, Shih-Chii Liu and Tobi Delbruck, "A 240×180 130 dB 3 µs latency global shutter spatiotemporal vision sensor," IEEE Journal of Solid-State Circuits 49, no. 10 (2014): 2333–2341. 4. Bongki Son and colleagues, "A 640×480 dynamic vision sensor with a 9µm pixel and 300Meps address-event representation," IEEE International Solid-State Circuits Conference (2017). 5. Yunjae Suh and colleagues, "A 1280×960 dynamic vision sensor with a 4.95-µm pixel pitch and motion artifact minimization," IEEE International Symposium on Circuits and Systems (2020). 6. Thomas Finateu and colleagues, "A 1280×720 back-illuminated stacked temporal contrast event-based vision sensor with a 4.86µm pixel, 1.066GEPS readout, programmable event-rate controller and compressive data-formatting pipeline," IEEE International Solid-State Circuits Conference (2020). 7. Prophesee, "IMX636 HD sensor" technical documentation (docs.prophesee.ai), for resolution, pixel size, power, event rate and temperature range. 8. Gregory Cohen and colleagues, "Event-based sensing for space situational awareness," Journal of the Astronautical Sciences (2019). Chapter 3 1. Guillermo Gallego and colleagues, "Event-based vision: A survey," IEEE Transactions on Pattern Analysis and Machine Intelligence 44, no. 1 (2022): 154–180. 2. Xavier Lagorce, Garrick Orchard, Francesco Galluppi, Bertram E. Shi and Ryad B. Benosman, "HOTS: A hierarchy of event-based time-surfaces for pattern recognition," IEEE Transactions on Pattern Analysis and Machine Intelligence 39, no. 7 (2017): 1346–1359. 3. Alex Zihao Zhu, Liangzhe Yuan, Kenneth Chaney and Kostas Daniilidis, "Unsupervised event-based learning of optical flow, depth, and egomotion," IEEE/CVF Conference on Computer Vision and Pattern Recognition (2019). 4. Daniel Gehrig, Antonio Loquercio, Konstantinos G. Derpanis and Davide Scaramuzza, "End-to-end learning of representations for asynchronous event-based data," IEEE/CVF International Conference on Computer Vision (2019). 5. Simon Schaefer, Daniel Gehrig and Davide Scaramuzza, "AEGNN: Asynchronous event-based graph neural networks," IEEE/CVF Conference on Computer Vision and Pattern Recognition (2022). 6. Ryad Benosman, Charles Clercq, Xavier Lagorce, Sio-Hoi Ieng and Chiara Bartolozzi, "Event-based visual flow," IEEE Transactions on Neural Networks and Learning Systems 25, no. 2 (2014): 407–417. 7. Guillermo Gallego, Henri Rebecq and Davide Scaramuzza, "A unifying contrast maximization framework for event cameras, with applications to motion, depth, and optical flow estimation," IEEE/CVF Conference on Computer Vision and Pattern Recognition (2018). 8. Hanme Kim, Stefan Leutenegger and Andrew J. Davison, "Real-time 3D reconstruction and 6-DoF tracking with an event camera," European Conference on Computer Vision (2016). 9. Henri Rebecq, Timo Horstschaefer, Guillermo Gallego and Davide Scaramuzza, "EVO: A geometric approach to event-based 6-DOF parallel tracking and mapping in real time," IEEE Robotics and Automation Letters 2, no. 2 (2017): 593–600. 10. Antoni Rosinol Vidal, Henri Rebecq, Timo Horstschaefer and Davide Scaramuzza, "Ultimate SLAM? Combining events, images, and IMU for robust visual SLAM in HDR and high-speed scenarios," IEEE Robotics and Automation Letters 3, no. 2 (2018): 994–1001. 11. Elias Mueggler, Chiara Bartolozzi and Davide Scaramuzza, "Fast event-based corner detection," British Machine Vision Conference (2017). 12. Daniel Gehrig, Henri Rebecq, Guillermo Gallego and Davide Scaramuzza, "EKLT: Asynchronous photometric feature tracking using events and frames," International Journal of Computer Vision 128 (2020): 601–618. 13. Garrick Orchard, Ajinkya Jayawant, Gregory K. Cohen and Nitish Thakor, "Converting static image datasets to spiking neuromorphic datasets using saccades," Frontiers in Neuroscience 9 (2015): 437. 14. Arnon Amir and colleagues, "A low power, fully event-based gesture recognition system," IEEE Conference on Computer Vision and Pattern Recognition (2017). 15. Alex Zihao Zhu and colleagues, "The multivehicle stereo event camera dataset: An event camera dataset for 3D perception," IEEE Robotics and Automation Letters 3, no. 3 (2018): 2032–2039. 16. Mathias Gehrig, Willem Aarents, Daniel Gehrig and Davide Scaramuzza, "DSEC: A stereo event camera dataset for driving scenarios," IEEE Robotics and Automation Letters 6, no. 3 (2021): 4947–4954. 17. Etienne Perot, Pierre de Tournemire, Davide Nitti, Jonathan Masci and Amos Sironi, "Learning to detect objects with a 1 megapixel event camera," Advances in Neural Information Processing Systems 33 (2020). 18. Alex Zihao Zhu, Liangzhe Yuan, Kenneth Chaney and Kostas Daniilidis, "EV-FlowNet: Self-supervised optical flow estimation for event-based cameras," Robotics: Science and Systems (2018). 19. Henri Rebecq, René Ranftl, Vladlen Koltun and Davide Scaramuzza, "Events-to-video: Bringing modern computer vision to event cameras," IEEE/CVF Conference on Computer Vision and Pattern Recognition (2019). 20. Nico Messikommer, Daniel Gehrig, Antonio Loquercio and Davide Scaramuzza, "Event-based asynchronous sparse convolutional networks," European Conference on Computer Vision (2020). 21. Daniel Gehrig and Davide Scaramuzza, "Low-latency automotive vision with event cameras," Nature 629 (2024): 1034–1040. Chapter 4 1. Wolfgang Maass, "Networks of spiking neurons: The third generation of neural network models," Neural Networks 10, no. 9 (1997): 1659–1671. 2. Louis Lapicque, "Recherches quantitatives sur l'excitation électrique des nerfs traitée comme une polarisation," Journal de Physiologie et de Pathologie Générale 9 (1907): 620–635. 3. Guillaume Bellec, Darjan Salaj, Anand Subramoney, Robert Legenstein and Wolfgang Maass, "Long short-term memory and learning-to-learn in networks of spiking neurons," Advances in Neural Information Processing Systems 31 (2018). 4. Eugene M. Izhikevich, "Simple model of spiking neurons," IEEE Transactions on Neural Networks 14, no. 6 (2003): 1569–1572. 5. A. L. Hodgkin and A. F. Huxley, "A quantitative description of membrane current and its application to conduction and excitation in nerve," Journal of Physiology 117, no. 4 (1952): 500–544. 6. Simon Thorpe, Denis Fize and Catherine Marlot, "Speed of processing in the human visual system," Nature 381 (1996): 520–522. 7. Yongqiang Cao, Yang Chen and Deepak Khosla, "Spiking deep convolutional neural networks for energy-efficient object recognition," International Journal of Computer Vision 113 (2015): 54–66. 8. Peter U. Diehl and colleagues, "Fast-classifying, high-accuracy spiking deep networks through weight and threshold balancing," International Joint Conference on Neural Networks (2015). 9. Bodo Rueckauer, Iulia-Alexandra Lungu, Yuhuang Hu, Michael Pfeiffer and Shih-Chii Liu, "Conversion of continuous-valued deep networks to efficient event-driven networks for image classification," Frontiers in Neuroscience 11 (2017): 682. 10. Emre O. Neftci, Hesham Mostafa and Friedemann Zenke, "Surrogate gradient learning in spiking neural networks," IEEE Signal Processing Magazine 36, no. 6 (2019): 51–63. 11. Friedemann Zenke and Surya Ganguli, "SuperSpike: Supervised learning in multilayer spiking neural networks," Neural Computation 30, no. 6 (2018): 1514–1541. 12. Sumit Bam Shrestha and Garrick Orchard, "SLAYER: Spike layer error reassignment in time," Advances in Neural Information Processing Systems 31 (2018). 13. Jason K. Eshraghian and colleagues, "Training spiking neural networks using lessons from deep learning," Proceedings of the IEEE 111, no. 9 (2023): 1016–1054. 14. Wei Fang and colleagues, "SpikingJelly: An open-source machine learning infrastructure platform for spike-based intelligence," Science Advances 9, no. 40 (2023): eadi1480. 15. Guo-qiang Bi and Mu-ming Poo, "Synaptic modifications in cultured hippocampal neurons: Dependence on spike timing, synaptic strength, and postsynaptic cell type," Journal of Neuroscience 18, no. 24 (1998): 10464–10472. 16. Peter U. Diehl and Matthew Cook, "Unsupervised learning of digit recognition using spike-timing-dependent plasticity," Frontiers in Computational Neuroscience 9 (2015): 99. 17. Guillaume Bellec and colleagues, "A solution to the learning dilemma for recurrent networks of spiking neurons," Nature Communications 11 (2020): 3625. Chapter 5 1. Paul A. Merolla and colleagues, "A million spiking-neuron integrated circuit with a scalable communication network and interface," Science 345, no. 6197 (2014): 668–673. 2. Dharmendra S. Modha and colleagues, "Neural inference at the frontier of energy, space, and time," Science 382, no. 6668 (2023): 329–335; IBM Research blog, "A new chip architecture points to faster, more energy-efficient AI" (2023). 3. Steve B. Furber, Francesco Galluppi, Steve Temple and Luis A. Plana, "The SpiNNaker project," Proceedings of the IEEE 102, no. 5 (2014): 652–665. 4. TU Dresden, "Milestone for energy-efficient AI systems: TUD launches SpiNNcloud supercomputer," press release, April 2025. 5. Mike Davies and colleagues, "Loihi: A neuromorphic manycore processor with on-chip learning," IEEE Micro 38, no. 1 (2018): 82–99. 6. Intel, "Intel builds world's largest neuromorphic system to enable more sustainable AI," press release, 17 April 2024. 7. Christian Pehle and colleagues, "The BrainScaleS-2 accelerated neuromorphic system with hybrid plasticity," Frontiers in Neuroscience 16 (2022): 795876. 8. SynSense, Speck hardware overview, Sinabs documentation. 9. IEEE Spectrum, report on the launch of Innatera's Pulsar neuromorphic microcontroller, May 2025. 10. Mike Davies and colleagues, "Advancing neuromorphic computing with Loihi: A survey of results and outlook," Proceedings of the IEEE 109, no. 5 (2021): 911–934. Chapter 6 1. Horowitz, "Computing's energy problem" (2014). 2. Steven Davidson and Steve B. Furber, "Comparison of artificial and spiking neural networks on digital hardware," Frontiers in Neuroscience 15 (2021): 651141. 3. Manon Dampfhoffer, Thomas Mesquida, Alexandre Valentian and Lorena Anghel, "Are SNNs really more energy-efficient than ANNs? An in-depth hardware-aware study," IEEE Transactions on Emerging Topics in Computational Intelligence (2023). 4. Paredes-Vallés and colleagues (2024), and the accompanying TU Delft MAVLab summary, for network power, idle power and GPU comparison. 5. Noah T. Jafferis, E. Farrell Helbling, Michael Karpelson and Robert J. Wood, "Untethered flight of an insect-sized flapping-wing microscale aerial vehicle," Nature 570 (2019): 491–495. 6. Peter Blouw, Xuan Choo, Eric Hunsberger and Chris Eliasmith, "Benchmarking keyword spotting efficiency on neuromorphic hardware," Proceedings of the 7th Annual Neuro-inspired Computational Elements Workshop (2019). 7. Jason Yik and colleagues, "The neurobench framework for benchmarking neuromorphic computing algorithms and systems," Nature Communications 16 (2025). Chapter 7 1. Mandyam V. Srinivasan, Shaowu Zhang, Javaan S. Chahl, Erhardt Barth and Svetha Venkatesh, "How honeybees make grazing landings on flat surfaces," Biological Cybernetics 83 (2000): 171–183. 2. Davide Falanga, Kevin Kleber and Davide Scaramuzza, "Dynamic obstacle avoidance for quadrotors with event cameras," Science Robotics 5, no. 40 (2020): eaaz9712. 3. Sihao Sun, Giovanni Cioffi, Coen de Visser and Davide Scaramuzza, "Autonomous quadrotor flight despite rotor failure with onboard vision sensors: Frames vs. events," IEEE Robotics and Automation Letters 6, no. 2 (2021): 580–587. 4. Antonio Vitale, Alpha Renner, Celine Nauer, Davide Scaramuzza and Yulia Sandamirskaya, "Event-driven vision and control for UAVs on a neuromorphic chip," IEEE International Conference on Robotics and Automation (2021). 5. Julien Dupeyroux, Jesse J. Hagenaars, Federico Paredes-Vallés and Guido C. H. E. de Croon, "Neuromorphic control for optic-flow-based landing of MAVs using the Loihi processor," IEEE International Conference on Robotics and Automation (2021). 6. Jesse J. Hagenaars, Federico Paredes-Vallés and Guido C. H. E. de Croon, "Self-supervised learning of event-based optical flow with spiking neural networks," Advances in Neural Information Processing Systems 34 (2021). 7. Paredes-Vallés and colleagues, "Fully neuromorphic vision and control for autonomous drone flight" (2024). Chapter 8 1. Jörg Conradt and colleagues, "A pencil balancing robot using a pair of AER dynamic vision sensors," IEEE International Symposium on Circuits and Systems (2009). 2. Tobi Delbruck and Manuel Lang, "Robotic goalie with 3 ms reaction time at 4% CPU load using event-based dynamic vision sensor," Frontiers in Neuroscience 7 (2013): 223. 3. Roland S. Johansson and J. Randall Flanagan, "Coding and use of tactile signals from the fingertips in object manipulation tasks," Nature Reviews Neuroscience 10 (2009): 345–359. 4. Wang Wei Lee and colleagues, "A neuro-inspired artificial peripheral nervous system for scalable electronic skins," Science Robotics 4, no. 32 (2019): eaax2198. 5. Tasbolat Taunyazov and colleagues, "Event-driven visual-tactile sensing and learning for robots," Robotics: Science and Systems (2020). 6. Chiara Bartolozzi, Giacomo Indiveri and Elisa Donati, "Embodied neuromorphic intelligence," Nature Communications 13 (2022): 1024. 7. Guangzhi Tang, Arpit Shah and Konstantinos P. Michmizos, "Spiking neural network on neuromorphic hardware for energy-efficient unidimensional SLAM," IEEE/RSJ International Conference on Intelligent Robots and Systems (2019). 8. Gehrig and Scaramuzza, "Low-latency automotive vision with event cameras" (2024). Chapter 9 1. Gregor Lenz and colleagues, Tonic: event-based datasets and transformations library (open-source software, 2021 onward). 2. Henri Rebecq, Daniel Gehrig and Davide Scaramuzza, "ESIM: An open event camera simulator," Conference on Robot Learning (2018). 3. Yuhuang Hu, Shih-Chii Liu and Tobi Delbruck, "v2e: From video frames to realistic DVS events," IEEE/CVF Conference on Computer Vision and Pattern Recognition Workshops (2021). 4. Jens Egholm Pedersen and colleagues, "Neuromorphic intermediate representation: A unified instruction set for interoperable brain-inspired computing," Nature Communications 15 (2024). 5. Intel Labs, Lava software framework (open-source, released 2021). Conclusion 1. Dhireesha Kudithipudi and colleagues, "Neuromorphic computing at scale," Nature 637 (2025): 801–812. Glossary Address-event representation (AER). A communication scheme in which each spike or sensor event is transmitted as a digital address identifying its source, sent only at the moment it occurs. Used by event cameras and most neuromorphic processors. Contrast threshold. The relative change in brightness, measured on a logarithmic scale, that an event-camera pixel must see before it emits an event. Set by programmable bias currents. Contrast maximisation. A family of methods that estimate motion from events by finding the motion that, when used to warp events back to a common time, produces the sharpest image of edges. Dynamic range. The ratio between the brightest and darkest light levels a sensor can capture at once, usually expressed in decibels. Event cameras commonly exceed 120 dB. Event. The basic output of an event camera: a tuple giving a pixel's position, a timestamp and a polarity, emitted when that pixel's brightness changes past its threshold. Graded spike. A spike that carries a small integer value rather than a single bit, supported by Intel's Loihi 2 to make change-based networks efficient. Leaky integrate-and-fire (LIF) neuron. A spiking neuron model whose membrane potential accumulates weighted input spikes, decays towards rest over time, and emits a spike and resets when it crosses a threshold. Neuromorphic processor. A chip designed to run spiking or event-driven neural networks, typically with many small cores, local memory and spike-based communication, doing work only when spikes arrive. Optic flow. The apparent motion of the visual scene across a sensor caused by relative movement between the observer and its surroundings. Its expansion, or divergence, indicates time to contact. Polarity. The sign of an event: ON for an increase in brightness, OFF for a decrease. Surrogate gradient. A smooth stand-in for the derivative of a spike's all-or-nothing threshold, used during backpropagation so that spiking networks can be trained with gradient descent. Time-multiplexing. The practice, in digital neuromorphic cores, of using one small processing unit to update the stored state of many neurons in turn, rather than building a separate circuit for each neuron. Hashtags: #NeuromorphicComputing #NeuromorphicHardware #NeuromorphicEngineering #BrainInspiredComputing #SpikingNeuralNetworks #SNN #EventBasedSensors #EventBasedVision #EventCameras #DynamicVisionSensors #DVS #AsynchronousComputing #EventDrivenProcessing #SpikeBasedComputing #ArtificialNeurons #LeakyIntegrateAndFire #SpikeTimingDependentPlasticity #SurrogateGradientLearning #NeuromorphicProcessors #IntelLoihi #IBMTrueNorth #SpiNNaker #BrainScaleS #LowPowerAI #EnergyEfficientComputing #EdgeAI #RoboticPerception #AutonomousDrones #EventBasedOpticalFlow #NeuromorphicRobotics

Download the Book (PDF): Introduction Somewhere in a drainage culvert under a motorway, a sensor the size of a matchbox wakes up. It has been asleep for fifteen minutes, drawing a few millionths of an amp from a battery that was soldered in place four years ago and is expected to last six more. It switches on a pressure transducer, waits for the reading to settle, converts it, decides whether the water level has changed enough to be worth mentioning, and, if it has, powers up a radio for perhaps two seconds to transmit a few dozen bytes to a gateway on a lamp post half a kilometre away. Then it goes back to sleep. Nobody will look at this device again unless it fails. Its entire working life is an exercise in saying as little as possible, as rarely as possible, as cheaply as possible. Hundreds of kilometres away, in a data centre, a cloud service holds a record that represents that sensor. The record says what firmware the device is running, what reporting interval it has been told to use, when it was last heard from, and what its most recent reading was. An engineer can change the reporting interval in that record from fifteen minutes to five, because a storm is coming. The change is accepted instantly. The device, of course, knows nothing about it. It is asleep, and it will remain ignorant until it next wakes, connects, and asks whether anything has changed. The distance between those two pictures, the frugal, intermittent, physically embedded device and the always-on, apparently authoritative cloud record, is what Internet of Things architecture is about. It is easy to describe IoT as "connecting things to the internet", and that description has done a good deal of harm, because it suggests that the thing at the edge is simply a small computer that happens to be in an awkward place. It is not. It is a fundamentally different kind of participant in a distributed system, one that is absent most of the time, speaks through narrow and unreliable channels, cannot be physically reached when something goes wrong, and runs on an energy budget measured in a few thousand milliamp-hours for its whole life. The argument of this book This book argues one thing, and builds the rest around it: in IoT systems, the constraints of the device at the edge, above all its energy budget and its intermittent connectivity, should drive the architecture all the way up to the cloud, and not the other way round. The protocols that have succeeded in this field, MQTT foremost among them, succeeded because they were designed from the device outward. The cloud abstractions that work, such as the device twin, work because they accept that the cloud never really knows the device's current state; it knows only what the device last said and what someone last asked for. Gateways earn their place because they absorb the mismatch between the world of sleeping sensors and the world of permanently connected servers. And battery life is not a hardware specification to be checked at the end of a project. It is the master variable that every other decision spends from. Systems that are designed the other way round, starting from a cloud dashboard and working down towards the device, tend to fail in recognisable ways. They poll devices that should be sleeping. They assume a request will receive an immediate response. They treat a disconnection as an error rather than as the normal state of affairs. They ship firmware that cannot be updated, credentials that cannot be rotated, and data models that cannot evolve. Each of these failures is cheap to prevent on a whiteboard and very expensive to fix once ten thousand devices are bolted to walls, buried in fields or sealed inside machinery. What is covered, and what is not The book follows the path a measurement takes from the physical world to a cloud application, and the path a command takes back. Chapter 1 sets out the constraint stack: why energy, bandwidth, intermittency, physical inaccessibility and fleet scale make IoT a distinct engineering discipline rather than a variant of web development. Chapter 2 looks at the radios and network topologies that sensor networks are built on, from Bluetooth Low Energy and Thread meshes to LoRaWAN and the cellular low-power standards, because the choice of radio fixes so much of what follows. Chapter 3 is a close study of MQTT: its publish-subscribe model, topic design, quality-of-service levels, sessions, retained messages and the improvements of version 5. Chapter 4 places MQTT alongside its main alternatives, including CoAP, LwM2M, MQTT-SN and plain HTTP, and explains when each is the better fit. Chapter 5 turns to edge gateways: what they are for, what they should and should not do, and how industrial deployments use them to bridge older fieldbus equipment into modern messaging. Chapter 6 examines the device twin, or shadow, the cloud-side model of device state, and the subtle problems of versioning, conflict and staleness that come with it. Chapter 7 is about battery life: how to build an energy budget, where the energy actually goes, and the techniques, from duty cycling to cellular power-saving modes, that turn a battery life of months into one of a decade. Chapter 8 deals with security and the long life of a fleet: identity, provisioning, over-the-air updates and the regulations that, since 2024, have begun to make good practice a legal requirement in several markets. Several things are deliberately left out. This is not a book about data analytics, machine learning on sensor data, or the business case for IoT; those questions matter, but they sit downstream of the architecture described here and deserve their own treatment. It is not a vendor guide. Cloud IoT services are mentioned where their design illustrates a general principle, but the products change faster than the principles, and one of the lessons of the past few years is that a platform can disappear. It does not try to teach embedded programming or radio-frequency engineering, though it explains enough of both for an architect to have a sensible conversation with the specialists. And it concentrates on telemetry and control systems: fleets of sensors and actuators that report data and receive configuration. Consumer smart-home ecosystems appear where they illuminate something, but they are not the focus. Who this is for The intended reader is someone who must make or review architectural decisions about connected devices without necessarily being a specialist in every layer: a software engineer moving from cloud services towards hardware, a hardware engineer who has to choose a messaging protocol, a technical lead inheriting a fleet, or a product manager who needs to understand why the firmware team keeps saying no. The book assumes basic familiarity with networking ideas such as TCP, IP addresses and the client-server model, and with the general shape of cloud computing. It does not assume any prior knowledge of MQTT, of radio standards or of embedded power management. The examples are drawn from the kinds of systems that make up most real IoT deployments: environmental and utility metering, asset tracking, building management, agriculture and industrial monitoring. These are less glamorous than talking appliances, but they are where the hard architectural lessons have been learned, because they are the deployments where devices must run unattended for years, where a site visit costs more than the device, and where getting the design wrong is paid for in truck rolls and replaced batteries. A note on numbers IoT is a field thick with impressive-sounding figures: billions of connected devices, battery lives of fifteen years, ranges of fifteen kilometres. Many of these figures are true under particular conditions and misleading under most others. A radio's quoted range is usually a best case in open country with a clear line of sight. A quoted battery life usually assumes a specific reporting interval, temperature and payload size. Where this book gives numbers, it either attributes them to a standard or a published specification, or presents them explicitly as illustrative assumptions in a worked calculation, so that the reader can see how the result depends on them. The habit of asking "under what assumptions?" whenever a number is quoted is perhaps the single most useful professional reflex in this field, and the chapters that follow try to model it. The culvert sensor will appear again. It is a useful companion, because it embodies all the constraints at once: it must last for years on a small battery, it is out of reach, its radio link is marginal, it is one of thousands, and the people who depend on its data do not care how it works, only that it does. Every architectural decision in this book can be tested by asking what it would cost that small device, and whether the cost is worth paying. Chapter 1: The Constraint Stack Most software architecture begins with a set of comfortable assumptions so deeply embedded that nobody states them. The server is on. The network is there. If a request fails, it can be retried in a second or two. If a machine misbehaves, someone can log into it, read its logs and restart it. If the code is wrong, a new version can be deployed this afternoon. Memory and processing are cheap enough that a framework's overhead is rarely worth worrying about. Energy is somebody else's problem, paid for on a utility bill. IoT removes every one of these assumptions, often all at once. The result is not merely a harder version of familiar engineering but a different set of priorities. It helps to lay the constraints out as a stack, because they interact: a decision that eases one tends to tighten another, and the art of IoT architecture is largely the art of trading between them knowingly. Energy: the constraint that spends all the others At the bottom of the stack sits energy. A mains-powered gateway or an industrial controller wired into a machine can be treated, for most purposes, like any other computer. But a large share of the devices that make IoT economically interesting, the sensors that justify themselves precisely because they can be placed anywhere without cabling, run on batteries or harvested energy. For those devices, energy is not one constraint among many. It is the currency in which every other choice is priced. Consider what a battery-powered device actually does with its energy. A microcontroller in a deep sleep state might draw a microamp or two. Awake and computing, it might draw a few milliamps. Its radio, while transmitting, might draw anywhere from ten milliamps for a Bluetooth Low Energy chip to a couple of hundred milliamps, with short peaks well above that, for a cellular modem. The sensor itself may need to be powered and given time to stabilise. Each of these states lasts for a different length of time, and the device's lifetime is determined by the weighted sum of them all. The arithmetic has a consequence that surprises people coming from conventional software: what dominates the energy budget is usually not computation but communication, and within communication, not the payload but the overhead around it. Waking a cellular modem, registering with the network, establishing a TCP connection and negotiating a TLS session can cost far more energy than transmitting the twenty bytes of data that prompted the whole exercise. A chatty protocol, one that needs several round trips before useful data can flow, is therefore not just slow in an IoT context. It is directly shortening the device's life. A message that could have been batched with the next one, but was not, cost real battery capacity. A server that asks a device to stay connected so it can be polled is asking it to burn energy listening for something that may never come. This is why the book places energy first. Nearly every protocol feature and architectural pattern discussed in later chapters can be read as an attempt to spend less energy per useful bit of information delivered: compact binary encodings, persistent sessions that avoid renegotiation, publish-subscribe rather than polling, local filtering at the edge so that only meaningful changes are sent, and cloud-side state models that let the device be absent without anyone needing it to be present. Bandwidth, latency and the cost of a byte Above energy sits the network itself. IoT links are frequently narrow. A LoRaWAN device at its most robust settings may achieve an effective data rate of a few hundred bits per second and, in European bands, must observe regulatory duty-cycle limits that cap the fraction of time it may transmit at all. A Narrowband IoT connection in deep indoor coverage may need to repeat each transmission many times to be heard, multiplying both latency and energy. Satellite IoT services, which have grown quickly in the last few years for remote assets, often charge by the message or by the kilobyte and may have latencies measured in minutes. On such links, a byte has a cost that is easy to feel. A JSON payload with verbose key names, sent over a connection with hundreds of bytes of protocol headers, may be ten times larger than the information it conveys. That is irrelevant on a fibre connection to a web server and decisive on a link that can carry a few dozen bytes per transmission. IoT architects learn to look at a message the way a telegraph operator once looked at a sentence: every word must earn its place. Latency matters in a different way. Many IoT systems are not latency-sensitive in the conventional sense; a temperature reading that arrives thirty seconds late is usually fine. But they are often latency-intolerant in a subtler sense. A cloud application that sends a command and waits for a response may wait minutes, hours or days if the device is a sleeping sensor that only checks in occasionally. Architectures that assume synchronous request-response between cloud and device break immediately under these conditions. The patterns that work, which later chapters describe in detail, are asynchronous: the cloud records an intention, the device acts on it when it can, and both sides reconcile later. Intermittency as the normal case The third layer is intermittency. In conventional distributed systems, a disconnected node is a fault. Monitoring systems raise alerts, failover mechanisms engage, and engineers are paged. In IoT, a disconnected node is often simply a device doing its job. The culvert sensor from the introduction is disconnected for more than ninety-nine per cent of its life, by design. A delivery van's tracker loses coverage in tunnels and rural valleys. A wearable leaves the range of its paired phone. A gateway on a farm loses its cellular backhaul when the weather turns. Treating disconnection as normal has deep consequences. It means that every message path must have an answer to the question "what happens if the other side is not there?" Should the device buffer readings and send them later, and if so, how many, and what happens when the buffer fills? Should the cloud queue commands, and for how long, and what if a newer command supersedes an older one that has not yet been delivered? When a device reconnects after a long absence, how does it learn what it missed, and how does the cloud learn what the device did while it was away? It also means that the cloud's view of the device is always, to some degree, a historical document. The record says the device's battery was at seventy per cent; it was, when the device last reported, which may have been an hour or a week ago. Good IoT systems are explicit about this. They record timestamps for every piece of reported state, distinguish clearly between what the device last said and what the operator wants, and make the age of information visible to anyone who relies on it. Poor systems present stale data as if it were current, and their users eventually make decisions on the basis of a device that died last Tuesday. Physical inaccessibility and the long tail of time The fourth constraint is that devices are hard to reach. A smart meter is on the wall of a private home. A soil moisture probe is buried in a field. A vibration sensor is bolted inside a pump housing that cannot be opened without shutting down a production line. A structural monitor is on the underside of a bridge. When such a device misbehaves, the options are limited: whatever can be done remotely, through the same narrow and intermittent link the device uses for its data, or a physical visit that may cost more than the device itself. Physical inaccessibility turns several ordinary software practices into architectural requirements. Remote firmware update is not a convenience but a necessity, because without it every bug and every security vulnerability is permanent. The update mechanism itself must be extraordinarily robust, since a failed update that leaves a device unbootable cannot be fixed by someone with a USB cable. Diagnostic information must be designed in from the start, because there will be no opportunity to attach a debugger later. Devices must recover from their own failures, using watchdog timers that reset a hung processor and fallback configurations that restore connectivity if a new setting turns out to be wrong. Inaccessibility combines with time. IoT deployments often have lifetimes measured in a decade or more. Utility meters, building controls and industrial sensors are expected to outlast several generations of smartphones, several versions of every cloud API, and, quite possibly, the companies that made them. Cryptographic algorithms considered strong at installation may be weak by the end of the device's life. Cellular networks that devices depend on can be switched off: operators around the world have retired their 2G and 3G networks, stranding devices that could not move to newer technologies, and in late 2024 AT&T announced that it would decommission its NB-IoT network and migrate customers to LTE-M. Cloud platforms can be withdrawn as well. Google retired its Cloud IoT Core service in August 2023, obliging every customer to migrate their device connectivity elsewhere. An architecture that ties devices too tightly to one network technology or one cloud vendor's proprietary interfaces is making a bet about the next ten years that it may lose. Scale and heterogeneity The last layer is scale. A single device is a gadget. Ten thousand devices are a fleet, and fleets have properties that individual devices do not. Small error rates become large absolute numbers: a failure mode that affects one device in a thousand will affect ten devices every time a fleet of ten thousand is updated. Synchronised behaviour becomes dangerous: if every device reconnects at the same moment after a network outage, the resulting surge can overwhelm the server that is trying to welcome them back, a problem engineers call a thundering herd. Configuration drift becomes inevitable: devices installed at different times, updated at different times and repaired with different spare parts will, without careful management, end up running a bewildering variety of firmware versions and settings. Scale also brings heterogeneity. Real fleets are rarely uniform. A building management system might include battery-powered temperature sensors on a mesh network, mains-powered air handlers on an industrial fieldbus, occupancy sensors from a different vendor speaking a different protocol, and a gateway that must make sense of all of them. Each device type has its own constraints, its own update cadence and its own failure modes. The architecture must accommodate this mess, not wish it away. Cost, multiplied Running through all five layers is a constraint that is easy to forget because it is so ordinary: money. In conventional software, the marginal cost of serving one more user is small, and an inefficient design can often be rescued by buying more servers. In IoT, every design decision that touches the device is multiplied by the size of the fleet, and many of them recur for the device's whole life. The device's bill of materials is the most visible part. A secure element, an extra megabyte of flash, a larger battery or a more capable radio may each add a modest amount to the unit cost, but across a hundred thousand units the total becomes a line in the business plan, and product managers will rightly ask what each addition buys. This creates steady pressure to strip devices to the minimum, and it is one reason that architects must be able to explain, in concrete terms, why a second firmware slot or a hardware key store is not optional. Recurring costs are less visible and often larger. Cellular connectivity is usually paid for by subscription or by data volume, so a protocol that sends twice as many bytes as necessary roughly doubles a recurring charge for every device, every month, for a decade. Cloud services charge per message, per connection minute, per stored record or per rule evaluation, and an architecture that forwards every raw reading to the cloud when it could have forwarded a summary pays for that choice continuously. Then there is the cost that dominates many deployments: the site visit. Sending a technician to replace a battery, reset a hung device or reflash firmware involves travel, labour, access arrangements and sometimes the shutdown of the equipment being monitored. For a device installed on a remote pipeline, in a sealed meter cabinet or on a high structure, a single visit can easily cost more than the device itself. An architecture that extends battery life from three years to eight, or that allows a misbehaving device to be repaired remotely, is therefore not saving energy for its own sake. It is removing the most expensive recurring event in the device's life. Much of what this book recommends can be justified on these grounds alone, and it is often the economic argument, rather than the technical one, that persuades an organisation to invest in doing things properly. How the constraints interact The value of seeing these constraints as a stack is that it reveals the trade-offs between them. Some examples make the interactions concrete. Security costs energy. Establishing an authenticated, encrypted session requires computation and, more importantly, extra message exchanges. A device that tears down its connection between readings to save idle power must pay that setup cost every time it reconnects. Protocol features that resume sessions without a full handshake, or long-lived connections maintained with minimal keepalive traffic, are attempts to reconcile security with the energy budget. Skipping security to save energy is not an acceptable resolution, as Chapter 8 makes clear, but it is a temptation that the constraint stack creates. Responsiveness costs energy. A device that must respond to commands within seconds has to keep its receiver on, or wake very frequently to check for messages. A device that can tolerate commands arriving within an hour can sleep almost all the time. The question "how quickly does this device need to react to the cloud?" is therefore one of the most consequential product decisions in an IoT system, and it is often asked far too late, after a radio and a battery have already been chosen. Local intelligence trades energy and cost against bandwidth. Doing more processing on the device, or at a nearby gateway, can drastically reduce the volume of data that must cross the expensive part of the network. A vibration sensor that computes a frequency spectrum locally and sends a summary uses far less radio time than one that streams raw waveforms. But local processing needs a more capable processor, more memory and more energy for computation, and it moves complexity into the hardest place in the system to update. Robustness costs memory. Buffering readings during an outage, keeping two firmware images so an update can be rolled back, and storing enough logs to diagnose a failure all require storage that a minimal device may not have. Every byte of flash memory is a cost multiplied by the size of the fleet. Designing from the edge outward The practical conclusion of this chapter is a design discipline. When planning an IoT system, start with the most constrained device in the fleet and work outward. Ask how much energy it has for its whole life, how long it must last, how often it can afford to transmit, how long it can afford to listen, what link it will use, how big its messages can be, how it will be updated and what happens when it is out of contact. Only then design the gateway, the messaging layer and the cloud services, and design them to fit what the device can actually do. This sounds obvious, but organisations very often do the reverse. A cloud team designs an API and a data model, a product team designs a dashboard with real-time updates, and the firmware team is asked to make the device fit. The result is a device that is asked to report more often than its battery allows, to accept commands it cannot receive while asleep and to speak a protocol that is more expensive than its link can bear. The rest of this book is, in a sense, an extended argument for reversing that order, beginning with the physical layer where the device meets the world: the radios and network topologies that determine how, and how expensively, a sensor can speak at all. Chapter 2: Radios and Sensor Networks Every IoT architecture rests on a choice of radio, and that choice is made earlier, and reversed less easily, than almost any other. Once a printed circuit board has been designed around a particular radio module, certified for emissions in each target market and manufactured in volume, changing it means a new hardware revision. The radio determines how far a device can be from its nearest point of connection, how much data it can send, how much energy each transmission costs, whether it can receive commands at all while saving power, whether it needs a gateway, and whether somebody else's network must be paid for. Many decisions that look like software choices later turn out to have been made by the radio. This chapter surveys the main families of radio used in sensor networks and the topologies they support. The goal is not to make the reader an RF engineer but to make clear which architectural properties follow from which radio choice, so that the decision is made with its consequences in view. Three families, three trade-offs It is useful to group IoT radios into three broad families according to the job they do. The first is short-range personal and local area radios: Bluetooth Low Energy, the IEEE 802.15.4 family that underlies Zigbee and Thread, and ordinary Wi-Fi. These operate mostly in the licence-free 2.4 GHz band, cover distances from a few metres to a few tens of metres indoors, and offer data rates from hundreds of kilobits to many megabits per second. They are cheap, well understood and built into enormous numbers of chips. Their limitation is range, which means they almost always need a nearby gateway, hub or phone to reach the internet. The second is low-power wide-area networks, usually shortened to LPWAN, operating in unlicensed sub-gigahertz bands. LoRaWAN is the most widely deployed of these, and Sigfox, the ultra-narrowband system that popularised the category, still operates under new ownership after its original company entered receivership in 2022 and was acquired by UnaBiz. These radios trade data rate for range and energy efficiency: a LoRaWAN device can reach a gateway several kilometres away in open terrain, at data rates of a few hundred bits to a few kilobits per second, using very little energy per message. They are designed for devices that send small amounts of data infrequently. The third is cellular IoT, the low-power variants of 4G and 5G standardised by the 3GPP: LTE-M (also called LTE Cat-M1) and NB-IoT, both introduced in 3GPP Release 13 in 2016 and carried forward into the 5G era. These operate in licensed spectrum on mobile operators' networks. They offer wide coverage without the need for the customer to deploy any gateways at all, at the cost of subscription fees, dependence on an operator, and generally higher energy per message than LPWAN, although their power-saving features, discussed in Chapter 7, narrow that gap considerably. Table 1 compares representative members of these families on the attributes that matter most for architecture. The figures are indicative, drawn from the respective specifications and typical published performance; real-world range and throughput depend heavily on antennas, terrain, buildings and interference. Table 1. Indicative characteristics of common IoT radio technologies. Technology Spectrum Typical range Data rate Topology Gateway needed Bluetooth Low Energy 2.4 GHz unlicensed Tens of metres Up to 2 Mbit/s Star, mesh option Yes (hub or phone) Zigbee / Thread 2.4 GHz unlicensed Tens of metres per hop 250 kbit/s Mesh Yes (coordinator or border router) Wi-Fi 2.4 / 5 GHz unlicensed Tens of metres Many Mbit/s Star No (uses access point) LoRaWAN Sub-GHz unlicensed Kilometres ~0.3 to ~50 kbit/s Star of stars Yes (LoRaWAN gateway) NB-IoT Licensed cellular Kilometres Tens of kbit/s Star (operator cell) No (operator network) LTE-M Licensed cellular Kilometres Up to ~1 Mbit/s Star (operator cell) No (operator network) Short-range radios and the mesh question Bluetooth Low Energy, introduced with the Bluetooth 4.0 specification in 2010, has become the default radio for anything that talks to a phone. Its design reflects that heritage: devices advertise their presence with short broadcast packets, a central device such as a phone scans for and connects to them, and data is exchanged through a structured attribute model. For IoT architecture, BLE's most interesting property is its advertising mode. A sensor can broadcast its readings inside advertising packets without ever forming a connection, and any nearby receiver can pick them up. Beacons and many asset-tracking systems work this way, with fixed gateways listening for broadcasts from tags passing through a warehouse or hospital. Later versions of the specification added a long-range coded physical layer that trades data rate for distance, and a mesh profile, though BLE mesh has seen narrower adoption than its alternatives. The IEEE 802.15.4 standard defines a low-power radio and medium access layer on which several network stacks are built. Zigbee, maintained by the Connectivity Standards Alliance, has been used for many years in home automation, lighting and smart energy. Thread, a newer stack, carries IPv6 packets over 802.15.4 using the 6LoWPAN compression scheme, which means every device on a Thread network has a real IP address and can be addressed end to end. Thread became much more prominent as one of the two main transports for Matter, the smart-home interoperability standard whose first version the Connectivity Standards Alliance released in October 2022. Both Zigbee and Thread are mesh networks, and the mesh topology has a property that matters a great deal for energy. In a mesh, messages hop from device to device until they reach a coordinator or border router that connects to the wider network. For this to work, the devices that relay traffic must have their receivers on, or at least on very frequently, because they cannot know when a neighbour will send them something to forward. Listening is expensive, so routing nodes in practice are mains powered: light bulbs, smart plugs, wall switches, thermostats. Battery-powered devices join the mesh as sleepy end devices. They attach to a parent router, sleep most of the time, and periodically wake to send their data and poll their parent for any messages that arrived while they were asleep. The parent holds those messages for them. This parent-child arrangement is a miniature version of a theme that recurs throughout the book. The constrained device is absent most of the time, and something more capable, here the parent router, later the gateway or the cloud's device twin, holds state on its behalf. The mesh works well when there are enough mains-powered nodes to form a robust routing backbone. It works poorly in a field of battery sensors with no infrastructure, which is exactly the setting where LPWAN radios come into their own. Wi-Fi is the outlier among short-range radios. It offers high throughput and uses infrastructure that is already present in most buildings, which makes it attractive for mains-powered devices such as cameras, appliances and displays. But conventional Wi-Fi was not designed for low power. Associating with an access point, obtaining an address and establishing a secured connection takes time and energy, and a Wi-Fi radio listening for traffic draws considerably more than an 802.15.4 or BLE radio. Battery-powered Wi-Fi devices exist and can work well if they wake rarely and transmit quickly, and newer standards include power-saving mechanisms such as target wake time, while the sub-gigahertz Wi-Fi HaLow variant, IEEE 802.11ah, targets longer range and lower power. As a general rule, though, Wi-Fi is the choice for devices with power to spare, not for sensors that must last years on a coin cell. LoRaWAN: the star of stars LoRaWAN deserves a closer look because its architecture embodies, very cleanly, several of the principles this book advocates. The LoRa physical layer, originally developed by the French company Cycleo and acquired by Semtech, uses a chirp spread spectrum modulation that allows signals to be decoded even when they are well below the noise floor. The LoRaWAN protocol on top of it is maintained by the LoRa Alliance. The key architectural idea is the star of stars. End devices do not connect to any particular gateway. They simply transmit, and every gateway within range that hears the transmission forwards it, over an ordinary internet connection, to a central network server. The network server removes duplicates, chooses the best gateway for any reply, manages security keys and passes the application payload to an application server. The gateways themselves are relatively simple packet forwarders. This means that adding gateways improves coverage and reliability without any device-side reconfiguration, and that a device moving between gateway areas needs no handover. The radio's robustness is adjustable through the spreading factor. Higher spreading factors spread each bit over more time, making the signal more resistant to noise and extending range, but they also make each transmission take much longer. A packet at the highest spreading factor can take more than a second on air, compared with tens of milliseconds at the lowest. Longer time on air means more energy per message and more spectrum occupancy. LoRaWAN's adaptive data rate mechanism lets the network server instruct a well-placed stationary device to use a lower spreading factor, saving energy and capacity, while devices at the edge of coverage keep a higher one. LoRaWAN devices fall into three classes that map directly onto the energy-responsiveness trade-off from Chapter 1. Class A devices, which every LoRaWAN device must support, open two short receive windows immediately after each uplink transmission and are otherwise deaf. The network can only send them a message in response to something they have sent. This is extremely economical, and it means downlink latency is bounded by the device's own reporting interval. Class B devices additionally open scheduled receive slots synchronised to beacons broadcast by the gateways, giving the network predictable opportunities to reach them at some extra energy cost. Class C devices keep their receiver open almost continuously, which makes them responsive to commands but suitable only for mains-powered equipment. Two regulatory realities shape LoRaWAN deployments. In the European 868 MHz band, many sub-bands impose a duty-cycle limit, commonly one per cent, on how much of the time a device may transmit. A device using a high spreading factor may therefore be legally limited to a modest number of messages per hour. And because the spectrum is unlicensed and shared, LoRaWAN traffic is never guaranteed; other users and other technologies compete for the same airwaves. Applications must tolerate lost messages, a fact that pushes towards designs in which each message carries enough context, such as cumulative counters rather than increments, to be interpreted correctly even if its predecessor never arrived. LoRaWAN can be deployed privately, with an organisation running its own gateways and network server, or through public and community networks. This flexibility is one of its attractions: a farm, a campus or a city can build exactly the coverage it needs without a subscription, but it also means the organisation is now operating radio infrastructure, with all that implies for maintenance. Cellular IoT: coverage you do not have to build LTE-M and NB-IoT approach the same problem from the other direction. Rather than asking customers to deploy gateways, they reuse the cellular infrastructure that mobile operators have already built, adding features for low-cost, low-power devices. NB-IoT is the more radical of the two. It uses a very narrow channel and a simplified protocol, supports only low data rates, and does not support handover between cells while connected, which makes it best suited to stationary devices such as meters. Its design target includes a substantial coverage enhancement over earlier cellular systems, achieved largely by repeating transmissions many times so that a weak signal can be accumulated and decoded. This is how NB-IoT reaches meters in basements and devices deep inside buildings, but the repetitions cost time and energy, so a device in poor coverage may use many times the energy per message of an identical device near a window. LTE-M is closer to conventional LTE. It supports higher data rates, mobility with handover between cells, and voice over LTE, which makes it suitable for wearables, trackers and alarm panels. It has proved somewhat more widely supported among operators in North America, and the AT&T decision to retire NB-IoT in favour of LTE-M illustrates that the two technologies are not equally safe bets in every market. For architecture, the important properties of cellular IoT are that devices connect through an operator, usually with a SIM or an embedded eSIM, that each device has an IP connection to the internet (often through operator network address translation), and that the operator's network supports power-saving modes in which the device can be unreachable for long periods while remaining registered. These power-saving modes, Power Saving Mode and extended discontinuous reception, are the cellular equivalent of LoRaWAN's device classes and are treated in Chapter 7. There is also a growing satellite dimension. The 3GPP's Release 17 added support for non-terrestrial networks, including an IoT variant, and several companies now offer satellite connectivity for sensors in places no terrestrial network reaches, such as oceans, pipelines and remote mines. The architectural consequences are the familiar ones in exaggerated form: very small messages, high cost per byte and long latencies. Choosing a radio by asking the right questions Because the radio choice is so consequential, it pays to make it by working through a short set of questions grounded in the constraint stack, rather than by habit or by what the last project used. Where is the device, and where is the nearest reliable power and internet connection? A device in a building with existing Wi-Fi and mains power faces a very different set of options from one in a field. Does the device move? Mobility rules out technologies without handover, and it rules out mesh designs that assume a stable topology. How much data does it send, and how often? A meter that reports once a day and a camera that streams video are not candidates for the same radio, but the more common mistake is choosing a high-throughput radio for a device that sends a few bytes an hour, and paying for that capacity in energy and cost. How quickly must the device respond to the cloud? This is the energy-responsiveness question again, and the radio's receive modes determine what is possible. Who operates the network, and for how long? Using a mobile operator's network removes the burden of infrastructure but introduces a dependency on that operator's commercial decisions. Operating a private network gives control but creates an infrastructure team. Either way, the device's lifetime must be compared honestly with the expected lifetime of the network it relies on. What are the regulatory constraints in each market? Frequency bands, duty-cycle limits and certification requirements differ by region, and a device intended for global sale may need variants or multi-band radios. These questions do not always produce a single answer, and real fleets often mix technologies: BLE sensors feeding a cellular gateway, a LoRaWAN network for outdoor assets alongside Thread inside buildings. What they do is ensure that the radio is chosen for the device that actually exists rather than for an imagined one. With the radio fixed, the next question is what to say over it, and that brings us to the protocol that has become, more than any other, the common language of IoT messaging. Chapter 3: MQTT in Depth In 1999, Andy Stanford-Clark of IBM and Arlen Nipper of Arcom faced a practical problem. They needed to monitor oil pipelines through remote telemetry units connected over satellite links that were slow, expensive and unreliable. The existing approaches either consumed too much of that precious bandwidth or coupled every data source tightly to every consumer. Their solution was a deliberately minimal messaging protocol built around a central broker, which they called MQ Telemetry Transport. The name is now treated simply as MQTT, and the protocol, after years of quiet use in industrial settings, was published as an OASIS standard in version 3.1.1 in 2014, adopted as the international standard ISO/IEC 20922 in 2016, and substantially extended in version 5.0, which OASIS approved in 2019. MQTT's origins explain nearly everything about its design. It was built for exactly the constraint stack described in Chapter 1: narrow links, intermittent connectivity, devices with little processing power, and a need to decouple the devices that produce data from the systems that consume it. It was designed from the device outward. That is why, a quarter of a century later, it remains the most widely used messaging protocol in IoT, supported by every major cloud IoT service and by a large ecosystem of open-source and commercial brokers. Publish, subscribe and the broker The central idea of MQTT is publish-subscribe through a broker. Clients never talk to each other directly. A client that has data to share publishes a message to a topic, a hierarchical string such as site/berlin/building-3/floor-2/room-214/temperature. A client that wants data subscribes to one or more topics. The broker sits between them, receiving every published message and forwarding a copy to every client whose subscriptions match the topic. This indirection is the protocol's most important property. A temperature sensor does not know, and does not need to know, whether its readings are consumed by one dashboard, three analytics services and a building management system, or by nothing at all. New consumers can be added without touching the device. A consumer that is restarted or replaced does not require the sensor to do anything differently. The coupling between producer and consumer has been reduced to agreement on a topic name and a payload format. Compare this with the alternative many teams reach for first: each device runs a small web server, or each device calls a cloud HTTP endpoint. In the first case, every consumer must know every device's address, the device must be reachable through firewalls and network address translation, and it must stay awake to answer requests. In the second, the device is coupled to one specific endpoint and must make a full HTTP request, with its relatively verbose headers, for each reading. MQTT inverts the first problem by having devices make outbound connections to the broker, which works naturally through firewalls and NAT, and it reduces the second by keeping a single, long-lived connection over which each message costs only a few bytes of overhead. That overhead is genuinely small. An MQTT control packet begins with a fixed header of as little as two bytes: one byte encoding the packet type and flags, and a variable-length field giving the remaining length. A keepalive ping is two bytes in each direction. A publish packet adds the topic name and, for higher quality-of-service levels, a two-byte packet identifier. There are no mandatory text headers, no content negotiation and no cookies. The payload itself is opaque to the protocol: MQTT carries bytes and does not care whether they encode JSON, a compact binary format such as CBOR or Protocol Buffers, or a single raw integer. MQTT runs over TCP, conventionally on port 1883 for unencrypted connections and 8883 for connections secured with TLS. It can also be carried over WebSockets, which allows browser-based applications to connect to a broker directly. The reliance on TCP is both a strength, because the transport handles ordering and retransmission, and a limitation, because TCP's connection setup and the TLS handshake on top of it are expensive for the most constrained devices. Chapter 4 discusses the alternatives for those cases. Designing topics Topic design looks like a trivial naming exercise and turns out to be one of the most consequential decisions in an MQTT system. Topics are hierarchical, with levels separated by forward slashes, and subscriptions can use two wildcards. The single-level wildcard + matches exactly one level, so site/+/building-3/# would match building 3 at any site. The multi-level wildcard #, which must appear last, matches any number of remaining levels, so site/berlin/# matches everything under the Berlin site. Because subscriptions select messages by topic, the topic hierarchy is effectively the query language of the system. A hierarchy organised by location makes it easy to subscribe to everything in a building and hard to subscribe to every temperature sensor across all buildings. A hierarchy organised by device type makes the opposite easy. There is no universally right answer, but several principles have emerged from experience. Put the device or entity identity in the topic, not only in the payload. A topic such as devices/pump-0042/telemetry lets the broker's access control rules restrict each device to its own subtree, and it lets consumers subscribe to one device without receiving and discarding everyone else's messages. Separate the direction and purpose of messages into distinct branches. A common pattern uses one subtree for telemetry flowing up from the device, another for commands flowing down, another for state or configuration, and another for events such as alarms. This makes permissions clear: a device may publish to its own telemetry topic and subscribe to its own command topic, but not the reverse. Avoid putting volatile values in topic names. A topic that includes a timestamp or a reading value creates an unbounded number of distinct topics, which defeats subscription matching and can strain the broker. Keep topics reasonably short on constrained links, since the full topic string is sent with every publish. MQTT 5's topic aliases, discussed below, address this directly. Finally, plan for the hierarchy to change. Fleets grow, organisations restructure, and a topic scheme designed for one site may not survive expansion to fifty. Including a version element near the root of the hierarchy, such as v1/, is a cheap insurance policy that allows a new scheme to be introduced alongside the old one during migration. Quality of service and what it really guarantees MQTT offers three quality-of-service levels for each published message, and they are frequently misunderstood. At QoS 0, sometimes called "at most once", the sender transmits the message and forgets about it. There is no acknowledgement. If the TCP connection breaks before the message is delivered, it is lost. This is the cheapest option and is entirely appropriate for frequent telemetry where the next reading will soon replace a lost one. At QoS 1, "at least once", the sender stores the message until it receives a PUBACK acknowledgement from the receiver. If the acknowledgement does not arrive, for example because the connection dropped, the sender retransmits the message after reconnecting, with a duplicate flag set. The message will be delivered, but it may be delivered more than once. Consumers must therefore be prepared for duplicates, typically by making their processing idempotent or by including an identifier or sequence number in the payload that allows duplicates to be recognised. At QoS 2, "exactly once", a four-step handshake of PUBLISH, PUBREC, PUBREL and PUBCOMP ensures that the receiver processes the message once and only once. This costs two full round trips per message and requires both sides to hold state about in-flight messages. The crucial subtlety is that these guarantees apply to each hop, not end to end. When a device publishes at QoS 2, the guarantee covers delivery from the device to the broker. Delivery from the broker to each subscriber happens at the lower of the publisher's QoS and the QoS the subscriber requested. More importantly, no MQTT guarantee extends beyond the broker into the application that ultimately consumes the message. If a subscriber receives a message exactly once but then crashes before writing it to a database, the message is lost from the application's perspective, and MQTT has no knowledge of that. Exactly-once processing in a real system is a property of the whole pipeline, achieved with idempotent writes and deduplication, not something a protocol flag can provide. In practice, most IoT systems use QoS 0 for high-frequency telemetry and QoS 1 for messages that matter, such as alarms, commands and state changes, combined with idempotent handling. QoS 2 is used more rarely, and teams that reach for it should ask whether they are paying its round-trip cost for a guarantee that does not actually extend as far as they think. Sessions, keepalive, retained messages and the last will Several further features make MQTT well suited to intermittent devices. A client connects with a client identifier, and the broker can maintain a session associated with that identifier. A persistent session survives disconnection: the broker remembers the client's subscriptions and queues messages published at QoS 1 or 2 to its subscribed topics while it is away. When the client reconnects with the same identifier, it does not need to resubscribe, and the queued messages are delivered. For a device that disconnects between reports to save energy, this means commands sent while it was offline will be waiting when it returns. In MQTT 3.1.1 this behaviour is controlled by a "clean session" flag. MQTT 5 splits it into a "clean start" flag and a separate session expiry interval, so that a client can say, in effect, "keep my session for the next six hours, but discard it after that", which prevents brokers from accumulating sessions for devices that will never return. The keepalive interval tells the broker how long it may go without hearing from a client before concluding that the connection is dead. If no other traffic flows, the client sends a tiny PINGREQ and the broker replies with PINGRESP. Choosing the interval is another trade-off. A short keepalive detects dead connections quickly but costs energy and, on cellular networks, may be needed anyway to prevent operator NAT devices from silently discarding an idle connection. A long keepalive saves energy but means that a device whose connection has silently failed may believe it is connected when it is not. A retained message is a message the broker stores against a topic and delivers immediately to any client that subscribes to that topic later. Only the most recent retained message per topic is kept. This solves a common problem: a dashboard that starts up does not have to wait for the next report to learn a device's current status, because the last retained status message is delivered at once. Retained messages are well suited to slowly changing state such as configuration, online status and the most recent reading of an infrequent sensor. They should be used with care for high-frequency data, and stale retained messages from decommissioned devices should be cleared, which is done by publishing an empty retained message to the topic. The last will and testament is a message that a client registers with the broker when it connects, to be published on its behalf if it disconnects ungracefully, for example because its power failed or its network vanished. Combined with a retained "online" message published at connection time, the last will lets every interested party learn when a device has gone offline without anyone needing to poll it. A common pattern looks like this: CONNECT client_id=pump-0042 will_topic=devices/pump-0042/status will_payload="offline" will_retain=true will_qos=1 PUBLISH devices/pump-0042/status "online" retain=true qos=1 If the device disconnects cleanly, it publishes "offline" itself. If it vanishes, the broker publishes the will when the keepalive expires. MQTT 5 adds a will delay interval, so a device that reconnects quickly after a brief network blip does not trigger a spurious offline notification. What MQTT 5 changed MQTT 3.1.1 was deliberately spare, and experience at scale exposed some gaps. Version 5.0 addressed many of them while preserving the protocol's character. Reason codes on acknowledgements let the broker explain why something failed, for example that a client was not authorised to publish to a topic or that a quota was exceeded. In 3.1.1, many failures resulted simply in the connection being closed, leaving the device to guess. User properties allow arbitrary key-value metadata to be attached to a message, much like HTTP headers, so that information such as a schema version, a trace identifier or a content type can travel alongside the payload without being embedded in it. Message expiry lets a publisher specify how long a message remains useful. A command to open a valve that has not been delivered within ten minutes may be dangerous rather than merely late, and an expiry interval ensures the broker discards it instead of delivering it hours afterwards when the device reconnects. Topic aliases let a client replace a long topic string with a short integer after the first use within a connection, saving bytes on every subsequent publish. Shared subscriptions, using a topic filter of the form $share/group-name/topic, allow several consumer instances to share the load of a subscription, with each message delivered to only one member of the group. Before this was standardised, scaling out the back-end consumers of a high-volume topic required broker-specific extensions. Request-response support, through a response topic and correlation data carried in the message properties, provides a standard way to implement command-and-reply patterns over publish-subscribe, rather than every system inventing its own convention. Flow control through a receive maximum lets each side limit how many unacknowledged QoS 1 and 2 messages the other may have in flight, protecting small devices from being overwhelmed when a large backlog is delivered on reconnection. Not every device or cloud service supports every MQTT 5 feature, and some managed cloud brokers implement a subset of the protocol with their own limits on message size, topic depth and retained messages. Before designing around a feature, it is worth confirming that the specific broker in use supports it. The broker as infrastructure Because every message passes through it, the broker is the most critical piece of infrastructure in an MQTT system. Open-source brokers such as Eclipse Mosquitto are compact enough to run on a gateway or a small server and are widely used for edge deployments and development. Clustered brokers, both open-source and commercial, are designed to handle very large numbers of concurrent connections and to survive the failure of individual nodes. Cloud IoT services provide managed brokers integrated with their identity, rules and storage services. Operating a broker at scale raises the issues that Chapter 1 anticipated. Connection storms after an outage must be absorbed, ideally with devices applying randomised back-off before reconnecting. Persistent sessions consume memory and storage for every offline device, which is why session expiry matters. Access control must ensure that each device can touch only its own topics. Monitoring must track connection counts, message rates, queue depths and dropped messages, much of which brokers expose through special system topics, conventionally under $SYS/. MQTT's minimalism is a virtue, but it is also a source of confusion: the protocol says nothing about payload formats, topic schemes or how devices should be modelled, which leaves every deployment to invent its own conventions. Industrial users have responded with specifications such as Sparkplug, discussed in Chapter 5, that layer such conventions on top. Others have concluded that, for their most constrained devices, MQTT's dependence on TCP and a persistent broker connection is itself the problem. Those alternatives are the subject of the next chapter. Chapter 4: Beyond MQTT: Choosing a Messaging Protocol MQTT's success has created a mild orthodoxy in IoT circles: when in doubt, use MQTT. As defaults go, it is a good one. It is widely supported, well understood and well matched to devices that maintain a connection to a broker. But it is not the right answer for every device, and the reasons it sometimes fails are instructive, because they point straight back to the constraint stack. MQTT assumes TCP. TCP assumes a connection, and a connection must be established, secured and maintained. For a mains-powered gateway or a device that reports every few seconds, that cost is amortised over many messages and is negligible. For a battery-powered sensor that wakes once an hour on an NB-IoT link, the cost of a TCP three-way handshake followed by a TLS handshake, each potentially requiring retransmissions in poor coverage, may exceed the cost of the useful data many times over. If the device instead keeps the connection open between readings, it must send keepalives often enough to stop operator network address translation from timing out the connection, and those keepalives cost energy too. Neither option is good. This is the gap that the protocols in this chapter fill. Counting round trips The problem becomes clear if one counts the exchanges needed to deliver a single reading from a device that has just woken up and holds no existing connection. Over MQTT with TLS, the device must first open a TCP connection, which takes a three-way handshake, roughly one and a half round trips before data can flow. It must then perform a TLS handshake. With TLS 1.2, a full handshake takes two further round trips; TLS 1.3 reduces this to one, and both versions offer forms of session resumption that can shorten it further if the device has kept the necessary state from a previous connection. Only then can it send an MQTT CONNECT packet and wait for the broker's CONNACK, another round trip. Then it publishes its reading, and if it uses QoS 1, it waits for the PUBACK, one more round trip. Finally it disconnects, and TCP's own closing exchange follows. On a wired network with a round-trip time of a few tens of milliseconds, all of this completes in a fraction of a second and nobody notices. On an NB-IoT link in deep indoor coverage, where each round trip may take a second or more and the device's radio must remain active, listening, throughout, the same sequence may keep the radio busy for many seconds. The useful payload, perhaps a dozen bytes, accounts for a vanishingly small fraction of the energy spent. Compare a confirmable CoAP request over UDP from a device that already holds a DTLS session with the server. The device sends one datagram containing its reading and receives one acknowledgement: a single round trip. If no DTLS session exists, a handshake is needed first, and DTLS's handshake, which includes a cookie exchange to protect servers against spoofed requests, takes at least as many round trips as its TLS counterpart. The saving therefore depends on keeping that security session alive across the device's sleep periods. A complication arises here, because a cellular device that sleeps for an hour may return with a different public address after operator address translation, and the server would no longer recognise which session the incoming datagram belongs to. The DTLS connection identifier extension, specified by the IETF, addresses exactly this by labelling each record with an identifier that survives address changes, allowing a device to wake, send one protected datagram and sleep again. This arithmetic is the core of the case for CoAP and its relatives on the most constrained links. It is not that MQTT is badly designed; it is that MQTT's efficiency depends on amortising connection setup over a long-lived connection, and some devices cannot afford to keep one. CoAP: the web's model on a diet The Constrained Application Protocol, CoAP, was standardised by the Internet Engineering Task Force as RFC 7252 in 2014. Its design premise is that the web's architectural style, with resources identified by URIs and manipulated by a small set of methods, is a good model for devices, but that HTTP's implementation is far too heavy for them. CoAP keeps the model and replaces the implementation. CoAP runs over UDP rather than TCP. There is no connection to establish. A client sends a request, such as a GET on /sensors/temperature or a PUT on /config/interval, and the server replies. The message header is a compact four bytes, followed by a token for matching responses to requests, and options encoded in a compressed form. Methods and response codes deliberately mirror HTTP's, so that GET, PUT, POST and DELETE mean what a web developer expects, and a response code of 2.05 corresponds to HTTP's 200 and 4.04 to its 404. This makes it straightforward to build proxies that translate between CoAP and HTTP. Because UDP provides no reliability, CoAP adds its own lightweight mechanism. Messages can be sent as confirmable, in which case the recipient must acknowledge them and the sender retransmits with exponential back-off until it receives an acknowledgement or gives up, or as non-confirmable, which is fire-and-forget. This gives the application per-message control over the reliability-energy trade-off, much as MQTT's QoS levels do, without a persistent connection. Two extensions make CoAP practical for IoT. The Observe option, specified in RFC 7641, lets a client register interest in a resource and receive notifications whenever it changes, giving CoAP a form of publish-subscribe without a broker. Block-wise transfer, specified in RFC 7959, lets large payloads such as firmware images be split into blocks that fit within the small packets constrained networks can carry. Security for CoAP is typically provided by DTLS, the datagram version of TLS, which brings the familiar handshake and encryption to UDP. The IETF has also standardised OSCORE, RFC 8613, which protects CoAP messages at the application layer rather than the transport layer. The practical advantage of OSCORE is that protection survives passage through proxies and gateways that translate between transports, so a message can remain end-to-end encrypted from device to server even when it crosses several different networks on the way. CoAP's weaknesses are mostly the mirror image of its strengths. Its direct request-response model means that, without a broker, the server must know how to reach each device, and reaching a device behind NAT over UDP is unreliable, since NAT mappings for UDP typically time out faster than those for TCP. Many CoAP deployments therefore have the device initiate all communication and use the period immediately after each uplink to deliver any pending downlink, a pattern familiar from LoRaWAN Class A. CoAP also has a smaller ecosystem of cloud services and developer tools than MQTT, which matters when a team is choosing what it can support for a decade. LwM2M: device management as a standard CoAP on its own is a transport. It says nothing about what resources a device should expose or what they mean. Lightweight Machine to Machine, LwM2M, published by OMA SpecWorks, fills that gap with a complete device management and telemetry framework built on top of CoAP. LwM2M defines a standard object model. A device exposes objects, each identified by a number, containing resources that can be read, written, executed or observed. Some objects are defined by the specification itself and cover the essentials of device management: security credentials, server connection settings, device information such as manufacturer and battery level, connectivity monitoring and, importantly, firmware update. A large registry of further objects, many derived from the IPSO Alliance's smart object definitions, covers common sensor types such as temperature, humidity and location. Because these objects are standardised, a LwM2M server can manage devices from different manufacturers in the same way, and a device can be moved between servers without changes to its firmware. LwM2M also specifies a bootstrap process. A device is manufactured knowing how to contact a bootstrap server, which, on first connection, provisions it with the credentials and addresses of the management server it should actually use. This separates the manufacturing step from the deployment decision and provides a clean way to transfer devices between operators or service providers. For cellular IoT in particular, LwM2M has become an important option. Several mobile operators and module makers provide LwM2M support, and the combination of CoAP over UDP, DTLS with session resumption and a standard object model is very well matched to NB-IoT and LTE-M devices operating in power-saving modes. Its cost is complexity: LwM2M is a substantial specification, and teams accustomed to inventing their own MQTT topic schemes may find its rigour unfamiliar. That rigour is precisely the point. The firmware update object, for example, encodes years of collective experience about the states an update can pass through and the errors it can encounter, experience that a home-grown scheme typically rediscovers the hard way. MQTT-SN: MQTT for sensor networks MQTT for Sensor Networks, MQTT-SN, takes a different route to the same destination. Rather than abandoning MQTT's publish-subscribe model, it adapts it for networks where TCP is unavailable or unaffordable. MQTT-SN runs over UDP or directly over non-IP transports such as 802.15.4 radio links, and it communicates with an MQTT-SN gateway that translates to and from standard MQTT on the broker side. Several changes make it more economical. Topic names, which in MQTT are sent in full with every publish, are replaced by short numeric topic identifiers registered once or predefined in advance. Messages are shorter overall. Most significantly for battery devices, MQTT-SN includes explicit support for sleeping clients: a client can tell the gateway it is going to sleep for a given duration, and the gateway buffers messages destined for it until it wakes and asks for them. This is the sleepy-end-device pattern from Chapter 2, expressed at the messaging layer. MQTT-SN has existed for many years as a specification originally published by IBM, and OASIS has since taken up work on a standardised version. Its practical adoption is narrower than either MQTT or CoAP, but it is attractive in designs that already use an MQTT back end and need to bring very constrained devices into the same topic namespace. HTTP, AMQP and the rest Plain HTTP deserves a fair hearing. It is universally understood, every cloud platform and every programming language supports it, and every firewall permits it. For mains-powered devices that report infrequently and do not need to receive commands promptly, an HTTPS POST of a JSON document is a perfectly reasonable design. Its costs are verbose headers, a request-response model that cannot easily push messages to the device, and, if connections are not reused, the expense of establishing a new TLS session for each request. HTTP/2 and HTTP/3 reduce some of these costs, but they increase implementation complexity on small devices. HTTP tends to work best where the device is effectively a well-resourced client and the constraint stack is light. AMQP, the Advanced Message Queuing Protocol, standardised in version 1.0 by OASIS in 2012 and subsequently as ISO/IEC 19464, is a richer enterprise messaging protocol with sophisticated routing, flow control and transactional semantics. It is rarely used on constrained devices themselves but is common between gateways and cloud services, and some cloud IoT platforms offer it as an alternative device protocol alongside MQTT. DDS, the Data Distribution Service, is a brokerless publish-subscribe standard from the Object Management Group with fine-grained quality-of-service controls, widely used in robotics, defence and automotive systems, and notably as the default middleware in the ROS 2 robotics framework. Its strengths lie in real-time local networks rather than wide-area telemetry. Cellular networks add one more option. NB-IoT and LTE-M support non-IP data delivery, in which the device sends small payloads through the operator's control plane without an IP stack at all, and the operator delivers them to the application server through an exposure interface. This can save energy and bytes for the very smallest messages, at the cost of tying the device's communication path firmly to a particular operator's infrastructure. Comparing the main options Table 2 summarises how the principal protocols compare on the attributes that matter most when choosing between them. Table 2. Comparison of common IoT messaging protocols. Protocol Transport Pattern Minimum header Sleeping-device support Typical fit MQTT 5 TCP (with TLS) Publish-subscribe via broker 2 bytes Persistent sessions, queued messages Connected devices, gateways, general telemetry MQTT-SN UDP or non-IP Publish-subscribe via gateway Few bytes Explicit sleep and buffering Very constrained devices with MQTT back end CoAP UDP (with DTLS or OSCORE) Request-response, Observe 4 bytes Device-initiated exchanges Constrained IP devices, cellular IoT LwM2M CoAP Managed object model As CoAP Queue mode on server Standardised device management HTTPS TCP (with TLS) Request-response Text headers Polling only Well-powered devices, infrequent reports Payload formats: the other half of the message Choosing a protocol settles how bytes move. It does not settle what the bytes mean. Every protocol in this chapter carries an opaque payload, and the payload format matters as much for efficiency and maintainability as the protocol does. JSON is the default for good reasons: it is human-readable, self-describing and supported everywhere. It is also verbose. A reading such as {"temperature": 21.5, "humidity": 48} uses dozens of bytes to convey two numbers. On a broadband connection this is irrelevant; on a LoRaWAN link at a high spreading factor it may push a message beyond the maximum payload size or multiply its time on air. Binary formats address this in different ways. CBOR, the Concise Binary Object Representation, specified by the IETF in RFC 8949, keeps JSON's data model but encodes it compactly, so it can be translated to and from JSON without a schema. Protocol Buffers and similar schema-based formats achieve greater compactness by requiring both sides to share a schema in advance, which also provides a disciplined way to evolve message formats over time. At the extreme, many LPWAN devices use hand-packed binary payloads in which every bit position has a defined meaning, decoded by a small function on the network or application server. SenML, the Sensor Measurement Lists format in RFC 8428, offers a standard way to represent sensor readings with units and timestamps in JSON, CBOR or XML. The trade-off is between efficiency on the wire and friction everywhere else. A hand-packed binary payload saves bytes but requires a decoder that must be versioned, deployed and kept in sync with every firmware release. A self-describing format costs bytes but can be inspected with ordinary tools and survives schema evolution more gracefully. A reasonable rule is to use the most self-describing format the link can afford, and to include a format version in every message, either in the payload or, with MQTT 5, as a user property, so that consumers can cope with a fleet in which several firmware versions coexist. How to choose The choice between these protocols should follow from the device, not from fashion. A useful set of questions, in order, runs as follows. Does the device have an IP stack and enough memory for TLS? If not, the options narrow to MQTT-SN, non-IP data delivery or a gateway-mediated design. Is it on a link where TCP connection setup or keepalive traffic is prohibitively expensive, such as NB-IoT in deep coverage? If so, UDP-based CoAP or LwM2M is likely to be more economical. Does the system need a broker to decouple many producers from many consumers? MQTT is designed for that. Is standardised, multi-vendor device management a priority? LwM2M provides it out of the box. Is the device a capable, mains-powered machine on a good network? Then MQTT or even HTTPS will do, and the choice can be made on ecosystem and team familiarity. Many real systems use more than one. Constrained sensors speak CoAP or a radio-specific protocol to a gateway, which in turn speaks MQTT to the cloud. That arrangement, in which a gateway sits between the world of constrained devices and the world of servers, is common enough and important enough to deserve a chapter of its own. Chapter 5: Edge Gateways Between the sensor and the cloud there is very often a third party: a box on a wall, a DIN-rail computer in a cabinet, a router on a lamp post, or a phone in someone's pocket. It is called a gateway, and its existence is a direct consequence of the constraint stack. Constrained devices cannot, or should not, speak directly to the cloud. They may lack an IP stack, or the energy to maintain a secure internet connection, or a radio that reaches beyond a few tens of metres. The cloud, for its part, is a poor neighbour for a sleeping sensor: it is far away, it is reached over links that fail, and it speaks protocols designed for servers. The gateway absorbs this mismatch. Gateways are easy to underrate. They are sometimes treated as mere plumbing, a protocol converter to be configured once and forgotten. In well-designed systems they are much more than that: the place where the local and the global are reconciled, where data is reduced to what matters, where operation continues when the wide-area link fails, and where a security boundary is drawn. They are also, as this chapter will argue, a place where complexity can quietly accumulate until the gateway becomes the hardest component in the system to manage. What a gateway is for The functions of a gateway can be grouped under six headings, and it helps to be explicit about which of them a given design needs, because each adds cost and complexity. Protocol translation is the most basic. A gateway receives data over a local radio or fieldbus, such as BLE, Zigbee, a LoRaWAN packet forwarder, Modbus over a serial line or an industrial Ethernet protocol, and republishes it over an internet protocol, typically MQTT over TLS, to the cloud. Commands flow the other way. In doing so the gateway often also translates data models, turning a register address on a Modbus device into a named, typed value with units. Aggregation and reduction come next. A gateway serving fifty sensors can combine their readings into fewer, larger messages, which reduces per-message overhead on the backhaul link. It can also discard or compress data that carries no new information. A common technique is report by exception: rather than forwarding every reading, the gateway forwards a value only when it changes by more than a configured deadband, together with a periodic heartbeat so that the absence of messages is not mistaken for a failure. For high-rate data, such as vibration waveforms, the gateway may compute features, for instance an overall vibration level and the amplitudes at a few frequencies of interest, and send only those. Store-and-forward is the gateway's defence against intermittency. When the wide-area link fails, the gateway continues to collect data and stores it locally, then forwards the backlog when connectivity returns. This sounds simple and is full of design decisions, discussed below. Local control and autonomy matter wherever the system does something physical. If a building's ventilation is controlled by rules that run in the cloud, an internet outage stops the ventilation from responding to occupancy or air quality. If the rules run on the gateway, the building continues to work, and the cloud's role reduces to supervision, configuration and analysis. For safety-relevant functions, local autonomy is not optional. Security boundary is the fifth function. A gateway can be the only device on a site with a connection to the internet, so that local devices, which may have weak or non-existent security, are never directly exposed. It holds the credentials for the cloud connection, terminates TLS, enforces which local devices are allowed to communicate, and can apply firewall rules to the local network. This is valuable, but it also makes the gateway a high-value target, as Chapter 8 discusses. Local services round out the list. Gateways often provide time synchronisation to devices that have no clock of their own, local storage for recent history, a local user interface for technicians who need to commission or diagnose equipment on site when the cloud is unreachable, and, in LoRaWAN or Thread networks, the radio infrastructure itself. Store-and-forward done properly Store-and-forward is the gateway function most often implemented naively, so it is worth examining what a robust implementation must decide. The first decision is capacity. Local storage is finite, and an outage may last longer than anyone planned. The design must specify what happens when the buffer fills. Discarding the newest data preserves the start of the outage and loses its end, which is usually the opposite of what operators want. Discarding the oldest preserves the most recent picture. A better approach is often to degrade gracefully: as the buffer fills, the gateway thins out older data, keeping, say, every tenth reading, or replacing raw readings with minimum, maximum and mean values over longer intervals, so that the shape of the outage period is preserved at lower resolution. The second is priority. Not all data is equally important. Alarms and state changes should be forwarded before routine telemetry when the link returns, and they should be the last to be discarded if space runs short. This implies at least two queues, or a single queue with priority-aware ordering. The third is timestamps. Every buffered reading must carry the time it was measured, not the time it was forwarded. This sounds obvious, yet systems that stamp readings on arrival at the cloud are common, and they produce data in which an hour-long outage appears as a burst of readings all marked with the same minute. Source timestamps in turn require the gateway, and ideally the devices, to have a trustworthy clock. Gateways typically synchronise with network time when connected, and must be designed to cope with clock drift or a reset clock during long outages, for example by recording monotonic counters alongside wall-clock time so that relative timings can be reconstructed. The fourth is rate of catch-up. When connectivity returns, a gateway with a large backlog that transmits as fast as possible may saturate a cellular link, starve current traffic and, if a whole region's gateways reconnect simultaneously after a network outage, overload the cloud ingestion service. Backlog should be forwarded at a controlled rate, with current data and alarms interleaved ahead of it. The fifth is idempotency. If the gateway sends a batch, the connection drops before it receives an acknowledgement, and it resends the batch, the cloud will receive duplicates. Each record should therefore carry a stable identity, such as the device identifier plus a sequence number or the source timestamp, so that the cloud can discard records it has already stored. This is the end-to-end view of reliability that Chapter 3 argued MQTT's quality-of-service levels cannot provide on their own. An outage, walked through A concrete case shows how these decisions play out. Imagine a gateway at a small water pumping station, connected to the cloud over a cellular link. It polls two pump controllers and a flow meter every few seconds, applies report-by-exception with a heartbeat every five minutes, and runs a local rule that raises an alarm if the reservoir level falls below a threshold. On a Friday evening, a storm damages the nearest cell site and the gateway loses its backhaul. Nothing about the station's operation changes. The pumps continue under the control of their own controllers, as they always have, and the gateway continues to poll them. When the reservoir level falls during the night and crosses the alarm threshold, the gateway's local rule fires. It cannot reach the cloud, so it does two things: it records the alarm at the head of its high-priority queue, and, because the design anticipated this, it switches on a local alarm output wired to a beacon that a site visitor would see. It also continues to store routine readings in its lower-priority buffer, each stamped with the time of measurement. By Sunday morning the buffer is half full. The gateway begins thinning older routine readings, keeping a reduced set together with the minimum, maximum and mean values over each quarter hour, so that a full weekend can be held in the space originally intended for a day. On Sunday afternoon the cell site is repaired. The gateway reconnects, but it does not simply flush everything at once. It first publishes its current status and the unacknowledged alarm, so that the operations centre immediately sees what matters most. It then resumes live reporting, and forwards the weekend's backlog in the background at a limited rate, interleaved with live data. Every record carries its station identifier, sequence number and source timestamp, so when a connection drop forces the gateway to resend one batch, the cloud quietly discards the duplicates. When the operators look at the history on Monday, they see an accurate, if partly lower-resolution, record of the weekend, with the alarm placed at the time it actually occurred rather than the time it arrived. None of this required sophisticated software. It required that someone, at design time, had asked what the gateway should do when the cloud was not there, and had answered each of the five questions above deliberately. Bridging industrial equipment Industrial sites illustrate the gateway's role especially clearly, because they contain equipment designed long before anyone talked about the Internet of Things. Programmable logic controllers, drives, meters and instruments communicate over fieldbuses and industrial protocols, many dating from the 1970s and 1980s. Modbus, introduced by Modicon in 1979, remains ubiquitous: it is simple, open and supported by almost every industrial device, but it is also a polled, register-based protocol with no built-in notion of what a register means, no timestamps and no security. To read a temperature from a Modbus device, a client must know that, on this particular model, holding register 40021 contains the temperature in tenths of a degree. A gateway on such a site polls the equipment, interprets the registers according to a configured mapping, and publishes meaningful values upstream. This is where the polled, local world of the factory floor meets the event-driven, publish-subscribe world of IoT messaging, and the gateway is the translator. OPC UA, standardised as IEC 62541, is the more modern industrial interoperability standard. It provides a rich information model in which devices describe their own data, with types, units and relationships, along with built-in security and both client-server and publish-subscribe communication. Many newer industrial devices expose OPC UA servers, and many gateways act as OPC UA clients on the plant side while publishing to MQTT on the enterprise side. The gap that MQTT leaves, its silence on topic structure and payload meaning, is particularly painful in industrial settings, where hundreds of devices from many vendors must be integrated and where consumers need to know not just a value but whether that value is current. The Sparkplug specification, developed originally by Cirrus Link and now maintained under the Eclipse Foundation, addresses this by layering conventions on top of MQTT. Sparkplug defines a fixed topic namespace, beginning with a version element and organised by group, message type, edge node and device. It defines a compact payload encoding based on Protocol Buffers, which carries metric names, data types, values and timestamps. Most importantly, Sparkplug makes state awareness explicit. When an edge node connects, it publishes a birth certificate message describing every metric it and its devices will report, with their current values. It registers a death certificate as its MQTT last will, so that if it disconnects unexpectedly the broker announces its death to all subscribers. Devices behind the edge node have their own birth and death messages. Subsequent data messages report only changes. A consuming application therefore always knows which nodes and devices are alive, what metrics they provide and whether the last value it holds is still valid. If it misses messages or starts up mid-stream, it can request a rebirth, and the edge node republishes its full state. This turns MQTT's general-purpose transport into a self-describing, state-aware industrial data fabric. Sparkplug is often associated with the idea of a unified namespace, an architectural approach in which a single, well-structured MQTT broker hierarchy becomes the central place where every system on a site, from controllers to manufacturing execution systems to analytics, publishes its current state and finds the state of every other system. The idea is appealing because it replaces a tangle of point-to-point integrations with one shared hub. Its success depends on exactly the discipline that this book recommends for topic design: a hierarchy agreed in advance, consistent naming, and clear ownership of each branch. Software on the gateway A modern gateway is usually a small Linux computer, and the software running on it has grown more sophisticated over the past decade. Rather than a single monolithic application, many gateways now run several independently deployable components: a protocol adapter for each local technology, a local MQTT broker such as Mosquitto that the components use to talk to one another, a store-and-forward module, a rules engine, perhaps a small time-series database and a local user interface. These components are commonly packaged as containers, and cloud providers offer edge runtimes, such as AWS IoT Greengrass and Azure IoT Edge, that deploy and manage containerised modules on gateways from the cloud. Lightweight Kubernetes distributions are also used on more capable edge hardware. This architecture brings the cloud's deployment model to the edge, and it has real advantages: components can be updated independently, the same module can run on many gateways, and the gateway's configuration can be described declaratively and versioned. It also brings risks. A gateway running a container orchestrator, a broker, a database and a dozen modules is a small data centre with no operations staff, deployed in a cabinet where nobody can see it. Every component is something that can fail, consume disk space, leak memory or require security patches. The discipline that helps is restraint. A gateway should run what it needs to fulfil the functions listed at the start of this chapter, and nothing more. Analytics that do not need to run locally should run in the cloud, where they can be updated, monitored and scaled cheaply. Logic that must run locally, such as safety interlocks and autonomous control, should be as simple and as well tested as possible. Disk usage must be bounded, with local logs and buffers rotated. Every gateway should report its own health: processor load, memory, disk, temperature, uptime, the versions of every component and the state of every local link. A gateway that silently fills its disk with logs and stops forwarding data is one of the most common and most avoidable failures in IoT operations. Where to put the intelligence The broader question raised by gateways is where processing should happen: on the device, at the gateway or in the cloud. There is no fixed answer, but the constraint stack gives a reliable method for deciding. Processing belongs on the device when it saves more radio energy than it costs in computation and when the logic is stable enough that it will rarely need changing. Computing a running average or detecting a threshold crossing locally is almost always worthwhile. Running a complex model on a battery-powered sensor usually is not, unless it allows the device to transmit dramatically less. Processing belongs at the gateway when it must continue during wide-area outages, when it significantly reduces backhaul traffic, when it needs data from several local devices at once, or when latency requirements rule out a round trip to the cloud. Local control loops, cross-device correlation and data reduction are the classic cases. Processing belongs in the cloud when it needs data from many sites, when it changes frequently, when it requires substantial computing resources, or when it benefits from the cloud's operational tooling. Fleet-wide analytics, model training and business integration belong here. The common mistake is not putting processing in the wrong place once, but letting it drift. A rule added to a gateway as a quick fix becomes a dependency; a second follows; within a year, the system's behaviour depends on configuration scattered across hundreds of gateways, nobody is sure which version of which rule runs where, and the gateway has become the component everyone is afraid to update. Keeping a clear, documented boundary between what runs where, and treating gateway logic as code that is versioned and deployed like any other, is what prevents it. Gateways and devices alike are configured from the cloud, and both report their state back to it. The model the cloud uses to hold that configuration and state, and to reconcile the two, is the device twin. Chapter 6: Device Twins and the Problem of State Return to the scene from the introduction. An engineer, anticipating a storm, changes the culvert sensor's reporting interval from fifteen minutes to five. The device is asleep. What exactly has happened? In a naive system, the engineer's action becomes a command sent to the device. If the device is not listening, the command fails, or is queued somewhere with uncertain lifetime, and the engineer's screen either shows an error or, worse, shows the new interval as though it had taken effect. In a well-designed system, the action does something more modest and more honest. It records an intention: the desired reporting interval for this device is now five minutes. It does not pretend the device has changed. The reported interval remains fifteen minutes, because that is what the device last said it was using. The difference between the two, the delta, is the pending work. When the device next wakes and connects, it learns of the delta, applies the new setting, and reports back that it is now using five minutes. Desired and reported agree, the delta disappears, and the engineer's screen shows that the change has been applied, and when. This pattern, a cloud-side document that holds both what the operator wants and what the device last reported, is called a device twin in Microsoft's Azure IoT Hub and a device shadow in AWS IoT Core. The terms differ but the idea is the same, and it is the single most important abstraction for managing state in a fleet of intermittently connected devices. This chapter examines how it works, why it works, and the subtle problems that arise when it is used carelessly. Desired, reported and the delta A device twin is, in its simplest form, a document, usually JSON, associated with one device and stored in the cloud. It has two main sections. The desired section is written by back-end applications and operators and expresses the configuration the device should have. The reported section is written by the device and expresses the configuration and state it actually has. Cloud services typically add metadata recording when each property was last updated, and a version number that increments with every change. A minimal shadow for the culvert sensor might look something like this: { "state": { "desired": { "report_interval_s": 300 }, "reported": { "report_interval_s": 900, "firmware": "2.4.1", "battery_mv": 3480 } }, "version": 57 } The service computes the delta: the set of desired properties whose values differ from the reported ones. Here the delta is simply the reporting interval. Devices subscribe to delta notifications, or request the full document when they connect, so that they learn of pending changes as soon as they can. The important design property is that the two sections are owned by different parties and never overwritten by the other. Operators do not write reported state, because they cannot know what the device is really doing. Devices do not write desired state, because that is the operator's intention. Keeping this ownership clean is what makes the twin trustworthy: at any moment, it answers two separate questions, "what do we want?" and "what did the device last tell us?", and the answer to the first never masquerades as the answer to the second. This is a direct application of the book's central argument. The twin is a cloud abstraction designed around the device's limitations. It accepts that the device will be absent, that changes cannot be applied synchronously, and that the cloud's knowledge of the device is always historical. It turns those facts into a model, rather than treating them as errors. Declarative state versus commands The twin works best for declarative state: properties that describe how the device should be configured, such as reporting intervals, thresholds, enabled features, target firmware version, or a setpoint. Declarative state has a very useful property. Applying it is idempotent. If the device receives "reporting interval should be 300 seconds" twice, nothing bad happens. If it receives three successive changes while it was asleep, it only needs to apply the latest. If it reboots in the middle of applying a change, it can simply compare desired and reported again on restart and finish the job. This makes declarative state robust against exactly the intermittency, duplication and partial failure that IoT systems are full of. Some operations are not like this. "Reboot now", "take a photograph", "run a self-test", "open the valve for thirty seconds" are imperative commands: they are events that should happen once, at a particular time, and their meaning depends on when they arrive. Representing them as desired state is awkward and sometimes dangerous. If "reboot" is written into the desired section and the device reboots before reporting that it has done so, it may reboot again on restart, and again, in a loop. Cloud platforms therefore offer separate mechanisms for commands. Azure IoT Hub distinguishes between desired properties, direct methods, which are synchronous calls that succeed only if the device is connected and responds within a timeout, and cloud-to-device messages, which are queued. AWS IoT offers a jobs service for operations that must be tracked across a fleet, such as firmware updates. MQTT 5's request-response properties, discussed in Chapter 3, provide a protocol-level foundation for command patterns. Table 3 summarises the three kinds of cloud-to-device interaction and when each is appropriate. Table 3. Three ways the cloud communicates with a device. Mechanism Nature Works if device asleep Idempotent Suitable for Desired state (twin) Declarative intention Yes, applied on wake Yes Configuration, setpoints, target versions Queued command or job Imperative, tracked Yes, until it expires Must be designed in Updates, one-off operations Direct method or synchronous call Imperative, immediate No Must be designed in Interactive actions on connected devices A practical rule follows. Whenever possible, express what you want as state rather than as a command. "Firmware version should be 2.5.0" is better than "install firmware 2.5.0", because it can be retried, compared and audited. "Valve should be open until 14:30" is better than "open the valve for thirty seconds", because it carries its own meaning regardless of when it arrives. Reserve commands for operations that genuinely are events, and give every command an expiry time so that a stale instruction is discarded rather than executed late. Versions, conflicts and the device that disagrees The twin's simplicity hides several hard problems, and they tend to appear only once a fleet is large and has been running for a while. The first is concurrent updates. Two operators, or an operator and an automated system, may change the same desired property at nearly the same time. Twin services address this with optimistic concurrency: each update can specify the version of the document it was based on, and the service rejects it if the document has changed in the meantime. Back-end applications that write to twins should always use this mechanism, re-reading and reapplying their change when it is rejected, rather than blindly overwriting. The second is changes the device makes itself. Many devices have local inputs: a thermostat has buttons, an industrial controller can be adjusted by a technician on site, a gateway may change its own configuration in response to local conditions. Suppose the desired setpoint is 21 degrees and a user presses a button to set 23. The device now reports 23. The delta shows a mismatch, and if the device naively applies the desired value on its next sync, it will overwrite the user's choice. The system must decide, property by property, who has authority. Common answers are that local changes win and the device updates its reported state, prompting the back end to update the desired value to match; or that cloud configuration wins and local changes are temporary overrides with their own expiry. Either can be right. What is wrong is leaving the question unanswered, so that devices and cloud fight over the value. The third is partial application. A desired update may contain several properties, and the device may be able to apply some and not others, perhaps because one value is out of range or requires a firmware feature the device lacks. The reported section should reflect exactly what was applied, and a well-designed device also reports why the rest was not, for instance in a status property that records the last configuration error. Without this, operators see a delta that never resolves and have no way to tell whether the device is offline, broken or simply refusing an invalid value. The fourth is ordering and staleness of reports. A device that buffers reports during an outage and sends them later may deliver an old reported state after a newer one, overwriting fresher information with stale. Including a device-side timestamp or sequence number with reported state, and having the back end refuse to replace newer state with older, prevents this. The general principle is that every piece of reported state should carry the time the device observed it, and every consumer of the twin should be able to see how old each value is. A change, from request to confirmation It helps to trace the storm-preparation change through every step, including the ways it can go wrong, because the twin's value lies largely in how it handles the failures. The engineer sets the desired reporting interval to 300 seconds. The back-end application reads the twin at version 57, writes the new desired value conditional on that version, and the service accepts it, incrementing the version to 58. The delta now contains the interval. The engineer's screen shows the change as pending, with the time it was requested. Some minutes later, the sensor wakes on its own schedule. It connects and, as its firmware always does on connection, requests the current twin document, or the delta alone, to save bytes. It sees that the desired interval differs from what it is using. It validates the value, checking that it lies within the range its firmware supports, applies it to its own configuration, persists it to non-volatile memory so that it survives a reboot, and only then publishes an updated reported section stating that its interval is now 300 seconds, along with the time it applied the change. The service records the report, the delta becomes empty, and the engineer's screen shows the change as applied, with a timestamp. Now consider the failures. If the device's connection drops after it applied the setting but before its report reached the cloud, the delta persists. On its next wake, the device sees the same delta, notices that its stored configuration already matches, and simply reports again. Because applying desired state is idempotent, the retry is harmless. If the engineer had mistyped and requested an interval of 3 seconds, below what the device permits, the device would not apply it. It would leave its reported interval at 900 and report a configuration error explaining that the requested value was out of range. The engineer's screen would show not a silent, perpetually pending change but a specific refusal that can be corrected. If, while the device was asleep, a second operator had changed the desired interval again to 600 seconds, the device would never see the 300-second request at all. It would see only the current desired value and apply that. Intermediate intentions that were superseded before the device could act on them simply disappear, which is almost always what everyone wants. Each of these behaviours falls out of the same small set of rules: separate ownership of desired and reported state, idempotent application, validation on the device, explicit error reporting, and timestamps on everything. What does not belong in the twin Because the twin is convenient, there is a temptation to put everything into it. This is a mistake, and cloud services enforce it with size limits on twin documents that are measured in kilobytes, along with limits on update rates. Telemetry does not belong in the twin. A twin holds state: the current configuration and status of a device. A stream of temperature readings is not state; it is a time series, and it belongs in a time-series store fed by the telemetry path. Writing every reading into the reported section turns a configuration document into a high-churn data store, generates large volumes of twin-change notifications for every subscriber and exceeds update rate limits. The twin may reasonably hold a small number of slowly changing summary values, such as the battery voltage or the timestamp of the last reading, if they help operators, but not the data stream itself. Large blobs do not belong in the twin. Firmware images, certificates and lengthy configuration files should be stored elsewhere, with the twin holding a reference, such as a URL and a cryptographic hash, and the desired version. Secrets do not belong in the twin unless the service is specifically designed to protect them, because twin contents are typically visible to many back-end applications and operators. Most services also provide a third category of twin data, often called tags or attributes, that is stored in the cloud but never sent to the device: the site where it is installed, the customer it belongs to, the date it was last serviced. These are used for querying and grouping, so that an operator can, for example, set a desired property on every device at a given site with a single fleet-wide operation. Twins beyond the cloud vendor It is worth separating the device twin pattern from the products that implement it. The pattern, desired and reported state with a delta and versioning, is general. It can be implemented on any MQTT broker with retained messages and a small service that computes deltas; it is built into LwM2M's object model, where the server writes resources and the device reports them; and it is the basis of open-source frameworks such as Eclipse Ditto. Sparkplug's birth certificates and state-aware messaging, described in Chapter 5, serve a related role for industrial telemetry. This matters because of the platform risk noted in Chapter 1. When Google retired Cloud IoT Core in 2023, customers had to move their devices to other services, and those whose firmware was written against one vendor's specific topic names and document formats faced the most work. Firmware that implements the twin pattern behind a thin abstraction, so that the mapping to a particular service's topics and formats is isolated in one module, can be migrated far more easily than firmware that weaves vendor specifics through its logic. The term "digital twin" is also used, increasingly, for something much larger: a detailed simulation model of a physical asset or process, fed with live data and used for prediction, optimisation and planning. Such models can be very valuable, and they are often built on top of device twins, but they are a different thing. A device twin is an operational record of configuration and status; a simulation digital twin is an analytical model. Keeping the distinction clear avoids the confusion of asking a configuration document to do the work of a physics model, or vice versa. Designing for honest state The deepest lesson of the device twin is about honesty. Every IoT system presents a picture of the physical world to its users, and the quality of that picture depends on how honestly it represents what is known and what is not. A dashboard that shows a device's configuration as whatever was last requested, rather than what was last confirmed, misleads. A display that shows the last reading without its age invites decisions based on information that may be days old. A fleet view that counts devices as "online" because they have a record in the database, rather than because they have been heard from recently, hides failures. The twin pattern, used well, is a discipline for avoiding these errors. Keep desired and reported apart and visible. Timestamp everything the device reports. Show the delta as pending work, not as accomplished fact. Report errors when desired state cannot be applied. Express intentions declaratively wherever possible, and give every imperative command an expiry. These practices cost little in the cloud and nothing on the device, and they are the difference between a system that operators trust and one they learn to second-guess. They also have a direct bearing on battery life. A device that knows its pending changes will be waiting for it can afford to sleep for long periods without anyone needing it to be awake. The twin is what allows the cloud to stop asking the device to listen. How much energy that saves, and where else the energy goes, is the subject of the next chapter. Chapter 7: Engineering for Battery Life A battery-powered IoT device has a fixed amount of energy for its entire working life, and every architectural decision spends from it. This chapter makes that statement quantitative. It shows how to build an energy budget, where the energy in a typical telemetry sensor actually goes, which design choices make the largest difference, and why the figures quoted on datasheets and marketing material so often fail to survive contact with the field. The central lesson can be stated in advance. In most remote sensors, the radio dominates the energy budget, and within the radio budget, the fixed overhead of each communication session dominates the payload. The most powerful lever for battery life is therefore not a better battery or a more efficient microcontroller, but fewer, better-organised radio sessions. Once that lever has been pulled, the second most important factor is the current the device draws while it is doing nothing at all. Building an energy budget An energy budget begins with a list of the states the device passes through and, for each state, the current it draws and the time it spends there. Multiplying current by time gives charge, conventionally expressed in milliamp-hours, and summing the charge over all states for a typical day gives the daily consumption. Dividing the usable battery capacity by the daily consumption gives an estimate of battery life. The calculation is simple; the inputs are where the difficulty lies. Datasheet figures for sleep current are measured under ideal conditions on a bare chip. Radio figures are given for transmission at a specified power, but a real session also involves listening, waiting for the network, retransmitting and, on cellular networks, lingering in a connected state after the data has been sent. Sensor warm-up times vary. The only reliable way to obtain a budget's inputs is to measure the actual device, running its actual firmware, on a current-measurement instrument capable of capturing both microamp sleep currents and the short, high peaks of radio activity. Several manufacturers make affordable power-profiling tools for exactly this purpose, and no serious battery-powered product should ship without such measurements. To show how the budget behaves, consider a worked example. The figures below are illustrative assumptions, chosen to be plausible for a cellular sensor using LTE-M with power-saving features, not measurements of any specific product. The device wakes every fifteen minutes, powers a sensor for 200 milliseconds at 1 milliamp, and sleeps at 3 microamps in between. When it transmits, a complete radio session, including waking the modem, exchanging data with the network and returning to sleep, is assumed to average 80 milliamps over 3 seconds. The battery is a lithium primary cell from which 2,400 milliamp-hours can be usefully drawn. In the first scenario, the device transmits every reading as soon as it is taken: 96 transmissions a day. The radio consumes 80 milliamps for 3 seconds, 96 times, which is 23,040 milliamp-seconds, or 6.4 milliamp-hours per day. Sleep consumes 3 microamps for 24 hours, or 0.072 milliamp-hours. The sensor consumes about 0.005 milliamp-hours. The total is roughly 6.48 milliamp-hours per day, and the battery lasts about 370 days. Almost ninety-nine per cent of the energy goes to the radio. In the second scenario, the device takes the same 96 readings but batches them, transmitting sixteen readings together every four hours: six transmissions a day. Assuming the batched payload does not materially lengthen the session, which is reasonable because the readings add only a few dozen bytes, the radio now consumes 0.4 milliamp-hours per day. The total falls to about 0.48 milliamp-hours per day, and the theoretical battery life rises to nearly fourteen years. At that point, the real limit will be the battery's own self-discharge and ageing rather than the device's consumption. The same sensor, the same battery and the same data have produced a thirteenfold improvement simply by changing when the radio is used. The third scenario introduces a common defect. Suppose a design flaw, such as a pull-up resistor left connected or a peripheral that is never properly powered down, raises the sleep current from 3 to 30 microamps. In the first scenario this would barely register, because the radio dwarfs everything else. In the batched scenario, sleep now consumes 0.72 milliamp-hours per day, more than the radio, and battery life falls from nearly fourteen years to under six. Table 4 sets out the three scenarios side by side. Table 4. Illustrative energy budget for a cellular telemetry sensor (assumptions as stated in the text). Scenario Transmissions per day Sleep current Daily charge Estimated life A: transmit every reading 96 3 µA ~6.48 mAh ~1.0 year B: batch every four hours 6 3 µA ~0.48 mAh ~13.8 years (before self-discharge) C: batch, with sleep defect 6 30 µA ~1.13 mAh ~5.8 years The pattern in these numbers generalises. When the radio dominates, reducing the number of radio sessions is overwhelmingly the most effective optimisation. Once the radio has been tamed, sleep current becomes decisive, and a few tens of microamps of leakage, which no one would notice in a mains-powered device, can halve the product's life. Taming the radio Several techniques reduce radio energy, and they compound. Batching readings, as in the example, amortises the fixed cost of each session over more data. The limit is set by how stale the data may become before it is useful: a utility meter can batch for a day, an environmental alarm cannot. Report by exception sends data only when it changes meaningfully, combined with a periodic heartbeat that confirms the device is alive. For slowly changing quantities, such as the water level in a culvert during dry weather, this can reduce transmissions to a handful a day, while still allowing an immediate report when the level rises. The device's firmware must then distinguish between routine readings, which can wait, and significant events, which justify an immediate session. Avoiding unnecessary handshakes is the third technique. Every new TCP connection and full TLS handshake costs round trips and energy. Protocols and configurations that resume previous security sessions, such as TLS session resumption or DTLS connection identifiers, or that avoid connection setup altogether, such as CoAP over UDP, can cut the session cost substantially. This is one of the main reasons the protocol choice in Chapter 4 matters for battery life. Ending sessions promptly matters especially on cellular networks. After a device sends its data, the network typically keeps the radio connection active for some seconds in case more traffic follows, and the device must keep listening during that time. Cellular standards include mechanisms, generally described as release assistance, by which the device can tell the network that it has no more data to send, allowing the connection to be released immediately. Where the network and module support it, this can trim a significant fraction of each session's energy. Coverage awareness is the fourth. A cellular device in poor coverage may need many repetitions to be heard, which multiplies energy per message. A LoRaWAN device far from a gateway must use a high spreading factor, with much longer time on air. Battery-life estimates should be made for the worst coverage a device will realistically experience, not the best, and installation procedures should check signal quality and, where possible, move the device or antenna to improve it. A sensor installed a metre further from a basement wall may last years longer. Sleeping without disappearing The device twin, as Chapter 6 explained, allows the cloud to stop requiring the device to be present. Cellular networks offer two complementary mechanisms that let the device sleep while remaining part of the network. Power Saving Mode, or PSM, lets a device remain registered with the network while being completely unreachable for long periods. After sending data, the device stays reachable for a short, negotiated active time, during which the network can deliver any pending downlink, and then enters a deep sleep in which its radio is off. It must wake and update the network before a second, much longer, negotiated timer expires, which can be set to many hours or even days. Because it stays registered, it does not need to perform a full network attach each time it wakes, which saves considerable energy. While in PSM, however, the network cannot reach it at all, so downlink messages wait until the device next wakes. Extended discontinuous reception, or eDRX, takes a different approach. Instead of switching off, the device wakes periodically to check for paging messages from the network, but with much longer intervals between checks than an ordinary phone uses. For LTE-M the longest eDRX cycle is around 43 minutes, and for NB-IoT it is close to three hours. eDRX suits devices that must be reachable within a bounded delay but do not need to respond instantly. Two practical points about these features are often missed. First, the device requests timer values, but the network grants them, and operators may grant different values from those requested, or not support the features at all on some parts of their network. Devices must read back and respect the granted values, and battery-life estimates should be validated on the actual networks where the product will be deployed. Second, these features shift the responsiveness trade-off from Chapter 1 into network configuration. A device in PSM with a long sleep timer will not receive a command for hours, so the cloud application and the operators who use it must be designed with that delay in mind. This is exactly why the declarative desired-state model of the device twin fits so naturally with power-saving radios. LoRaWAN's Class A operation, described in Chapter 2, achieves a similar effect by design: the device is deaf except immediately after its own transmissions, and the network server holds any downlink until then. The battery itself The arithmetic above treats the battery as a simple reservoir of charge. Real batteries are less obliging, and choosing and characterising the battery is a design task in its own right. Long-life remote sensors commonly use lithium thionyl chloride primary cells, which offer high energy density, a stable voltage over most of their life, a wide operating temperature range and a very low self-discharge rate, which is what makes multi-year lifetimes possible. They have two well-known peculiarities. They are poor at delivering high pulse currents, especially the bobbin-type cells optimised for low self-discharge, and the cellular modem's transmission peaks can cause the voltage to sag enough to trigger a brownout reset. And during long periods of low drain, they form a passivation layer that causes a temporary voltage delay when a high current is suddenly demanded. The usual remedy is to pair the cell with a capacitor, or a hybrid layer capacitor designed for the purpose, that supplies the short peaks while the battery recharges it slowly. Coin cells, such as the common CR2032 lithium manganese dioxide cell, are attractive for small BLE devices, but their nominal capacity, in the region of a couple of hundred milliamp-hours, is quoted at very low drain. Their relatively high internal resistance means that repeated pulse loads both reduce the usable capacity and cause voltage drops, so a coin-cell device needs a careful pulse-current budget and often a buffer capacitor. Alkaline cells are cheap and familiar but lose capacity in cold conditions and have higher self-discharge, which makes them better suited to devices that are serviced periodically than to sealed, decade-long deployments. Temperature affects every chemistry. Capacity falls in the cold, and self-discharge rises in the heat. A sensor on a north-facing wall in a Scandinavian winter and one in a metal cabinet in desert sun will not have the same battery life, even with identical firmware. Energy harvesting, from small solar panels, thermal gradients or vibration, can extend or even remove the battery-life limit, but it brings its own design problems: harvested power is intermittent, rechargeable storage has a limited cycle life, and the device must manage its activity according to the energy available, deferring non-essential transmissions during a run of overcast days. Finally, estimating how much charge remains is harder than it sounds. A lithium thionyl chloride cell's voltage stays almost flat until it is nearly exhausted, so voltage alone gives little warning. Many devices therefore count the charge they consume, using a coulomb-counting circuit or a firmware model based on the measured energy budget, and report an estimated remaining capacity. Such an estimate, reported to the device twin, is one of the most valuable pieces of operational data a fleet can provide, because it allows battery replacements to be planned rather than discovered. Firmware that does not drain the battery Some of the most damaging energy failures come not from steady-state design but from what the device does when something goes wrong. The classic case is the retry loop. A device that cannot reach the network, because of a coverage gap, a failed gateway or a cloud outage, may try again immediately, and again, and again, keeping its radio active for hours. A single bad day can consume months of battery life. Retries must use exponential back-off with an upper limit and with randomised jitter, so that the device gives up gracefully, sleeps, and tries again later, and so that a fleet does not reconnect in lockstep when service returns. The device should also record how many failed attempts it has made and report this when it next succeeds, so that the cloud can see which devices are struggling. Peripheral power management is the second. Every sensor, external memory chip and level shifter must be switched off when not in use, and every microcontroller pin configured so that it does not leak current through pull-up resistors or floating inputs. These details account for many of the sleep-current defects that halve battery life, and they are only caught by measurement. Firmware updates themselves consume energy. Downloading an image of a few hundred kilobytes over a narrowband link can cost as much as weeks or months of normal operation. Update strategies should account for this, using differential updates that send only the changed portions of an image where possible, scheduling updates for devices with healthy batteries, and avoiding repeated failed downloads. Diagnostics must be budgeted too. Detailed logging and frequent health reports are valuable during development and can be ruinous in the field. A common approach is to collect diagnostics locally, send a compact summary with routine reports, and allow more verbose diagnostics to be enabled remotely, through the device twin, for a specific device and a limited time. What a battery-life claim should say Given all of this, a responsible battery-life claim is not a single number. It is a statement of conditions: this device, with this firmware, reporting at this interval, in this coverage, at this temperature range, with this battery, is expected to last this long. The worked example in this chapter shows how sensitive the result is to each of these conditions. A change in reporting strategy moved the result by more than a factor of ten; a small hardware defect moved it by more than half. For architects, the practical consequence is that battery life must be an explicit, owned requirement from the start of a project, with an energy budget maintained alongside the code, measured on real hardware, and revisited whenever a feature is added. Every new requirement, whether a faster reporting interval, a new diagnostic, a more responsive command path or a stronger security protocol, should be asked what it costs in milliamp-hours per day. Security is one of the requirements that costs energy, and it is also one that cannot be traded away. It is the subject of the final chapter. Chapter 8: Security and the Long Life of a Fleet In the autumn of 2016, a piece of malware called Mirai demonstrated, at scale, what the IoT industry had been warned about for years. Mirai scanned the internet for devices such as cameras and video recorders that accepted remote logins, and tried a short list of factory-default usernames and passwords. It found hundreds of thousands of devices that let it in. It then used them to launch distributed denial-of-service attacks of unprecedented size, including an attack in October 2016 on the DNS provider Dyn that disrupted access to many major websites across parts of the United States and Europe. The devices themselves worked as advertised for their owners throughout. Nobody had broken their cryptography, because most of them had none worth breaking. They were compromised by the simplest possible failure: every unit shipped with the same credentials, and nobody changed them. Mirai is an enduring lesson because it shows that IoT security failures are mostly not exotic. They are failures of identity, of configuration, of update and of lifecycle, the same things this book has been concerned with throughout, viewed through the lens of an adversary. This chapter deals with them in that order, and then turns to the regulations that, since 2024, have begun to make the basic practices mandatory in several major markets. Identity: every device is someone The foundation of IoT security is that every device has its own, unique, verifiable identity, and that nothing is ever trusted merely because it is on the right network or knows a shared secret. In practice, identity usually means a cryptographic key pair unique to the device, with the private key never leaving the device, and a certificate or registration that binds the public key to the device's identifier. When the device connects to a broker or cloud service, it proves possession of the private key during the TLS handshake, in what is called mutual authentication, and the service checks the certificate against a trusted authority or a registry. MQTT brokers in cloud IoT services commonly authenticate devices this way, using X.509 client certificates, and map the authenticated identity directly to the device's permissions. Where the private key lives matters. A key stored in ordinary flash memory can be read out by anyone with physical access and the right tools, and IoT devices are, by their nature, physically accessible to attackers: they are on walls, in fields and on public infrastructure. Dedicated secure elements, small tamper-resistant chips that generate and store keys and perform cryptographic operations without ever exposing the key, and security features built into modern microcontrollers, such as isolated secure execution environments, make key extraction far harder. For devices whose compromise would matter, they are worth their modest cost. For the most constrained devices, where certificate-based TLS is too heavy, pre-shared symmetric keys unique to each device are an acceptable alternative, provided they really are unique and are protected on the device. LoRaWAN, for example, uses per-device root keys from which session keys are derived. The unforgivable pattern is the one Mirai exploited: a single secret shared by every device of a model, so that extracting it from one compromises them all. Identity also drives authorisation. Once a device is authenticated, it should be permitted to do the minimum its function requires. In MQTT terms, a temperature sensor should be able to publish to its own telemetry topic and subscribe to its own command and configuration topics, and nothing else. It should not be able to subscribe to the whole hierarchy with a multi-level wildcard, publish to other devices' command topics or write to its own desired state. This is why Chapter 3 recommended placing device identity in the topic structure: it allows access control policies to be expressed as simple patterns tied to the authenticated identity, such that a compromised device can at worst misreport its own data. Provisioning: how a device gets its identity Giving every device a unique identity raises a logistical question: how does each device acquire its keys and credentials, and how does the cloud learn to trust them, without creating a weak point in the process? One approach is to generate keys during manufacturing, ideally inside a secure element so that the private key is never exposed even to the factory, and to register each device's public key or certificate with the cloud service before shipment. This is robust but ties manufacturing to the eventual deployment, which may not be known when the device is built. A more flexible approach separates the two. Devices are manufactured with a credential that proves they are genuine products of a particular manufacturer, signed by the manufacturer's certificate authority, but that does not yet grant access to any particular customer's system. On first connection, the device contacts a provisioning service, proves its authenticity, and is assigned to the correct customer, cloud tenant and configuration, receiving its operational credentials in the process. Cloud providers offer such services, for example the Azure IoT Hub Device Provisioning Service and AWS IoT fleet provisioning, and LwM2M's bootstrap server, described in Chapter 4, serves the same purpose in a standardised way. Matter's commissioning process for smart-home devices, which verifies a device attestation certificate before admitting a device to a home network, applies the same idea in the consumer world. Whatever the mechanism, provisioning should answer three questions clearly. Who can create a valid device identity? How is a genuine device distinguished from a counterfeit or a clone? And how is a device's identity revoked when it is decommissioned, stolen or compromised? The third question is frequently neglected, but a fleet in which credentials cannot be revoked is a fleet in which a stolen device remains a trusted member indefinitely. Updates: the security control that makes all others possible No device ships without bugs, and some of those bugs will be security vulnerabilities discovered years after installation. A device that cannot be updated securely is therefore a device whose security can only decline. Over-the-air firmware update is the control on which every other security property ultimately depends, and it must itself be designed with great care, because an update mechanism is also a perfect way to install malicious code on an entire fleet at once. A secure update system rests on several elements. Signed images ensure that a device installs only firmware signed by the manufacturer's private key, which is kept offline or in a hardware security module and is never present on build servers in usable form. Secure boot ensures that, every time the device starts, its bootloader verifies the signature of the firmware before running it, so that even an attacker who writes to flash cannot persuade the device to execute unsigned code. Anti-rollback protection prevents an attacker from installing an older, correctly signed but vulnerable firmware version. Atomic installation, usually achieved with two firmware slots so that the new image is written to one while the device continues to run from the other, ensures that a power failure or interrupted download never leaves the device unbootable; if the new image fails to start or fails a health check, the bootloader returns to the previous one. The IETF's SUIT working group has published an architecture for firmware updates on constrained devices, RFC 9019, along with a standard manifest format that describes an update, its target devices, its dependencies and its signatures in a compact, verifiable form. Using such a format rather than an ad hoc scheme brings the benefit of collective scrutiny to one of the most security-critical parts of the system. Fleet-scale rollout adds operational discipline. Updates should be staged, starting with a small group of devices, often internal test units and then a small percentage of the fleet, with automated monitoring of health indicators such as reconnection rate, crash reports and battery consumption before proceeding. Devices should report their running firmware version in the device twin, and the target version should be expressed as desired state, as Chapter 6 recommended, so that the fleet's progress towards the target is always visible and devices that were offline during the rollout catch up when they return. The energy cost of updates, discussed in Chapter 7, must be budgeted, and differential updates help both energy and bandwidth. The long tail: lifecycle security The constraint stack in Chapter 1 noted that IoT devices live for a long time. Security over a decade raises problems that do not arise for software replaced every year or two. Certificates expire. Device certificates, broker certificates and the root certificates that devices use to verify servers all have expiry dates. A device whose trust store contains only a root certificate that expires during its service life will one day be unable to verify its server and will fall off the network. This has happened in practice: when a widely used root certificate associated with the Let's Encrypt certificate authority expired in September 2021, a range of older devices and software that had not received updated trust stores began failing to connect to services. Devices must be able to receive updated trust anchors through their update mechanism, and the expiry dates of every certificate in the chain should be tracked as an operational risk. Cryptography ages. Algorithms and key sizes considered strong at installation may be weakened over a device's life, and the transition to post-quantum cryptography, which standards bodies are now pursuing, will eventually reach IoT as well. Devices built today cannot anticipate every future algorithm, but those with secure update, some headroom in memory and processing, and protocol stacks designed to negotiate algorithms rather than hard-code them are in a far better position than those without. Clocks matter. Certificate validation requires a reasonably accurate idea of the current time, and many small devices have no battery-backed clock. They must obtain time securely from the network early in each boot, or adopt validation strategies that tolerate uncertain time without becoming trivially exploitable. Gateways are high-value targets. A gateway, as Chapter 5 explained, often holds the cloud credentials for an entire site and sits between local devices and the internet. Compromising it may give an attacker control of everything behind it. Gateways therefore deserve the strongest protections in the fleet: secure boot, hardware key storage, minimal installed software, timely patching of their operating system and components, and network segmentation so that a compromised local device cannot easily attack the gateway in turn. Decommissioning is part of the design. When a device is retired, its credentials should be revoked, its device twin archived, its retained MQTT messages cleared, and any data it holds erased if it is to be resold or recycled. A fleet's security posture includes every device that has ever been part of it and still has valid credentials. Regulation catches up For many years, IoT security was governed largely by voluntary guidance. That has changed decisively, and an architect designing a fleet today must treat several regulatory regimes as requirements. The details vary and continue to evolve, so specific obligations should be checked against the current texts, but the direction is clear and consistent. Table 5 summarises the principal regimes. Table 5. Principal regulatory regimes for connected-device security. Regime Jurisdiction Status Core expectations ETSI EN 303 645 European standard, widely referenced Published 2020 Baseline consumer IoT security provisions Product Security and Telecommunications Infrastructure (PSTI) regime United Kingdom In force since 29 April 2024 No universal default passwords, vulnerability reporting route, stated support period Radio Equipment Directive cybersecurity requirements European Union Applicable since 1 August 2025 Network protection, data protection, fraud prevention for internet-connected radio equipment Cyber Resilience Act European Union In force December 2024; reporting from September 2026; main obligations from December 2027 Secure design, vulnerability handling, security updates over support period U.S. Cyber Trust Mark United States Voluntary labelling programme launched 2025 Labelled consumer devices meeting NIST-based criteria ETSI EN 303 645, published by the European Telecommunications Standards Institute, set out a baseline of security provisions for consumer IoT that has since become a reference point for many regulators. Its first provisions address precisely the Mirai failure: no universal default passwords, a means for people to report vulnerabilities, and keeping software updated. The United Kingdom's PSTI regime, which came into force on 29 April 2024, made the first three of these legal requirements for most consumer connectable products sold in the UK: manufacturers may not ship products with universal default passwords, must publish a way to report security issues, and must state the minimum period for which the product will receive security updates. The European Union's Cyber Resilience Act, which entered into force in December 2024, goes considerably further and applies across a broad range of products with digital elements, not only consumer devices. Its obligations to report actively exploited vulnerabilities and severe incidents apply from September 2026, and its main requirements, covering secure-by-design development, vulnerability handling and the provision of security updates throughout a defined support period, apply from December 2027. Separately, cybersecurity requirements under the EU Radio Equipment Directive have applied to many internet-connected wireless devices since August 2025. In the United States, the Federal Communications Commission's voluntary Cyber Trust Mark programme, launched in 2025, provides a label for consumer devices that meet criteria derived from guidance by the National Institute of Standards and Technology. For architects, the common thread is that the practices described in this chapter, unique identities, secure updates, vulnerability handling and a defined support lifetime, are no longer simply good engineering. In many markets, they are conditions of sale. The stated support period is particularly significant, because it obliges manufacturers to plan, at design time, how long they will maintain update infrastructure, signing keys and cloud services for each product, which is exactly the long-horizon thinking that IoT's lifecycle demands. Security as an architectural property Security in IoT cannot be added at the end, because almost every security property depends on decisions made earlier: whether the device has a secure element, whether its memory can hold two firmware images, whether its radio budget allows for a TLS handshake, whether its topics are structured to support least-privilege access, whether its configuration is managed declaratively so that the fleet's state can be audited. Each of these is a constraint-stack decision with an energy, cost or complexity price, and each must be taken knowingly. The good news is that the practices that make a fleet secure are, almost without exception, the same practices that make it manageable. Unique identities make devices individually addressable and accountable. Secure, staged updates are how bugs of every kind get fixed. Declarative state in a device twin makes the fleet's configuration visible and auditable. Gateways with minimal software are both easier to secure and easier to operate. Designing for a long lifecycle, with renewable trust anchors and a planned support period, is both a regulatory obligation and a commercial necessity. Security, in other words, is not a separate discipline layered on IoT architecture. It is what IoT architecture looks like when it is done properly. Conclusion It is worth returning one last time to the culvert sensor, now that every layer of its architecture has been examined. It wakes, measures, decides whether anything has changed, and, if so, opens a radio session that has been made as short and as rare as possible. Its message is small, carefully encoded and stamped with the time it was taken. It speaks a protocol chosen for its link: perhaps CoAP over NB-IoT, perhaps a LoRaWAN uplink to a gateway on a lamp post, perhaps MQTT to a broker if it has power to spare. If a gateway is involved, that gateway buffers, reduces and forwards the data, and keeps the local system working when the wide-area link fails. In the cloud, a device twin records what the operator wants and what the device last reported, keeps the two apart and shows the difference as pending work. The device's identity is its own, its firmware can be replaced securely, and its battery, assuming the energy budget was taken seriously, will last as long as the product promised. None of these choices is exotic. What makes them coherent is the order in which they were made. Each layer was designed to fit the one beneath it, starting from the most constrained element in the system, and not the other way round. That is the argument of this book, and the preceding chapters have, in effect, tested it at every layer. It is now possible to say what follows from it. What the argument implies The first implication is about the order of decisions in a project. The questions that matter most, how long the device must last, how often it may speak, how quickly it must respond, and over what link, are the ones that most constrain everything else, yet they are routinely answered late, by default, or by whoever happens to be in the room. A project that begins with the device's energy budget and responsiveness requirements, written down and owned, will make better protocol, gateway and cloud decisions than one that begins with a dashboard mock-up. The energy budget deserves the same status as the system's data model: a living artefact, measured on real hardware and revised whenever a feature is added. The second implication is about the honesty of the cloud's picture. A cloud built around the device's constraints does not pretend to know what it cannot. It distinguishes intention from fact, timestamps every report, shows the age of every value and treats a long silence as information. This sounds like a matter of user interface, but it is architectural: it requires that desired and reported state be modelled separately, that devices report what they actually applied, and that commands carry expiry times. Systems that skip this end up with operators who distrust their own data, which is the most expensive failure an IoT system can have, because it silently undoes the reason the system was built. The third implication is about where complexity is allowed to live. Every chapter encountered a temptation to move complexity into the hardest place to manage it: verbose protocols on narrow links, sprawling software stacks on unattended gateways, imperative commands where declarative state would do, hand-rolled update schemes where a standard exists. The discipline that resists these temptations is the same at every layer. Put logic where it can be updated, observed and tested most cheaply, unless the constraint stack forces it elsewhere, and when it does, keep what is placed there as simple and as standard as possible. The fourth implication is about time. An IoT fleet is a long-lived commitment, and the architecture must be judged by how it ages, not by how it performs at launch. The networks it relies on may be switched off, as 2G and 3G networks have been and as at least one major operator's NB-IoT network has been. The cloud service it connects to may be withdrawn, as Google's was in 2023. Its certificates will expire, its cryptography will weaken and its regulatory obligations will grow, as they have in the United Kingdom and the European Union since 2024. Architectures that isolate vendor specifics behind thin abstractions, keep secure update working above all else, and plan explicitly for a support period are the ones that will still be running, and still be trusted, at the end of their intended life. What remains unsettled Several questions in this field are genuinely open, and it would be misleading to present the architecture as finished. The balance between standardisation and fragmentation is still shifting. MQTT has become a near-universal transport, but the layers above it, topic structures, payload schemas and device models, remain largely bespoke outside specific communities such as Sparkplug's in industry and Matter's in the smart home. LwM2M offers a rigorous device model but has not displaced home-grown MQTT conventions in most deployments. Whether a widely adopted, cross-industry device model will emerge, or whether each sector will continue to maintain its own, is not yet clear. The economics of connectivity are also unsettled. Cellular low-power standards, unlicensed LPWAN and satellite IoT are all evolving, and their relative costs and coverage will change over the lifetime of devices being designed now. The decommissioning of networks shows that choosing a radio is a bet on an ecosystem, and the safest available hedge, multi-technology hardware or modules that support several standards, has its own costs in energy, size and certification. The regulatory landscape, finally, is moving faster than at any time in the field's history. The obligations of the Cyber Resilience Act in particular will be clarified by standards and guidance over the coming years, and manufacturers selling globally must reconcile overlapping regimes. The direction is unambiguous, towards secure design, vulnerability handling and defined support lifetimes, but the details that will determine compliance are still being written. What to do differently For a reader about to design, review or inherit an IoT system, the practical conclusions are few and concrete. Write down the most constrained device's energy budget and responsiveness requirement before choosing a protocol or designing a cloud API, and measure the budget on real hardware as early as possible. Choose the radio by asking what the device actually needs and how long the network will exist, not by habit. Design the topic or resource hierarchy deliberately, with device identity, direction of flow and a version element built in. Use quality-of-service levels for what they actually guarantee, and achieve end-to-end reliability with idempotent processing and stable record identities. Give gateways the functions they need and nothing more, make them report their own health, and treat their logic as versioned code. Model device state as desired and reported, express intentions declaratively, timestamp every report and give every command an expiry. Batch, report by exception and end radio sessions promptly, and test the device's behaviour when the network is absent as carefully as when it is present. Give every device its own identity, make secure update the one subsystem that must never fail, and plan the support period and the decommissioning process before the first unit ships. None of this requires new technology. Everything described in this book exists, is standardised or well established, and is in production use today. What it requires is a habit of mind: looking at every architectural decision from the point of view of the smallest, most distant, most power-starved participant in the system, and asking what it would cost that device. A system designed that way is not merely more efficient. It is more honest about what it knows, more robust when things go wrong and more likely to still be working, quietly and unattended, long after the people who designed it have moved on. Further Reading Standards and specifications OASIS, MQTT Version 5.0 (OASIS Standard, 2019).** The authoritative specification of the protocol described in Chapter 3. Dense but readable, and the only reliable guide to what each feature actually guarantees. The earlier MQTT Version 3.1.1 (2014) remains useful because many devices and services still implement it. Z. Shelby, K. Hartke and C. Bormann, The Constrained Application Protocol (CoAP), RFC 7252 (IETF, 2014). The core CoAP specification, with its companions RFC 7641 (Observe) and RFC 7959 (block-wise transfer). The introductory sections are a clear statement of the design rationale for constrained networks. OMA SpecWorks, Lightweight M2M (LwM2M) Technical Specification. The device management framework described in Chapter 4, with its object model and bootstrap process. The accompanying object registry is a useful reference even for teams that do not adopt LwM2M. Eclipse Foundation, Sparkplug Specification. The industrial conventions for topic namespace, payload encoding and state awareness on top of MQTT, discussed in Chapter 5. LoRa Alliance, LoRaWAN Link Layer Specification and Regional Parameters.** The protocol behind the star-of-stars architecture and device classes in Chapter 2. The regional parameters document explains duty-cycle and frequency constraints market by market. B. Moran, H. Tschofenig, D. Brown and M. Meriac, A Firmware Update Architecture for Internet of Things, RFC 9019 (IETF, 2021). The SUIT architecture for secure updates on constrained devices, a compact statement of the requirements discussed in Chapter 8. ETSI, EN 303 645: Cyber Security for Consumer Internet of Things: Baseline Requirements. The baseline security provisions that underpin several of the regulatory regimes described in Chapter 8. NIST, NISTIR 8259: Foundational Cybersecurity Activities for IoT Device Manufacturers (2020).** Practical guidance from the U.S. National Institute of Standards and Technology on building security into connected products, and part of the basis for the U.S. Cyber Trust Mark criteria. Books David Hanes, Gonzalo Salgueiro, Patrick Grossetete, Robert Barton and Jerome Henry, IoT Fundamentals: Networking Technologies, Protocols, and Use Cases for the Internet of Things (Cisco Press, 2017).** A thorough survey of IoT networking, strong on radio technologies, IP adaptation for constrained networks and industrial use cases. Adrian McEwen and Hakim Cassimally, Designing the Internet of Things (Wiley, 2013).** An accessible, practitioner-oriented introduction to building connected devices, from prototyping to manufacture, with sensible attention to the physical realities that software-focused texts overlook. Dominique Guinard and Vlad Trifa, Building the Web of Things (Manning, 2016).** Argues for applying web architecture to devices, and is a useful counterpoint to broker-centric designs; it complements the discussion of CoAP and HTTP in Chapter 4. Brian Russell and Drew Van Duren, Practical Internet of Things Security (Packt, 2016).** A security engineering perspective on IoT systems, covering threat modelling, identity, cryptography and lifecycle management. Samuel Greengard, The Internet of Things (MIT Press Essential Knowledge series, 2015).** A short, non-technical overview of the field's social and economic context, useful for readers who need to explain IoT to colleagues outside engineering. Research Manos Antonakakis and colleagues, "Understanding the Mirai Botnet", Proceedings of the 26th USENIX Security Symposium (2017).** The definitive measurement study of the Mirai botnet discussed at the start of Chapter 8: how it spread, what devices it infected and why default credentials proved so damaging. Hashtags: #InternetOfThings #IoTArchitecture #IoTSystems #MQTT #MQTTProtocol #MQTT5 #PublishSubscribe #MQTTBroker #EdgeGateways #EdgeComputing #SensorNetworks #WirelessSensorNetworks #IoTConnectivity #IoTCommunication #IoTProtocols #LoRaWAN #BluetoothLowEnergy #NB_IoT #LTEM #Zigbee #ThreadNetworking #CoAP #LwM2M #LowPowerIoT #BatteryOptimization #DeviceTwins #IoTDeviceManagement #OverTheAirUpdates #IoTSecurity #IndustrialIoT

Download the Book (PDF): Introduction Most students who leave home to study in another country prepare for the wrong emergency. They worry about the rare and dramatic: the exotic infection, the hospital stay in a language they cannot speak, the political crisis that sends everyone to the airport. Those events do happen, and some preparation for them is sensible. But the health trouble that actually spoils a semester abroad is usually far more ordinary. It is the three weeks of broken sleep after a twelve-hour flight. It is the stomach that never quite settles because every meal is unfamiliar and some of them are unsafe. It is the prescription that ran out in week six because nobody checked whether the medication could be bought locally. It is the slow, embarrassing loneliness of the second month, when the excitement has worn off, the coursework has arrived, and the friends from orientation have drifted into their own routines. None of these problems is exotic. What makes them powerful is that they arrive together. At home, a bad week of sleep is absorbed by everything else that is stable: familiar food, a known doctor, a friend down the hall, a routine that runs without thought. Abroad, all of those supports are removed at the same moment that the demands on your body and mind are highest. The move itself is the health event. It strips away the scaffolding that normally holds health in place, and it does so just as a new academic system, a new language, and a new set of social rules demand your full attention. That is the argument of this book. Health abroad is decided less by what happens to you there than by the transition you design before and during the move. The student who treats departure as a gradual, planned change of environment, starting at a travel clinic two or three months before the flight and continuing through the first weeks on the ground, is far better protected than the student who simply packs, flies, and hopes. The good news is that the design is not complicated. It requires knowing which decisions matter, when to make them, and where to find reliable information instead of guesswork. What this book covers and what it leaves out The chapters follow the order in which a student actually meets these problems. The first chapter makes the case that relocation is a health event in its own right, and sketches the timeline that the rest of the book fills in. The second deals with the travel clinic and vaccinations: what a pre-travel consultation is for, how vaccines for travelers are categorized, and why the only trustworthy source for your destination is current official guidance applied by a clinician who knows your history. The third covers the practical infrastructure of care: medications, prescriptions, insurance, and how to keep ongoing treatment, including mental health treatment, running across a border. The middle of the book turns to the body in its first weeks abroad. Chapter 4 explains jet lag as a problem of biological timing, and shows how light, sleep, and a small number of well-timed choices can shorten it considerably. Chapter 5 addresses the less discussed period after jet lag: building sleep, movement, and daily routine in a place where none of the old cues exist. Chapter 6 deals with food, from the realistic risk of traveler's diarrhea to the quieter challenge of eating well on an unfamiliar diet, managing allergies, and keeping religious or ethical food practices. The final two chapters address the mind. Chapter 7 examines culture shock, not as the neat four-stage story often told at orientation sessions, but as the research literature actually describes it: a set of distinct adjustment tasks, some emotional and some practical, that improve with specific kinds of effort. Chapter 8 looks at the long middle of a stay and its end: loneliness, mental health, alcohol, personal safety, and the surprisingly difficult return home. What the book deliberately does not do is give destination-specific medical rules. It will not tell you which vaccines you need for a particular country, whether malaria prevention is required in a given region, or what a particular government demands at its border. That omission is intentional. Those requirements change, they depend on your own medical history and itinerary, and printed lists go out of date. Instead, the book shows you how to use the sources that are kept current, above all the Centers for Disease Control and Prevention's travel pages and its reference work known as the Yellow Book, the World Health Organization's international travel and health guidance, your own government's travel-health service, and a qualified travel clinic. The skill this book tries to teach is knowing what to ask and whom to ask. Who this book is for The reader I have in mind is a university student preparing to spend a semester, a year, or a full degree in another country. You might be an American heading to Europe for a spring term, a student from India beginning a master's degree in Canada, a Nigerian student starting a doctorate in the United Kingdom, or a European student taking up an exchange place in East Asia. Because the book is written for readers from many places, it tries not to assume a particular home system. Where it does discuss something specific to one country, such as how American health insurance tends to treat care received overseas, it says so, and it notes that the details differ between countries and between institutions. Your own university's international office and study-abroad office are the authorities on the rules that apply to you. The book also assumes that you are an intelligent adult who will make your own decisions. It does not lecture you about fun. Studying abroad is one of the most valuable experiences a university can offer, and the point of preparing your body and mind is to be well enough to enjoy it, to learn from it, and to handle the difficult moments that come with any serious change. How to use it The chapters can be read in order, and the early ones are most useful two to three months before departure, when there is still time to act on them. A pre-travel medical appointment ideally happens at least a month before you leave, and earlier is better if you need a series of vaccine doses, have a chronic condition, or take medication that may be restricted at your destination. The chapters on jet lag and the first weeks are worth rereading in the days before you fly. The chapters on culture shock and long-term wellbeing are worth returning to about a month after arrival, when their subject matter tends to become real. Throughout, you will find concrete scenarios involving students. These are illustrative composites built to show how common problems unfold, not accounts of real individuals. Where the book cites research or official guidance, the sources are listed in the Notes, and a short annotated list of reliable resources appears in Further Reading. One note is essential before you begin. This book is educational. It explains how health risks and adjustments during international study generally work and how to prepare for them, but it cannot know your medical history, your medications, your destination's current conditions, or your personal risks. It is not a substitute for individual advice from a doctor, a travel health clinician, a pharmacist, or a counselor. When the book says to ask a professional, that is not a formality. It is usually the single most useful thing you can do. A word about attitude There is a way of preparing for travel that turns every glass of water into a threat and every stranger into a risk. That is not the aim here. Anxiety is a poor travel companion, and a student who spends a semester afraid of the food and the city will have lost something that no vaccination can replace. The aim is closer to what an experienced mountaineer means by preparation: do the careful work in advance, so that on the mountain you can pay attention to where you are. Most students who prepare sensibly have a healthy, rich experience abroad. The ones who struggle are rarely the victims of bad luck alone. More often, a series of small, foreseeable problems accumulated because nobody had thought about them in advance. The chapters that follow are an attempt to do that thinking with you, early enough for it to help. Chapter 1: The Move Is the Health Event Consider a second-year engineering student who leaves a mid-sized American city in late August to spend a year at a university in Germany. She is healthy, fit, and organized. She has booked her flight, arranged housing, and bought a rail pass. In her first four weeks she sleeps badly for ten days, skips breakfast because the dormitory kitchen is shared and unfamiliar, walks far more than usual and develops sore feet, catches a cold from the orientation crowd, and spends two anxious evenings trying to work out whether her insurance will pay for a doctor. Nothing on the list is serious. Yet by the end of September she is tired, a little low, behind on reading in her second language, and wondering whether she made a mistake. Her story is typical, and it is worth taking seriously precisely because nothing in it is dramatic. It shows the central fact about health during international study: the most important risks come not from any single threat but from the simultaneous loss of the ordinary systems that keep a person well. Understanding why that happens, and how to plan against it, is the foundation for everything that follows. Why the stressors stack Health in daily life rests on a set of supports that most people never notice because they work automatically. You sleep at roughly the same time because your body clock, your light exposure, and your schedule all agree. You eat reasonably because you know where the food is, what it costs, and how to cook it. You recover from minor illness because you know where the pharmacy is and which remedy works for you. You manage stress because you have people to talk to, places to go, and habits that discharge tension without you having to think about them. And when something goes wrong, you know how to get care: whom to call, where to go, what it will cost. International relocation removes nearly all of these supports in a single day. The body clock is displaced by the flight. The food is unfamiliar, sometimes carries new microbes, and must be bought and prepared in new ways. The pharmacy uses different brand names and may not stock your usual medicine. The friends and family are asleep when you are awake. The health system has different rules for who pays and how appointments work. And the language, even when it is one you have studied, demands constant effort in ordinary transactions that at home take no effort at all. Psychologists who study stress have long observed that the burden of change depends partly on how much of life changes at once, not just on whether any individual change is pleasant or unpleasant. Moving abroad is, for most students, a welcome and chosen event. That does not stop it from being demanding. Excitement and strain can coexist, and in the first weeks they usually do. The student who assumes that a wanted change must feel easy is often the one most surprised when the tiredness and irritability arrive. A useful way to picture this is to think of two quantities: load and reserve. Load is everything the new environment demands of you, from adjusting to a new time zone to decoding a supermarket in another language to understanding what a professor expects in a seminar. Reserve is the capacity you bring to meet those demands, built from sleep, nutrition, physical fitness, social connection, and a sense of control over your circumstances. At home, load is moderate and reserve is steady. In the first weeks abroad, load spikes sharply at the same moment that reserve falls, because sleep is disrupted, eating is erratic, and social ties are thin. The gap between the two is where minor illness, low mood, poor concentration, and bad decisions tend to appear. This picture explains several things that otherwise seem puzzling. It explains why students who have never had trouble with anxiety at home sometimes experience it in the first month abroad. It explains why a cold that would be trivial at home can feel overwhelming when it arrives during jet lag and a first week of classes. And it explains why the most effective preparation is not necessarily the most medical. A student who arrives rested, with a plan for the first week of meals and a list of contacts for help, has protected reserve in ways that matter as much as any vaccine. Two kinds of preparation Preparation for health abroad falls into two categories that are easy to confuse. The first is protective: specific measures that reduce the chance of a specific harm. Vaccinations, preventive medicines for certain regions, insect repellent, safe food and water practices, and road safety fall into this category. They are important, and for some destinations they are essential. They are also the part of travel health that most students have heard of, because it is concrete and because clinics and websites are organized around it. The second category is structural: the arrangements that keep your ordinary health systems running across the transition. This includes having enough medication and the documentation to carry it, understanding your insurance, knowing where to get care at your destination, planning the first days so that sleep and food are handled, keeping up contact with people who matter to you, and deciding in advance how you will respond if you begin to struggle. Structural preparation rarely appears on travel-health checklists in any detail, yet it accounts for a large share of what actually goes wrong. Students tend to over-invest in protective preparation for rare harms and under-invest in structural preparation for common ones. A student may spend an afternoon researching an obscure infection with a tiny risk at her destination and no time at all working out how to refill an antidepressant prescription. Neither task should be neglected, but the balance matters. A good rule is that protective preparation should be driven by professional advice tailored to your itinerary and history, while structural preparation is mostly your own responsibility and requires your own planning. The imbalance has an understandable cause. Protective measures feel like health care: there is a clinic, a needle, a certificate, a sense of having done something. Structural preparation feels like administration, and administration is easy to postpone. Consider a student from Nairobi beginning a two-year master's program in the Netherlands. He attends a travel clinic, updates his vaccinations, and packs a thorough first-aid kit. He does not look into how students register with a general practitioner in his new city, because it seems like something to handle once he arrives. In his fifth week he develops a painful ear infection on a Friday evening. He has no doctor, does not know whether the out-of-hours service will see an unregistered student, and spends the weekend in pain searching forums in a language he is still learning. The infection is easily treated on Monday. The weekend was avoidable, and a single hour of research in the month before departure would have avoided it. There is also a third element, which sits between the other two: information. Knowing where reliable health guidance comes from is itself a form of preparation, and it is one that students routinely neglect in favor of whatever a search engine or a social media thread offers. A forum post from a student who went to the same country three years ago may be honest and well meant, but it cannot tell you what is required now, and it knows nothing about your health. The official sources discussed in the next chapter are dull by comparison, and they are the ones to trust. The shape of a good transition Because the problems of relocation are foreseeable, they can be addressed on a timeline. What follows is a general sequence rather than a rigid schedule. Your own program, destination, and health needs will change the details, and your university's study-abroad or international office may have its own deadlines that come first. Two to three months before departure. This is the time to start the medical side of preparation. Check your destination against current official travel-health guidance, and book a pre-travel consultation with a travel clinic or a doctor who provides travel medicine. The Centers for Disease Control and Prevention advises that travelers see a healthcare provider at least a month before departure, and earlier is wiser for students, whose stays are long, whose itineraries often expand to include side trips, and who may need vaccine series that take weeks to complete. This is also the time to look at your routine vaccinations, which many young adults have let lapse, and to gather your vaccination records. In the same window, begin the structural work. Find out what health insurance your program requires, what your existing coverage does abroad, and whether your destination requires proof of insurance as a condition of a student visa. If you take regular medication, speak to your prescribing doctor about supply, about whether the medicine is available and legal at your destination, and about a letter describing your treatment. If you are receiving care for a mental health condition, begin a conversation with your clinician about continuity. Each of these matters is discussed in Chapter 3. One month before. Complete or continue any vaccinations. Assemble a small medical kit and the documents you will carry. Research how care works at your destination: whether your university has a health service, how students register with local doctors, what the emergency number is, and where the nearest hospital is to your accommodation. Check whether your program or insurer offers a support line for students abroad, and save the number. The final week. Begin preparing your body clock if you are crossing many time zones, using the approaches in Chapter 4. Get as much sleep as you can; many students do the opposite, staying up late to pack and say goodbye, and arrive already sleep-deprived. Plan your first twenty-four hours after arrival: how you will get from the airport to your accommodation, where you will eat, and what you will do on the first evening. The less you have to improvise while exhausted, the better. The flight and the first seventy-two hours. These are the days of highest load and lowest reserve. The aims are modest: arrive safely, get light at the right times, eat something regular, drink enough water, sleep at local night-time as best you can, and avoid big decisions. Do not plan an ambitious schedule of sightseeing or late nights for the first days. Your body is doing real work. The first six weeks. This is the period in which routines are built or not built. It is when sleep and eating habits settle into their new pattern, when social networks form, and when the novelty of the place gives way to the demands of the academic term. Chapters 5 through 8 are mostly about this period. The single most useful principle is to deliberately construct the routines that at home you never had to think about: a regular wake time, a place to buy food, a form of exercise, a way of staying in touch, and at least one standing social commitment. Two cautions apply to this timeline. The first is that it compresses badly. Students who receive a late acceptance, or who decide to go abroad only a few weeks before a program starts, should still see a clinician as soon as possible. Even a last-minute consultation is worth having: some vaccines give useful protection after a single dose, preventive medicines can often be started shortly before travel, and the advice about food, insects, and injury does not depend on timing at all. The second caution is that the timeline does not end at arrival. Many students treat preparation as something completed at the airport, when the most consequential habits are formed in the weeks afterward. It helps to think of the first six weeks as the second half of preparation rather than as the beginning of the experience proper. Knowing your own baseline A final part of preparation is less about the destination than about you. Before you leave, it is worth taking honest stock of how your health usually works, because relocation tends to exaggerate existing patterns. A student who sleeps poorly under stress at home will likely sleep poorly in the first weeks abroad. A student who eats irregularly during exam periods will be at risk of doing the same when every meal requires new effort. A student with a history of depression or anxiety may find that the first months abroad test the strategies that have kept those conditions in check. This is not a reason for alarm, and it is certainly not a reason to avoid studying abroad. Many students with chronic conditions, including mental health conditions, study abroad successfully every year. It is a reason to plan with your own history in mind. Ask yourself a few questions. When you have struggled in the past, what were the early signs? What helped? Who did you turn to? Which of those supports will travel with you, and which will need replacing? A student who knows that low mood usually begins, for her, with withdrawing from people and sleeping late can watch for that pattern abroad and act early, rather than recognizing it only after several weeks. It also helps to think about your own tendencies under novelty. Some people cope with an unfamiliar environment by doing too much: filling every evening, saying yes to every trip, sleeping little because there is so much to see. Others cope by doing too little: retreating to their rooms, avoiding situations where they might feel awkward, waiting for things to feel comfortable before engaging. Both patterns are understandable, and both can undermine health if they persist. Knowing which one is more like you allows you to plan the correction in advance, whether that is protecting two quiet evenings a week or committing to one new social activity each week regardless of how you feel. It is equally useful to know your own practical details: your blood type if you know it, your allergies, your vaccination history, the generic names of your medicines, and the contact details of your doctors at home. Write these down in a single document, keep a copy on your phone and a paper copy in your luggage, and share one with a trusted person at home. If you are ever unwell and unable to explain yourself clearly, that document will speak for you. Treating the move as a health event changes how a student behaves in small but meaningful ways. It changes the decision to take a red-eye flight and head straight into a welcome party. It changes the choice to bring one month of a daily medication and "sort it out there." It changes whether a student ignores the first signs of loneliness or treats them as a signal to act. Most of all, it gives a student permission to go gently in the first weeks, to recognize that feeling tired, disoriented, or low during a major relocation is a normal response to a heavy load, not a sign of personal failure or a bad choice of program. The engineering student in Germany did nothing wrong. She simply had not thought of her first month as a period requiring care. Had she arrived with a plan for her first week of meals, a strategy for getting her sleep onto local time, a clear understanding of her insurance, and a standing weekly call with a friend at home, her September would probably still have been demanding. But it would have been demanding in a way she recognized and could manage, rather than in a way that made her question the whole venture. The chapters that follow take each part of that plan in turn, beginning with the part that has to happen first: the visit to a travel clinic. Chapter 2: The Travel Clinic and Your Vaccinations Ask a group of students what they need to do medically before studying abroad and most will say "get my shots." The instinct is right but incomplete. Vaccinations are the most visible part of travel medicine, and for some destinations they are genuinely important. But the purpose of a pre-travel consultation is broader: it is a structured assessment of the risks your particular trip poses to your particular body, followed by a plan to reduce them. Vaccines are one tool in that plan. Advice about food, water, insects, injury, medications, and what to do if you fall ill are others, and they are often just as valuable. This chapter explains how that assessment works, how travel vaccines are categorized, and how to find reliable information. It does not list which vaccines you need for any particular country. That is not an evasion. Vaccine recommendations for travelers depend on the destination, the regions within it you will visit, the season, the length of stay, your activities, your age, your vaccination history, and your health, and the official guidance is updated as disease patterns change. A printed list would be wrong for many readers and out of date for the rest. What this chapter can do is make you an informed participant in the conversation with the clinician who will give you a correct answer. What a pre-travel consultation is for A pre-travel consultation is typically offered by specialist travel clinics, by some general practitioners and family doctors, by many university health services, and in some countries by pharmacies with trained staff. The clinician's job is to combine three kinds of information: what is known about health risks at your destination, what you will actually be doing there, and what is true about you. The first kind of information comes from official sources, which the clinician will consult and which you can consult too. The second and third kinds come from you, and the quality of the advice depends heavily on how much you tell. Students often describe their trip too narrowly. A student may say "I'm going to study in Madrid for a semester" when the full truth is "I'm studying in Madrid, and I plan to spend spring break in Morocco and maybe a week in Peru over the summer." The side trips can change the advice substantially. Tell the clinician everything you might plausibly do, including rural travel, volunteering, hiking, contact with animals, visits to friends and family in their homes, and the possibility of new sexual partners. These are not matters of judgment; they are the variables that determine risk. The personal history matters as much. Bring your vaccination records, a list of your medications and allergies, and a summary of any chronic conditions. Tell the clinician if you are pregnant or might become pregnant, if you have a weakened immune system for any reason, including medications such as steroids or biologic drugs, or if you have had a serious reaction to a vaccine before. Some vaccines are unsuitable in these circumstances, and some preventive medicines interact with other treatments. A good consultation usually ends with several things: a plan for vaccinations, with dates if a series is needed; a decision about preventive medicine for any destination where malaria or other conditions call for it; advice about food and water, insect bites, sun, altitude, road safety, and sexual health; and a discussion of what to do if you become ill, including whether to carry any standby treatment. If you leave with only a list of injections, ask about the rest. Where reliable information comes from Before and after the consultation, you will want to read about your destination yourself. The difficulty is that travel-health information online ranges from excellent to dangerously wrong, and search engines do not reliably tell the difference. The most useful habit is to go directly to a small set of official sources that are maintained by public health agencies and updated as conditions change. Table 1 summarizes several widely used ones. They sometimes differ slightly in emphasis, because they are written for different populations and health systems, but they draw on the same underlying evidence. Table 1. Official travel-health sources and what each is best used for. Source Maintained by Best used for CDC Travelers' Health (cdc.gov/travel) US Centers for Disease Control and Prevention Destination pages listing recommended vaccines and medicines; current travel health notices CDC Yellow Book (cdc.gov/yellow-book) US Centers for Disease Control and Prevention Detailed reference on travel illnesses, vaccines, and prevention, written for clinicians but readable WHO international travel and health (who.int) World Health Organization Global guidance, disease outbreak news, and yellow fever vaccination requirements by country TravelHealthPro (travelhealthpro.org.uk) UK National Travel Health Network and Centre Country pages and outbreak alerts for travelers from the UK Government travel advice (e.g. travel.gc.ca, smartraveller.gov.au) National foreign ministries Health and safety notices, entry rules, and consular help for that country's citizens Three points about using these sources are worth stressing. First, they are starting points for your conversation with a clinician, not substitutes for it. A destination page will list vaccines that are recommended for most travelers and others recommended for some, and deciding which group you fall into is exactly what the consultation is for. Second, entry requirements, such as proof of certain vaccinations, are set by the destination country, and the authoritative source for them is that country's embassy or consulate and its official immigration pages, together with the WHO's published list for yellow fever. Third, check your sources again close to departure. Outbreaks, notices, and recommendations change, and what was true when you booked may not be true when you fly. What should you do with information from friends, forums, and social media? Treat it as a prompt for questions, never as an answer. If a student who studied at your host university says that everyone needs a particular vaccine, or that nobody bothers with one, the right response is to check that claim against official guidance and raise it with your clinician. Peer advice is often valuable for practical matters, such as which campus clinic is friendly to international students, and unreliable for medical ones. How travel vaccines are categorized Clinicians and official sources tend to group vaccines for travelers into three broad categories. Understanding the categories helps you make sense of the advice you receive, and it prevents a common confusion: treating a vaccine that is merely "not required" as if it were unnecessary. The distinctions are summarized in Table 2. Table 2. The three broad categories of vaccines for travelers. Category What it means Typical examples Who decides Routine Vaccines recommended for people of your age at home, regardless of travel Measles-mumps-rubella, tetanus-diphtheria-pertussis, influenza, others per national schedule Your national immunization schedule and your clinician Recommended Vaccines advised because of risks at a destination or in certain activities Hepatitis A, typhoid, rabies, Japanese encephalitis, depending on itinerary Official travel guidance applied by your clinician Required Vaccines that a country demands as a condition of entry Yellow fever for certain countries and routes The destination country's government, per WHO rules Routine vaccines are the easiest to overlook and among the most important. Many young adults have gaps in their childhood or adolescent vaccinations, or have never had boosters that are due in adulthood. Travel brings you into contact with large numbers of new people, often in dense settings such as dormitories, lecture halls, and airports, and diseases that are uncommon in your home country may be circulating elsewhere. Measles is the classic example: it is highly contagious, it continues to cause outbreaks in many parts of the world, including high-income countries, and it is preventable with a vaccine most people received as children. Checking that you have had the recommended doses for your age is the first step in any pre-travel plan. The same review is a good opportunity to confirm your tetanus booster status, to get the current season's influenza vaccine, and to follow current national advice on COVID-19 vaccination. Many universities have their own vaccination requirements for enrolled students, independent of travel, and these sometimes include vaccines against meningococcal disease, which spreads more readily among young adults living in close quarters. If you are enrolling in a foreign university as a degree student, check its requirements as well as your home institution's. Recommended travel vaccines are those advised because of specific risks at a destination or during specific activities. Whether you need any of them depends on your itinerary and circumstances. Hepatitis A and typhoid, both spread through contaminated food and water, are frequently recommended for travelers to regions where sanitation infrastructure is limited. Rabies pre-exposure vaccination may be advised for longer stays in areas where rabies is present in animals and access to post-exposure treatment is uncertain, or for students who will work with animals or spend time in remote places. Japanese encephalitis vaccine is considered for some travelers to parts of Asia and the western Pacific, depending on season, location, and duration. Tick-borne encephalitis vaccine is relevant for some outdoor activities in parts of Europe and Asia. Hepatitis B vaccination, which is part of routine schedules in many countries, is also often reviewed for long stays. The phrase "depending on itinerary" is doing real work in each of those sentences. A student spending a semester in a capital city and a student spending the same semester doing rural fieldwork in the same country may receive quite different advice. This is why vaccine lists copied from the internet are unreliable, and why the clinician needs your full plans. Required vaccines are those a country demands as a condition of entry. The best-known example is yellow fever. Under the International Health Regulations, some countries require travelers to show proof of yellow fever vaccination, sometimes for all arrivals and sometimes only for travelers coming from, or transiting through, countries where the disease is present. The proof is a stamped International Certificate of Vaccination or Prophylaxis, often called the yellow card. Since 2016, under an amendment to the Regulations, a single dose of yellow fever vaccine has been treated as valid for life for the purposes of this certificate. Because requirements depend on the countries on your route, including transit stops, you should check the WHO's current list and the destination's official entry rules, and let your clinician know every country you will pass through. Yellow fever vaccine is given only at designated centers in many countries, so find one early. Some countries also have health-related requirements for long-stay visas that are not vaccinations as such, such as screening for tuberculosis for applicants from certain countries, or proof of health insurance. These are set by immigration authorities, and your university's international admissions office will usually know what applies. The main practical reason to start early is that several travel vaccines require more than one dose, spaced over weeks or months, and protection builds over time after vaccination. Some vaccines also interact with others in ways that affect scheduling. Certain live vaccines, for instance, are generally given either on the same day or separated by several weeks. Your clinician will build a schedule that fits your departure date, and a late start may mean an accelerated schedule or incomplete protection at arrival. Even so, a late visit is always better than none. Cost is a real barrier for many students. In some health systems, routine vaccines are free or covered by insurance while travel-specific vaccines must be paid for privately, and the prices can be substantial. There are several ways to manage this. Ask your university health service whether it offers travel vaccines, since campus clinics are sometimes cheaper than private travel clinics. Ask your insurer or national health service which vaccines are covered. Ask your clinician to help you prioritize if cost forces a choice, rather than skipping the consultation altogether; they can tell you which vaccines address the most significant risks for your plans. And check whether your study-abroad program offers any support for pre-departure medical costs. Keep good records. Ask for written documentation of every vaccine you receive, including the product and date, and store a copy digitally and on paper. Keep any International Certificate of Vaccination or Prophylaxis with your passport. If you will be abroad for a long time, you may need boosters or further doses while you are there, and records make it far easier for a clinician in another country to know what you have had. Beyond vaccines: the rest of the consultation Vaccination is the part of the consultation students remember, but several other parts deserve equal attention. The first is prevention of insect-borne disease. For many destinations, the most important protection against diseases such as malaria and dengue is not a vaccine but avoiding bites: using an effective repellent, wearing covering clothing at the times the relevant mosquitoes bite, and sleeping in screened or air-conditioned rooms or under treated nets where appropriate. Official sources such as the CDC list repellent ingredients with good evidence behind them, including DEET, picaridin, IR3535, and oil of lemon eucalyptus. For regions where malaria is transmitted, your clinician may recommend preventive medicine. The choice of drug, when to start and stop it, and whether it is needed at all are decisions that depend on your destination and health, and they should never be made from a forum post. Students sometimes stop taking antimalarial medicine early because they feel well or because side effects are inconvenient; if you have problems with a prescribed medicine, contact a clinician about alternatives rather than stopping on your own. The second is advice about food and water, which is covered in detail in Chapter 6, including whether to carry any standby treatment for traveler's diarrhea. The third is injury. For young, healthy travelers, injuries, particularly from road traffic crashes and water-related accidents, are a more serious threat to life than most infections. The CDC identifies road traffic crashes as a leading cause of preventable death and injury among travelers. A clinician may not raise this unless asked, but it is worth discussing: the habits that protect you at home, such as wearing a seatbelt and a helmet, not riding with a driver who has been drinking, and avoiding swimming after alcohol, are sometimes abandoned abroad in exactly the settings where they matter most. The fourth is sexual health. Students abroad often have new relationships, and the risks of sexually transmitted infections and unintended pregnancy travel with them. Bringing condoms from home, since quality and availability vary, and knowing how to obtain contraception and emergency contraception at your destination are simple, sensible steps. If you use hormonal contraception, arrange enough supply, and ask about how time-zone changes affect the timing of daily pills. Many students leave a consultation without asking the questions that would have been most useful to them, simply because they did not think of them in the moment. A short list, brought to the appointment, solves this. Useful questions include: Given everything I have told you, which risks at my destination matter most for me? Are there any vaccines I should consider getting at my destination later in my stay? Should I carry any medicines for self-treatment, and exactly when would I use them? What symptoms, while I am abroad or after I return, should make me seek care promptly? And if I add a side trip later, should I come back or contact you? That last question is important. Plans change during a semester abroad, and a spontaneous trip to a region with different risks may call for fresh advice. Many travel clinics are happy to answer brief questions by phone or email, and official destination pages are always available. The habit worth building is simple: when your itinerary changes, check the guidance again. A pre-travel consultation, done well, should leave you not more anxious but more settled. The risks will have been named and sized, the preventable ones addressed, and the rest reduced to sensible habits. The next task is to make sure that the health care you already rely on at home travels with you. Chapter 3: Medications, Insurance, and Continuity of Care Some of the most stressful health problems that students face abroad have nothing to do with illness. They are problems of access. A student with asthma discovers that her inhaler is sold under a different name and requires a prescription she cannot get without a local doctor. A student taking medication for attention deficit hyperactivity disorder learns at the airport, or worse, at the border, that his medicine is tightly controlled in his destination country. A student who has been seeing a therapist weekly for a year assumes the sessions can simply continue by video, only to be told that her therapist is not permitted to treat patients located abroad. A student with a sprained ankle is asked to pay a large bill at the clinic desk and has no idea whether he will ever be reimbursed. Each of these students is healthy enough to study abroad, and each problem could have been prevented or reduced with preparation. This chapter covers the practical infrastructure that keeps your existing care running across a border: medications, insurance, ongoing treatment, and knowing where to go when you need a doctor. It is the least glamorous part of preparing to study abroad, and for many students it is the most consequential. Carrying medication across borders If you take any medication regularly, start planning its supply as soon as you know you are going abroad. There are three questions to answer: whether the medicine is legal to bring into your destination, how you will have enough for your whole stay, and what you will do if you need more. The legal question matters more than most students realize. Countries regulate medicines differently, and a drug that is routinely prescribed in one country may be restricted, require special permission, or be prohibited in another. The medicines most likely to be affected are those classed as controlled substances, which can include stimulant medications for attention deficit hyperactivity disorder, opioid pain medicines, some medicines for anxiety and sleep, and certain medicines derived from cannabis. Even some over-the-counter products, including some cold remedies, can be restricted in particular countries. The rules may limit the quantity you can bring, require a permit applied for in advance, or require documentation from your doctor. The authoritative source for these rules is your destination country's embassy or consulate, or its national medicines regulator. The International Narcotics Control Board, a United Nations body, also collects information about national regulations for travelers carrying medicines that contain controlled substances. Do not rely on the fact that a friend brought the same medicine without trouble. Enforcement varies, and the consequences of carrying a restricted substance without authorization can be serious. If you discover that your medication is restricted, talk to your prescribing doctor well before departure. In some cases the paperwork is straightforward; in others, switching to a different medicine that is permitted at your destination may be the better option, and that switch is best made at home, where you can be monitored while you adjust. For any regular medication, follow a few general rules. Carry it in its original, labeled packaging, which identifies it and links it to you. Keep it in your hand luggage rather than checked baggage, because checked bags are sometimes delayed or lost, and some medicines are damaged by the temperatures in aircraft holds. Bring a copy of your prescription and a letter from your doctor on official letterhead that lists your condition, the medicines you take by their generic names as well as brand names, the doses, and the reason for them. Generic names are important because brand names differ between countries, while the active ingredient does not. Quantity is the next problem. Ideally you would bring enough for your entire stay plus a margin for delays. That is not always possible: prescribers may be limited in how much they can issue at once, insurers may restrict early refills, and some destinations limit how much of a controlled medicine a traveler can bring. Ask your doctor and pharmacist what is possible. Some insurers will authorize an extended supply for travel if you ask and explain the situation. If you cannot bring enough for the whole stay, make a plan before you leave for how you will obtain more, which usually means registering with a doctor at your destination early in your stay and bringing your records to that first appointment. Do not plan to have medicines posted to you from home without first checking that this is permitted; many countries restrict importing medicines by mail, and packages can be held at customs. A particular warning applies to buying medicines abroad. In your host country, your medicine may be available under a different name, in a different strength, or combined with other ingredients. A pharmacist can help you identify the right product if you know the generic name and dose. Be very cautious, however, about buying medicines from unregulated sources, including many websites and informal markets. The World Health Organization has repeatedly warned that substandard and falsified medical products are a global problem, and they are especially common where regulation is weak or where medicines are sold outside legitimate pharmacies. Some medicines need extra planning because of the flight itself. Insulin and other injected medicines must be kept at safe temperatures and carried with the necessary equipment, and the timing of doses across time zones should be discussed with your diabetes team before travel. Hormonal contraceptive pills taken at a fixed time of day also require a plan for the time-zone change, because a long flight can shift your usual dose time by many hours. If you use medical devices, such as a continuous glucose monitor, an insulin pump, or a machine for sleep apnea, check the airline's rules, bring spare supplies, and confirm that your device's charger will work with the local electrical supply. Insurance and paying for care Health insurance for students abroad is a subject where generalization is difficult, because arrangements depend so heavily on your nationality, your destination, your university, and your type of program. What follows describes the main patterns and the questions to ask. Your study-abroad office or international student office is the authority on what applies to you. For students from the United States, a common and costly misunderstanding is the assumption that a domestic health insurance plan will cover care abroad in the same way it does at home. Many American plans offer limited or no coverage outside the country, and even where coverage exists, the plan may pay only for emergencies, may require you to pay the foreign provider up front and claim reimbursement later, or may exclude medical evacuation. Government programs such as Medicare generally do not cover care received abroad. For these reasons, many American universities require students on their programs to enroll in a specific international health insurance plan. If yours does not, it is worth buying coverage designed for students abroad. Students from other countries face different arrangements. Students from European Union countries studying elsewhere in the EU, the European Economic Area, or Switzerland can often use the European Health Insurance Card to access necessary state-provided health care on the same terms as local residents, though it does not cover everything, and private care or repatriation is usually excluded. Students traveling to countries with national health services may be able to register with that service, sometimes after paying a fee. The United Kingdom, for example, charges most visa applicants an immigration health surcharge as part of the visa application, which gives access to the National Health Service. Other countries require international students to hold a particular kind of private insurance, and proof of adequate insurance is sometimes a condition of receiving a student visa at all. Because these rules change and vary, check them with your host university and with the official immigration pages of your destination. Whatever system applies to you, ask your insurer or study-abroad office a specific set of questions before you leave: 1. What care is covered abroad: emergencies only, or also routine visits, prescriptions, mental health care, and dental care? 1. Will I have to pay up front and claim reimbursement, and what documents will I need to make a claim? 2. Is there a list of providers at my destination who bill the insurer directly? 3. Does the policy cover medical evacuation to a hospital with adequate facilities, and repatriation home if necessary? 4. Are pre-existing conditions covered? 5. Is there a support line available around the clock, and in what languages? 6. Does the coverage extend to side trips to other countries? Write the answers down, save the insurer's emergency number in your phone, and carry your insurance card or policy details with you. The time to learn how to make a claim is before you need to. Evacuation coverage deserves a word of its own because students tend to dismiss it as something for serious adventurers. Medical evacuation means being transported, sometimes by specialized air ambulance, to a hospital able to treat a serious illness or injury, which may be in another city or country. Without insurance, the cost can be enormous. For most students the likelihood of needing it is small, but the consequences of being uninsured when it happens can burden a family for years. Good student policies usually include it. Keeping ongoing care going If you are being treated for a chronic condition, the goal is to arrive with a plan that keeps your treatment steady during the most disruptive period of your stay. The best way to start is a dedicated appointment with the clinician who manages your condition, a few months before departure, with a simple agenda: how will my treatment continue while I am away, what changes in my routine could affect my condition, what signs should prompt me to seek care, and whom should I contact? This matters for a wide range of conditions. For students with asthma, the new environment may bring different allergens, air pollution, or respiratory infections, and a spare inhaler and a written action plan are sensible. For students with diabetes, the changes in food, activity, and meal timing that come with relocation can disturb blood glucose control, and a plan for the first weeks is essential. For students with epilepsy, sleep deprivation from travel and jet lag can make seizures more likely, which makes protecting sleep in the first days a medical priority rather than a comfort. For students with disabilities, the accommodations provided by your home university do not automatically transfer to a host institution, so contact the host university's disability or accessibility office early, with documentation. Mental health care needs particular care, because both the need for it and the barriers to it can increase abroad. If you are in therapy or taking medication for a mental health condition, talk with your clinician about the move well in advance. Some specific questions are worth raising. Can therapy continue by video while I am abroad? This is not always possible: in some jurisdictions, including many American states, clinicians are licensed to treat patients located within their own jurisdiction, and some cannot legally provide therapy to a patient who is physically in another country. Ask directly rather than assuming. If sessions cannot continue, can your clinician help you find a provider at your destination, perhaps one who works in your language? Does your host university have a counseling service, and do its clinicians work in English or your first language? Does your insurance cover mental health care abroad? Just as important is a plan for difficult periods. With your clinician, work out your own early warning signs, the steps you will take if they appear, and the people you will contact. Some students choose to tell their study-abroad program about a mental health condition so that staff can support them if needed. That decision is yours, and disclosure is voluntary, but programs can usually help more effectively when they know. Whatever you decide, leave with the contact details of a local counseling or mental health service, your program's emergency contact, and your insurer's support line saved in your phone. Finding care when you arrive The most useful thing you can do in your first week abroad, from a health point of view, is to learn how to get care before you need it. That means finding out where students go for routine medical care, how to register, what it costs, and what to do outside office hours. At many universities, the answer is a student health service or a designated local clinic. In countries with national health services, students may need to register with a local general practice, and registration can take time, so do it early. International student offices usually provide this information at orientation; if they do not, ask. Save a few numbers in your phone and write them on paper: the local emergency number, which differs by country; the number for your insurer's support line; your program's emergency contact; and the address of the nearest hospital emergency department to where you live. In the European Union and in many other countries, 112 connects to emergency services, and many mobile networks route it correctly even in countries that use another number, but learn the local number rather than relying on this. Your own country's embassy or consulate can also help in serious situations and often publishes lists of local doctors and hospitals, including those with staff who speak your language. Seeing a doctor in another country for the first time can be disconcerting even when the care is excellent. Consultations may be shorter or longer than you are used to. Doctors may be more or less willing to prescribe antibiotics, more or less directive, or more or less inclined to explain their reasoning. Pharmacies may play a larger role than at home, with pharmacists advising on minor conditions and dispensing medicines that would require a prescription elsewhere, or a smaller one. None of this means the care is worse; it is often simply different. What helps is preparation: bring your summary of medical history and medicines, write down your symptoms and questions before the appointment, and if you are not confident in the local language, ask whether an interpreter is available or bring a trusted friend. Translation apps can help with simple exchanges, but for anything complex or serious, a qualified interpreter is safer, and many health systems provide one on request. Consider an illustrative exchange student from Australia studying in Japan who develops a persistent cough in her second month. She has registered with the university health center, which gives her a referral to a local clinic. Before the appointment, she writes a short note in simple English, which a Japanese classmate helps her translate, listing when the cough began, her other symptoms, her asthma history, and the inhaler she uses. The doctor reads it, examines her, and adjusts her treatment. The whole visit takes less time than she feared. The note did most of the work, and it took twenty minutes to prepare. Finally, bring a small medical kit that covers the minor problems which are inconvenient to solve in an unfamiliar place, especially in the first days. A sensible kit might include your regular medicines, a pain and fever reliever you know you tolerate, oral rehydration salts, adhesive bandages and antiseptic, a thermometer, sunscreen, insect repellent if appropriate, and any standby treatment your clinician has recommended. The point is not to become your own doctor, but to avoid a late-night search for a pharmacy with a fever, in the rain, in a city you arrived in two days ago. Access to care is easy to take for granted until it disappears. A student who arrives with enough medicine, clear documentation, an understanding of her insurance, and a doctor's address already registered has quietly removed one of the largest sources of avoidable stress in the first months abroad. With that infrastructure in place, attention can turn to the first challenge the body meets on arrival: the confusion of its internal clock. Chapter 4: Jet Lag and the Science of Resetting Your Clock Jet lag is often treated as a minor inconvenience, something to be endured for a day or two with coffee and willpower. For a student crossing many time zones at the start of an academic term, it is more than that. It can mean a week or more of nights spent awake at three in the morning and afternoons spent fighting sleep in orientation sessions, placement tests, and first lectures, precisely when the student most needs to be alert, sociable, and able to absorb large amounts of new information. It also wears down the reserve described in Chapter 1, at the moment when that reserve matters most. The encouraging news is that jet lag is one of the best understood problems in travel health. It is caused by a mismatch between the time kept by an internal biological clock and the time of the place you have arrived, and that clock responds in predictable ways to a small number of signals, above all light. A student who understands how it works can shorten jet lag considerably, not by heroic effort but by timing a few ordinary things well. The clock inside you Nearly every tissue in the human body runs on a roughly twenty-four-hour cycle, known as a circadian rhythm. These rhythms govern when you feel sleepy and alert, when your body temperature rises and falls, when certain hormones are released, and even when your digestive system expects food. They are coordinated by a master clock in a small region of the brain called the suprachiasmatic nucleus, which sits just above the point where the optic nerves cross. The master clock keeps time on its own, but not perfectly. In most people, its natural cycle is slightly longer than twenty-four hours, so it must be nudged back into line each day. The strongest nudge is light reaching the eyes, which the clock receives through specialized cells in the retina. Other signals, including meal times, physical activity, and social routines, have weaker effects. Under normal conditions, the daily pattern of light and darkness keeps the clock aligned with local time, and you feel sleepy at night and alert during the day without thinking about it. In the evening, as darkness falls, the brain begins to release melatonin, a hormone that signals biological night. Core body temperature falls through the night, reaching its lowest point a couple of hours before your usual waking time, and then begins to rise toward morning. That low point is a useful landmark, as we will see, because the effect of light on the clock depends on which side of it the light arrives. When you fly across several time zones, the local clock changes in hours, but your internal clock does not. It carries on keeping the time of the place you left. If you fly from Boston to Rome, six time zones east, your body will want to sleep at what is early morning in Rome and will feel alert late into the Roman night. The symptoms of jet lag, which include difficulty falling asleep or staying asleep at night, sleepiness and impaired concentration during the day, irritability, low mood, and digestive upset, are the result of living out of step with your own biology. The internal clock does adjust, but only gradually. Estimates vary between individuals and studies, but a common rule of thumb in the medical literature is that the clock shifts by roughly an hour or so per day without deliberate intervention. That is why crossing two or three time zones rarely causes serious trouble, while crossing eight or ten can leave a traveler disordered for a week or more. Direction matters too. Because the clock's natural cycle runs slightly long, it finds it easier to shift later than earlier, which is why most people find eastward travel, which requires the clock to advance, harder than westward travel, which requires it to delay. It is also worth separating jet lag from travel fatigue. A long journey is exhausting in its own right: sleeping badly in a cramped seat, dry cabin air, hours in airports, stress, and irregular meals. Travel fatigue usually resolves after a good night's sleep. Jet lag persists because the underlying cause, the misaligned clock, persists. A student who flies a short distance north to south, crossing no time zones, may be tired on arrival but will not be jet lagged. Light: the master lever Because light is the clock's strongest signal, the most effective way to manage jet lag is to control when you get light and when you avoid it. The principle is precise, and it is worth understanding rather than memorizing, because the details of your journey will differ from any generic rule. Light shifts the clock in different directions depending on when it arrives. Light received in the hours before the body temperature minimum, which is to say late in your biological evening and during your biological night, pushes the clock later. Light received in the hours after the minimum, which is your biological early morning, pushes the clock earlier. Light at other times of day has smaller effects. The pattern that describes this is called a phase response curve, and it underlies nearly all practical jet lag advice. For eastward travel, the goal is to shift the clock earlier, so you want light in your biological morning and should avoid light in your biological evening. For westward travel, the goal is to shift the clock later, so you want light in your biological evening and should avoid it in your biological morning. The complication is that on arrival, your biological morning and evening are still set to your home time zone, not the local one. For modest shifts this rarely matters. For large eastward shifts, however, it can matter a great deal. Consider a student flying from the west coast of North America to a program in continental Europe, nine time zones east. On the first morning after arrival, local morning corresponds to the middle of the night in his home time zone, which may fall before his body temperature minimum. If he goes out into bright early-morning light on that first day, as generic advice might suggest, the light could push his clock in the wrong direction, later rather than earlier. For large eastward shifts, sleep researchers therefore commonly advise avoiding bright light in the early local morning for the first day or two, for example by wearing sunglasses outdoors, and instead seeking light later in the morning and around midday, then moving the light window earlier each day as the clock catches up. For very large shifts of around ten time zones or more, some travelers find that the clock adjusts by delaying instead of advancing, and specialist advice sometimes plans for that. These are situations in which a detailed plan from a reliable source, or a consultation with a clinician who understands sleep, is worth having. Table 3 sets out the general strategies by direction. Treat it as a framework to adapt, not a set of fixed instructions. Table 3. General light and sleep strategies for jet lag, by direction of travel. Direction and size of shift Clock needs to Seek light Avoid bright light Other steps Few time zones (about 3 or fewer) Shift a little Daylight at local times Screens late at night Keep local meal and sleep times; symptoms usually brief Eastward, moderate (about 4 to 8) Move earlier Local morning and midday Local evening Go to bed a little earlier than usual; limit long naps Eastward, large (about 9 or more) Move earlier, slowly Late morning to early afternoon for the first days Early local morning at first, then evening Shift light window earlier each day; consider expert planning Westward (any size) Move later Local afternoon and evening Early local morning for the first days Stay up until local bedtime; westward adjustment is usually faster The table summarizes principles found in clinical reviews of jet lag, including those by Robert Sack and by Jim Waterhouse and colleagues, listed in the Notes. It does not give exact hours because those depend on your usual sleep schedule and the specific time difference. Several free tools and apps now calculate personalized light schedules from these principles; if you use one, prefer one that explains its reasoning and matches the principles above. Two practical points make light-based strategies easier. First, outdoor daylight is far brighter than indoor lighting, even on an overcast day, so a walk outside at the right time does more than sitting near a window. Second, avoiding light is as important as seeking it. Sunglasses outdoors and dim lighting indoors during the wrong windows help, and so does keeping screens dim late in the local evening. Melatonin, caffeine, naps, and sleep medicines Light is the main lever, but several other tools can help, and students frequently ask about them. Melatonin. Taken as a supplement, melatonin has two effects: it can promote sleepiness for a few hours, and, when timed correctly, it can help shift the internal clock. A Cochrane systematic review by Andrew Herxheimer and Keith Petrie, one of the most cited analyses on the subject, concluded that melatonin was effective in preventing or reducing jet lag for travelers crossing five or more time zones, particularly flying east, when taken close to the target bedtime at the destination. The review found that doses between about half a milligram and five milligrams were similarly effective in reducing jet lag, although the higher dose helped people fall asleep faster, and it noted that melatonin appeared safe for short-term use in healthy people, while advising caution for people with epilepsy and people taking the anticoagulant warfarin. Several cautions apply. Melatonin's legal status differs by country: in some, including the United States, it is sold as a dietary supplement; in others, including the United Kingdom, it is available only on prescription. Where it is sold as a supplement, product quality is not regulated in the same way as medicines, and the actual content may not match the label. Timing is critical, because melatonin taken at the wrong time can shift the clock the wrong way. And like any supplement, it can interact with other medicines. If you are considering melatonin, raise it during your pre-travel consultation or with a pharmacist, particularly if you take other medications or have a medical condition. Caffeine. Coffee and tea can help you stay alert during the local day, which makes it easier to stay awake until local bedtime. The drawback is that caffeine lingers in the body for hours and can disrupt the next night's sleep, which is the very thing you are trying to fix. Use it in the morning and early afternoon at your destination, and stop early enough that it does not interfere with sleep. Naps. A short nap can make the first days bearable, but a long nap, especially one taken during your biological night, can deepen the confusion by letting you sleep through the light you need and leaving you unable to sleep at local night. If you must nap, keep it short, around twenty to thirty minutes, and take it in the early afternoon. Set an alarm and put the phone across the room. Sleep medicines. Prescription sleep medicines can help a traveler sleep during the first nights, but they do not shift the internal clock, and they carry risks, including next-day grogginess, impaired judgment, and dangerous interactions with alcohol. They should be used only on the advice of a clinician who knows your history. Be especially wary of taking a sedating medicine on a flight in a way that leaves you immobile for many hours. Alcohol. Many travelers use alcohol to fall asleep on a plane or on the first night. It is a poor choice. Alcohol may help you drift off, but it fragments sleep in the second half of the night and worsens dehydration. Combined with jet lag, it tends to leave you more tired, not less. Planning the journey and the first days The best jet lag strategy begins before you leave. In the final week, you can start moving your sleep schedule toward the destination time zone. A group of sleep researchers led by Charmane Eastman has shown in laboratory studies that shifting sleep by about an hour per day for several days before an eastward flight, combined with bright morning light, can reduce the misalignment you arrive with. Even a partial shift of two or three hours makes the first days noticeably easier. The practical difficulty is that the final week before departure is often full of farewells and packing, and many students do the reverse, staying up late and arriving already short of sleep. Protecting sleep in the last few nights at home is itself one of the most useful things you can do. The choice of flight matters as well. When possible, choose a flight that lets you arrive in the local afternoon or early evening, so that you need to stay awake for only a few hours before local bedtime. On overnight eastward flights, try to sleep during the portion of the flight that corresponds to night at your destination. Set your watch or phone to destination time when you board, and eat and sleep according to that time where you can. Long flights have one other health consideration. Sitting for many hours in a cramped seat increases the risk of blood clots in the legs, known as deep vein thrombosis. The risk for most healthy young travelers is small, but it rises with certain factors, including a previous clot, some inherited clotting disorders, recent surgery, pregnancy, and the use of estrogen-containing contraceptives. Standard advice is to get up and walk when it is safe to do so, flex your ankles and calves while seated, stay hydrated, and avoid heavy use of alcohol and sedatives. If you have risk factors, ask your clinician about further precautions before flying. On arrival, follow a simple rule for the first few days: live on local time as far as possible, and use light as your main tool. Eat meals at local times, even if you are not hungry. Go outside during the light window that suits your direction of travel. Stay awake until a reasonable local bedtime, and get up at a consistent local time each morning even if you slept badly, because a fixed wake time anchors the clock. Build some slack into the schedule. If your program allows it, arrive several days before orientation or classes begin, so that the worst of the jet lag falls on days without obligations. Avoid scheduling important tasks, such as a language placement test or a meeting with an adviser, on the first day after a long eastward flight. Tell yourself in advance that the first nights will be broken and that waking at three in the morning is expected. Lying in bed anxious about sleep makes things worse; if you are wide awake, get up, keep the lights dim, do something quiet, and return to bed when sleepy. Finally, remember that jet lag works in both directions. Students who travel home for a holiday mid-program, or who return at the end of a semester to begin exams or a new term, will face the same process in reverse. The same principles apply, and the same planning helps. A student who manages jet lag well does not escape it entirely. But she compresses a week of disorder into a few days of mild tiredness and arrives at her first classes able to think. That leaves her in a far stronger position for the next task, which is to build a new daily life from scratch. Chapter 5: The First Weeks: Sleep, Movement, and Routine Once jet lag fades, many students expect to feel settled. Often they do not. The internal clock has caught up with local time, but the rest of life has not caught up with anything. There is no regular time to wake because classes start at different hours each day. There is no familiar exercise because the gym at home is thousands of kilometers away. Meals happen when hunger becomes urgent, at whatever place is nearest. Evenings disappear into scrolling through messages from home, which arrive at odd hours because of the time difference. Weekends are either overfilled with trips and parties or strangely empty. This period, roughly the first six weeks after arrival, receives far less attention than jet lag or vaccinations, and yet it is where the habits of a whole stay are set. The routines a student builds or fails to build in these weeks tend to persist. This chapter explains why routines dissolve during relocation, and how to rebuild the three that matter most for health: sleep, physical activity, and the daily structure that holds everything else in place. Why routines dissolve Most healthy behavior at home is not the product of daily decisions. It is carried by context. You go to the gym because it is on the way home and your friend expects you. You eat breakfast because the cereal is in the cupboard and you have done it every morning for years. You go to bed at a certain time because the house goes quiet. Psychologists who study habits describe how behaviors become linked to cues in the environment, so that the cue triggers the behavior with little conscious effort. That is what makes habits efficient, and it is also what makes them fragile when the environment changes. When you move abroad, nearly every cue disappears at once. The kitchen, the route to class, the people, the shops, and the rhythm of the day are all new. The habits that depended on those cues do not transfer automatically. This is why students who were disciplined at home often find themselves unaccountably disorganized abroad. It is not a failure of character. Their habits were anchored in a context that no longer exists, and new habits have not yet formed. There is an opportunity hidden in this. Research on habit change suggests that moments of major life change, such as a move, can make it easier to establish new behavior, precisely because old cues are gone and new ones have not yet been set. A student who arrives abroad has a rare chance to design routines deliberately rather than inheriting them. The student who makes that effort in the first weeks often ends up with better habits than she had at home. The one who does not usually drifts into whatever patterns the new environment suggests, and those are not always healthy. Sleep in an unfamiliar place Even after the body clock has adjusted, sleep in a new place is often poor for a while. Sleep researchers have long observed what they call the first-night effect: people sleep less deeply on their first night in an unfamiliar environment, such as a sleep laboratory. A plausible explanation is that part of the brain remains more vigilant in a new setting. For a student abroad, the unfamiliar setting persists for more than one night. A new bed, unfamiliar noises, different light, a roommate with a different schedule, and a background of mild uncertainty can keep sleep lighter than usual for days or weeks. Local culture adds its own pressures. In some countries, dinner is eaten late in the evening and social life begins at an hour when a student from elsewhere would normally be going to bed. In others, shops and cafes close early and life quietens at night. Housing may be noisy, heating and cooling may work differently, and summer light may stretch late into the evening at high latitudes, while winter days are short. Each of these affects sleep, and each requires some adjustment. The principles for sleeping well in a new place are the same ones that sleep medicine recommends at home, but they need to be applied deliberately because nothing in the environment enforces them. The first and most powerful is a consistent wake time. Your body clock stabilizes around the time you get up and see morning light, more than around the time you go to bed. Choosing a wake time and keeping it on most days, including many weekend days, gives the clock a fixed anchor. If your timetable varies, set the wake time according to your earliest regular commitment, and use the free mornings for exercise, study, or errands rather than for sleeping late. The second is control over the sleep environment. A few inexpensive items solve most problems: earplugs for noise, an eye mask or blackout material for light, and a small fan or extra blanket depending on the climate. If you share a room, talk early with your roommate about sleep times, lights, and noise. That conversation is easier in the first week than in the fifth, when resentment has built. The third is protecting the hour before bed. Late-night messaging with friends and family at home is one of the most common and least discussed sleep problems among students abroad. Because of the time difference, the natural moment for home to reach you may be your late evening or night. Bright screens, emotionally engaging conversations, and the pull of news from home all make it harder to fall asleep. It helps to schedule calls home at a time that suits both of you, rather than letting them drift into your night, and to leave your phone out of reach of the bed. A related trap is the weekend drift. Students abroad often travel on weekends, stay out late on Friday and Saturday nights, and sleep late on Sunday. Each of these may be enjoyable, but together they create what sleep researchers sometimes call social jet lag: a weekly shift in sleep timing that leaves the body clock perpetually adjusting, as if the student flew a few time zones west every Friday and back every Monday. The Monday-morning fog that results is easy to mistake for a lack of motivation or for homesickness. Keeping the weekend wake time within an hour or two of the weekday one, and getting morning daylight even after a late night, limits the damage without requiring a quiet social life. The fourth is recognizing when poor sleep is more than adjustment. If weeks pass and you still cannot sleep, or if sleep problems come with persistent low mood, anxiety, or loss of interest in things you normally enjoy, speak to a doctor or the university counseling service. Persistent insomnia is treatable, and the most effective treatment for chronic insomnia, cognitive behavioral therapy for insomnia, does not rely on medication. Movement as medicine and as structure Physical activity changes dramatically for many students abroad, sometimes for the better and sometimes for the worse. A student who moves from a car-dependent suburb to a compact European or Asian city may find herself walking many kilometers a day without trying, and her fitness may improve. A student who played a team sport at home may lose it entirely and find that, between the demands of study and the effort of daily life, exercise quietly vanishes. The health case for staying active is strong and well known. The World Health Organization's guidelines recommend that adults do at least 150 to 300 minutes of moderate-intensity aerobic activity per week, or an equivalent amount of vigorous activity, along with muscle-strengthening activity on two or more days. For students abroad, activity has particular value beyond general fitness. Regular exercise supports sleep, helps regulate mood, and offers a reliable way to discharge the stress of adjustment. It is also one of the easiest ways to meet people. That last point deserves emphasis. Joining a university sports club, a running group, a climbing wall, a dance class, or a community team gives you a standing commitment with a fixed time and place, which is exactly what a new routine needs. It gives you repeated contact with the same people, which is how friendships form. And it often brings you into contact with local students rather than only with other international students, which has benefits for adjustment discussed in Chapter 7. Few other activities offer health, structure, and social connection in a single package. A few practical points help. Find out early what your university offers; sports clubs often recruit in the first weeks of term, and joining later can be harder. If you exercised in a particular way at home, look for the local equivalent, but be open to what is popular where you are: many students discover a sport they would never have tried at home. If you are walking far more than usual, invest in good shoes; sore feet and blisters are a common and surprisingly limiting complaint in the first weeks. And if you have a health condition affected by exercise, such as asthma or diabetes, remember that a new climate, altitude, or level of activity may require adjusting your management, as discussed in Chapter 3. Climate changes what exercise feels like and what it demands. A student who arrives from a temperate country into tropical heat and humidity will find that a familiar run feels far harder, and that the body needs a week or two of gradual exposure to adapt to heat; exercising in the cooler early morning or evening, drinking more fluids, and easing into intensity reduce the risk of heat illness. A student who arrives from a warm country into a northern winter faces the opposite problem: dark, cold, wet days that make outdoor activity unappealing for months. Here the answer is usually indoor options, such as a university gym, swimming pool, or indoor sports hall, and the right clothing, since in many cold countries people simply dress for the weather and carry on. Local students are usually the best guide to how people in that climate stay active through the year. Be alert to one specific risk. Students abroad sometimes take up activities with real danger attached, such as scooter riding, swimming in unfamiliar water, or hiking in mountains, without the local knowledge that keeps residents safe. Chapter 2 noted that injuries are a leading threat to travelers' health. Use a helmet, learn local traffic patterns before cycling or riding, swim only where it is known to be safe, and never hike alone without telling someone your route. Building a daily structure Sleep and exercise sit inside a larger structure: the shape of a day and a week. At home, that shape is mostly given to you. Abroad, you have to build it, and a little deliberate design goes a long way. A useful approach is to identify a small number of anchor points and fix them early. An anchor point is a regular event at a fixed time that other activities can organize themselves around. The wake time is one. A regular meal, such as breakfast at home or lunch with classmates on weekdays, is another. A weekly exercise session, a standing call with family, a language exchange meeting, and a regular grocery shop are others. Five or six anchors, set in the first two weeks, are enough to give a week its shape. They do not need to be rigid; they need to be reliable enough that you do not have to decide afresh each day whether to do them. Study needs its own structure, and the academic culture you meet abroad may be quite different from home. Some systems rely on frequent assignments and tests; others offer few assessments and expect long periods of independent reading followed by a single examination. Students from systems with frequent deadlines sometimes find the second kind of system disorienting, and the absence of weekly pressure can let the first half of a term slip away. Establishing a regular place and time to study, early in the term, protects against the late-term panic that disrupts sleep and health. Ask local students and teaching staff what successful students actually do; the unwritten expectations are often more important than the written ones. Language adds a hidden load to all of this. Even students who are competent in the local language often underestimate how tiring it is to use it all day. Following lectures, shopping, reading notices, and making small talk in a second language demands constant concentration, and many students report a heavy, unfamiliar fatigue in their first weeks that they attribute to jet lag or illness, when it is at least partly mental effort. Expect it. Build short breaks into the day, and do not interpret tiredness from language effort as a sign that something is wrong. Minor illness also deserves a place in your planning. The first weeks of any academic term bring large numbers of people together from many places, and colds and other respiratory infections spread readily in lecture halls and residences. In the United Kingdom, the wave of colds that follows the start of the academic year is familiar enough to have its own informal name, freshers' flu. Washing hands, staying up to date with seasonal vaccines, getting enough sleep, and resting when you are ill will not prevent every infection, but they help. If you become ill, take it seriously: rest, drink fluids, and seek care if symptoms are severe or persistent, rather than pushing through a demanding schedule and prolonging the illness. It helps to see how these pieces fit together in practice. Consider a first-year master's student from Brazil who arrives in the Netherlands for a two-year program. In her first two weeks, she recovers from jet lag reasonably well but notices that her days have no shape. Her classes are scattered through the week, she eats whenever she remembers, and she spends most evenings in her room on video calls with her family and her partner, which run late because of the time difference. In her third week, she decides to rebuild her routine deliberately. She sets a wake time of seven thirty every weekday, which fits her earliest class. She joins a university rowing club that trains twice a week in the early morning, which, though she had never rowed before, gives her two fixed early starts, exercise, and a group of classmates. She moves her calls with her family to Sunday afternoons, which suit both time zones, and her calls with her partner to an early evening slot rather than late at night. She does her grocery shopping on Monday evenings and cooks two larger meals each week to eat over several days. She reserves the library for study on the mornings she has no classes. None of these choices is remarkable. Together, they give her week a structure that carries her through the less enjoyable weeks of the term, when the novelty has faded, coursework has increased, and the Dutch autumn has grown dark and wet. She still has bad days. But when she has them, her routine keeps running, and it keeps her sleeping, moving, and seeing people, which are exactly the things most likely to see her through. This is the goal of the first weeks. Not a perfect schedule, but enough structure that health no longer depends on how you feel each morning. With that structure in place, the next question is what goes on your plate. Chapter 6: Eating Abroad: Food Safety, New Diets, and the Traveler's Stomach Food is one of the great pleasures of living abroad and one of its most persistent sources of trouble. For many students, eating in a new country is a highlight: market stalls, regional dishes, meals shared with new friends, the gradual confidence of ordering in another language. For others, food becomes a daily low-level stress. They cannot find familiar ingredients, do not know how to cook with local ones, spend more than they can afford, or suffer repeated bouts of stomach upset that make them wary of eating out at all. Two quite different problems are at work here, and it helps to separate them. The first is food safety: the risk of infection from contaminated food and water, which varies greatly by destination and which matters most in the first weeks. The second is nutrition: the quieter challenge of eating well, affordably, and in line with your needs and beliefs, on a diet you did not grow up with, for months at a time. This chapter deals with both, beginning with the one that tends to arrive first. What actually makes travelers sick Traveler's diarrhea is the most common health problem among international travelers, as the CDC Yellow Book notes, and students are no exception. It is usually caused by bacteria, and less often by viruses or parasites, picked up from food or water contaminated with fecal matter. The likelihood depends heavily on the destination: it is much more common where sanitation, water treatment, and food hygiene infrastructure are limited, and less common where they are well developed. But it can happen anywhere, including in wealthy countries, and outbreaks of foodborne illness occur in every part of the world. The traditional advice to travelers is a memorable rule: boil it, cook it, peel it, or forget it. The logic is sound. Heat kills most pathogens, peeling removes contaminated surfaces, and avoiding risky foods avoids risk. The difficulty is that the rule is very hard to follow in real life, particularly for a student living somewhere for months rather than passing through for a week. Studies of travelers have repeatedly found that most people break food rules within days, and the evidence that following them closely reduces diarrhea is weaker than one might expect. One likely reason is that much of the risk lies in things travelers cannot see or control, such as hygiene in restaurant kitchens. This does not mean food precautions are pointless. It means they should be sensible and sustainable rather than absolute. A few habits give the most protection for the least effort, especially in destinations where official sources indicate a higher risk: · Prefer food that is freshly cooked and served steaming hot. Food that has been cooked and then left to sit at room temperature, as on some buffets, carries more risk. · Be cautious with raw foods that cannot be peeled, such as salads, and with raw or undercooked meat, fish, and shellfish, unpasteurized dairy products, and sauces or dips left out on tables. · Fruit you peel yourself, after washing your hands, is generally safer than fruit prepared by others. · Wash your hands with soap before eating and after using the toilet, and carry an alcohol-based hand sanitizer for when soap is unavailable, while remembering that sanitizer is less effective on visibly dirty hands. · Choose busy food stalls and restaurants, where food turns over quickly, rather than quiet ones where it may have been waiting. Water deserves its own attention. In many study-abroad destinations, tap water is safe to drink, and there is no need to buy bottled water. In others, it is not. Official travel-health sources and your host university are the reliable guides; do not assume either way. Where tap water is unsafe, drink sealed bottled water or water that has been properly treated. Boiling is the most reliable method: the CDC advises bringing water to a rolling boil for one minute, or three minutes at altitudes above about 2,000 meters. Filters and chemical disinfectants are useful alternatives, but they vary in what they remove, so check what a particular product is designed to do. Remember that ice, drinks mixed with tap water, and water used to brush teeth can all carry the same risk as the tap itself. For a student who will live in a higher-risk destination for months, the most practical approach is often to be strict in the first weeks, when the gut is least accustomed to local microbes and you do not yet know which places are reliable, and then to relax some precautions as you learn which food sources, cafeterias, and restaurants you can trust. Your local friends and classmates can be helpful here, not because their stomachs are the same as yours, but because they know which places have good reputations. Managing traveler's diarrhea Despite sensible precautions, many students will have at least one episode of traveler's diarrhea. Most episodes are unpleasant but short, resolving within a few days. The priority in every case is to replace the fluids and salts lost through diarrhea, and to recognize the signs that mean you need medical care. Rehydration is the foundation of treatment. For mild illness, drinking plenty of safe fluids is usually enough. For more significant fluid loss, oral rehydration salts, which come as sachets to be mixed with safe water, replace both water and the salts the body needs in the right proportions. They are inexpensive, widely available, and worth carrying in your medical kit. Plain water alone, or sugary soft drinks, do not replace salts as effectively. Beyond rehydration, the choice of treatment depends on how severe the illness is. An international expert panel convened by the International Society of Travel Medicine, whose guidelines were published in 2017 by Mark Riddle and colleagues, recommended classifying traveler's diarrhea by its effect on the traveler rather than by the number of bowel movements. Mild diarrhea is tolerable and does not interfere with planned activities. Moderate diarrhea is distressing or interferes with activities. Severe diarrhea is incapacitating or completely prevents planned activities, and any diarrhea with blood in the stool, known as dysentery, is treated as severe. Table 4 summarizes the general approach the panel described. It is a guide for understanding and for discussion with your clinician before you travel, not a prescription. Table 4. General approach to traveler's diarrhea by severity, following the 2017 expert panel guidelines. Severity How it affects you General approach When to seek care Mild Tolerable; you can carry on with plans Fluids; loperamide or bismuth subsalicylate may be considered If it worsens or lasts more than a few days Moderate Distressing or interferes with plans Fluids; loperamide may be used; antibiotic may be considered if advised by your clinician If no improvement in a day or two, or warning signs appear Severe or bloody Incapacitating, or blood in stool Fluids; antibiotic treatment is usually indicated Promptly, especially with fever, blood, or signs of dehydration The table reflects the published guidelines listed in the Notes. Medicines, doses, and suitability depend on your destination, health, and other medications, so discuss them with a clinician before departure. Several points about these treatments are important. Loperamide, an antimotility medicine, reduces the frequency of bowel movements and can make mild or moderate diarrhea more manageable, for example during a journey. It should not be used if you have a high fever or blood in your stool without medical advice. Bismuth subsalicylate, found in some over-the-counter products, can reduce symptoms, but it is related to aspirin and is not suitable for everyone, including people allergic to aspirin or taking certain medications. It also harmlessly turns the tongue and stool black, which can alarm people who are not expecting it. Antibiotics are a more complicated subject. For moderate to severe traveler's diarrhea, a short course of an appropriate antibiotic can shorten the illness considerably, and some clinicians prescribe a standby course for travelers to high-risk destinations to take if needed. But there are good reasons for restraint. Research has shown that travelers who take antibiotics during travel are more likely to return colonized with bacteria resistant to multiple antibiotics; a study by Anu Kantele and colleagues of Finnish travelers found that taking antibiotics for traveler's diarrhea was associated with a considerably higher rate of colonization by extended-spectrum beta-lactamase-producing bacteria. Colonization often causes no symptoms, but it contributes to the spread of antibiotic resistance and can complicate future infections. This is one reason current guidance favors reserving antibiotics for moderate and severe cases, and why the choice of antibiotic should be made by a clinician who knows the resistance patterns of your destination. Do not buy antibiotics over the counter abroad and take them on your own judgment. Know the warning signs that mean you should see a doctor promptly: blood or mucus in the stool, a high fever, severe abdominal pain, persistent vomiting that prevents you from keeping fluids down, signs of significant dehydration such as very dark or minimal urine, dizziness, or confusion, and diarrhea that continues for more than a few days. Seek care sooner if you have a chronic medical condition, are pregnant, or take medicines that can be affected by dehydration. And if you develop persistent digestive symptoms after returning home, tell your doctor where you have been; some infections acquired abroad cause symptoms that last or appear later. Eating well on an unfamiliar diet Once the early weeks pass, the more lasting food challenge for most students is not infection but nutrition. Eating well requires knowledge, time, money, and access to kitchens and shops, and relocation can disrupt all four. Many students' diets change substantially abroad, in both directions. Some eat better than at home: more fresh produce from local markets, more home cooking because eating out is expensive, more walking to shops. Others eat worse: more convenience food because the local supermarket is confusing, more irregular meals because the timetable has no shape, more snacking late at night during long study sessions. Changes in weight in either direction are common and usually reflect these patterns rather than anything medically significant, but they are worth noticing. Cooking is often the pivot. Students who know how to cook a handful of simple, balanced meals, and who learn early where to buy ingredients, generally eat better and spend less. If you do not cook, the months before departure are a good time to learn three or four basic dishes that are nutritious and can be made with widely available ingredients. On arrival, an early trip to a supermarket with a local student, or even with a translation app, can demystify labels, unfamiliar products, and how things are sold. Many students find that learning to cook local dishes, perhaps from a flatmate or at a university cooking group, becomes one of the most rewarding parts of living abroad. Money shapes all of this. Many students abroad live on tighter budgets than at home, with exchange rates, housing costs, and travel competing for the same funds, and food is often where they economize. Cheap eating does not have to be poor eating. Staple foods such as rice, bread, pasta, lentils, beans, eggs, oats, seasonal vegetables, and frozen vegetables are affordable almost everywhere and can form the basis of balanced meals. Local markets near closing time, supermarket own brands, and university cafeterias, which are subsidized in many countries, stretch a budget further. Cooking in larger batches and sharing meals with flatmates saves money, reduces waste, and turns a chore into a social occasion. What tends to drain both budgets and nutrition is the pattern of eating out by default because there is no plan, followed by skipping meals later in the month when money runs short. A weekly shop and a rough plan for the week's meals prevent most of that. Familiar food has emotional value too. Homesickness often takes the form of a craving for particular dishes, and there is nothing wrong with seeking them out. International grocery stores, community restaurants, and student associations from your home country can supply comfort food and company at the same time. A balanced approach, eating locally most of the time and returning to familiar food when it helps, is healthier than either refusing local food or forcing yourself to give up home food entirely. Some specific nutritional points deserve attention. If you follow a vegetarian or vegan diet, find out early which local foods supply protein, iron, and vitamin B12, since the products you relied on at home may not be available. If you have a condition that depends on diet, such as diabetes, celiac disease, or inflammatory bowel disease, plan with your clinician before you leave and research how to find suitable food locally; in some countries, specialized products are widely available, while in others they are hard to find. And if your relationship with food has been difficult in the past, be aware that the stress, loss of routine, and changes in body image that sometimes accompany relocation can reawaken disordered eating. If you notice this happening, contact your counseling service or a doctor early; eating disorders respond best to early treatment. Allergies and dietary practices For students with food allergies, eating abroad requires planning, because the systems that protect them at home, such as labeling rules, restaurant awareness, and their own ability to read ingredients, may be weaker or unfamiliar. Food labeling laws differ between countries. The European Union, for instance, requires a list of major allergens to be emphasized in ingredient lists on packaged food and declared for food sold loose, while elsewhere labeling may be less consistent or absent. Language is an obvious barrier: an ingredient you could spot instantly at home may be invisible in another language or alphabet. Several steps reduce the risk. Carry a card written in the local language that explains your allergy clearly and asks about specific ingredients; many allergy organizations provide templates, and a native speaker should check the translation. If you have been prescribed adrenaline auto-injectors, carry two, as is standard advice, keep them with you at all times rather than in your room, and check the airline's rules for carrying them on board. Tell your roommates, close friends, and program staff about your allergy and show them how to use your auto-injector. Learn the local emergency number, and learn the phrase for "I am having a severe allergic reaction" in the local language. Be especially cautious with street food and with dishes where ingredients are hard to see, such as sauces, pastes, and fried foods cooked in shared oil. Religious and ethical dietary practices raise their own challenges. Students who keep halal or kosher, who are vegetarian for religious reasons, or who fast during particular periods may find that suitable food is abundant in some places and scarce in others. Religious communities and student associations at your destination are usually the best source of guidance on where to shop and eat, and they often provide community as well as food. Observing a fast in a new country can require particular planning: the length of the fasting day depends on latitude and season, and it may differ considerably from what you are used to. If you have a health condition, speak to your clinician about fasting safely, as you would at home. Food, in the end, is not only fuel or risk. It is one of the main ways people come to belong somewhere. The student who learns to shop, cook, and eat with some confidence in a new country has solved more than a nutritional problem. She has made a part of the place her own, and that, as the next chapter shows, is at the heart of adjusting to a new culture. Chapter 7: Culture Shock: What the Research Actually Shows Most students leaving to study abroad have heard of culture shock, usually in the form of a curve drawn on a slide at a pre-departure orientation. First comes the honeymoon, when everything is exciting. Then comes the crisis, when differences become irritating and homesickness sets in. Then comes recovery, and finally adjustment, when the student feels at home. The curve is reassuring because it promises that the bad feelings are a normal phase and will pass. There is something true in that message, and something misleading. It is true that difficult feelings during adjustment are normal and usually improve with time. It is misleading to suggest that adjustment follows a single predictable shape for everyone, that the worst comes after a period of euphoria, or that it resolves on its own if you simply wait. The research on how people adjust to new cultures, which now spans more than half a century, paints a more useful picture. It shows that adjustment is not one process but several, that the hardest period for many people is at the very beginning, and that specific actions, not time alone, drive improvement. This chapter explains that picture and what it means in practice. Where the idea came from The term culture shock is usually traced to the anthropologist Kalervo Oberg, who described it in a short article published in 1960. Oberg characterized culture shock as the anxiety that results from losing all our familiar signs and symbols of social interaction: the countless small cues, such as how to greet people, when to shake hands, how to give and take instructions, how to accept or refuse invitations, and when to take statements seriously, that guide behavior at home without conscious thought. Abroad, those cues are missing or different, and the result is a pervasive sense of strain and disorientation. A few years earlier, in 1955, the Norwegian sociologist Sverre Lysgaard had published a study of Norwegian Fulbright scholars in the United States. He suggested that their adjustment followed a U-shaped pattern over time: relatively good at first, worse after some months, and better again later. In 1963, John and Jeanne Gullahorn extended the idea into a W-curve, arguing that the same pattern repeats when travelers return home, a phenomenon now known as reverse culture shock and discussed in Chapter 8. These ideas were highly influential, and the U-curve in particular became a staple of study-abroad orientations. But they were based on limited evidence. Lysgaard's data were cross-sectional, comparing different people at different stages rather than following the same people over time, and later researchers found the U-shape hard to reproduce. What the research actually shows Among the most important of those later studies was a longitudinal study by Colleen Ward and colleagues, published in 1998 under the pointed title "The U-curve on trial." The researchers followed Japanese students in New Zealand, assessing their adjustment on arrival and at several points over their first year. They did not find a U-curve. Instead, adjustment problems, both psychological and practical, were greatest at the beginning, on entry into the new country, and decreased over time. There was no early honeymoon period followed by a crisis. This finding has practical significance. If students are told to expect a honeymoon, those who find the first weeks difficult may conclude that something is wrong with them or with their choice. In fact, for many people the first weeks are the hardest, which is consistent with the picture of load and reserve set out in Chapter 1. Other students do experience something like the classic pattern, with early excitement giving way to a later dip, often around the time when coursework intensifies and the novelty fades. The honest message is that individual patterns vary, and neither pattern is a sign of failure. Ward and her colleagues also drew an important distinction between two kinds of adjustment. Psychological adjustment refers to emotional wellbeing: feelings of satisfaction, mood, and freedom from anxiety and depression. Sociocultural adjustment refers to the ability to fit in and function effectively: handling everyday tasks, interacting with local people, and understanding the social rules. The two are related but not identical, and they respond to different influences. Research by Wendy Searle and Colleen Ward found that psychological adjustment was more closely related to factors such as personality, life changes, and social support, while sociocultural adjustment was more closely related to factors such as cultural knowledge, contact with host nationals, and cultural distance, meaning how different the new culture is from one's own. A student might be skilled at getting things done in a new country while feeling lonely and low, or might feel emotionally content while still bewildered by daily life. Building on this work, Ward, Stephen Bochner, and Adrian Furnham, in their book The Psychology of Culture Shock, organized the field around three broad perspectives, often summarized as the ABC of acculturation: affect, behavior, and cognition. The affective perspective treats cross-cultural transition as a series of stressful life changes and asks how people cope with stress. The behavioral perspective treats adjustment as a matter of learning the specific social skills needed to function in a new culture. The cognitive perspective asks how people think about their own identity and about the groups around them. Each points to different kinds of action, as Table 5 summarizes. Table 5. Three perspectives on cross-cultural adjustment and what each suggests students do. Perspective Core question What goes wrong What helps Stress and coping (affect) How do people cope with the strain of change? Anxiety, low mood, homesickness Social support, coping strategies, looking after sleep and health Culture learning (behavior) What skills are needed to function in the new culture? Misunderstandings, social awkwardness, daily frustration Learning local norms deliberately, language practice, contact with host nationals Social identification (cognition) How do people see themselves and other groups? Stereotyping, feeling torn between identities Reflecting on identity; finding a balance between home and host cultures The table is adapted from the framework described by Ward, Bochner, and Furnham, listed in the Notes and in Further Reading. A related and much-cited framework comes from the psychologist John Berry, who proposed that people moving between cultures face two questions: how much to maintain their heritage culture and identity, and how much to seek contact with and participate in the new culture. The combinations produce four broad strategies. Integration means keeping one's own culture while also engaging with the new one. Assimilation means engaging with the new culture while letting go of one's own. Separation means holding on to one's own culture while avoiding the new one. Marginalization means losing touch with both. Research has often, though not always, found integration to be associated with better adaptation, and the model is widely used, although researchers have debated its details and noted that the options open to a person depend on how the host society treats newcomers. For a student abroad, the practical lesson is that adjustment does not require giving up who you are. The most comfortable path for many people is to stay connected to home while building real ties in the new place. Friendship and belonging If there is one factor that runs through almost all research on adjusting abroad, it is social connection. And the kind of connection matters. In 1977, Stephen Bochner and colleagues proposed what they called a functional model of international students' friendships. They observed that students tend to form three kinds of network. The first, and often the largest, consists of friends from their own country, known as co-nationals, who provide familiarity, emotional support, and a space to express their home culture. The second consists of host nationals, local students and residents, who help students learn about the culture, the language, and the academic system. The third consists of other international students, who share the experience of being foreign and provide companionship and recreation. Each network serves a purpose, and each has value. But later research has pointed to the particular importance of host-national friendships. A study by Blake Hendrickson, Devan Rosen, and Kelly Aune of international students in the United States found that students with a higher proportion of host-national friends reported greater satisfaction and contentment and lower homesickness. The direction of cause is not entirely clear, since students who are adjusting well may find it easier to make local friends, but the finding is consistent with what the culture-learning perspective would predict: local friends teach you how the place works in ways no orientation can. The difficulty is that host-national friendships are often the hardest to form. Local students already have established friends, families nearby, and busy lives. International students are frequently housed together and introduced to each other at orientation, which makes friendships among themselves easy and natural. Without deliberate effort, many students spend an entire stay abroad within an international bubble. A few approaches help. Join activities organized around shared interests rather than around being international: sports clubs, music groups, volunteering, academic societies, faith communities. These bring you into repeated contact with the same local people, which is how friendship forms. Language exchange arrangements, in which you help a local student with your language and they help you with theirs, create natural reasons for regular meetings. Accept invitations, even when tired, especially in the first months. And be patient: friendships in some cultures form slowly, and a lack of immediate warmth may reflect different norms rather than rejection. None of this means avoiding friends from home or other international students. Those friendships provide real comfort and are part of a healthy mix. The aim is balance. Practical strategies for adjusting The research points toward several practical strategies, grouped here by the kind of problem they address. For the stress of transition, the most important tools are the basic health practices discussed earlier in this book: sleep, physical activity, regular meals, and social connection. They sound unrelated to culture, but they are the foundation of the reserve that makes the strain of adjustment manageable. Add to these whatever coping strategies have worked for you before, whether writing, exercise, prayer, music, or talking to a trusted person. Allow yourself time off from the effort of adjusting: an evening with familiar food, a film in your own language, a call home. These are not failures to integrate; they are rest. For the practical difficulties of daily life, treat culture as a set of skills to be learned rather than a test you are failing. Many of the small frustrations of the first months, such as not knowing how to queue, how to address a professor, how to split a restaurant bill, or how directly to disagree in a seminar, can be solved by asking. Local friends, classmates, program staff, and even patient shopkeepers are usually happy to explain. Some students keep a notebook of observations and questions, which turns confusion into curiosity. Learning the local language, even to a modest level, has an outsized effect on daily life and on how people respond to you. For the more subtle cognitive side of adjustment, it helps to be aware of a common trap: interpreting others' behavior through your home culture's rules. A shop assistant who does not smile may be following a norm in which smiling at strangers seems insincere. A professor who criticizes your work bluntly may be showing respect, not disdain. A classmate who declines an invitation without explanation may be following local norms about privacy. Before concluding that people are rude, cold, or hostile, ask whether a different rule might be operating. Often it is. At the same time, keep your own values; understanding a norm does not require adopting it. It would be dishonest to discuss adjustment without acknowledging that some difficulties abroad are not misunderstandings. International students may encounter discrimination and racism, whether in the form of hostile remarks, exclusion, harassment, or unfair treatment by landlords, employers, or institutions. These experiences are genuinely harmful and are associated with poorer wellbeing. If they happen, they are not a failure of adjustment on your part. Tell someone you trust, record what happened, and use your university's reporting procedures and support services; many institutions have staff specifically responsible for responding to such incidents. Student associations and community organizations can also offer support and solidarity. Finally, know the difference between the ordinary difficulties of adjustment and something more serious. Feeling homesick, frustrated, tired, or low at times during the first months abroad is normal. But if low mood persists for more than a couple of weeks, if you lose interest in things you normally enjoy, if you are withdrawing from people, struggling to function, sleeping or eating very differently, or having thoughts of harming yourself, these are signs of something that needs help, not patience. Culture shock is not a diagnosis, and it should never be used as a reason to dismiss symptoms of depression or anxiety, either by you or by anyone else. The next chapter discusses mental health abroad in more detail and how to get help. It may help to see these strategies at work in a single case. Consider an illustrative doctoral student from China who begins a program in the United Kingdom. Her English is excellent on paper, and she is academically strong. Yet by her second month she feels quietly miserable. Seminars confuse her: British students interrupt the lecturer, disagree openly, and seem to be rewarded for it, while she waits to be invited to speak and never is. Her supervisor's feedback, full of phrases such as "you might want to consider," seems mild, and she does not realize until much later that it contained firm instructions. Her flatmates are friendly in the kitchen but never seem to follow up on vague suggestions to "grab a coffee sometime." She begins to eat most meals in her room and to spend evenings talking to friends in Shanghai. Seen through the three perspectives, her difficulty has several parts, each with its own remedy. The stress side shows in her withdrawal, her poor sleep, and her growing sense that she does not belong; it calls for the basics of sleep, activity, and support, and perhaps a conversation with the university counseling service. The culture-learning side shows in the seminar and the supervisor's feedback; these are learnable rules, and a direct question to a trusted British classmate or to her supervisor ("When you say I might want to consider something, how firmly do you mean it?") would decode them quickly. The social side shows in the unfollowed coffee invitations; in many British settings, such remarks are friendly but not concrete, and the way forward is to propose a specific time and place herself. None of these is solved by waiting for a curve to turn. Each is solved by a particular kind of action, and once she takes some of them, her experience begins to change within weeks. The case also shows why the distinction between psychological and sociocultural adjustment matters. Her emotional distress was real, but much of it grew from sociocultural confusion. Addressing only her mood, or only her skills, would have helped less than addressing both. The picture that emerges from the research is more demanding than the old curve, but also more hopeful. Adjustment is not something that simply happens to you on a timetable. It is something you do, through looking after yourself, learning actively, and building relationships. Students who approach it that way tend to find that the new culture, once bewildering, gradually becomes a second home. Chapter 8: Staying Well Over the Long Haul, and Coming Home The early weeks abroad get most of the attention in pre-departure advice, and rightly so, since that is when load is highest and reserve lowest. But a semester or a year is long, and a full degree is longer. Once the initial adjustment is over, a different set of challenges tends to appear. The novelty has faded. Coursework, examinations, and deadlines have arrived. The seasons may have turned, bringing short days and bad weather. Friendships formed in the first rush of orientation have settled into patterns, some deeper and some more distant than expected. And at some point, the end of the stay comes into view, with its own mixture of relief, grief, and uncertainty about going home. This chapter addresses that long arc: mental health and loneliness during the middle of a stay, the risks associated with alcohol, drugs, and personal safety, and the surprisingly difficult business of returning home. Loneliness, mood, and getting help Loneliness is one of the most common difficulties students report abroad, and it is often misunderstood. It is not the same as being alone. A student can be surrounded by people, in a busy residence with a full social calendar, and still feel lonely, because loneliness reflects the gap between the relationships one has and the relationships one needs. Abroad, that gap often concerns depth. A student may have many acquaintances but no one who knows her well, no one she can call at two in the morning, no one who shares her history. The friends who meet those needs are at home, in another time zone, living lives that are moving on without her. Homesickness is closely related: a longing for home, for familiar people, places, food, and routines, often accompanied by preoccupation with home and difficulty engaging with the new environment. It is extremely common among students who move away, including within their own country, and for most people it eases as they build connections and routines in the new place. It can, however, return at particular moments: holidays and family occasions, illness, bad news from home, or simply a difficult week. Several practical steps reduce loneliness and homesickness over the long run. The most important is investing in a small number of deeper relationships rather than many shallow ones. Friendships deepen through repeated contact and shared experience, so standing commitments, such as a weekly dinner with the same flatmates, a regular sports session, or a study group that meets every week, do more than occasional large events. It helps to take small risks in friendship: suggesting a meal, sharing something personal, asking someone how they are really doing. Many other students are feeling the same loneliness and are waiting for someone else to make the first move. Contact with home deserves thought. Regular, scheduled contact with family and old friends provides continuity and support. But constant contact, such as messaging throughout the day and spending evenings on video calls, can keep a student living partly in a place she has left, making it harder to invest in the place she is. There is no right formula, but many students find that a predictable rhythm, such as a few scheduled calls a week, serves them better than continuous connection. Pay attention to how you feel after contact with home; if it regularly leaves you more unsettled, adjust the pattern. Seasonal change can also affect mood, especially for students who move from sunny climates to places at high latitudes, where winter days are short and dark. Some people experience a recurrent pattern of depression in autumn and winter, known as seasonal affective disorder, and many more notice lower energy and mood during the darkest months. Getting outside in daylight, particularly in the morning, staying physically active, and keeping regular routines help. If low mood during winter is significant, see a doctor; seasonal depression is treatable. Consider an illustrative third-year American student spending a full academic year in Sweden. His autumn goes well: he travels, makes friends among the other exchange students, and enjoys his courses. In January, several of those friends leave at the end of their one-semester programs. The days are short, his new courses are harder, and the friends who remain have formed their own routines. By February he is sleeping late, skipping his morning seminar, and spending most evenings alone with his laptop. He tells his family on the phone that everything is fine, because he feels he should be enjoying the experience and is embarrassed that he is not. Nothing in his story is unusual. The departure of first-semester friends, a dark season, harder coursework, and a sense that one ought to be happy are a common combination in the middle of a year abroad. What makes the difference is whether he notices the pattern and responds. The responses that help are specific: restoring a fixed wake time and getting outside in the morning light; joining an activity with a regular meeting time, perhaps one with Swedish students rather than only exchange students; telling one person honestly how he is doing; and, if his mood does not lift within a couple of weeks of trying these steps, booking an appointment with the university's student health or counseling service. The embarrassment is itself worth naming. Many students feel that struggling abroad is ungrateful, and that belief keeps them silent at exactly the time when speaking would help. Most important of all is knowing when difficulty has become something that needs professional help, and knowing how to get it. Signs that warrant speaking to a professional include low mood or anxiety that persists for more than a couple of weeks, loss of interest or pleasure in things you usually enjoy, marked changes in sleep or appetite, withdrawing from people, difficulty functioning in your studies or daily life, using alcohol or other substances to cope, and any thoughts of harming yourself or that life is not worth living. These can happen to anyone, including students who have never had mental health difficulties before, and they are not a sign of weakness or of having made a mistake in going abroad. Most universities offer counseling or mental health services to their students, and many international offices can connect you with them. Your study-abroad program may have its own support staff or a telephone support line through its insurer. If language is a barrier, ask whether services are available in English or in your first language; many universities and cities have practitioners who work with international clients. If you were receiving care at home, return to the continuity plan you made before departure, as described in Chapter 3. If you or someone else is in immediate danger, call the local emergency number at once. That number differs by country; in the European Union and many other places, 112 reaches emergency services, and in the United States the number is 911. For suicidal thoughts or emotional crisis, many countries have dedicated crisis lines. In the United States, the 988 Suicide and Crisis Lifeline can be reached by calling or texting 988, and in the United Kingdom and Ireland the Samaritans can be reached on 116 123. Crisis services and numbers differ between countries, so find the one for your destination before you need it and save it in your phone, alongside your university's counseling service and your program's emergency contact. A student who is worried about a friend can also help. Asking directly how someone is doing, listening without rushing to fix things, and encouraging them to contact a professional or going with them are all genuinely useful. If you are worried about someone's immediate safety, do not keep it to yourself: contact emergency services or your program staff. Alcohol, drugs, and personal safety Studying abroad often brings students into contact with different drinking cultures, different laws, and a sense of freedom that encourages experimentation. For many, this is a normal part of the experience. For some, it is where the most serious problems of a stay begin. Laws and norms around alcohol differ widely between countries. The legal drinking age may be lower or higher than at home. In some countries, drinking is woven into daily life in moderate amounts with meals; in others, heavy episodic drinking is a common part of student social life; in others, alcohol is heavily restricted or prohibited. Students from countries with a high legal drinking age sometimes arrive somewhere with a lower one and drink more heavily than they ever did at home, without the experience to judge their limits. Drinks may also be stronger or served in larger measures than students are used to. A few principles reduce the risk. Know what you are drinking and how strong it is. Eat before and while drinking, alternate alcoholic drinks with water, and set yourself a limit before you start. Go out with people you trust, arrive and leave together, and look after each other. Keep an eye on your drink, and do not accept drinks from strangers or leave a drink unattended, since drink spiking, the adding of alcohol or drugs to someone's drink without their knowledge, occurs in many countries. Plan how you will get home safely before you go out, and keep enough money and phone battery to do so. Know the signs of alcohol poisoning, which is a medical emergency: confusion, vomiting, seizures, slow or irregular breathing, pale or bluish skin, low body temperature, and being difficult or impossible to wake. If someone shows these signs, call the local emergency number immediately. Do not leave them to sleep it off. While waiting for help, stay with them, keep them on their side in the recovery position so that they do not choke if they vomit, and do not give them anything to eat or drink. Many students hesitate to call for help because they fear getting themselves or their friend into trouble. A friend's life is more important. Laws on drugs deserve particular attention. Penalties for possessing or using illegal drugs vary enormously between countries, and in some countries they are very severe, including long prison sentences. Being a foreign student gives you no protection from local law, and your embassy cannot override it. Substances that are legal or tolerated in one country, including cannabis in some places, may be seriously illegal in another, including in countries you pass through. The only safe assumption is to learn and respect the laws of wherever you are. Beyond legal risk, drugs bought in an unfamiliar place carry health risks of their own, since their content and strength are unknown. Personal safety more broadly depends largely on local knowledge. Your program and university will usually provide safety information for your city, and your own government's travel advice pages provide country-level guidance. Learn which areas are considered unsafe at night, how to use public transport and taxis safely, and what common scams target visitors. Register with your embassy's traveler registration scheme if your country offers one, so that you can be contacted in an emergency. Keep copies of your passport and important documents separately from the originals. And remember, as noted earlier in this book, that road traffic is one of the most serious threats to young travelers' lives: be careful when crossing roads where traffic drives on the other side, use a helmet on bicycles and motorcycles, and never ride with a driver who has been drinking. Sexual health and consent are part of personal safety too. Students abroad may form new relationships, and the norms of dating differ between cultures. The fundamentals do not differ: consent must be clear and freely given, and a person who is heavily intoxicated cannot give it. Use condoms to reduce the risk of sexually transmitted infections, and know where to get contraception, emergency contraception, and testing locally. If you experience sexual assault, you can seek emergency medical care, which may include treatment to prevent infection and pregnancy that is time-sensitive, and your program and university can help you access support and reporting options at your own pace. Coming home The end of a stay abroad often arrives more quickly than students expect, and it brings its own adjustment. Most students anticipate culture shock when they go abroad. Far fewer anticipate that coming home can be just as disorienting, a phenomenon that the Gullahorns recognized in their W-curve and that is now widely known as reverse culture shock or re-entry shock. Several things make re-entry difficult. Students have changed while abroad, often in ways they only notice once they are home: new habits, new perspectives, new independence, sometimes a new language. Home has changed too, since friends have moved on and family life has adjusted to their absence. Friends and family may be interested in the experience for a short time and then lose interest, leaving the returning student feeling that something important cannot be shared. Some students grieve the life and friendships they left behind abroad. And there is often a practical crunch of re-entering an academic program, finding housing, or starting a job, sometimes while jet lagged. The same principles that help on arrival help on return. Expect some difficulty, and recognize it as normal rather than as a sign that something is wrong. Rebuild routines deliberately: sleep, exercise, regular meals, and social contact. Stay in touch with friends from abroad, while also reinvesting in relationships at home. Look for ways to use the experience, such as connecting with international students on your home campus, joining a language group, mentoring students preparing to go abroad, or reflecting on how your time abroad has shaped your academic and career plans. Many universities run re-entry sessions for returning students; they are worth attending. There is also a medical side to coming home. Some illnesses acquired abroad appear only after return, sometimes weeks or even months later. The most urgent example is malaria: if you have been in a region where malaria is transmitted and develop a fever after returning, whether in the first weeks or later, seek medical care promptly and tell the clinician where you have been, since malaria can become life-threatening quickly and must be tested for. More generally, whenever you see a doctor in the months after return, mention your travel, including any side trips. Persistent digestive symptoms, unexplained fevers, skin problems, or other symptoms that are not getting better should be assessed. If you had any potential exposures while abroad, such as an animal bite, a new sexual partner, a medical procedure, or close contact with someone with tuberculosis, raise them with your doctor so that appropriate testing can be considered. Finally, if you took medication for malaria prevention or were on any course of preventive treatment, check whether it needs to be continued for a period after you leave the risk area; some regimens do, and stopping early is a common mistake. And bring your records home: the vaccinations you received abroad, any treatment you had, and any prescriptions, so that your doctor at home has a full picture. The end of a stay abroad is not only an ending. For many students, it is the moment when the value of the experience becomes clear. The skills that carried them through adjustment, managing their own health, building routines from nothing, learning a new culture, and asking for help, do not stay behind at the airport. They come home with the student, and they turn out to be useful for the rest of life. Conclusion: Designing the Transition Read one after another, the chapters of this book point to something that none of them could show alone. The health risks of studying abroad are not mainly a list of hazards waiting at a destination. They are mostly the consequences of a transition: the brief period in which a student's body clock, diet, routines, relationships, and access to care are all disrupted at once. Vaccines, jet lag, food, culture shock, and loneliness look like separate subjects, with separate experts and separate advice. In practice they interact. Jet lag erodes the sleep that makes culture learning possible. Loneliness makes irregular eating and heavy drinking more likely. A stomach infection in week two keeps a student away from the sports club where she would have made her first local friend. A missed refill in week six turns an ordinary difficult month into a crisis. The student experiences one transition, not five topics. If that is right, several conclusions follow that are not obvious from any single chapter. Preparation belongs in two places The first conclusion concerns timing. Most of the effort students and institutions put into health preparation is concentrated in the weeks before departure, and much of it focuses on protective measures against specific diseases. That work matters, and the case for a proper pre-travel consultation made in Chapter 2 stands. But the evidence gathered in the later chapters suggests that an equally important window opens after arrival. The research on adjustment finds that many students have the hardest time at the start, not after a honeymoon. Habits form or fail to form in the first weeks. Sleep, routine, and friendship networks settle into patterns that tend to persist. A student who treats arrival as the end of preparation has stopped paying attention at exactly the moment when attention would help most. The practical implication is to plan the first six weeks as carefully as the last six weeks before departure. That means a written plan, not an intention: the wake time you will keep, the anchor points you will fix, the club you will join, the calls home you will schedule, the doctor you will register with, and a date around week four or five on which you will honestly review how you are doing. That review matters because the problems of this period, such as drifting sleep, thinning social contact, and creeping low mood, develop slowly enough to be missed. A fixed checkpoint catches them. Institutions could learn the same lesson. Pre-departure orientations often concentrate on dramatic risks and on the promise of a honeymoon period. A program that instead scheduled a brief, routine health and wellbeing check-in a month after arrival, when difficulties are likely but still easy to address, would be applying what the research actually shows. Structural preparation is the student's own work The second conclusion concerns responsibility. The protective side of travel health is well served by professionals: clinicians, official guidance, and travel clinics exist to tell you which vaccines and preventive measures your trip requires. The structural side is not. No one else will make sure you have enough medication and the paperwork to carry it, that your therapy can continue or be replaced, that you understand your insurance before you need it, that you know where to go on a Friday night with a fever, or that you have arranged your first week so that exhaustion does not decide everything. Those tasks are unglamorous, and they are the ones that most often fail. This division suggests a simple test for any student preparing to leave. For every health need you have at home, ask who will meet it abroad and how you will reach them. If the answer is "I'll sort it out when I get there," you have found a gap worth closing now. What remains unsettled Honesty requires acknowledging where the evidence behind this book is thinner than its confident advice might suggest. The research on cross-cultural adjustment has moved well beyond the U-curve, but much of it comes from particular groups of students in particular host countries, and it is not certain how well its findings generalize. The association between host-national friendships and wellbeing is consistent, but the direction of cause is not fully established. The strategies for jet lag rest on sound physiology, but individual body clocks vary, and personalized schedules are only as good as the assumptions behind them. The evidence that strict food rules prevent traveler's diarrhea is weaker than their popularity suggests, and expert opinion on when travelers should carry standby antibiotics continues to evolve as concern about antimicrobial resistance grows. Regulation of mental health care delivered across borders by video is in flux in many places. Official vaccine recommendations change as disease patterns change. None of this undermines the core advice, but it explains why this book has repeatedly sent readers to current official sources and to clinicians rather than offering fixed rules. The student who knows where good information lives, and who returns to it when plans change, is better protected than one who memorized any list, including one in a book. What to do differently The final conclusion concerns attitude. Students often prepare for studying abroad as if health were something to be protected from the destination. The argument of this book is that health abroad is better understood as something to be rebuilt in a new place, deliberately and early, from the ground up. That shift has a practical consequence. It turns the ordinary difficulties of the first months, such as tiredness, disorientation, loneliness, and minor illness, from signs that something has gone wrong into expected features of a transition that can be managed. It gives a student permission to go gently at the start and a plan for the moments when things become harder. It also turns out to be a lasting benefit. The skills involved in making this transition well, planning for care before it is needed, building routines without external structure, learning the unwritten rules of an unfamiliar system, forming new relationships, and recognizing when to ask for help, are the same skills that carry people through every later relocation: a first job in a new city, a move for a partner's work, a period of illness, a new country later in life. Studying abroad is often described as an education in another culture. Done well, it is also an education in looking after oneself through change, and that may prove to be the most durable thing a student brings home. Notes References are grouped by the chapter in which they are first discussed. Official web resources are updated regularly; consult the current versions rather than relying on any printed summary. Introduction and Chapter 1 Centers for Disease Control and Prevention. CDC Yellow Book 2026: Health Information for International Travel. New York: Oxford University Press, 2025. Also available online at cdc.gov/yellow-book. Centers for Disease Control and Prevention. Travelers' Health. cdc.gov/travel. World Health Organization. International travel and health. who.int. Chapter 2 World Health Organization. International Health Regulations (2005), third edition. Geneva: World Health Organization, 2016. Annex 7 sets out the requirements concerning yellow fever vaccination, including the validity of the International Certificate of Vaccination or Prophylaxis for the life of the person vaccinated. National Travel Health Network and Centre (UK). TravelHealthPro. travelhealthpro.org.uk. Centers for Disease Control and Prevention. Preparing international travelers; Mosquitoes, ticks, and other arthropods; and Road and traffic safety. In CDC Yellow Book 2026. Chapter 3 International Narcotics Control Board. Information for travellers carrying medicines containing internationally controlled substances. incb.org. World Health Organization. Substandard and falsified medical products. Fact sheet. who.int. Chapter 4 Sack, R. L. (2010). Jet lag. New England Journal of Medicine, 362(5), 440-447. Waterhouse, J., Reilly, T., Atkinson, G., & Edwards, B. (2007). Jet lag: trends and coping strategies. The Lancet, 369(9567), 1117-1129. Eastman, C. I., Gazda, C. J., Burgess, H. J., Crowley, S. J., & Fogg, L. F. (2005). Advancing circadian rhythms before eastward flight: a strategy to prevent or reduce jet lag. Sleep, 28(1), 33-44. Eastman, C. I., & Burgess, H. J. (2009). How to travel the world without jet lag. Sleep Medicine Clinics, 4(2), 241-255. Herxheimer, A., & Petrie, K. J. (2002). Melatonin for the prevention and treatment of jet lag. Cochrane Database of Systematic Reviews, (2), CD001520. Chapter 5 Wood, W., & Neal, D. T. (2007). A new look at habits and the habit-goal interface. Psychological Review, 114(4), 843-863. Verplanken, B., & Wood, W. (2006). Interventions to break and create consumer habits. Journal of Public Policy & Marketing, 25(1), 90-103. Bull, F. C., Al-Ansari, S. S., Biddle, S., et al. (2020). World Health Organization 2020 guidelines on physical activity and sedentary behaviour. British Journal of Sports Medicine, 54(24), 1451-1462. Tamaki, M., Bang, J. W., Watanabe, T., & Sasaki, Y. (2016). Night watch in one brain hemisphere during sleep associated with the first-night effect in humans. Current Biology, 26(9), 1190-1194. Chapter 6 Riddle, M. S., Connor, B. A., Beeching, N. J., et al. (2017). Guidelines for the prevention and treatment of travelers' diarrhea: a graded expert panel report. Journal of Travel Medicine, 24(suppl_1), S57-S74. Kozicki, M., Steffen, R., & Schär, M. (1985). "Boil it, cook it, peel it or forget it": does this rule prevent travellers' diarrhoea? International Journal of Epidemiology, 14(1), 169-172. Shlim, D. R. (2005). Looking for evidence that personal hygiene precautions prevent traveler's diarrhea. Clinical Infectious Diseases, 41(Suppl 8), S531-S535. Kantele, A., Lääveri, T., Mero, S., et al. (2015). Antimicrobials increase travelers' risk of colonization by extended-spectrum betalactamase-producing Enterobacteriaceae. Clinical Infectious Diseases, 60(6), 837-846. Regulation (EU) No 1169/2011 of the European Parliament and of the Council on the provision of food information to consumers. Official Journal of the European Union, L 304, 22 November 2011. Chapter 7 Oberg, K. (1960). Cultural shock: adjustment to new cultural environments. Practical Anthropology, 7, 177-182. Lysgaard, S. (1955). Adjustment in a foreign society: Norwegian Fulbright grantees visiting the United States. International Social Science Bulletin, 7, 45-51. Gullahorn, J. T., & Gullahorn, J. E. (1963). An extension of the U-curve hypothesis. Journal of Social Issues, 19(3), 33-47. Ward, C., Okura, Y., Kennedy, A., & Kojima, T. (1998). The U-curve on trial: a longitudinal study of psychological and sociocultural adjustment during cross-cultural transition. International Journal of Intercultural Relations, 22(3), 277-291. Searle, W., & Ward, C. (1990). The prediction of psychological and sociocultural adjustment during cross-cultural transitions. International Journal of Intercultural Relations, 14(4), 449-464. Ward, C., Bochner, S., & Furnham, A. (2001). The Psychology of Culture Shock, second edition. Hove: Routledge. Berry, J. W. (1997). Immigration, acculturation, and adaptation. Applied Psychology, 46(1), 5-34. Bochner, S., McLeod, B. M., & Lin, A. (1977). Friendship patterns of overseas students: a functional model. International Journal of Psychology, 12(4), 277-294. Hendrickson, B., Rosen, D., & Aune, R. K. (2011). An analysis of friendship networks, social connectedness, homesickness, and satisfaction levels of international students. International Journal of Intercultural Relations, 35(3), 281-295. Chapter 8 Gullahorn, J. T., & Gullahorn, J. E. (1963), cited above for Chapter 7, on re-entry. Centers for Disease Control and Prevention. Post-travel evaluation; Fever in the returned traveler. In CDC Yellow Book 2026. 988 Suicide & Crisis Lifeline (United States). 988lifeline.org. Samaritans (United Kingdom and Ireland). samaritans.org. Further Reading Centers for Disease Control and Prevention, CDC Yellow Book 2026: Health Information for International Travel (Oxford University Press, 2025; free online at cdc.gov/yellow-book).** The standard reference on travel medicine. Written for clinicians but readable by a careful student, it covers vaccines, food and water, insect-borne disease, injury, and care after return. Use its destination guidance alongside a clinician, not instead of one. CDC Travelers' Health (cdc.gov/travel) and WHO international travel and health (who.int). The two most useful starting points for destination-specific information, current travel health notices, and, in the WHO's case, yellow fever vaccination requirements by country. TravelHealthPro (travelhealthpro.org.uk) and your own government's travel advice service. The UK's national travel health service offers clear country pages and outbreak alerts; foreign ministries such as Canada's (travel.gc.ca) and Australia's (smartraveller.gov.au) combine health, safety, and entry information for their citizens. Colleen Ward, Stephen Bochner and Adrian Furnham, The Psychology of Culture Shock, second edition (Routledge, 2001). The most thorough scholarly account of cross-cultural adjustment, organized around the stress-and-coping, culture-learning, and social-identification perspectives used in Chapter 7. Academic but rewarding. Craig Storti, The Art of Crossing Cultures, second edition (Intercultural Press, 2001). A short, practical, and humane book on why cultural differences cause friction and how to respond to them. Widely used in study-abroad and international work. Robert L. Sack, "Jet Lag," New England Journal of Medicine 362 (2010): 440-447.** A concise clinical review of the physiology of jet lag and the evidence for light, melatonin, and other strategies. Charmane I. Eastman and Helen J. Burgess, "How to Travel the World Without Jet Lag," Sleep Medicine Clinics 4 (2009): 241-255.** A detailed, practical guide to planning light exposure and sleep shifts before and after flights, from researchers who have tested these methods in the laboratory. Mark S. Riddle and colleagues, "Guidelines for the Prevention and Treatment of Travelers' Diarrhea," Journal of Travel Medicine 24, suppl. 1 (2017): S57-S74.** The expert panel guidelines summarized in Chapter 6, useful for understanding the reasoning behind current advice on self-treatment and antibiotics. Your host and home universities' international, study-abroad, and counseling offices. Not a publication, but the most reliable source on insurance requirements, registering with health services, and support available to you. Read their pre-departure materials in full. Hashtags: #HealthyStudyingAbroad #StudyAbroadWellness #InternationalAcademicTravel #StudyAbroadPreparation #InternationalStudents #StudentHealth #StudentMentalHealth #TravelHealth #PreTravelHealth #TravelMedicine #TravelVaccinations #HealthInsuranceAbroad #MedicationManagement #ContinuityOfCare #JetLagManagement #CircadianRhythms #HealthySleepHabits #SleepHygiene #PhysicalWellbeing #HealthyEatingAbroad #FoodAndWaterSafety #CultureShock #CulturalAdjustment #Homesickness #LonelinessPrevention #StressManagement #MentalHealthSupport #StudentSafetyAbroad #HealthyDailyRoutines #ReverseCultureShock

Download the Book (PDF): Introduction In January 2022 Moxie Marlinspike, the cryptographer who created the Signal messaging protocol, minted a non-fungible token as an experiment. Anyone who looked at it on OpenSea saw one picture. Anyone who looked at it on Rarible saw a different one. Anyone who bought it and opened it in a crypto wallet saw a large emoji of a pile of excrement. Nothing about the token had changed between those three views. The token was the same entry in the same contract on the same blockchain. What changed was the answer returned by an ordinary web server that Marlinspike controlled, which looked at who was asking and served a different file to each. A few days later OpenSea removed the token from its marketplace, and, more revealingly, it then vanished from the wallet on his own phone, because the wallet was not reading the blockchain at all; it was asking OpenSea's servers what he owned. The stunt was a joke with a serious point, and Marlinspike made the point plainly: the token contained a URL, and there was no cryptographic commitment to what that URL would return. Whoever controls the server, whoever buys the domain name when it lapses, or whoever breaks into the machine can change the image, the title and the description of the "unique digital asset" whenever they like. The blockchain faithfully records who owns the token. It has no opinion about what the token is a token of. That gap is the subject of this book. Its argument is simple to state and surprisingly demanding to act on. A non-fungible token secures exactly as much as its chain of references commits to cryptographically, and no more. The ledger entry recording ownership is genuinely robust: it is replicated across thousands of machines and cannot be altered without the owner's key. Everything that makes the token worth owning, though, lives at the end of a chain of pointers, from contract to metadata document to image or video file. Each link in that chain is either a hash, which binds it to exact bytes, or a location, which binds it only to whoever controls that place. A hash gives integrity: it guarantees that the bytes you fetch are the bytes the creator committed to. It does not give availability: nobody is obliged to keep those bytes anywhere. Durable digital ownership therefore requires two separate things done deliberately. Every link from ledger to file must be content-addressed, and someone, identifiable and funded, must keep the content alive. Why the architecture matters The NFT market has been through a speculative boom and a long bust, and much public discussion of the subject has been about prices, celebrities and fraud. This book is about none of those. It is about the machinery, because the machinery determines what a buyer has actually bought, and the answer is frequently less than the buyer assumes. When someone buys an NFT, they acquire control of an entry in a smart contract: a small program on a blockchain, usually Ethereum or a network compatible with it, which keeps a table mapping token identifiers to owner addresses. That control is real and enforceable in the narrow sense that nobody can move the token without the owner's private key or an approval the owner granted. The token also exposes a function that returns a string, typically a URL, pointing to a small JSON document. That document names the asset, describes it and contains another URL pointing to the image or media file. The media file is what the collector looks at, displays and talks about. In many collections, especially those launched quickly in 2021, the JSON document and the image both sat on a company's web server or a commercial cloud bucket. If the company stopped paying its hosting bill, the token would continue to exist and continue to be owned, but it would point at nothing. There is a better way to build this, and it is well understood. The InterPlanetary File System, or IPFS, names data by a cryptographic hash of its contents rather than by the server that holds it. An address of the form ipfs:// followed by a content identifier cannot silently point to different bytes, because changing a single bit of the file changes its identifier. Used properly, IPFS closes the integrity gap Marlinspike exploited. It does not, however, close the availability gap, and a great deal of confusion in the NFT world comes from treating the two as one. Content on IPFS persists only as long as at least one node chooses to keep it. "It's on IPFS" is a statement about naming, not about storage. What this book covers The book moves from the ledger outward to the file, and then back again to the decisions a builder or buyer has to make. Chapter 1 establishes what a token is at the level of data structures: a mapping in contract storage, an event log and a set of rules about who can change them. It separates the three things people mean by "owning an NFT" (control of the ledger entry, access to the content, and legal rights in the work) and shows that only the first is enforced by the chain. Chapter 2 examines ERC-721, the standard that defined the non-fungible token on Ethereum in 2018: its required functions, its approval model, its "safe" transfers and the receiver check behind them, its interface-detection mechanism and the optional metadata extension that introduced tokenURI. Each design decision is read for what it protects and what it leaves open. Chapter 3 turns to ERC-1155, the multi-token standard that came out of game development. It holds many token types in one contract, moves them in batches and treats fungibility as a matter of supply rather than kind. Its metadata scheme, with a single URI template and a substituted identifier, has direct consequences for how assets can be stored. Chapter 4 opens the metadata layer itself: the JSON document, the conventions marketplaces built on top of the bare standard, and the chain of indirection from contract to file. It lays out the hosting options as a series of trust assumptions. Chapter 5 is about failure. It catalogues the ways the reference chain breaks: lapsed servers and domains, mutable base URIs controlled by an owner key, swap-after-reveal tricks, gateways that disappear, and indexers that become the de facto source of truth. Chapter 6 explains content addressing and IPFS from first principles: hashing, content identifiers and their encodings, Merkle DAGs, how files are chunked and linked, how peers find and exchange blocks, and what an HTTP gateway does and does not guarantee. Chapter 7 confronts persistence. It covers pinning, the economics of pinning services, Filecoin's storage deals, Arweave's one-time endowment model, and fully on-chain storage, along with the honest costs of each. Chapter 8 assembles all of this into a working architecture: how to write a contract whose metadata cannot be swapped, how to publish and verify content, how to arrange redundant persistence, and how a collector can audit any token before buying it. The conclusion draws out what follows from the argument for creators, platforms and owners. A note on scope The book concentrates on Ethereum and the many networks that run the Ethereum Virtual Machine, because that is where the ERC-721 and ERC-1155 standards live and where most NFT architecture has been worked out. Other chains, and Bitcoin's Ordinals inscriptions, appear where they illuminate a design choice, particularly about storing data directly on a ledger. Code is described rather than reproduced at length; where function names and event signatures matter, they are given exactly, because precision is the point. Prices and market history appear only where they help explain why the architecture took the shape it did. Readers do not need to be programmers. They do need patience with a small number of technical ideas, chief among them the cryptographic hash: a function that turns any input into a short fixed-length fingerprint such that changing the input in any way produces an unrelated fingerprint, and such that nobody can feasibly find two inputs with the same one. Almost everything in this book follows from what hashes can and cannot do. A hash can prove that a file is the file. It cannot make anyone keep it. Chapter 1: What a Token Actually Is Strip away the marketplaces, the profile pictures and the language of collecting, and a non-fungible token is a row in a table. The table lives inside a smart contract, the contract lives at an address on a blockchain, and the row says that a particular number belongs to a particular account. Everything else is built on top of that row or around it. To understand what NFT architecture can and cannot guarantee, it is necessary to begin with the row: where it is stored, who can change it, what record is left when it changes, and what it does not contain. The ledger entry Ethereum is, at the level that matters here, a shared computer whose state is agreed upon by every participating node. That state includes accounts, each holding a balance of ether, and contracts, each holding code and a private area of persistent storage. Contract storage is organised as a very large key-value store in which both keys and values are 32-byte words. High-level languages such as Solidity hide this behind familiar constructs. When a developer declares a mapping from token identifier to owner address, the compiler arranges for each entry to occupy a storage slot whose location is derived by hashing the token identifier together with the mapping's position in the contract. A token, then, is a number, usually a 256-bit unsigned integer, and owning it means that the storage slot associated with that number contains your address. The contract also keeps a second mapping from each address to a count of the tokens it holds, so that a balance can be read without scanning every token, and further mappings for approvals, which are discussed in the next chapter. That is all the core data there is. A collection of ten thousand tokens is a contract with ten thousand populated slots in its owner mapping. Changing a slot requires a transaction: a message, signed with an account's private key, that calls a function on the contract. The contract's code checks whether the caller is entitled to make the change, for example whether the caller is the current owner of the token, and either updates storage or reverts, undoing everything. Once a transaction is included in a block, and that block is buried under enough subsequent blocks, the change is effectively permanent. Every full node has executed the same code on the same inputs and arrived at the same storage. To forge a transfer, an attacker would have to produce a valid signature for the owner's key, which is computationally infeasible, or rewrite the chain's history, which on Ethereum since its move to proof of stake in September 2022 would require controlling and sacrificing a very large amount of staked ether. The same standards and contracts also run on many other networks that execute Ethereum's virtual machine, including rollups such as Arbitrum, Optimism and Base, and independent chains such as Polygon's. The token code can be identical; the security of the ledger entry is not. A rollup inherits much of its security from Ethereum but typically relies on a single sequencer to order transactions and on upgradeable bridge contracts whose administrators could, in principle, alter its rules. An independent chain relies on its own validators. A token is exactly as durable as the ledger it lives on, and "on the blockchain" names a family of systems with very different guarantees. This book uses Ethereum as its reference point, and the arguments about content apply on every one of these networks unchanged. This is the part of the system that justifies the excitement. The ownership record is public, verifiable by anyone running a node, independent of any single company and resistant to tampering. It can be read and written by any other program on the same chain, which is why a token minted by one project can be listed on a marketplace built by another, lent against in a lending protocol built by a third and displayed in a wallet built by a fourth, without any of them asking permission. Storage is expensive, and that cost shapes every architectural decision that follows. On Ethereum, writing a 32-byte word into a previously empty storage slot costs 20,000 units of gas, with a surcharge on top when the slot is first touched in a transaction. Storing one kilobyte of data as raw storage therefore costs on the order of 640,000 gas, a meaningful fraction of a whole block's capacity. Whatever the price of gas at a given moment, the conclusion has always been the same: the chain is a place to keep small, valuable facts, such as who owns token 4,071, and not a place to keep a high-resolution image. The image had to go somewhere else, and the token had to point to it. The rest of this book is, in a sense, about the consequences of that pointer. Events and the history of a token Contract storage records the present. It says who owns token 4,071 now, not who owned it last year. History lives in a different structure: the event log. When a contract executes, it can emit events, which are structured records attached to the transaction receipt. Events are not readable by other contracts and do not occupy contract storage, so they are much cheaper than storage writes, but they are part of the chain's permanent record and can be retrieved by anyone with access to a node. The NFT standards require contracts to emit specific events whenever ownership changes. Under ERC-721, every transfer, including the creation of a token and its destruction, emits a Transfer event naming the previous owner, the new owner and the token identifier. Creation is signalled by a transfer from the zero address, destruction by a transfer to it. These events are how the outside world sees NFTs. A wallet that wants to show a user their tokens does not, in practice, call ownerOf on every token in every contract that exists; there are far too many. Instead, indexing services read the event logs of the entire chain, reconstruct who owns what and serve the result through an ordinary web API. Marketplaces do the same. The convenience is enormous and the trade-off is easy to miss: the user is now trusting the indexer's database, not the chain. Marlinspike's token disappeared from his wallet not because anything happened on Ethereum but because the wallet asked OpenSea what he owned and OpenSea had decided to stop telling it. This distinction, between the authoritative state held by the chain and the convenient view assembled by an intermediary, recurs at every layer of NFT architecture. At the ownership layer it is mostly harmless, because anyone can check the indexer's answer against the chain. At the content layer, as later chapters show, it can be decisive. Contracts are programs, not certificates It is tempting to think of an NFT contract as a registry with fixed rules, like a land title office with a published procedure. It is better to think of it as a program written by the project's developers, which may or may not do what the standard describes, and which may or may not contain functions beyond the standard. The ERC standards define an interface: a set of function signatures and events, together with prose describing how they should behave. A contract that implements the interface can be used by any application that understands the standard. Nothing enforces the prose. A contract can claim to be an ERC-721 token while containing a function that lets the deployer move any token at will, or pause all transfers, or burn tokens from other people's wallets. Such functions are sometimes legitimate, for example a pause mechanism for responding to a discovered bug, and sometimes they are the mechanism of a fraud. Either way, they are part of what the buyer owns. A token's guarantees are the contract's code, read in full, not the standard's description. The same is true of the pointer to content. The standard requires only that a function exist which returns a URI for a given token. How that URI is computed is up to the contract. It might be a constant string stored at deployment that can never change. It might be a base string concatenated with the token number, where the base string is held in storage and can be replaced by anyone holding an administrative key. It might be generated entirely by code inside the contract, with no external reference at all. All three contracts are equally standard-compliant. They offer completely different guarantees about whether the thing you bought today will be the thing you own next year. Upgradeable contracts add a further layer. Many projects deploy their tokens behind a proxy: a small contract that holds the storage and forwards every call to a separate implementation contract, whose address can be changed by an administrator. This pattern lets developers fix bugs after launch. It also means that the code governing a token can be replaced wholesale. An upgradeable NFT contract is, as a matter of architecture, a promise by its administrators rather than a guarantee by its code. Whether that promise is acceptable depends on who holds the upgrade key, whether it is protected by a multi-signature wallet or a time delay, and whether it has been renounced. None of this is visible on a marketplace listing. Three meanings of ownership When someone says they own an NFT, they may mean any of three things, and the chain enforces only one of them. The first is control of the ledger entry. This is the narrow, technical sense: the owner mapping contains your address, and only you, or someone you have approved, can change it. This meaning is enforced by consensus and cryptography. It is as strong as the contract's code and the chain's security. The second is access to and integrity of the content: the ability to retrieve, display and rely on the image, video, 3D model or document that the token represents, and confidence that it is the same content the creator issued. This meaning depends on the chain of references from contract to file, on whether each link commits to exact bytes, and on whether anyone is keeping those bytes available. The chain enforces none of it directly. At best, the chain stores a hash that lets you verify content you obtained some other way. The third is legal rights in the work: copyright, licences to display or commercialise the image, rights to physical goods or event access. These are matters of contract law and intellectual property, governed by terms the issuer publishes, often on a website, sometimes nowhere at all. Owning a token is not, by default, owning the copyright in the image it references, any more than owning a print is owning the copyright in the photograph. Some projects grant broad commercial licences to holders; some grant almost nothing; some changed their terms after launch. In 2022 the venture firm Andreessen Horowitz published a set of standard licences for NFT projects, under the name "Can't Be Evil", precisely because the legal layer had been left so inconsistent. Licence terms can themselves be stored on IPFS and referenced from the contract, which binds the token to a specific text, but the enforceability of that text is still a question for courts, not code. Most disappointment with NFTs arises from confusing the first meaning with the second or third. The ledger entry is strong, so buyers assume the content and the rights are equally strong. They are not, unless someone made them so. This book is concerned mainly with the second meaning, the integrity and survival of the content, because that is where architecture can make the largest difference and where the most avoidable failures have occurred. The legal layer reappears only where architecture touches it. Before the standard: CryptoPunks The history of the first widely known NFT project illustrates every point above, including the solution this book will eventually recommend. CryptoPunks was launched in June 2017 by Matt Hall and John Watkinson, working as Larva Labs. It comprised ten thousand small pixel-art characters generated by an algorithm, which anyone with an Ethereum wallet could claim for free at launch. It predated the ERC-721 standard by several months, so its contract was a custom design, closer to the fungible token conventions of the time, with its own functions for transferring, offering and bidding on punks. What the CryptoPunks contract did not contain was the images. Storing ten thousand images on Ethereum in 2017 would have been prohibitively expensive. Instead, Larva Labs composed all ten thousand characters into a single image file and embedded a SHA-256 hash of that file in the contract. The image itself was hosted by Larva Labs and widely copied. The design meant that anyone could check a candidate image against the hash recorded on the chain and know whether it was the genuine composite. The contract did not keep the image alive, but it fixed, permanently and verifiably, what the image was. That is integrity without availability: precisely the property this book attributes to content addressing. The weakness was that availability rested on copies, and the attributes of each punk, its type and accessories, were not recorded on the chain at all. In August 2021, after the market for punks had grown enormously, Larva Labs deployed an additional contract that stored the punk images and attributes directly on Ethereum, in compact encoded form, along with functions that render each punk as an image from that on-chain data. From that point the punks no longer depended on any server. The cost of doing so in 2021 was considerable, and it was paid long after launch, by which time the collection's value made it obviously worthwhile. The arc of CryptoPunks, from a hash in the contract to the full data on the chain, maps the spectrum of approaches that later chapters examine. At one end, a token points by location to a file on someone's server, and integrity and availability both depend on that someone. In the middle, a token points by hash, so integrity is guaranteed and availability depends on whoever keeps copies. At the far end, the data lives in the same replicated state as the ownership record, and both are equally durable. Each step along the spectrum costs more and guarantees more. The job of the standards CryptoPunks also showed why standards were needed. Because its contract was custom, every wallet and marketplace that wanted to support punks had to write code specifically for it. When CryptoKitties launched in November 2017, with its breeding cats and a contract designed by a team at Axiom Zen that included Dieter Shirley, the industry had two incompatible non-fungible designs and the prospect of hundreds more. CryptoKitties also demonstrated the pressure that popular NFT applications could put on Ethereum: within days of launch its transactions were a substantial share of network traffic, and the network slowed under the load. The response was ERC-721, drafted by William Entriken, Dieter Shirley, Jacob Evans and Nastassia Sachs, which defined a common interface so that any wallet or marketplace could support any compliant collection without special code. The standard's job was interoperability of the ledger layer. It deliberately said little about content. Its metadata extension specified a function returning a URI and a minimal JSON schema with three fields, and left almost everything about where that JSON should live, how it should be addressed and who should keep it to the implementer. That silence was a reasonable choice for a standard concerned with ownership and transfer. It also left the most important question about the token's value, whether the thing would still be there and still be the same thing, to the discretion of each project. The next two chapters examine the two standards that govern NFT ownership in detail. The chapters after that follow the pointer out of the contract and into the world the standards declined to specify. Chapter 2: ERC-721 and the Grammar of Ownership ERC-721 reached final status as an Ethereum standard in 2018 and has governed the great majority of non-fungible tokens since. It is short, as standards go, and almost every line in it encodes a judgement about risk. Reading it closely shows what the designers thought needed protecting, what they thought could be left to applications, and where the gaps that later caused trouble were already visible. This chapter walks through the interface in the order a builder would meet it: identity, ownership, transfer, delegation, discovery and, last and least specified, metadata. Identity and ownership Every ERC-721 token is identified by a pair: the address of the contract and a 256-bit unsigned integer, the token identifier. The standard says the identifier must not change for the life of the contract and that the pair is globally unique. It deliberately does not say how identifiers are chosen. Many collections number tokens sequentially from zero or one. Others derive identifiers from hashes of some property of the asset, which allows identifiers to be computed off-chain before minting. The standard's authors noted explicitly that callers must not assume identifiers follow any pattern, and treat them as opaque. Two read functions expose ownership. balanceOf(address owner) returns how many tokens an address holds in this contract. ownerOf(uint256 tokenId) returns the address that owns a given token. The standard requires ownerOf to throw an error for a token that does not exist rather than returning the zero address, and requires balanceOf to reject queries about the zero address. These small rules matter: a token whose owner reads as zero would be indistinguishable from a destroyed one, and code that treated "no owner" as a valid answer could be tricked. Notice what these two functions do not provide. There is no way, using only the required interface, to ask a contract which tokens an address owns, or to list every token that exists. The authors considered that enumeration would be expensive to maintain in storage for large collections, so they moved it into an optional extension, discussed below. The practical consequence was that the ecosystem came to rely on off-chain indexers, reading Transfer events, to answer the most basic question a user asks: what do I own? The trust implications of that reliance were noted in the previous chapter. Transfer and the receiver check Three functions move tokens. transferFrom(from, to, tokenId) moves a token from one address to another if the caller is entitled to do so. safeTransferFrom(from, to, tokenId) does the same with an additional safety check, and a second version of safeTransferFrom takes an extra bytes argument that is passed along to the recipient. The safety check exists because of a failure that had already cost users money with fungible tokens. On Ethereum, an address can belong either to a person, through a private key, or to a contract. A contract that was not written to handle tokens has no way to move them out once they arrive. Send a token to such a contract and it is locked forever, owned in the ledger by code that will never transfer it. With fungible tokens, a portion of a balance is lost. With a non-fungible token, the entire asset is. The safeTransferFrom functions address this by checking, after updating ownership, whether the recipient is a contract. If it is, the token contract calls a function on the recipient named onERC721Received, passing the operator, the previous owner, the token identifier and the extra data. The recipient must return a specific four-byte value, the first four bytes of the hash of that function's own signature, which works out to 0x150b7a02. If the recipient returns anything else, or does not implement the function at all, the whole transfer reverts. A contract can therefore receive tokens through a safe transfer only if it has been deliberately written to accept them, signalled by returning that magic value. This is a clever piece of defensive design, and it carries its own hazards. Calling into the recipient hands control of execution to arbitrary code in the middle of the token contract's operation. If the token contract has not finished updating its own state, or if it performs further actions after the call, the recipient can call back into the token contract and exploit the inconsistency, a pattern known as reentrancy. Several NFT minting contracts have been exploited this way: a contract that minted a token with a safe transfer, invoked the receiver hook, and only then incremented its count of minted tokens or checked a per-wallet limit allowed an attacker's receiver to mint again from inside the hook. The receiver check prevents one kind of loss and opens a door to another, which is why careful implementations update all state before calling external code and guard minting functions against reentry. The plain transferFrom remains in the standard because some callers know the recipient is safe and do not want to pay the gas for the check, and because some recipient contracts predate the standard. Wallet interfaces and marketplaces generally use the safe variants. Approvals and operators An NFT that could be moved only by its owner would be difficult to sell. A marketplace needs to transfer the token to a buyer at the moment payment arrives, without the seller being online to sign the transfer. ERC-721 handles this with two levels of delegation. approve(address approved, uint256 tokenId) lets an owner nominate one address that may transfer a specific token. There can be only one approved address per token at a time, and the approval is cleared automatically whenever the token is transferred. getApproved(tokenId) reveals the current approved address. setApprovalForAll(address operator, bool approved) is broader. It authorises an operator to transfer every token the owner holds in this contract, now and in the future, until the approval is revoked. isApprovedForAll(owner, operator) reports whether such authorisation exists. Marketplaces typically ask a seller to grant operator approval once per collection, after which listings can be created by signing off-chain messages, without further on-chain transactions. Each change emits an event: Approval for single-token approvals and ApprovalForAll for operator grants and revocations. These events let wallets and security tools show a user what permissions they have outstanding. The operator model is efficient and has been the single largest source of NFT theft. An operator approval is a standing instruction: any address the owner has approved for all can drain every token in that collection from the owner's wallet at any time. Phishing schemes have exploited this relentlessly, presenting users with a transaction that looks like a mint or a login but is in fact setApprovalForAll to the attacker's address. Once signed, the attacker does not need to act immediately. The approval persists until revoked, and many users never review their approvals. Architecturally, this is a choice to optimise for convenience at the cost of a large and long-lived attack surface. Later proposals and wallet features, including clearer transaction previews and approval-revocation tools, have mitigated it at the edges. The standard itself is unchanged, because changing a deployed standard would break the applications that depend on it. Discovering what a contract supports Applications need to know whether an arbitrary address is an ERC-721 contract, and which optional extensions it implements. ERC-721 requires compliant contracts to implement ERC-165, a separate standard for interface detection. ERC-165 defines a single function, supportsInterface(bytes4 interfaceId), which returns true if the contract implements the interface with that identifier. An interface identifier is computed by taking the four-byte selector of each function in the interface and combining them with exclusive-or. Under this scheme the core ERC-721 interface has identifier 0x80ac58cd, the metadata extension 0x5b5e139f and the enumeration extension 0x780e9d63. A marketplace encountering an unfamiliar contract can call supportsInterface with these values and adapt accordingly. The mechanism is honest only to the extent that the contract is: a contract can return true for an interface it implements badly, or not at all. It is a declaration, not a proof, and it is another instance of the general rule that the standard describes behaviour it cannot enforce. A sale, step by step It helps to trace a single marketplace sale through these functions, because the sequence shows where each protection operates and where the trust lies. A collector holding token 4,071 decides to list it. The marketplace's interface first checks, by calling isApprovedForAll, whether its exchange contract is already an operator for the collector in this collection. If not, the collector signs and sends a transaction calling setApprovalForAll with the exchange contract's address and true. The token contract records the grant and emits ApprovalForAll. This is the only on-chain step the seller takes. The listing itself, stating the token, the price and an expiry, is a message the collector signs off-chain and the marketplace stores in its database. A buyer accepts the listing. The buyer's transaction calls the exchange contract, passing the seller's signed message and the payment. The exchange contract checks the signature, confirms the listing has not expired or been cancelled, transfers payment to the seller (minus any fees and royalties it chooses to pay), and then calls safeTransferFrom on the token contract, moving token 4,071 from the seller to the buyer. The token contract checks that the caller, the exchange, is an approved operator for the seller, updates the owner mapping and the two balances, clears any single-token approval on 4,071, emits Transfer, and, if the buyer is a contract, calls onERC721Received and checks the magic value. If any step fails, the entire transaction reverts, and neither payment nor token moves. Two features of this sequence matter. First, the atomicity is real: the token contract and the exchange contract execute together, so the buyer cannot pay without receiving the token or receive it without paying. That is a genuine improvement on any arrangement that relies on an escrow agent. Second, nothing in the sequence touched the token's content. The buyer's decision to pay was based on the image and attributes the marketplace displayed, which the marketplace obtained from its own cache of the token's metadata. The transaction verified ownership and payment with full cryptographic rigour and verified the thing being bought not at all. The enumeration extension The optional enumeration extension adds three functions. totalSupply() returns the number of tokens in existence. tokenByIndex(index) returns the identifier of the token at a position in a list of all tokens. tokenOfOwnerByIndex(owner, index) returns the identifier of the token at a position in the list of an owner's tokens. Together they allow a client to list every token, or every token an address holds, by calling the contract directly. Supporting these functions requires the contract to maintain additional arrays and index mappings in storage and to update them on every transfer, which makes transfers noticeably more expensive. During the period of intense minting in 2021 and 2022, many projects dropped the extension to save gas, and some went further. Azuki's ERC-721A implementation, released in early 2022, restructured ownership storage so that minting many tokens in one transaction costs little more than minting one, by recording ownership only for the first token in a batch and inferring the owners of the rest. Such optimisations are legitimate and widely used, and they push the job of answering "what exists and who owns it" further toward off-chain indexers. The metadata extension The metadata extension is the part of ERC-721 that matters most for this book and the part the standard says least about. It adds three functions. name() returns a descriptive name for the collection. symbol() returns a short abbreviated symbol. tokenURI(uint256 tokenId) returns a "distinct Uniform Resource Identifier" for a given token, which the standard says may point to a JSON file conforming to a schema it provides. That schema, labelled "ERC721 Metadata JSON Schema", has three properties: name, identifying the asset; description, describing it; and image, a URI pointing to an image resource. The standard suggests the image be between 320 and 1080 pixels wide with an aspect ratio between 1.91:1 and 4:5. That is all. There is no field for attributes or traits, no field for animation or audio, no field for a content hash, no rule about the URI scheme and no requirement that the URI or the document it points to be immutable. The URI scheme was left open deliberately. A URI may begin with https://, pointing to a web server; with ipfs://, pointing to content-addressed data; with ar://, pointing to Arweave; or with data:, containing the JSON inline in the string returned by the function itself. The standard permits all of these and privileges none. A token whose metadata lives on a company's web server is exactly as compliant as one whose metadata is generated on the chain. The decision to leave metadata unspecified had reasonable motives. In early 2018 the community had little experience with decentralised storage, gas costs ruled out on-chain media for most projects, and a standard that mandated a particular storage system would have tied the ownership layer to that system's fate. A minimal standard that let practice evolve was defensible. The cost was that the most important property for a buyer, whether the thing the token points to is fixed, was left to each implementation and became invisible at the point of sale. Other omissions followed from the same restraint. The standard defines no event for a change in metadata, so when a project changed what its tokens pointed to, marketplaces had no reliable signal and kept showing cached versions. A later proposal, EIP-4906, added MetadataUpdate and BatchMetadataUpdate events so that contracts could announce changes and indexers could refresh. The proposal is useful, but notice what it does: it makes mutation easier to coordinate. It does not make immutability easier to verify. Extensions that grew around the standard ERC-721's minimalism invited extensions, and several are now widespread enough to be considered part of the working architecture. EIP-2981, proposed in 2020 and now widely implemented, defines a royaltyInfo(tokenId, salePrice) function that returns a recipient address and an amount owed to the creator on resale. It is purely informational: it tells a marketplace what the creator would like to be paid, and it cannot make the marketplace pay. When competition between marketplaces in 2022 and 2023 pushed several to make creator royalties optional, the limits of a signalling standard became obvious. OpenSea briefly attempted to enforce royalties through an on-chain registry that let collections block transfers via marketplaces that did not honour them, then abandoned the approach in 2023. The episode is outside this book's main subject, but it reinforces its theme: a standard can describe an intention, but only code that actually executes on the chain enforces anything. EIP-4907 adds a time-limited "user" role separate from the owner, so that a token can be rented without being transferred. ERC-6551, proposed in 2023, gives every NFT its own smart-contract account, which can hold other tokens and act on the chain, controlled by whoever owns the NFT. Both treat the token as an identity or key rather than as a pointer to a picture, and both inherit the same separation between strong ledger state and whatever off-chain content the token refers to. What ERC-721 settles and what it leaves open Read as a whole, ERC-721 settles the ledger layer carefully. Ownership is unambiguous, transfers emit events, accidental loss to incompatible contracts is guarded against, delegation is explicit and capabilities are discoverable. Where the standard is weak, the weakness lies in delegation that is too broad and in receiver hooks that open reentrancy paths, both well understood and both manageable by careful implementation. What the standard leaves open is everything between tokenURI and the asset. It does not say whether the URI may change, who may change it, whether the document it names is bound to exact bytes, where that document should be kept or who should keep it. A collector comparing two ERC-721 tokens on a marketplace sees the same interface and the same apparent guarantee of ownership. The difference between a token whose content can be swapped by a single key and one whose content is fixed forever is not part of the standard at all. It is in the contract's code and in the URI it returns, and the only way to know is to read both. The next chapter examines ERC-1155, which approaches the ledger layer differently and whose metadata design makes the storage question sharper still. Chapter 3: ERC-1155 and the Many-Token Contract ERC-721 treats each contract as a single collection of unique items. That model fits a set of ten thousand portraits well and fits a video game badly. A game might have a sword of which there are exactly one, a healing potion of which there are a million, a currency used to buy both, and thousands of other item types besides. Under ERC-721 the unique sword is natural, the million potions would be a million separately tracked tokens, and the currency would need a different standard altogether, ERC-20, in a different contract. Moving a player's inventory from one place to another would require a separate transaction, or at least a separate call, for each item. ERC-1155, the multi-token standard, was written to solve that problem. Its authors, Witek Radomski, Andrew Cooke, Philippe Castonguay, James Therien, Eric Binet and Ronan Sandford, were led by Radomski of the blockchain gaming company Enjin and included developers from other game-focused teams, and the proposal was created in June 2018. It reached final status and has become the second pillar of NFT architecture, used by games, by editioned art, by ticketing and membership systems, and by many platforms that let creators mint without deploying their own contracts. One contract, many token types The central change in ERC-1155 is that a token identifier no longer names a single item. It names a type, and each address holds a quantity of each type. Where ERC-721 keeps a mapping from token identifier to owner, ERC-1155 keeps a mapping from token identifier and owner to balance. The core read function reflects this: balanceOf(address account, uint256 id) returns how many units of type id the account holds. There is no ownerOf. The concept does not exist at the level of the standard, because in general a token type may be held by many accounts in many quantities. A type with a total supply of one, held by a single account, behaves like an ERC-721 token, and a type with a supply of a million behaves like a fungible currency, but the contract does not distinguish them. Fungibility in ERC-1155 is a matter of supply, decided by the contract's minting logic, not a matter of kind fixed by the standard. This has a real consequence for what a buyer can verify. With an ERC-721 token, the question "is this unique?" is answered by the standard itself: each identifier has exactly one owner. With an ERC-1155 type, uniqueness depends on whether the contract will ever mint more units of that type. A creator can sell a type as a one-of-one and later mint a second unit, unless the contract's code prevents it. Some contracts record a maximum supply per type and refuse to exceed it; some expose no supply information at all. The standard is silent. A buyer who cares about scarcity has to read the minting function. Batch operations The second change is batching. ERC-1155 has safeTransferFrom(from, to, id, amount, data) for moving a quantity of one type and safeBatchTransferFrom(from, to, ids, amounts, data) for moving quantities of many types in a single call. There is a matching balanceOfBatch(accounts, ids) that reads many balances at once. Batching matters for cost. Every Ethereum transaction carries a fixed base cost, and every external call between contracts carries overhead. Moving fifty items in one batch amortises those costs across all fifty. For a game that needs to grant a player a bundle of rewards, or for a platform that airdrops editions to many collectors, the saving is substantial. Notice that ERC-1155 has no unsafe transfer at all. Every transfer, single or batch, performs a receiver check when the recipient is a contract. The recipient must implement onERC1155Received for single transfers, returning 0xf23a6e61, and onERC1155BatchReceived for batches, returning 0xbc197c81. The designers had watched tokens get locked in contracts that could not handle them and chose to make the protective check mandatory. The reentrancy concern described in the previous chapter applies here too, and with more force, since every transfer to a contract invokes external code. Events and the reconstruction of state ERC-1155 defines TransferSingle and TransferBatch events. Each names the operator who initiated the transfer, the sender, the recipient, and the identifiers and amounts moved. Minting is a transfer from the zero address and burning a transfer to it, as with ERC-721. The standard places an unusually strong requirement on these events. It requires that the balances of every account can be reconstructed from the event log alone, which means a contract must emit a transfer event for every change in balance, including minting, with no silent adjustments. This is a direct acknowledgement of the role indexers play. Because the standard offers no enumeration function, nothing like ERC-721's optional tokenOfOwnerByIndex, the only practical way to answer "what does this account hold?" is to replay the events. The standard made that replay reliable by obligation. There is also an ApprovalForAll event and the corresponding setApprovalForAll and isApprovedForAll functions. ERC-1155 has no per-token approval. An owner either authorises an operator for every type and quantity they hold in the contract, or authorises nothing. This is simpler than ERC-721's two-level model and concentrates risk further. A single mistaken approval exposes everything the owner holds in that contract, which for a game or a shared minting platform may be a great many items from many creators. Interface detection uses ERC-165 as before. The core ERC-1155 interface has identifier 0xd9b67a26, and the optional metadata URI extension 0x0e89341c. Metadata by template ERC-1155's approach to metadata differs from ERC-721's in a way that matters for storage. The optional metadata extension defines a function uri(uint256 id) that returns a URI for a token type. Crucially, the standard allows, and expects, that the same string be returned for every type, containing the placeholder {id}. Clients are required to replace that placeholder with the actual token identifier, formatted as lowercase hexadecimal, without a 0x prefix, padded with leading zeros to exactly sixty-four characters. So a contract might return https://example.com/api/{id}.json for every type, and a client wanting the metadata for type 314,592 would compute its hexadecimal form, 4cce0, pad it to sixty-four characters, and request a file whose name is fifty-nine zeros followed by those five digits. The standard's own example uses exactly that identifier. The reason for the template is economy. A contract with thousands of types need store only one string, and need not compute a different URI per type on chain. The cost is that it ties metadata strongly to a directory model: one base location containing one file per type, named by a rigid convention. That works naturally with a web server, which can generate responses dynamically for any identifier. It also works with a content-addressed directory, in which all metadata files are bundled together and the directory as a whole receives a single hash. It works less naturally when each type's metadata is stored and addressed independently, because there is then no single base under which every file can be found. The standard also defines a URI event, emitted with the new string and the type identifier when a type's URI changes. Like ERC-721's later metadata-update events, this exists to let indexers notice changes. Its presence in the core standard reflects the gaming origins of ERC-1155, where items might reasonably evolve, but it also normalises mutation. An ERC-1155 contract that emits URI events is announcing that the metadata of its types is not fixed. The metadata JSON schema in ERC-1155 extends ERC-721's with a decimals field, indicating how a type's balance should be displayed if it is divisible, and a properties object for arbitrary additional data. It also includes a localisation scheme in which the metadata can point to translated versions using a {locale} placeholder. None of this changes the basic structure. A URI, possibly templated, points to a JSON document, which contains a further URI for the image. Semi-fungibility and changing state Because ERC-1155 treats fungibility as a matter of supply, a single contract can model items that move between fungible and non-fungible states, and this has proved useful well beyond games. Consider an event ticket. Before the event, all general-admission tickets are interchangeable, so they are naturally one type with a supply of, say, two thousand. After the event, a ticket that was used might become a commemorative collectible, perhaps unique to the seat or to the attendee. An ERC-1155 contract can implement this by burning one unit of the general-admission type and minting a unit of a new collectible type in the same transaction, emitting a TransferSingle event for each. The ticket holder's balance of the first type goes down by one and of the second goes up by one. Nothing about this requires a second contract or a second standard. The same pattern covers crafting in games, where several common items are burned to mint a rarer one, and redemption schemes, where a token representing a claim on a physical object is burned when the object is shipped and replaced with a token recording that it was delivered. Each of these is a state transition expressed as burns and mints of different types within one contract, which is efficient and transparent, since every step is in the event log. The flexibility has an architectural price that bears directly on this book's argument. When item types are created dynamically, as players craft or as events are scheduled, the metadata for new types cannot all be prepared and content-addressed in advance. The natural implementation is a URI template pointing to a server that generates metadata for any identifier on request, and that is how many games and ticketing systems work. The template then names a location, not content, and every type, including those minted long ago, depends on the server. A more careful design separates the two cases: types whose metadata is fixed point to content-addressed files, published as each type is created, and only genuinely live data is served dynamically. ERC-1155's single template makes this harder, since one string must serve all types, which is why many contracts override uri to return a different value for different ranges of identifiers or store a per-type URI in addition to the template. Both are standard-compliant. Both give up some of the simplicity that made the template attractive. A batch transfer traced A concrete trace shows how the pieces fit. Suppose a game contract governs three types: type 1, a fungible gold coin; type 2, a potion with a supply in the hundreds of thousands; and type 77, a unique sword. A player wants to move 500 gold, 3 potions and the sword to a second account, which happens to be a smart-contract wallet. The player's wallet sends one transaction calling safeBatchTransferFrom with the player's address as sender, the smart wallet as recipient, the identifier list one, two and seventy-seven, the amount list 500, 3 and 1, and empty data. The token contract checks that the caller is the sender or an approved operator, then checks that the sender's balance of each type is sufficient. It subtracts each amount from the sender's balances and adds it to the recipient's. It emits a single TransferBatch event recording the operator, the two addresses and both lists. Because the recipient is a contract, it then calls onERC1155BatchReceived on the smart wallet, which must return 0xbc197c81. If it does, the transaction completes; if not, every balance change reverts. A client wanting to show the sword afterwards calls uri(77) and receives, say, the template string with the {id} placeholder. It replaces the placeholder with seventy-seven written as sixty-four hexadecimal characters, which ends in 4d after sixty-two zeros, and fetches that file. Whether that file is fixed, and whether it will be there next year, depends on what the template points to. The batch transfer, for all its efficiency, is silent on the matter, exactly as an ERC-721 transfer is. Choosing between the standards The choice between ERC-721 and ERC-1155 is partly a matter of fit and partly a matter of the guarantees each makes visible. Table 1 sets out the differences that matter most for architecture. Table 1. Key differences between ERC-721 and ERC-1155 (source: EIP-721 and EIP-1155 texts). Property ERC-721 ERC-1155 Unit identified One unique token A token type with balances Ownership query ownerOf(id) balanceOf(account, id) only Batch transfer Not in standard safeBatchTransferFrom Unsafe transfer transferFrom allowed None; receiver check always Approvals Per token and per operator Per operator only Metadata function tokenURI(id), per token uri(id), {id} template Change event None in core standard URI event For a collection of unique works of art, each sold individually, ERC-721 says more on its face. The existence of ownerOf means uniqueness is enforced by the standard rather than by minting logic, and the per-token approval lets owners delegate narrowly. For editions, games, tickets and anything with many identical copies, ERC-1155 is far more efficient, and its batch operations and mandatory receiver checks are genuine improvements. A common pattern on creator platforms is a shared ERC-1155 contract in which many artists mint types. This is cheap for the artist, who need not deploy a contract, but it concentrates control. The platform's contract governs every type, often holds administrative keys that can change URIs, and may be upgradeable. An artist who mints a one-of-one on such a platform has produced a token whose scarcity depends on the platform's code and whose content depends on the platform's administration of URIs. Some platforms handle this responsibly, storing metadata on IPFS and limiting administrative powers; the point is that the standard does not make that responsibility visible, and the buyer has to check. Where the two standards meet For all their differences, the two standards share the structure that this book is concerned with. Both secure ownership on the chain with the full strength of consensus. Both expose a function that returns a string. Both say nothing binding about whether that string can change, whether it commits to exact bytes, or where the bytes live. Both let a contract return a web address on a server that the issuer controls, and both are equally compliant when it does. There is one practical difference worth carrying forward. ERC-721 lets each token compute its own URI, so a contract can return a different content identifier for every token if it chooses, and tokens can be added to a collection later, each with its own independently published metadata. ERC-1155's template encourages a single directory published at once, which is excellent for a fixed set of types and awkward for a catalogue that grows. A growing ERC-1155 collection that wants content-addressed metadata must either publish a new directory, and therefore a new root identifier, each time types are added, which means changing the template and emitting URI events, or override uri to return a separate identifier per type. The first approach reintroduces a mutable reference at the top of the chain; the second departs from the template that clients expect to receive. Neither is wrong, but each moves the burden of proving immutability onto the contract's code, which is where a careful buyer must look for it. The standards also share an assumption that metadata is a separate document rather than part of the token. That separation was driven by cost and has been useful, letting rich descriptions, attributes and media sit alongside a compact ledger. It also means that every NFT, under either standard, is a two-part object: a strong core and a soft periphery joined by a URI. The next chapter examines that periphery in detail: what the metadata document contains in practice, how marketplaces interpret it, and the options for where it can be kept. Chapter 4: The Metadata Layer Ask a collector what their NFT is and they will describe a picture: a pixelated punk, a cartoon ape, a generative abstraction, a photograph. Ask the contract and it will return a string. Between the two lies the metadata layer, a small JSON document and the chain of addresses that leads to it and away from it. This layer is where the token becomes an asset in anyone's eyes, and it is where most of the architectural risk sits. This chapter describes what the document contains, how its conventions arose, how the chain of references is assembled, and what the alternatives are for where each piece lives. The document A typical NFT metadata document is a few hundred bytes of JSON. The ERC-721 standard specified three fields, name, description and image. In practice almost every collection uses more, because marketplaces, above all OpenSea in the period when it dominated NFT trading, defined additional fields and displayed them prominently, and projects followed whatever made their tokens look good where they were sold. The fields that became conventional are summarised in Table 2. Most are informal: they are documented by marketplaces rather than by any Ethereum standard, and interpretation varies at the edges. Table 2. Common NFT metadata fields and their origin (sources: EIP-721, EIP-1155, OpenSea metadata documentation). Field Purpose Defined by name Title of the individual token EIP-721 description Human-readable description EIP-721 image URI of the main image EIP-721 attributes List of traits with values Marketplace convention animation_url URI of video, audio, 3D or HTML Marketplace convention external_url Link to the project's own page Marketplace convention properties Arbitrary extra data EIP-1155 The attributes field deserves attention because it carries much of a collection's economic structure. In a generative collection, each token is assembled from layers (background, body, clothing, eyes, accessory) and each layer's choice is recorded as an attribute, an object with a trait_type and a value, such as a trait type of "Eyes" with a value of "Laser". Rarity rankings, which strongly influenced prices in large collections, are computed from these attributes across the whole collection. If the attributes can change, the rarity of a token can change, and with it the price buyers paid on the basis of it. The animation_url field matters for a different reason. It can point to an HTML page, which marketplaces render in a sandboxed frame. That allows interactive and generative works that run in the viewer's browser, but it also means the "asset" may be a program that fetches further resources at run time. An HTML artwork that loads a library from a public content-delivery network, or data from an API, has dependencies that do not appear in the metadata at all. Its integrity depends on those external resources as well. The metadata document is also small enough to be placed directly in the contract's response. A data: URI, of the form data:application/json;base64, followed by the encoded document, lets tokenURI return the metadata itself rather than a pointer to it. Contracts that generate their metadata on chain use exactly this technique. It removes one link from the chain entirely, since there is no external document to fetch, and moves the question of integrity to whatever the inline document's image field points to. If that field is also a data: URI containing an encoded SVG image, the whole token is self-contained; if it is an https:// URL, the inline metadata has merely moved the weak link one step further out. The chain of references Assembling the pieces, a typical ERC-721 token is resolved like this. A client calls tokenURI(4071) on the contract and receives a string. In many contracts, that string is formed by joining a stored base URI with the token number, perhaps with a .json suffix. The client then fetches the JSON document at that URI. Inside it, the client finds the image field, another URI, and fetches the image. If there is an animation_url, it fetches that too, and if that is an HTML page, the browser fetches whatever the page requests. Each arrow in that sequence is a reference, and each reference is one of two kinds. A location reference names a place: a domain name and a path on a web server, or a bucket and key in a cloud storage service. Whatever is at that place when you ask is what you get. A content reference names specific bytes, usually by a cryptographic hash: an IPFS content identifier, an Arweave transaction identifier, or a hash recorded alongside a location. Whatever you retrieve either matches the reference or is rejected. The integrity of the whole chain is the integrity of its weakest link. If the contract returns a content reference to a JSON document, but that document's image field is an https:// URL on the project's server, then the metadata is fixed and the image is not. The project can replace the picture at will, and the hashed JSON will continue to point faithfully at whatever the server now returns. Conversely, if the JSON and the image are both on IPFS but the base URI in the contract can be changed by an administrator, then the administrator can point every token at a different, equally content-addressed, set of files. Each link has to be fixed, and the first link, the contract's own logic for producing the URI, has to be fixed too. This is the reason the book's controlling claim is phrased in terms of a chain. A token is secure in its content only if every step from the storage slot to the final pixel is bound by a hash and the code computing the first step cannot be changed. Where the pieces can live Builders have several options for where to put metadata and media, and each embodies a different trust assumption. Table 3 summarises them, ordered roughly from weakest to strongest guarantee of integrity. Table 3. Hosting options for NFT metadata and media, by what each guarantees. Option Reference type Integrity Availability depends on Project web server or API Location (https://) None; host can change it Host's continued operation Cloud object storage Location (https://) None; account holder can change it Account and payment IPFS via a gateway URL Location wrapping a hash Only if client verifies Gateway operator and pinners IPFS native URI Content (ipfs://) Verifiable by hash Whoever pins the content Arweave Content (ar:// or ID) Verifiable by hash Arweave network and endowment On-chain data Contract storage or code Same as ledger The blockchain itself The first two options are what the industry calls centralised hosting. They are cheap, fast and familiar. They also give the operator unlimited power to change what a token shows, and they make the asset's survival depend on the operator remaining in business, remembering to renew its domain, paying its cloud bill and not being compromised. The reasons projects chose them were mostly practical. A dynamic API can generate metadata on demand, update it when game state changes, hide unrevealed tokens until a sale ends and serve images through a fast content-delivery network. All of those conveniences are also capabilities to mutate. The third row is subtle and widely misunderstood. Many contracts store URIs of the form https://ipfs.io/ipfs/ followed by a content identifier, or the equivalent on another gateway. The content identifier inside the URL is a hash, so in principle the content is fixed. But the URL as a whole is a location reference to a particular gateway. If that gateway shuts down, the URL stops working even if the content is available elsewhere on IPFS. And a client that fetches the URL over HTTP and does not itself check the returned bytes against the identifier is trusting the gateway operator to return the right content. In practice most clients have trusted gateways implicitly. The Cloudflare public IPFS gateway, which many projects had hard-coded into their metadata, was retired in August 2024, with traffic redirected for a transition period to gateways run by the IPFS Foundation's operators. Projects that had written the native ipfs:// form were unaffected; projects that had written Cloudflare's hostname depended on that redirect. The fourth and fifth rows give genuine integrity, because the reference is the hash and any compliant client can verify it. They differ in their persistence models, which are the subject of Chapter 7. The sixth row places the data in the same replicated state as the ownership record. It is the strongest option and the most expensive, and it constrains what kind of asset is practical. The case for centralised hosting, and its limits It would be unfair to treat centralised hosting as mere negligence. Its defenders make a serious argument, and it deserves a serious answer. The argument runs as follows. Most NFTs are issued by identifiable organisations, many of them established companies with legal obligations, reputations and customer-service departments. A buyer of such a token is trusting the issuer anyway, for the licence, for any associated perks and often for the token's market value, which depends on the issuer's continued activity. Adding content addressing does not remove that trust; it only removes one small part of it. Meanwhile, centralised hosting delivers fast loading, the ability to fix mistakes, compatibility with every browser and the flexibility to add features. Customers want those things. If the issuer misbehaves, the buyer has legal recourse, as with any other digital product. On this view, insisting on IPFS is ideological purity at the expense of user experience. Parts of this are right. Trust in the issuer is not eliminated by content addressing, and for tokens whose value lies mainly in a service the issuer provides, such as access to events or software features, the content of the metadata may matter much less than the issuer's ongoing performance. For those tokens, a hosted API may be a perfectly reasonable design. The argument fails, however, for tokens sold as digital objects whose value lies in the object itself: art, collectibles, records, anything advertised as permanent or unique. For those tokens, centralised hosting does not merely retain some trust in the issuer; it makes the issuer's continued existence and continued good behaviour a condition of the asset existing at all. Legal recourse against a company that has closed is worth little, and recourse against an attacker who hijacked an expired domain is worth nothing. The user-experience benefits, meanwhile, are almost all available with content addressing too: content-addressed files can be served through fast gateways and content-delivery networks, mistakes can be corrected before metadata is frozen, and dynamic features can be built from on-chain state. What content addressing removes is the ability to change the object silently after sale. For a token sold as a fixed object, that is not a feature the buyer should want the issuer to keep. The honest position, then, is that hosting should match the claim. A token that is presented as a service credential can live on a server. A token presented as a permanent object must not. Dynamic metadata and its legitimate uses It would be too simple to say that metadata should always be immutable. Some tokens are designed to change. A game character may level up. A ticket may record that it has been used. A generative artwork may respond to the time of day or to on-chain events. A membership pass may display a holder's tenure. Tokens like these are often called dynamic NFTs, and their metadata must change by design. The architectural question is not whether metadata changes but who can change it and under what rule. There is a large difference between metadata that changes because a server operator decided to change it and metadata that changes because a contract's code computes it from on-chain state according to logic anyone can read. In the first case, the buyer is trusting the operator's future behaviour. In the second, the buyer is trusting code they can inspect, which will behave the same way regardless of who runs the server. The cleanest dynamic designs keep the variable state on chain and either compute the metadata in the contract or compute it off chain deterministically from that state, with the rendering logic and any media assets content-addressed. A level-up then changes a number in contract storage, which everyone can see, and the image is drawn from fixed, hashed components according to a fixed, published rule. The token changes, but nobody can change it arbitrarily. Designs that keep the state in a company's database and expose it through an API offer no such assurance, whatever they call themselves. Reveals and provenance hashes One common practice deliberately starts with mutable metadata and then fixes it: the delayed reveal. During a generative collection's sale, every token points to the same placeholder image, so that buyers cannot pick the rare ones by inspecting metadata before minting. After the sale ends, the project changes the base URI to point at the real metadata, and each token acquires its traits. The reveal is reasonable in purpose and dangerous in mechanism, because the same function that sets the real base URI can set any base URI, and a project that knows which buyers hold which tokens could, in principle, arrange the assignment of rare traits to favoured wallets. The practice that emerged to constrain this is the provenance hash. Before the sale, the project computes a hash of every final image in a defined order, concatenates those hashes, hashes the result and publishes that single value, often in the contract itself. After the sale, a random starting offset, ideally derived from a value the project could not control, such as a future block's data or a verifiable random function, determines how tokens map to that ordered list. The provenance hash commits the project to the final set of images and their order before anyone knows which token will receive which. After the reveal, anyone can recompute the hash from the published images and check it matches. Bored Ape Yacht Club, launched in 2021, published such a provenance record, and the technique became common practice. Its guarantee is limited to what it commits to: if the commitment covers only image files and not the metadata, traits could in principle still be adjusted; if the offset is chosen by the project, the randomness is only as fair as the project's honesty. Used well, it shows what this book argues for in miniature: a hash, published before the fact, turning a promise into something checkable. Freezing Once metadata is final, the contract should make it impossible to change. The simplest way is never to provide a function that changes the URI at all, setting it once in the constructor. Where a reveal or a corrected deployment requires the ability to set it later, a contract can include a one-way switch, a function that sets a flag after which the URI setter permanently reverts. OpenSea popularised a convention of emitting a PermanentURI event to announce that a token's URI is frozen, and its interface displays frozen metadata accordingly. An event is a statement, not a constraint. A contract can emit PermanentURI and still contain a setter that works. The only reliable test of whether metadata is frozen is to read the code: confirm that every path that could change the URI is disabled, that no proxy can swap the implementation, and that the URI returned is a content reference whose content's own internal references are also content references. That is a demanding audit to ask of every collector, which is one reason the failures described in the next chapter happened as often as they did. Chapter 5: How the Pointers Fail A pointer fails in one of two ways. Either it stops resolving, and the token points at nothing, or it resolves to something other than what it originally named, and the token points at the wrong thing. The first is a failure of availability; the second, of integrity. Both have happened to NFTs repeatedly, and they have happened through a small number of recurring mechanisms. This chapter catalogues those mechanisms, because the defences described in the following chapters make sense only against a clear picture of what they defend against. Link rot, and why NFTs are not exempt The ordinary web loses its content steadily. A study by the Pew Research Center published in 2024 found that 38 percent of web pages that had existed in 2013 were no longer accessible a decade later, and that broken links were common even on government and news sites. Pages disappear because organisations reorganise their websites, change domain names, stop paying for hosting, are acquired or close. Nothing about a URL obliges anyone to keep it working. An NFT whose metadata or image is referenced by an https:// URL is subject to exactly the same decay. The fact that the reference is stored on a blockchain does not change the nature of the reference. The blockchain will preserve the URL perfectly, for as long as the chain exists; it will not preserve what the URL points to for even a day. The permanence of the ledger has, if anything, made the decay of the periphery more conspicuous. A broken link on a news site is an annoyance. A broken link in an asset that someone paid for, and which is advertised as permanent, is a broken promise. The most common path to an empty token is the most mundane: the issuing company stops operating. Startups fail, and NFT startups failed in large numbers after the market contracted in 2022. When a company that hosted its own metadata shuts down, its servers go dark, its cloud account is closed and its domain eventually lapses. The tokens persist, their ownership records remain accurate, and every one of them now resolves to an error. No hack, fraud or bad faith is needed. Ordinary business failure is sufficient. Corporate issuers are not immune merely because they are large. A brand that launches an NFT collection as a marketing initiative may wind the initiative down when priorities change, and the servers supporting the collection are then a cost with no budget line. Unless the collection was built so that its content does not depend on the issuer, the issuer's change of strategy becomes the owner's loss. Domains as attack surface A lapsed domain is worse than a dead one, because someone else can register it. Once a domain expires and is released, whoever registers it controls every URL beneath it. If an NFT collection's metadata lived at that domain, the new registrant can serve any metadata they like for every token in the collection. They can replace images, rewrite descriptions and alter attributes. They can serve images that harm the owners' reputations or redirect viewers to phishing pages. The contract, faithfully, continues to point at the domain. The same exposure exists without expiry. A domain can be hijacked by compromising the registrar account, by social engineering the registrar's support staff, or by manipulating the domain name system. A web server can be compromised directly. A cloud storage bucket can be misconfigured so that others can write to it. In every case, whoever controls the location controls the asset, and the token's on-chain ownership record offers no protection, because it never committed to the content in the first place. This is precisely the vulnerability Moxie Marlinspike highlighted: no hash commitment for the data at the URL. The deliberate swap Not every change is an accident or an attack by an outsider. The project itself may change what tokens point to, and the mechanisms described in the previous chapter make that easy. Most generative collections deployed in 2021 and 2022 store a base URI in contract storage with a setter function restricted to the contract owner. The setter exists to support the reveal, and in many contracts it remains active afterward. Until the owner disables it, the owner can, with a single transaction, point every token in the collection at a different set of metadata. The new set can be on IPFS, perfectly content-addressed, and still be different from what buyers bought. Content addressing protects a reference from silently changing its target. It does nothing if the reference itself is replaced. The mechanism has been used for benign purposes, such as migrating metadata from a centralised server to IPFS after launch, which is a real improvement for owners. It can also be used to alter the economics of a collection after the fact, for example by changing attributes so that tokens held by insiders become rarer. And it can be used to abandon a collection gracefully or abruptly. Because the swap function looks the same in all three cases, its mere existence means the buyer depends on the owner's continued good faith and on the owner's key not being stolen. A compromised owner key on a contract with a live base-URI setter hands an attacker the content of the entire collection. Upgradeable proxies widen the exposure. If the contract's implementation can be replaced, then the logic of tokenURI itself can be replaced, along with every other behaviour of the token. A frozen URI in the current implementation is no guarantee if the next implementation ignores it. Responding differently to different viewers Marlinspike's experiment points to a subtler integrity failure. A server can return different content to different requesters. It can inspect the requester's IP address, user-agent string, cookies or referring page and decide, request by request, what to serve. A marketplace's indexer might see one image, a collector's browser another and a journalist's laptop a third. Most people never think about this possibility because they assume, without examining the assumption, that a URL names a single thing. It does not. It names a request that a server will answer however it chooses. For ordinary web content this is a feature, enabling personalisation and localisation. For a token claiming to represent a unique and specific artwork, it means there may be no single answer to the question "what does this token show?" Content addressing removes the possibility entirely: a content identifier names bytes, and any server returning different bytes is returning something that fails verification. Gateways as hidden locations The previous chapter noted that a URL of the form https:// plus a gateway domain plus /ipfs/ plus a content identifier is a location reference wearing a content identifier. This failure mode deserves separate treatment because it has affected projects that believed they had done the right thing. When IPFS became the recommended way to store NFT metadata, many projects stored gateway URLs rather than native ipfs:// URIs, because browsers did not understand the native scheme and gateway URLs simply worked. That choice made the project dependent on the continued operation of a specific gateway. Public gateways are run by organisations that pay for bandwidth and storage and may decide to stop. Cloudflare's withdrawal of its public IPFS gateway in 2024 was handled carefully, with months of notice and a redirect period, but it illustrated the point: a project's tokens can depend on a third party that never agreed to support them. Gateways can also rate-limit, block content in response to legal demands or abuse reports, and, like any server, return wrong content if compromised or misconfigured. A client that fetches from a gateway without checking the hash has delegated its integrity guarantee to the gateway. Most wallets and marketplaces have historically done exactly that. The native ipfs:// form avoids hard-coding any one gateway. Clients translate it to a gateway of their choice, or fetch through a local IPFS node, or verify the content themselves. The data is named by what it is, not by who serves it, and the choice of server can change without changing the token. Caches that hide the damage A curious feature of NFT failures is that they are often invisible for a long time. Marketplaces and wallet services do not fetch every image from its origin each time a user views a token. They fetch it once, store a copy and serve that copy through their own content-delivery networks. When the origin disappears, the marketplace's cached copy continues to display, and neither the owner nor potential buyers notice anything wrong. Caching postpones the failure but does not prevent it. The cached copy belongs to the marketplace, which may purge it on a refresh, when the collection is delisted, when its cache policy changes or when the marketplace itself winds down. The owner usually discovers the problem only when trying to view the token somewhere else, or when the marketplace re-indexes and finds nothing at the origin. By then the original files may be unrecoverable. Caching also means that the image a buyer sees at the moment of purchase may not be the image the token currently points to. If the origin's content has changed since the marketplace last fetched it, the buyer is shown the old image and acquires a token pointing at the new one. This is the reverse of Marlinspike's demonstration and just as possible. The cache, like the indexer described in Chapter 1, is a convenient view assembled by an intermediary; it is not the asset. Dependencies outside the metadata Even a carefully content-addressed token can depend on resources its metadata does not list. The most common case is the HTML artwork referenced by animation_url. Such a work might load a JavaScript graphics library from a public content-delivery network, a font from a web font service, or data from an API. Each of those is a location reference embedded in the artwork's code. If the library's URL changes or the font service retires a version, the artwork breaks, even though every link the token itself declares is a hash. Format obsolescence is a slower form of the same problem. Digital preservation professionals know that a file is only as durable as the software able to interpret it. Adobe ended support for Flash Player at the end of 2020, and web browsers removed it, which made a large body of interactive web art unplayable without emulation. NFT media in common formats such as PNG, JPEG, MP4 and standard HTML are relatively safe, because those formats are well documented and widely implemented. Media in proprietary or niche formats, or interactive works that depend on particular browser behaviours, carry a risk that no storage system can address. The bytes may survive while the ability to experience them does not. Off-chain ownership claims A final category of failure involves tokens that are not quite on the chain at all. Some platforms offer "lazy minting", in which a creator signs a message authorising the creation of a token, and the token is actually written to the chain only when someone buys it. Until then, the "NFT" is a signed message in the platform's database. That is a reasonable way to save creators the cost of minting unsold work, but it means that an unsold lazily minted token has none of the properties of a ledger entry. If the platform loses the signature, the token never existed. Similarly, some services display NFTs that are in fact records in a custodial database, with on-chain settlement deferred or batched. These are not failures of the NFT standards; they are cases where the standards were never applied. They are mentioned here because the user experience can be identical to that of a real token, and the architectural guarantees are entirely different. Tracing a broken token The failure modes above are easiest to understand by following one token through its decline. The example is a composite, built from mechanisms that have each occurred, rather than a single documented case. A collection launches in 2021. Its contract stores a base URI of the form https://api. followed by the project's domain and /metadata/, with a setter controlled by the founders' single-key wallet. The API generates metadata on request from a database, and each document's image field is an https:// URL to a cloud storage bucket. Marketplaces index the collection, fetch every image once and cache them. In the first year, nothing appears wrong. The founders use the setter once, legitimately, to move from a placeholder to the revealed metadata. Holders see their tokens on every marketplace. In the second year, the project's revenue dries up. The founders stop paying for the API server, which goes offline. Marketplaces continue to display cached images and cached attributes, so the outage is unnoticed. A holder who tries to view a token in a new wallet application, which fetches metadata directly, sees a blank card and assumes the wallet is at fault. In the third year, the cloud account is closed for non-payment, deleting the images. A marketplace refreshes its metadata for the collection after a user requests it, finds nothing at the origin, and replaces the cached images with placeholders. Now everyone notices. The domain registration lapses some months later. A speculator registers it and points the API path at a server returning metadata for a different set of images, along with an external_url that leads to a phishing site styled to look like the original project. Marketplaces that refresh pick up the new metadata and display the substituted images under the original collection's name. At no point did anything happen on the blockchain. Every token's ownership record remained exact. The contract continued to return the same URI. The failure was entirely in the periphery, and it progressed through every category described in this chapter: availability loss hidden by caches, then exposed, then converted into an integrity failure by a domain takeover. The founders' setter, still live, was never used maliciously, but if their key had been stolen at any point, an attacker could have done the same damage directly. Each stage could have been prevented by a decision made at launch. Content-addressed metadata and images would have made the domain takeover irrelevant. A disabled setter would have closed the key-theft path. A persistence plan independent of the founders' finances would have kept the images available after the company failed. None of those decisions was expensive in 2021. All of them were expensive to retrofit afterward, and some were impossible, because once the original files were deleted, there was nothing left to content-address. A taxonomy of failure Gathered together, the failure modes fall into a short list. Availability fails when the host of a location reference stops serving it: business failure, lapsed hosting, gateway retirement, cache purge. Integrity fails when the content at a location reference changes: domain takeover, server compromise, deliberate swap at the origin, viewer-dependent responses. Integrity also fails when the reference itself is changed: a live base-URI setter, an upgradeable implementation, an administrator key that is stolen. Both can fail through dependencies outside the declared references: external libraries, fonts and data, and formats that lose software support. Content addressing, the subject of the next chapter, eliminates every integrity failure in the second group, provided the client checks the hash. It does nothing about the third group, which must be addressed in the contract's code, and nothing about availability, which must be addressed by deliberate persistence. The defences are therefore three, and they correspond to the three groups: hash every reference, freeze the code that produces the first reference, and make sure someone keeps the bytes. Chapter 6: Content Addressing and the InterPlanetary File System The web names things by where they are. A URL tells your browser to contact a particular server, identified by a domain name, and ask it for a particular path. The answer is whatever that server says. Content addressing turns this around and names things by what they are. The name of a file is derived from the file's bytes, so that anyone holding the bytes can compute the name and anyone holding the name can check the bytes. It is an old idea, used for decades in version-control systems such as Git and in peer-to-peer file sharing, and it is the idea at the heart of the InterPlanetary File System. IPFS was designed by Juan Benet and described in a 2014 paper, "IPFS - Content Addressed, Versioned, P2P File System". It was developed by Protocol Labs, the company Benet founded, and its main implementations are now maintained by Interplanetary Shipyard, a team that separated from Protocol Labs in 2024. The reference implementation in the Go language, long called go-ipfs, was renamed Kubo in 2022; a JavaScript implementation called Helia runs in browsers and Node.js. This chapter explains how IPFS names, structures, finds and transfers data, and then what that machinery guarantees. Hashes as names A cryptographic hash function takes any input and produces a fixed-length output, the digest. A good hash function has three properties that matter here. It is deterministic: the same input always produces the same digest. It is collision resistant: nobody can feasibly find two different inputs with the same digest. And small changes to the input produce unrelated digests, so there is no way to make a near-miss. SHA-256, the most widely used hash function in IPFS, produces a 256-bit digest; no collision has ever been found, and finding one is believed to be far beyond any foreseeable computing capacity. If a file is named by its SHA-256 digest, three useful consequences follow. First, the name is self-certifying: given the name and some bytes claiming to be the file, anyone can hash the bytes and check. No trust in the source is required. Second, the name is location-independent: the same bytes have the same name whether they are on a server in Frankfurt, a laptop in Lagos or a hard drive in a drawer, so anyone who has them can serve them. Third, the name is immutable: a different file has a different name, and there is no way to change what a name refers to. To "update" content-addressed data is to create new data with a new name. These are exactly the properties missing from the location references described in the previous chapter. A content-addressed metadata URI cannot be redirected by a new domain owner, cannot be served differently to different viewers without the difference being detectable, and cannot be quietly replaced at the origin. It is a commitment, in the cryptographer's sense, to specific bytes. Content identifiers IPFS does not use bare hashes as names. It wraps them in a self-describing format called a content identifier, or CID, built from a family of small specifications collectively called Multiformats. The design anticipates that hash functions, data formats and text encodings will change over time, and makes every CID carry enough information to be interpreted without guesswork. A CID has up to four components. A multihash combines the digest with a prefix identifying which hash function produced it and how long the digest is, so that a SHA-256 digest is unambiguously distinguishable from one produced by any other function. A multicodec identifies how the hashed bytes are to be interpreted: raw binary, a particular IPFS file-structure format, JSON, CBOR and so on. A version number distinguishes CID formats. And when the CID is written as text, a multibase prefix identifies which text encoding was used. There are two CID versions in use. Version 0, the original, is a SHA-256 multihash encoded in base58, always implying a particular file-structure codec; such CIDs are 46 characters long and always begin with the letters Qm. Many early NFT collections use them, and they are still recognised everywhere. Version 1 carries explicit version, codec and multibase information and by default is written in lower-case base32; for the most common kind of file data, these CIDs begin bafy. Version 1 is recommended for new work, partly because it is extensible and partly because base32 is case-insensitive, which lets CIDs appear safely in places that ignore case, such as domain-name labels. The same content can be expressed as either version; converting between them does not change the underlying hash. A subtlety matters for NFTs. The CID of a file depends not only on the file's bytes but on how IPFS structured them before hashing. Two people adding the same image to IPFS with different settings, discussed below, can obtain different CIDs. Both are valid names for data that, when reassembled, is the same image. This is rarely a problem, because a collection's CIDs are computed once by the creator and recorded on the chain, but it means that verifying a file against a recorded CID requires reproducing the same structure, or, more simply, fetching the structure by its CID rather than recomputing it from a file obtained elsewhere. Blocks, links and Merkle DAGs IPFS does not hash large files whole. It splits them into blocks, hashes each block, and then builds a structure of nodes that link to the blocks by their CIDs. A node that links to other nodes by their hashes, which in turn link to further nodes by their hashes, forms what is called a Merkle DAG, a directed acyclic graph in which every link is a hash. The CID of the top node, the root, therefore commits to the entire structure beneath it. Change any byte in any block, and that block's CID changes, which changes the node that links to it, and so on up to the root. The format used for ordinary files and directories is called UnixFS. By default, Kubo splits files into chunks of 256 kibibytes and arranges them under a balanced tree of link nodes. A directory is a node whose links are named entries pointing to the CIDs of files and subdirectories. This is how a whole NFT collection's metadata can be published under a single CID: the creator places ten thousand JSON files in a directory, adds the directory to IPFS, and obtains one root CID that commits to every file and every filename. A token's URI can then be written as ipfs:// followed by the root CID, a slash and the token's filename. That structure fits both standards. An ERC-721 contract can store the root CID as its base URI and append the token number. An ERC-1155 contract can store a URI template with the directory CID and the {id} placeholder, matching the sixty-four-character hexadecimal filenames the standard requires. In both cases one short string in contract storage fixes the content of the entire collection, provided that string cannot be changed. Chunking brings practical benefits too. Large media files can be fetched in parallel from several peers. Identical blocks in different files are stored once. A video can be streamed by fetching blocks in order. And a client can verify each block as it arrives rather than waiting for the whole file, rejecting bad data early. Finding and fetching A content address says what to fetch but not where. IPFS needs a way to discover which peers hold the blocks for a given CID and a way to transfer them. Discovery uses several mechanisms. The main public mechanism is a distributed hash table, or DHT, based on the Kademlia design. Nodes in the network share responsibility for storing provider records, small entries saying "peer such-and-such can provide CID such-and-such". A node that holds content announces itself as a provider; a node seeking content queries the DHT to find providers. Provider records expire and must be republished periodically, which is one of several reasons why content held by a node that goes offline becomes unfindable fairly quickly. Large providers and services also use faster indexing systems alongside the DHT, and nodes can be connected to each other directly when they know in advance where content lives. Transfer has traditionally used a protocol called Bitswap. A node sends its connected peers a list of the blocks it wants; peers that have them send them. As each block arrives, the receiving node hashes it and checks the result against the CID it requested. A peer that sends wrong data gains nothing, because the data is rejected, and the receiver can simply ask someone else. This is the property that makes content addressing robust in an untrusted network: integrity is checked at every hop by the party who needs it, using only the name. Gateways and the trust they reintroduce Most people, and most applications, do not run IPFS nodes. They use HTTP, and to bridge the gap the IPFS ecosystem relies on gateways: HTTP servers that run IPFS nodes behind the scenes, accept requests that include a CID and return the content. A request to a gateway at a path beginning /ipfs/ followed by a CID asks the gateway to fetch that content from the network and return it over ordinary HTTP. Public gateways such as ipfs.io and dweb.link are operated for the community; many companies run their own. Gateways are indispensable and they reintroduce exactly the trust that content addressing removes. When a gateway returns a file over HTTP, the browser has no built-in way to know that the file matches the CID in the URL. The gateway verified the blocks as it fetched them from the network, but the client is trusting the gateway's word that it did so, and that it is returning the same bytes. A malicious or compromised gateway could serve anything. For most uses this is an acceptable trust assumption, much like trusting a content-delivery network, but it is a trust assumption, and it is precisely the one the NFT architecture was supposed to eliminate. Two developments narrow the gap. The first is the subdomain gateway, which serves each CID from its own origin, such as a version-1 CID written as the first label of the hostname. This gives each piece of content its own security origin in the browser, preventing one HTML artwork from reading cookies or storage belonging to another, which matters when animation_url points to interactive content. The second is the trustless gateway model, in which the gateway returns the raw blocks, or a packaged bundle of blocks in the Content Addressable aRchive format, called a CAR file, rather than a reassembled file. The client then verifies every block against the CID itself. Libraries such as Helia's verified-fetch make this practical in browsers and applications. A marketplace or wallet using verified retrieval regains the full integrity guarantee without running a full node. Verifying a token by hand The guarantees above become concrete when one follows the steps a careful client takes to verify a single content-addressed token. Suppose a contract's tokenURI(42) returns ipfs:// followed by a version-1 CID beginning bafy, a slash, and 42.json. The client first parses the CID. The multibase prefix, the initial b, says the rest is base32. Decoding it yields the version number, a codec identifying the UnixFS file structure, and a multihash whose prefix identifies SHA-256 and whose remaining thirty-two bytes are the digest of the root node. The client now knows exactly what it is looking for and how to check it. The client requests the root node's block, from a local node, from peers or from a gateway in trustless mode. On receipt it hashes the block with SHA-256 and compares the result with the digest in the CID. If they differ, the block is discarded and requested elsewhere. If they match, the client decodes the block, which is a directory listing, and finds the entry named 42.json, which carries that file's own CID. It repeats the process: request the block, hash it, compare, decode. If the file is small it may be a single block; if larger, the block is a list of links to chunks, each of which is fetched and verified in turn. When the last chunk is verified and the bytes reassembled, the client has a JSON document that it knows, with cryptographic certainty, is the document the contract's URI committed to. The document's image field contains another ipfs:// URI, and the client verifies the image in the same way. At the end of the process, every byte displayed has been checked against a hash that traces back, link by link, to the string in contract storage. No server was trusted. A gateway may have relayed every block, but the gateway could not have substituted anything without detection. Compare the same process for a token whose tokenURI returns an https:// URL. The client sends a request and receives some bytes, and there is nothing to check them against. If the server returned the wrong document, the client has no way to know. The difference between the two processes is the difference between verification and belief. Mutable names on top of immutable data Content addressing produces immutable names, and sometimes people want names that can change, such as a pointer to the latest version of a website. IPFS provides a mechanism for this called IPNS, the InterPlanetary Name System, in which a name derived from a public key can be updated to point to different CIDs by whoever holds the corresponding private key. The Domain Name System can also be used, by publishing a CID in a DNS text record. These mechanisms are useful for websites and harmful for NFT metadata, and the reason is now familiar. An IPNS name is a mutable reference controlled by a key holder, exactly like a base-URI setter in a contract. A token whose URI is an IPNS name has content that can change whenever the key holder wishes. It has the vocabulary of IPFS and the trust model of a web server. A buyer checking whether a token is "on IPFS" needs to check that the URI uses /ipfs/ or ipfs:// with a CID, not /ipns/ with a key or domain name. What IPFS guarantees, and what it does not It is now possible to state precisely what content addressing provides. It provides integrity: any client that verifies blocks against the CID can be certain that the data it has is the data the CID names, regardless of where it came from. It provides location independence: any peer, gateway or archive holding the data can serve it, so the failure of one host need not mean the loss of the data. And it provides deduplication and verifiable structure: one root CID can commit to an entire collection. It does not provide persistence. IPFS is a protocol for naming and moving data, not a storage service. When a node adds a file, the file is stored on that node. Other nodes that fetch it keep a temporary copy in a cache that is periodically cleared by garbage collection. Nothing in the protocol obliges any node to keep any data. If every node that holds a CID's blocks deletes them or goes offline, the CID still exists as a name, and it still proves what the data was, but the data cannot be retrieved. The name is immortal; the content is not. This is the most important fact in the book, and the source of the most widespread misunderstanding about NFTs. A token whose metadata is "on IPFS" is protected against being changed. Whether it is protected against being lost depends entirely on who has committed to keep it, which is the subject of the next chapter. Chapter 7: Keeping the Bytes Alive Content addressing solves integrity. It turns every reference into a promise about exact bytes that anyone can check. What it cannot do is make anyone keep those bytes. Persistence has to be arranged, and arranging it is a question of incentives, money and institutions as much as of technology. This chapter examines the options in turn: pinning on IPFS, contracted storage on Filecoin, prepaid permanent storage on Arweave, and storing the data on the blockchain itself. Each answers the question "who keeps the bytes, and why?" differently. Pinning On an IPFS node, data is either pinned or cached. Pinned data is kept indefinitely, exempt from garbage collection. Cached data, which the node fetched or relayed in the ordinary course of operation, is deleted when the node needs space or when a periodic clean-up runs. To keep a collection available, someone must pin its root CID on at least one node that is reliably online and announcing itself as a provider of that content. Pinning a root CID pins every block beneath it, so one command can preserve an entire collection. The person or organisation doing the pinning carries the cost: disks, bandwidth, electricity and the labour of keeping a server running. A creator can run their own node, which gives full control and carries the same business-continuity risk as running a web server; when the creator stops, so does the pin. Many projects instead use commercial pinning services, which run large IPFS clusters and pin content on behalf of customers for a monthly fee. Pinata, founded in 2018, is the best known of these in the NFT world; others offer similar services, and the IPFS project defines a common Pinning Service API so that clients can talk to different providers in the same way. A pinning service is, in effect, a hosting company for content-addressed data. That makes it vastly better than a hosting company for location-addressed data, because the service cannot alter the content and because anyone else can pin the same CID without coordination. But the availability it provides lasts exactly as long as someone pays the bill and the service stays in business. A pin is a subscription, not a deed. It is also invisible from the chain: nothing in the contract or the metadata records who is pinning a CID or until when, so a buyer cannot tell from the token itself whether its content is held by five reliable parties or by none. The only test is to try retrieving it, from several sources, and to ask the issuer for the plan. The history of free pinning illustrates the point. In 2021 Protocol Labs launched NFT.Storage, a service offering free storage for NFT data, pinned on IPFS and backed by deals on the Filecoin network. It was enormously popular and absorbed a great deal of NFT content. Free storage at that scale was a subsidy, and subsidies end. The service later stopped accepting uploads to its original free tier and now offers long-term preservation in exchange for a one-time fee. Content uploaded under the old arrangement had to be reviewed by its owners for where it would continue to live. Nothing was lost through malice; the lesson is simply that the party paying for storage determines how long it lasts, and if nobody is paying, eventually nobody will be storing. The structural advantage of content addressing for pinning is that persistence can be redundant and uncoordinated. A creator, a pinning service, a collector, a marketplace and a museum can all pin the same CID independently. None of them needs permission from the others, and none of them can corrupt the content. A collection pinned by five unrelated parties survives the failure of any four. For the collector, this is the most important practical fact in the book: you can pin the content of what you own yourself, cheaply, and in doing so you make your asset less dependent on anyone else. Filecoin: storage by contract Filecoin, also developed by Protocol Labs and launched on its main network in October 2020, adds an economic layer to content-addressed storage. It is a blockchain whose participants, called storage providers, are paid to store data and must prove, continuously and cryptographically, that they are doing so. A client makes a storage deal with a provider, specifying the data, identified by a content identifier, the price and the duration. The provider seals the data in a process that produces a unique encoded replica, and then submits periodic proofs to the Filecoin chain. A Proof-of-Replication shows that the provider has created a distinct physical copy, and recurring Proofs-of-Spacetime show that the copy is still held over time. Providers put up collateral in Filecoin's token, which is forfeited if proofs are missed. The arrangement converts a pinning service's promise into a contract enforced by a blockchain. Filecoin deals are finite. They run for fixed terms and must be renewed to continue. Retrieval, getting data back out quickly, has historically been a weaker point than storage, and many Filecoin-backed services pair storage deals with IPFS pinning for fast access. Filecoin is therefore best understood as a verifiable, economically incentivised backstop: strong evidence that copies exist, for a known period, held by parties with money at stake. It still requires that someone keeps renewing deals and paying for them. Without renewal, the data is subject to the same eventual fate as an expired pin. Arweave: paying once Arweave, launched in 2018, takes a different approach. Rather than paying for storage over time, a user pays once, at upload, and that fee is intended to fund storage permanently. The mechanism rests on an endowment. Part of each upload fee is placed into a pool that is released gradually to miners over time. Miners are rewarded for producing blocks, and to produce a block a miner must prove access to randomly selected pieces of previously stored data, so miners who store more of the network's history have better chances of earning rewards. The design depends on an assumption about the future: that the cost of storing a given amount of data will keep falling, as it has for decades, so that a finite endowment can pay for storage indefinitely. Arweave's design documents set the fee conservatively, aiming to fund at least two centuries of replicated storage under pessimistic assumptions about how quickly costs decline. Data on Arweave is addressed by transaction identifiers, which are derived from hashes, and metadata URIs can use the ar:// scheme or an Arweave gateway URL. The same gateway caveats from Chapter 6 apply: a URL hard-coding a particular gateway's domain is a location reference, and a client that does not verify returned data is trusting the gateway. Arweave's model offers the most direct answer to the persistence problem short of putting data on the main chain. Its guarantee is economic and assumption-laden: it depends on storage costs continuing to fall, on the network continuing to attract miners and on the value of its token remaining sufficient to make mining worthwhile. Those are reasonable bets, but they are bets, and anyone evaluating the claim of "permanent" storage should understand what it rests on. Arweave has become widely used for NFT metadata, particularly on the Solana blockchain, where the Metaplex token-metadata standard encouraged it. On-chain storage The strongest form of persistence is to put the data in the same replicated state that holds the ownership record. If every full node of the blockchain must hold the data in order to validate the chain, then the data lasts exactly as long as the chain does, and no separate arrangement is needed. Tokens built this way are usually called on-chain NFTs. On Ethereum, contract storage is costly, as Chapter 1 showed: about 20,000 gas per 32-byte word. A cheaper technique stores data as the bytecode of a separate contract, since deploying code costs 200 gas per byte, and reading it back is efficient; this pattern is often called SSTORE2 after a widely used library. Each contract's code is limited to 24,576 bytes, so larger assets are split across several contracts. Even so, a single high-resolution photograph would be expensive, and a video impractical. The on-chain NFTs that work therefore exploit compression, generation and vector graphics. Larva Labs' Autoglyphs, released in 2019, generate their images entirely from code in the contract. Loot, released in August 2021 by Dom Hofmann, returns its metadata from tokenURI as a data: URI containing base64-encoded JSON, whose image is itself a data: URI containing an SVG, all assembled by the contract at call time. Art Blocks stores the generating script for each of its projects on Ethereum and gives each token a hash that seeds the script; the image is rendered by running the script, and the collection's software libraries have increasingly been registered on the chain as well. The CryptoPunks data contract described in Chapter 1 stores compact pixel data and renders it on request. A rough calculation shows why on-chain storage is reserved for compact assets. Take a collection of one thousand vector images, each a five-kilobyte SVG file, five megabytes in all. Stored as contract bytecode at 200 gas per byte, the code deposit alone comes to one billion gas, before counting the cost of sending the data in transactions, which adds a further sixteen gas per non-zero byte, and the fixed overhead of deploying a few hundred storage contracts. At an assumed gas price of 10 gwei, one billion gas is ten ether. The figure scales linearly with data: a collection of one thousand 500-kilobyte photographs would cost about a hundred times as much. Gas prices on Ethereum have varied by more than an order of magnitude in each direction over its history, so the result in currency can swing widely, but the ratio between compact generative art and photographic media is fixed by the arithmetic. Rollups and other networks that execute Ethereum's virtual machine offer much cheaper storage, with the different security assumptions described in Chapter 1. The arithmetic explains why the most successful on-chain projects store the recipe rather than the meal. A generative script of a few kilobytes and a 32-byte seed per token can reproduce images whose rendered files would be orders of magnitude larger. Storing the recipe on chain and the rendered images on IPFS or Arweave gives the integrity and permanence of the chain to the irreducible core of the work, while the convenient forms live where storage is cheap. Not all on-chain data is equally permanent. Contract storage and contract code are part of Ethereum's current state, which every full node must hold. Transaction input data and event logs, by contrast, are part of the chain's history, and Ethereum's client developers have been implementing a long-planned change, set out in a proposal known as EIP-4444 and usually called history expiry, that allows ordinary nodes to discard old history and rely on specialised archives to keep it. Data posted in the "blobs" introduced by the March 2024 Dencun upgrade is deleted by nodes after roughly eighteen days and was never meant for permanent storage. A design that hides an image in calldata or an event, reasoning that it is "on the chain", may find that it is on the chain only in the sense that someone, somewhere, keeps an archive. Bitcoin's Ordinals, introduced by Casey Rodarmor in January 2023, store files in the witness data of Bitcoin transactions, and associate them with individual satoshis through an ordering convention. The files are part of every unpruned full node's copy of the Bitcoin blockchain. The model is fully on-chain in that sense, but it relies on a convention and dedicated indexing software, outside Bitcoin's own rules, to define which inscription belongs to whom. Comparing the options Each of these approaches answers the persistence question with a different party and a different incentive. Table 4 summarises them. Table 4. Persistence options for NFT content, by who keeps the data and why. Option Who keeps the data Why they keep it Main residual risk Self-run IPFS node Creator or collector Own interest Node owner stops IPFS pinning service Commercial provider Ongoing payment Payment lapses or firm closes Filecoin storage deal Storage providers Paid deal, collateral at stake Deal not renewed Arweave Network miners Endowment-funded rewards Economic assumptions fail On-chain state Every full node Required to validate chain Cost limits asset size The table makes a pattern visible. As the guarantee strengthens, the obligation moves from a single named party to a protocol, and the cost moves from a recurring payment to an upfront one, or to the price of fitting the asset into the chain itself. No option is free of residual risk, but the risks are of very different kinds. A pinning service can fail tomorrow. Arweave's economics would need to break down over a long period. Ethereum's state would have to be abandoned by its entire community. Who should pay Every persistence option ultimately reduces to a question of funding, and the NFT ecosystem has been slow to answer it. In the boom years, storage was treated as an incidental cost of launch, often paid by a free service or a single month's subscription, while the sale itself raised sums many thousands of times larger. The mismatch is striking: an asset sold on the promise of permanence, with nothing set aside to make it permanent. There are several reasonable ways to close the gap. The simplest is for issuers to treat storage as part of the cost of goods: to allocate a defined portion of primary-sale proceeds to prepaid storage, whether an Arweave upload, multi-year Filecoin deals or a prepaid pinning contract, and to say publicly what was bought and for how long. A second is to dedicate part of any ongoing revenue, such as creator royalties where they are still paid, to renewal. A third is collective: holders of a collection can fund pinning jointly, which content addressing makes safe, since no single funder controls the content. A fourth is institutional: museums, libraries and archives that collect digital art can add pinning and storage deals to their ordinary preservation budgets, as some have begun to do with born-digital works generally. What these approaches share is that they make persistence somebody's explicit job, with money attached and a time horizon stated. That is the minimum a buyer should look for. An answer of "it's on IPFS" with no named party keeping it is not a persistence plan; it is a description of the naming scheme. Redundancy as the practical answer For most collections, the right answer is not one of these options but several in combination. The content is content-addressed, with the same CID usable on any IPFS node. It is pinned by the creator and by at least one commercial service, so that it is fast to retrieve. It is backed by Filecoin deals or uploaded to Arweave, so that a provider with economic incentives holds a copy independently of any single company. For small or generative assets, the essential data is placed on chain. And collectors are encouraged, and given the means, to pin what they own. Redundancy works because content addressing makes copies interchangeable and self-verifying. Ten copies of a location-addressed file on ten servers are ten separate claims, any one of which may differ from the others. Ten copies of a content-addressed file are the same file, and any one of them can be checked against the name recorded on the chain. That is why the integrity guarantee of Chapter 6 and the availability arrangements of this chapter must be read together. Integrity makes redundancy safe. Redundancy makes integrity worth something. The final chapter turns these principles into a design: how a contract, a publication process and a persistence plan can be put together so that the token's guarantees reach all the way from the storage slot to the file. Chapter 8: An Architecture That Holds The previous chapters took the NFT apart. This one puts it back together. The aim is a design in which every guarantee the token claims is actually delivered by something: by consensus, by a hash or by a party with a reason to keep doing its job. The chapter follows a single hypothetical collection from preparation to long-term care, and then turns the same logic around into an audit that a buyer can apply to any token. The collection is imaginary; the techniques are standard and in use. The working example Imagine an artist releasing a collection of one thousand generative images, each with a set of attributes, plus one longer animated work that will be issued in an edition of fifty. The artist wants the images to be fixed forever once revealed, wants the edition to be strictly limited, and wants collectors to be able to verify everything without trusting the artist, the platform or any marketplace. The artist is not wealthy enough to store a thousand full-resolution images on Ethereum, but can afford a modest one-time outlay for storage. The architecture has four layers: the media, the metadata, the contracts and the persistence plan. Each layer is designed so that the layer above it can commit to it by hash. Preparing the media The first decisions are about the files themselves, because the files are what everything else will point to. Formats should be chosen for longevity as well as appearance. PNG for still images and MP4 with a widely supported codec for video are safe choices, because they are openly documented and implemented in every browser and operating system. If the animated work is interactive and delivered as HTML, it should be self-contained: every script, font and data file it needs should be bundled into the same directory and referenced by relative path, so that the whole work is captured by one content identifier. A work that loads a library from a public content-delivery network has, as Chapter 5 showed, an undeclared dependency on a location reference. Bundling removes it. The artist should also decide what "the work" is at the level of bytes. If the generative images are produced by code, the code and its seeds may be a more fundamental and more compact representation than the rendered images. Publishing the code and seeds alongside the images, also content-addressed, gives future custodians a way to regenerate the work if every copy of a rendered file is somehow lost, and lets anyone confirm that the rendered images match what the code produces. The media files are placed in one directory, the animated work in another, and both are added to IPFS. Using version-1 CIDs and recording the exact tool and settings used makes the result reproducible: anyone holding the same files and the same settings will compute the same root CIDs. The output can be exported as CAR files, archives that contain every block of the structure along with its root CID, so that the precise IPFS representation can be uploaded to any pinning service or storage network without being recomputed, and can be archived offline. Building the metadata Next, the artist generates one metadata document per token. Each document's image field is an ipfs:// URI composed of the media directory's root CID and the image's filename. The animation_url for the edition is likewise an ipfs:// URI pointing into its own directory. No field contains an https:// URL to anything the artist controls. If the artist wants a link to a project website, it goes in external_url, which is understood as a convenience rather than part of the asset. Attributes are written into the metadata and, for the generative collection, should be derivable from the code and seed, so that they can be independently verified. A licence document, stating what rights a holder receives, can be content-addressed and referenced from each metadata file, binding every token to a fixed text rather than to a web page that might be edited later. The metadata files are placed in a directory, named by token identifier, and added to IPFS, giving a single root CID for all one thousand documents. For the edition, which will use ERC-1155, the metadata file's name must follow that standard's sixty-four-character lower-case hexadecimal convention so that clients substituting {id} into the template find it. At this point a chain of hashes exists: one CID for the metadata directory, which commits to every metadata document, each of which commits by CID to its image or animation. Change any pixel, any attribute or any word of any description, and the metadata root changes. Handling the reveal honestly The artist wants a delayed reveal, so buyers cannot pick rare tokens during the sale. This requires that, for a time, the contract point somewhere other than the final metadata. The honest way to do this is to commit to the final metadata before the sale and to make the assignment of final metadata to token numbers depend on randomness the artist cannot control. Before the sale, the artist publishes the metadata root CID, or a hash of it, in the contract's constructor as a provenance commitment. Because a CID is already a hash of the entire collection, this single value commits to every image and every attribute in a fixed order. During the sale, tokens point to a placeholder. When the sale ends, the contract obtains a random offset from a verifiable random function or from a future block value fixed in advance, and the mapping from token number to metadata file becomes the token number plus the offset, modulo the collection size. The contract then sets the base URI, but only if the CID being set matches the one committed in the constructor. The setter cannot be used to install anything else. This design narrows the reveal from a trusted act to a verified one. The artist cannot change which images exist, because they were committed in advance. The artist cannot choose which token gets which image, because the offset was not under the artist's control. And the base URI cannot become anything other than the committed root. Writing the contracts The contract layer must close the remaining gap identified in Chapter 5: the reference itself must not be changeable after the reveal. For the one thousand unique images, an ERC-721 contract is appropriate. Its tokenURI function returns ipfs://, the committed metadata root CID, a slash and the shifted token number. After the reveal, there is no function in the contract that can change the root. If the contract supports EIP-4906, it emits a single BatchMetadataUpdate event at reveal time so that marketplaces refresh their caches, and never again. It may also emit OpenSea's PermanentURI event for each token as a courtesy, but the guarantee comes from the absence of a setter, not from the event. The contract should not be deployed behind an upgradeable proxy. If the artist wants the safety of being able to fix a bug before launch, the right tool is testing and an independent audit, not an upgrade key that persists for the life of the collection. Administrative functions that remain, such as withdrawing sale proceeds, should not touch ownership or metadata. Where some ongoing administration is unavoidable, the key should be held in a multi-signature wallet with a published list of signers, and every power the key holds should be documented. For the edition of fifty, an ERC-1155 contract is appropriate, but the standard's silence about supply must be filled by code. The contract records a maximum supply for the type, fixed at deployment, and its minting function reverts if that maximum would be exceeded. After the fifty are minted, minting for that type is permanently closed. The uri function returns a template containing the metadata directory's CID and the {id} placeholder, and no function can change it. Because ERC-1155 defines a URI event for changes, the absence of any code path that would emit it is itself evidence of immutability that an auditor can check. The artist might go further for the generative collection and place the generating code and seeds on chain, using code-as-storage techniques, so that the collection can be regenerated from the blockchain alone even if every off-chain copy is lost. For one thousand images whose generator is a few kilobytes of code, that is affordable and turns the off-chain media into a convenience cache for something the chain itself preserves. The persistence plan With integrity sealed, availability must be provided deliberately, by more than one party with more than one kind of incentive. The artist pins the media and metadata roots on a self-operated IPFS node, for direct control, and with at least one commercial pinning service, for reliability. The same CAR files are used to obtain Filecoin storage deals, or uploaded to Arweave, so that a copy exists under an arrangement that does not depend on the artist continuing to pay a monthly bill. Where budget allows, both. The CAR files and the generating code are also kept offline, on media the artist controls, as a last resort. The artist publishes the root CIDs, the CAR files' hashes and instructions for pinning them, and encourages collectors to pin what they hold. Some collectors will. A museum or archive acquiring a token can pin the whole collection as a matter of course, since content addressing means its copy is exactly as authoritative as the artist's. The plan should be written down and published, with dates. If a pinning subscription is due for renewal or a Filecoin deal will expire, those facts are part of what a buyer is buying. A collection whose storage is funded until a certain year and then depends on community pinning is a different asset from one funded indefinitely, and both are different from one whose survival depends on the artist remembering to pay. Serving and verifying The last layer is the one users see. The artist's own website and any marketplace display images fetched through gateways for speed. The architecture does not change that, but it changes what the gateway is trusted for. Because every reference is a CID, any client can verify. A well-built viewer uses verified retrieval, fetching blocks or CAR files and checking them against the CID, and falls back from one gateway to another if one fails. A viewer that does not verify still benefits, because a wrong answer from a gateway can be detected by anyone who checks. The artist should resist, where possible, the convenience of returning gateway URLs from the contract. A gateway can be chosen by the viewer at display time. Written into the contract, it becomes a permanent dependency on a company that may not exist in a decade. The buyer's audit The same reasoning can be run in reverse to evaluate any NFT before buying it. The audit follows the chain from the ledger to the file and asks, at each link, whether it is bound by code, by a hash or only by someone's continued good behaviour. 1. Read the contract. Confirm the code is verified on a block explorer, so it can be read. Check whether it sits behind a proxy and, if so, who controls upgrades. List every administrative function and who can call it. 1. Check the URI logic. Find how tokenURI or uri builds its result. Look for any function that changes the base URI or individual token URIs, and whether it has been permanently disabled. 2. Inspect the returned URI. It should begin ipfs:// with a CID, ar://, or data:. An https:// URL to the project's domain means content can change. A gateway URL means a dependency on that gateway. An /ipns/ path means a key holder can change it. 3. Open the metadata. Check that image, animation_url and any other asset fields are themselves content-addressed. For HTML works, check whether the page loads anything from outside its own directory. 4. Check supply. For ERC-1155 types, find whether the contract enforces a maximum. For ERC-721, check whether minting is closed. 5. Check persistence. See whether the CIDs can be fetched through more than one gateway, whether the project publishes a storage plan, and whether you can pin the content yourself. None of these steps requires trusting the seller's description. All of them are answerable from public information, though they reward some technical fluency. Tools that automate parts of the audit exist and will improve, but their value is in executing these checks quickly, not in replacing the logic. Objections to immutability Making content impossible to change has costs, and three objections are raised often enough to deserve answers. The first is that mistakes become permanent. A typo in a description, a wrong attribute or a corrupted image file, once frozen, cannot be fixed. This is true, and the remedy is process rather than mutability: publishing all metadata and media to a test deployment, checking every file against its CID and every attribute against its generator, and inviting independent review before freezing. The reveal design described above already includes a window between commitment and reveal, during which errors found in the committed set can be addressed only by abandoning that commitment openly, which is itself a form of accountability. After freezing, an issuer who discovers an error can publish a correction alongside the token, for example in a separate content-addressed errata document, without altering the original. Archives and museums have always handled errors this way: the record stays as it was, and corrections are added. The second objection concerns illegal or harmful content. If an image turns out to infringe someone's copyright, or contains material that must be removed by law, an immutable architecture seems to make removal impossible. The reality is more nuanced. Content addressing fixes what a name refers to; it does not force anyone to store or serve the content. Pinning services, gateways and marketplaces can and do decline to host or display specific CIDs, and public gateways maintain deny-lists for that purpose. What an immutable architecture prevents is the issuer silently replacing the content for everyone, which is the property buyers need. Removal from public availability remains possible through the ordinary means by which hosts respond to legal demands. The token continues to point at the CID, but the content may become hard to retrieve. That is an uncomfortable outcome for an owner, and it is the right outcome when the content is unlawful. The third objection is that immutability limits creative possibility, closing off works designed to evolve. As Chapter 4 argued, the answer is to make change rule-governed rather than to forbid it. A work that evolves according to code on the chain, drawing on content-addressed components, is as mutable as its artist intended and no more. What the architecture excludes is not change but discretionary change by a party the buyer did not agree to trust. What the design achieves At the end of this process, the collection's guarantees can be stated plainly. Ownership is held by consensus on Ethereum. The link from contract to metadata is fixed by code that cannot change. The link from metadata to media is fixed by hashes. The media's integrity can be checked by anyone with any copy. The media's availability is provided by several independent parties under different incentives, at least one of which does not depend on the artist's continued payments, and the essential generative data is on chain. Every link that matters is either a hash or immutable code, and every copy that matters has someone responsible for it. The design costs somewhat more effort than putting files on a web server and storing a URL. It costs less than the reputational and financial damage of tokens that break, and it costs far less than the alternative of storing everything on chain. Most importantly, it makes the asset's guarantees match its claims. Conclusion The public argument about NFTs has mostly been conducted in the wrong terms. Enthusiasts claimed that blockchains made digital ownership permanent and verifiable. Sceptics replied that an NFT was "just a link to a JPEG". Each side was describing a real feature of the architecture and mistaking it for the whole. The ledger entry is as robust as its advocates said. The link is as fragile as its critics said. What decides whether a particular token is robust or fragile is the chain between them, and that chain is built by people, link by link, with choices that the standards leave open and the marketplaces rarely display. Several consequences follow from taking that seriously. For creators and issuers The first consequence is that the responsibility for an NFT's durability belongs to whoever issues it, and that responsibility can be discharged. Nothing about it is exotic. Content-addressing every asset, writing native ipfs:// or equivalent URIs, removing setters and upgrade keys after launch, committing to final metadata before a reveal and arranging redundant storage under more than one incentive are all well documented and within the reach of any competent team. Issuers who did not do these things in 2021 can be partly excused by the speed of that period and the immaturity of the tools. Issuers who do not do them now are choosing to sell something that can be changed or lost and describing it as something that cannot. That responsibility includes honesty about what remains mutable. Some tokens should change: game items, credentials, tickets, works designed to evolve. The architectural virtue is not immutability for its own sake but correspondence between what is promised and what is enforced. A dynamic token whose change follows readable rules from on-chain state is honest. A "permanent" artwork whose base URI can be reset by an administrator is not, however carefully the administrator behaves. It also includes planning for the issuer's own disappearance. Companies close, artists move on, and brands abandon initiatives. A collection designed so that it continues to function without its issuer, with its content pinned by others, archived in a storage network and verifiable by anyone, is a collection whose owners do not need to trust the issuer's future. That is the whole point of putting ownership on a blockchain in the first place. An NFT that still depends on the issuer's server has adopted the cost and complexity of decentralisation while retaining the dependency it was meant to remove. For platforms and marketplaces The second consequence is that platforms have been concealing the most important property of the assets they sell. A marketplace listing typically shows an image, a name, attributes, a price history and an owner. It rarely shows whether the image is content-addressed, whether the contract can change it, or who is storing it. Buyers cannot price what they cannot see, and the result has been a market in which durable and fragile tokens trade as if they were the same thing. Displaying these properties would be straightforward. The checks described in Chapter 8 can largely be automated: whether tokenURI returns a content reference, whether the metadata's asset fields do, whether the contract has a live URI setter or an upgradeable proxy, whether the content is retrievable from more than one source. A platform that surfaced these facts, as prominently as it surfaces rarity scores, would change issuers' incentives quickly. A platform that verified the content it displays, rather than trusting a gateway or its own cache, would stop being part of the problem described in Chapter 5. Platforms that index and cache NFTs are also, whether they intend it or not, among the largest holders of NFT content. A marketplace that pinned, rather than merely cached, the content-addressed assets it lists would add a meaningful layer of redundancy at modest cost. It would also turn a liability, the cached copy that silently diverges from the origin, into a contribution to the asset's survival. For owners The third consequence concerns owners, and it is the least appreciated. Content addressing changes who can preserve an asset. With location-addressed content, only the controller of the location can keep it available; everyone else holds unverifiable copies. With content-addressed content, any owner can pin the exact bytes their token commits to, and their copy is as authoritative as anyone's. The owner is no longer a passive holder of a claim against an issuer. The owner can be a custodian. This is a practical power, not a theoretical one. Pinning a collection's root CID on a personal node or a paid service costs little for typical NFT media. An owner who cares about an asset can make it materially more durable by doing so, and owners collectively, if enough of them pin, can keep a collection alive long after its issuer has gone. For high-value works, it would be reasonable to expect collectors and institutions to treat pinning and archiving as part of ownership, the way they treat insurance, conservation and climate control for physical art. The same logic sets a standard for due diligence. An owner who does not check whether a token's content is fixed and kept has bought a ledger entry and a hope. The audit in Chapter 8 takes less time than most people spend reading a listing's description. Owners who skip it are relying on precisely the trust that the technology was supposed to make unnecessary. What the technology does and does not do The deepest lesson of NFT architecture is about the limits of cryptography in preserving culture. A hash can bind a name to bytes with a strength no legal instrument can match. It can let strangers verify a file without trusting each other. It can let a thousand independent copies be one copy. What a hash cannot do is make anyone care. Persistence is ultimately a social and economic fact: some person or institution, with resources and a reason, keeps the bytes and keeps serving them. Protocols such as Filecoin and Arweave can structure that reason as payment and collateral; blockchains can make it a condition of participating in the network. None of them removes the need for someone, somewhere, to do the work. Seen this way, the NFT is less a revolution in ownership than a careful division of labour. The ledger handles who owns what, with a strength that no previous digital system offered. Content addressing handles what exactly is owned, with a precision that the web never had. Storage, whether by pinning, contract or endowment, handles whether it still exists, and that part remains as dependent on human commitment as libraries and archives have always been. Durable digital ownership comes from building all three parts and connecting them with hashes. Where any part is missing, the token still records an owner, but there may be nothing reliable left for it to point to. Glossary CAR file. Content Addressable aRchive: a file that packages a set of IPFS blocks together with their root CID, so the exact structure can be moved, uploaded or verified as a unit. CID (content identifier). The self-describing name IPFS gives to data, built from a hash of the data plus information about the hash function, data format, version and text encoding. Content reference. A reference that names specific bytes, usually by hash, so that any retrieved data either matches it or is rejected. ERC-165. An Ethereum standard by which a contract declares, through supportsInterface, which interfaces it implements. Gateway. An HTTP server that retrieves IPFS or Arweave content and returns it to ordinary web clients; unless the client verifies the result, it must trust the gateway. Indexer. An off-chain service that reads blockchain events to reconstruct ownership and metadata, and serves the results to wallets and marketplaces. IPNS. The InterPlanetary Name System: mutable names, controlled by a private key, that can be repointed to different CIDs. Location reference. A reference, such as an https:// URL, that names a place; whatever is at that place when asked is what is returned. Merkle DAG. A graph of data in which every link is the hash of the linked node, so the root hash commits to the entire structure. Operator approval. Permission, granted with setApprovalForAll, for another address to transfer all of an owner's tokens in a contract. Pinning. Instructing an IPFS node to keep data permanently rather than treating it as a cache subject to deletion. Provenance hash. A hash of a collection's final content published before a sale or reveal, so that the content cannot later be altered without detection. Notes 1. Moxie Marlinspike, "My first impressions of web3," moxie.org, 7 January 2022. Source for the context-dependent NFT, its removal by OpenSea, its disappearance from the wallet and the observation that NFTs lack a hash commitment to the data at the URL (Introduction, Chapters 1 and 5). 1. William Entriken, Dieter Shirley, Jacob Evans and Nastassia Sachs, "ERC-721: Non-Fungible Token Standard," Ethereum Improvement Proposals no. 721, created 24 January 2018, eips.ethereum.org/EIPS/eip-721. Source for function and event signatures, interface identifiers, the receiver check and the metadata JSON schema (Chapters 1, 2 and 4). 1. Witek Radomski, Andrew Cooke, Philippe Castonguay, James Therien, Eric Binet and Ronan Sandford, "ERC-1155: Multi Token Standard," Ethereum Improvement Proposals no. 1155, created 17 June 2018, eips.ethereum.org/EIPS/eip-1155. Source for batch functions, events, receiver magic values, interface identifiers and the {id} substitution rule (Chapters 3 and 4). 1. Christian Reitwiessner et al., "ERC-165: Standard Interface Detection," Ethereum Improvement Proposals no. 165 (Chapter 2). 1. Zach Burks, James Morgan, Blaine Malone and James Seibel, "ERC-2981: NFT Royalty Standard," Ethereum Improvement Proposals no. 2981 (Chapter 2). 1. "ERC-4906: EIP-721 Metadata Update Extension," Ethereum Improvement Proposals no. 4906. Source for the MetadataUpdate and BatchMetadataUpdate events (Chapters 2 and 8). 1. OpenSea developer documentation, "Metadata Standards," docs.opensea.io. Source for the conventional attributes, animation_url and external_url fields and the PermanentURI freezing convention (Chapters 4 and 8). 1. Pew Research Center, "When Online Content Disappears," May 2024. Source for the share of 2013 web pages no longer accessible a decade later (Chapter 5). 1. Cloudflare, "Cloudflare's public IPFS gateways and supporting Interplanetary Shipyard," The Cloudflare Blog, 2024. Source for the transition of Cloudflare's public gateway traffic and the August 2024 end of its gateway hostnames (Chapters 4 and 5). 1. Juan Benet, "IPFS - Content Addressed, Versioned, P2P File System," arXiv:1407.3561 (2014) (Chapter 6). 1. IPFS documentation, "Content addressing and CIDs," docs.ipfs.tech. Source for CID versions, encodings and the Qm and bafy prefixes (Chapter 6). 1. Protocol Labs, "Filecoin: A Decentralized Storage Network" (2017), filecoin.io. Source for Proof-of-Replication and Proof-of-Spacetime (Chapter 7). 1. Arweave yellow paper and protocol documentation, arweave.org. Source for the storage endowment model (Chapter 7). 1. Dipanjan Das, Priyanka Bose, Nicola Ruaro, Christopher Kruegel and Giovanni Vigna, "Understanding Security Issues in the NFT Ecosystem," Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS 2022). Background on marketplace and metadata-hosting weaknesses (Chapters 4 and 5). 1. "EIP-4444: Bound Historical Data in Execution Clients," Ethereum Improvement Proposals no. 4444; and "EIP-4844: Shard Blob Transactions," Ethereum Improvement Proposals no. 4844. Source for history expiry and the short retention of blob data (Chapter 7). Further Reading The EIP texts for ERC-721 and ERC-1155 (eips.ethereum.org). Short, readable and more informative than most commentary on them. The rationale sections explain why the authors made the choices they did, including the decision to leave metadata storage open. Moxie Marlinspike, "My first impressions of web3" (2022). The clearest short account of why a token that stores a URL does not commit to content, and of how much of the ecosystem depends on centralised APIs. Juan Benet, "IPFS - Content Addressed, Versioned, P2P File System" (2014). The original design paper. Parts have been superseded by later implementations, but its account of Merkle DAGs and self-certifying names remains the best introduction to the ideas. The IPFS documentation, especially "Content addressing and CIDs," "Persistence, permanence and pinning" and the pages on gateways (docs.ipfs.tech). Practical and current, with a useful candour about what IPFS does not guarantee. The Multiformats project (multiformats.io). The specifications for multihash, multicodec and multibase, for readers who want to decode a CID by hand. Protocol Labs, "Filecoin: A Decentralized Storage Network." The whitepaper describing storage deals and the proofs that underpin them. The Arweave yellow paper. The source for Arweave's endowment model and the economic assumptions behind its claim of permanence. Das, Bose, Ruaro, Kruegel and Vigna, "Understanding Security Issues in the NFT Ecosystem" (CCS 2022). A systematic academic study of marketplace and token weaknesses, including how and where metadata is hosted. OpenZeppelin Contracts documentation for ERC-721 and ERC-1155 (docs.openzeppelin.com). The most widely used reference implementations, with discussion of extensions such as URI storage, and a good place to see the standards turned into working code. Pew Research Center, "When Online Content Disappears" (2024). Not about NFTs, but the best recent measurement of link rot on the ordinary web, and a sobering baseline for any asset that depends on a URL. Hashtags: #NonFungibleTokens #NFTArchitecture #NFTDevelopment #BlockchainTechnology #EthereumBlockchain #SmartContracts #Solidity #ERC721 #ERC1155 #EthereumVirtualMachine #NFTMetadata #IPFS #InterPlanetaryFileSystem #DecentralizedStorage #ContentAddressing #ContentIdentifiers #CryptographicHashing #MerkleDAG #MetadataIntegrity #ImmutableMetadata #NFTMinting #NFTSmartContracts #OnChainNFTs #OffChainMetadata #IPFSPinning #Filecoin #Arweave #DigitalOwnership #NFTSecurity #Web3Architecture

Download the Book (PDF): Introduction On a Tuesday night in October, a sophomore sits on the floor of her chapter house with a laptop balanced on her knees. Chapter meeting ran long. After it came a committee check-in, then a group chat about Saturday's philanthropy event that is still buzzing at 11:40 p.m. She has an organic chemistry problem set due at nine the next morning, a shift at the campus library on Thursday, and a big sister who has texted twice to ask whether she is coming to the study session that turned into a movie night. She loves these women. She joined because she was lonely in her first semester and this house gave her a place to walk into without feeling like a visitor. She also has not slept more than six hours on a weeknight since recruitment ended, and lately she has felt a flatness in the mornings that she does not have a name for. Nothing in that scene is scandalous. No one is being forced to drink. No one is standing in a basement being yelled at. And yet it contains, in small form, almost everything this book is about: the real pull of belonging, the quiet arithmetic of obligations that were each reasonable on their own, the way sleep becomes the account everyone overdraws, and the uncertainty about whether it is acceptable to say, "I can't tonight." Fraternities and sororities occupy an unusual place in American higher education. They are among the oldest student institutions in the country, and they remain some of the most powerful. For hundreds of thousands of students they supply a ready-made community, leadership roles, alumni networks, service opportunities, and a sense of home at a stage of life when home has just been left behind. They are also where some of the worst harms on campus have happened. Students have died in fraternity houses after drinking rituals. National research has found that roughly three in four members of social fraternities and sororities report experiencing behaviors that meet the definition of hazing. The federal government, after decades of state-by-state legislation, passed a national hazing transparency law in December 2024. Both of those descriptions are accurate, and a useful book about wellness in Greek life has to hold them together. Many writings on the subject pick one. Promotional materials describe a world of sisterhood, brotherhood, scholarship, and service in which risk is an afterthought. Critical journalism, often written in the aftermath of a death, describes an institution so compromised that the only sensible response is to abolish it or stay away. Students who are actually in chapters, or who are thinking about joining, find neither account much help. They need to know how to get the good without paying for it with their health, and how to change the parts that are harmful without being cast out of the thing they came for. The argument of this book The central claim of this book is simple to state and harder to live: the qualities that make fraternity and sorority life valuable are the same qualities that make it risky, and wellness in a chapter depends less on individual willpower than on whether the group has made it safe to say no. Belonging is powerful because it matters to us what the group thinks. That same concern is what makes it so hard to refuse a drink, leave a party at midnight, skip an event that isn't mandatory but somehow feels mandatory, or tell a new member that what is being asked of them is wrong. Loyalty is valuable because it means someone will show up for you; it is dangerous when it means no one will call for help because they are afraid of getting the chapter in trouble. Tradition gives a chapter continuity and identity; it also carries forward practices that no current member chose and many privately dislike. If that is right, then the familiar advice to students ("manage your time better," "know your limits," "just say no") is not wrong but badly incomplete. A member can have excellent time-management skills and still lose sleep to a chapter calendar that assumes everyone is free every night. A member can know her limits perfectly well and still be in a room where refusing a drink carries a social price. What changes outcomes is the combination of personal skill and group norms: individuals who know what they need and how to ask for it, in chapters where asking is treated as ordinary rather than as disloyalty. This is good news, because norms are made by people and can be remade by them. Every chapter has members who set its tone, officers who design its calendar, and new members who notice, more clearly than anyone, what is being asked of them. Most students in a chapter are privately more uncomfortable with dangerous practices than they believe their peers to be. That gap between private belief and perceived norm is one of the best-documented findings in the research on college drinking and hazing, and it is also the opening through which change happens. Who this book is for This book is written first for students: those considering recruitment, new members in their first term, active members trying to balance chapter life with academics and work, and chapter officers who have realized that "wellness chair" is a harder job than it sounded. It is also written for the adults around them. Parents often have little idea what their son or daughter's chapter asks of them week to week and may not know what questions to ask. Advisors, fraternity and sorority life staff, and alumni volunteers have more authority than they sometimes realize and less visibility than they would like. It assumes the reader is intelligent and busy. It does not assume any prior knowledge of the research on hazing, alcohol, sleep, or mental health, and it tries to report that research honestly, including where it is limited. Where it describes students, the scenarios are illustrative composites built to show common patterns; they are not accounts of real individuals. It also tries to respect the variety within Greek life. The word "Greek" covers organizations that differ enormously. Chapters in the North American Interfraternity Conference and the National Panhellenic Conference often have houses, large memberships, and formal recruitment periods. Historically Black fraternities and sororities in the National Pan-Hellenic Council, and culturally based organizations in groups such as the National Association of Latino Fraternal Organizations and the National Multicultural Greek Council, often have smaller chapters, intake rather than recruitment, strong graduate-chapter traditions, and distinctive histories rooted in exclusion from the organizations that came first. Professional and honor fraternities have their own cultures again. Much of what follows applies across all of them, and where the differences matter the text says so. How the book is organized The first chapter looks directly at the double-edged nature of membership: what the evidence says about the benefits of belonging, what it says about the risks, and why both can be true of the same chapter at the same time. The second follows the student through recruitment or intake and the new-member period, the stretch of time when stress is highest, power is most unequal, and patterns are set. Chapters 3 and 4 address the two most serious physical dangers. Chapter 3 covers hazing: what it is, why intelligent people take part in it, what the research by Elizabeth Allan and her colleagues has found, and what the Stop Campus Hazing Act of 2024 now requires of colleges. Chapter 4 covers alcohol and emergencies, with particular attention to medical amnesty and Good Samaritan policies and to the single decision that most often separates a bad night from a death: whether someone calls for help. Chapters 5 and 6 turn to the less dramatic but more universal costs. Chapter 5 is about sleep and time, and about why a chapter calendar is a health document whether anyone treats it as one or not. Chapter 6 is about boundaries: how to decide what you will and will not do, and how to say no in ways that protect both your wellbeing and your relationships. Chapters 7 and 8 move from the individual to the group. Chapter 7 is about bystander intervention inside a chapter, where the people you would need to confront are also your friends. Chapter 8 is written for chapter leaders and those who advise them, and describes what it takes to build a culture in which mental health is treated as ordinary chapter business, drawing on the resources that national organizations, campus offices, and prevention researchers now provide. The conclusion draws these threads into a single test that any member, officer, or parent can apply. A note on health and safety This book discusses alcohol poisoning, hazing injuries, depression, anxiety, and suicidal thinking. It offers general information and practical guidance; it does not replace advice from a physician, counselor, or other professional who knows your situation. Two things are worth saying plainly at the start. If someone is unconscious, cannot be woken, is breathing slowly or irregularly, is having a seizure, or has been injured, call 911 (or your local emergency number) immediately; do not wait to see whether they improve. If you or someone you know is thinking about suicide or is in emotional crisis, in the United States you can call or text 988 to reach the 988 Suicide and Crisis Lifeline at any hour. Most campuses also run a counseling center with after-hours crisis support, and it is worth finding that number before you need it. The rest of the book is about the ordinary weeks, which are where most of the work is done. A chapter that is careful about sleep, respectful of boundaries, honest about mental health, and quick to call for help is not a less loyal chapter. It is a chapter whose loyalty is worth having. Chapter 1: What Belonging Gives and What It Can Cost Consider two first-year students who arrive on the same campus in the same week. The first, a young man from a small town three states away, knows no one. His roommate goes home most weekends. By the fifth week of the semester he is eating dinner alone with his phone, telling his parents things are "fine," and wondering whether he chose the wrong school. The second is a young woman who arrives with a dozen high-school classmates, a crowded social calendar, and a sense that she must be constantly available or be left behind. By the fifth week she is exhausted and anxious, sleeping five hours a night, and saying yes to everything because she is afraid of what saying no might cost. Both might join a fraternity or sorority in the spring. For the first, membership could be the single best decision of his college years: a group of people who expect him at dinner, older members who show him which professors to take, a reason to stay. For the second, it could simply add another layer of obligation to a life already organized around fear of exclusion. Or it could be the place where she finally learns that she can say no and still be loved. Which of these happens depends partly on the students and partly on the chapters they join. That is the starting point for any honest discussion of wellness in Greek life. Membership is not good or bad for health in general. It is a powerful social force, and powerful social forces amplify whatever they are pointed at. The evidence on both sides The need to belong is not a luxury. Psychologists Roy Baumeister and Mark Leary argued in an influential 1995 review that the desire for frequent, positive interactions within stable relationships is a fundamental human motivation, and that its absence is associated with a wide range of negative effects on health and wellbeing. Loneliness among college students is common and persistent. In the 2024–2025 Healthy Minds Study, which surveyed more than 84,000 students at 135 colleges and universities, 52 percent reported high levels of loneliness. That was an improvement from 58 percent in 2022, but it still describes a majority. Fraternities and sororities are, among other things, machines for manufacturing belonging. They give students a defined group, shared rituals, a physical space in many cases, a calendar of events that brings people together without anyone having to organize it from scratch, and an explicit promise that members will look after one another. For students who find it hard to build friendships through classes or residence halls, that structure can be a lifeline. The evidence on outcomes, though imperfect, points in a favorable direction on several measures. A 2014 Gallup survey of more than 30,000 US college graduates, conducted with the National Panhellenic Conference and the North American Interfraternity Conference, found that graduates who had been fraternity or sorority members were more likely than other graduates to be thriving across Gallup's five elements of wellbeing (purpose, social, financial, community, and physical) and more likely to report that they had felt emotionally supported in college. Forty-three percent of members working full time for an employer were engaged at work, compared with 38 percent of other graduates. The same report also acknowledged the serious concerns about hazing, alcohol, and sexual assault in some chapters. More direct evidence on mental health comes from a 2024 report by the Jed Foundation, a national nonprofit focused on the emotional health of teens and young adults. Drawing on data from the Healthy Minds Study, the American College Health Association's National College Health Assessment, and its own survey and concept-mapping research, the report found that fraternity members reported lower rates of depression, anxiety, and serious suicidal thoughts than non-members. In the Healthy Minds data it cited, about 29.8 percent of fraternity members screened positive for depression, compared with 39.1 percent of non-members; 22.5 percent screened positive for anxiety, against 33.2 percent; and 11.8 percent reported serious thoughts of suicide in the past year, compared with 15.5 percent. A 2020 study from the University of Tennessee's Postsecondary Education Research Center, funded by the fraternity industry's own foundation, similarly found that fraternity members reported higher levels of positive mental health. These findings deserve both attention and caution. They are associations, not proof that membership causes better mental health. Students who join are, on average, different from students who do not: they may be more socially confident, more financially secure, or more likely to have been involved in groups in high school. Some of the differences may reflect who joins rather than what joining does. Still, the direction of the evidence is consistent enough that a fair account cannot treat Greek life as simply a hazard to be managed. For many students, it is part of how they stay well. The same body of research that documents benefits also documents risks, and some of them are grave. The most extensive national study of hazing, published in 2008 by Elizabeth Allan and Mary Madden of the University of Maine, surveyed 11,482 students at 53 institutions and conducted more than 300 interviews. It found that 55 percent of students involved in clubs, teams, and organizations had experienced hazing. Among members of social fraternities and sororities, the figure was 73 percent. Hazing is the subject of Chapter 3, but it belongs in any account of what membership can cost. Alcohol is the second major risk. In the 2023 National Survey on Drug Use and Health, 29.3 percent of full-time college students aged 18 to 25 reported binge drinking in the past month. The Jed Foundation report, drawing on National College Health Assessment data, found that between 80 and 87 percent of fraternity and sorority members in the samples it examined reported binge drinking, compared with 64 to 65 percent of non-members. A long-running national study led by Sean Esteban McCabe at the University of Michigan followed high-school seniors into their mid-thirties. Published in 2018 in the Journal of Adolescent Health, it found that men who had lived in a fraternity house for at least one semester had greater odds of binge drinking across young adulthood and higher odds of reporting symptoms of alcohol use disorder at age 35. Women who had lived in sorority houses showed a similar pattern for binge drinking and alcohol use disorder symptoms. Earlier work by the same team found evidence of both selection (heavier drinkers are more likely to join) and socialization (membership is associated with increases in drinking beyond what students brought with them). The Jed Foundation report also found something subtler. Fraternity and sorority members reported greater awareness of campus mental health services than non-members, but while sorority members were more likely to use therapy, fraternity members were not. The benefit of belonging, in other words, did not automatically translate into getting help when help was needed. The report identified shame and secrecy around help-seeking, and norms that equate emotional struggle with weakness, as barriers. There are other costs that rarely make the news. Membership fees and social expectations can place real financial strain on students from lower-income families. The time demands of chapter life, discussed in Chapter 5, can crowd out sleep, study, and paid work. And the experience of rejection during recruitment, discussed in Chapter 2, can be painful in ways that last longer than the few days of the process itself. Why both can be true at once It would be convenient if the benefits and risks belonged to different chapters: good chapters that provide belonging and bad chapters that provide hazing. There is some truth to this. Chapters vary enormously, even within the same national organization on neighboring campuses. But the deeper point is that benefits and risks often come from the same source. Take cohesion. A chapter where members feel intensely bound to one another is a chapter where someone will drive you to the emergency room at 2 a.m., lend you rent money, or sit with you after a breakup. It is also a chapter where members may be reluctant to report wrongdoing for fear of betraying the group, and where the prospect of losing membership feels unbearable. Researchers who study hazing have repeatedly observed that it tends to flourish in groups that prize loyalty and have steep status hierarchies, not in groups that are loosely connected. Take tradition. Traditions give a chapter continuity across generations, and many are genuinely meaningful: rituals that mark commitment, songs, service projects, the passing of symbols from older to younger members. But tradition is also the most common justification for practices that no one would design from scratch. "It's always been done this way" is the sentence that keeps a dangerous practice alive long after everyone involved has privately stopped believing in it. Take shared identity. A strong sense of "we" is protective when it means members look after each other. It becomes risky when it means the chapter's reputation matters more than any one member's safety, or when the group's image, whether as the hardest-partying house or the most polished sorority on campus, creates pressure that individual members struggle to resist. This is why wellness in Greek life cannot be reduced to individual choices, and also why it cannot be reduced to rules imposed from outside. Individual choices happen inside group norms. Rules imposed from outside are followed, evaded, or resented depending on whether they match what members actually value. The most durable improvements come when members themselves decide that the chapter's strengths (loyalty, cohesion, tradition, identity) will be put to work protecting members rather than endangering them. One idea from the research on college drinking helps explain why this is possible. Beginning in the 1980s, researchers including H. Wesley Perkins and Alan Berkowitz found that college students consistently overestimated how much their peers drank and how comfortable their peers were with heavy drinking. Students then adjusted their own behavior toward what they believed was normal. Later studies by Deborah Prentice and Dale Miller at Princeton described a related phenomenon, "pluralistic ignorance," in which most members of a group privately reject a norm but assume that everyone else accepts it, so the norm persists. Hazing research has found the same pattern. Allan and her colleagues have documented that students often believe their peers are more supportive of hazing than they actually are, and that many who participate do so reluctantly while assuming everyone else is enthusiastic. When private discomfort is widespread but invisible, a single member saying out loud what others are thinking can shift the whole room. This book returns to that insight often. It is the reason that the chapter member who quietly leaves a party at midnight, or tells a new member "you don't have to do that," or suggests moving the Thursday meeting so people can sleep, matters more than it might seem. Norms are not fixed facts. They are shared guesses about what other people think, and they change when people provide better information. Different councils, different pressures The costs and benefits of membership do not fall evenly across the fraternity and sorority world, and a book that treated Greek life as one thing would mislead readers in important ways. Large chapters in the North American Interfraternity Conference and the National Panhellenic Conference, especially on campuses where they own or lease houses, tend to be where the most intensive social calendars, the largest parties, and the most formal recruitment processes are found. The research on residential fraternity drinking applies most directly here. So do the time pressures of living where the chapter lives: when your bedroom is upstairs from the chapter room, it is hard to be absent from anything. Organizations in the National Pan-Hellenic Council, the nine historically Black fraternities and sororities often called the "Divine Nine," have a different history and structure. They were founded, beginning in the early twentieth century, partly because Black students were excluded from existing organizations, and they have long emphasized service, scholarship, and lifelong membership through graduate chapters. Chapters on many campuses are small, sometimes only a handful of members, and membership intake rather than open recruitment is the norm. For Black students at predominantly white institutions, these organizations can provide a community of cultural affirmation that is hard to find anywhere else on campus, and that belonging can be protective in ways that general statistics do not capture. At the same time, these organizations have also struggled with hazing. In 1990 the NPHC organizations formally abolished pledging in favor of a membership intake process, yet hazing has persisted underground, and some of the most serious hazing incidents have occurred in small groups operating away from official oversight. Latino, Asian American, and multicultural fraternities and sororities share many of these features: small chapters, strong cultural purpose, and the risk that intense loyalty and secrecy combine in harmful ways. Small chapters face a particular version of the time problem. When a chapter has eight members, every member holds an office, every event needs every person, and the loss of a single member to burnout or academic trouble is felt immediately. Students in these organizations often describe a strong sense of responsibility to the chapter's history and to the graduate members who came before them, which can make stepping back feel like letting down generations of people. None of this changes the central argument. In every kind of organization, the forces that create belonging can also create pressure. But what that pressure looks like, and what protects against it, varies. A wellness practice that works in a 150-member residential chapter may need adapting for a nine-member intake class, and vice versa. Because chapters differ so much, the most useful thing a prospective member can do is gather information about the particular chapter, not the reputation of Greek life in general. Some of this information is now public. Under the Stop Campus Hazing Act, discussed in Chapter 3, colleges must publish a campus hazing transparency report listing student organizations found responsible for hazing violations. Many campuses also post chapter grade-point averages, conduct histories, and accreditation or standards reports from their fraternity and sorority life offices. The rest comes from asking. Prospective members often feel they cannot ask direct questions during recruitment without seeming difficult, but a good chapter should welcome them, and the way a chapter answers is itself informative. Questions worth asking include: How many hours a week do members typically spend on chapter obligations in the first semester, and in later semesters? Which events are mandatory, and what happens if someone misses one? How does the chapter handle a member who is struggling academically or emotionally? Has anyone ever called for medical help at a chapter event, and what happened? What does the new-member period involve, and can I see a schedule? What does membership cost each semester, including dues, social expenses, and apparel? Parents can ask many of the same questions of their student and, where appropriate, of the campus fraternity and sorority life office. They are rarely asked, and they shift the conversation from whether Greek life is good in general to whether this chapter is good for this person. What wellness means here Wellness is a vague word, and it is often used to sell things. In this book it means something specific: the conditions that allow a student to stay physically safe, sleep enough to function, keep up academically, maintain relationships outside the chapter as well as inside it, notice when they are struggling, and get help without fear. It includes the absence of harm (no hazing, no alcohol poisoning, no assault) and the presence of capacity (enough rest, enough time, enough support). A chapter that promotes wellness in this sense is not necessarily a quiet one. It can have a full social calendar, demanding standards, and serious traditions. What distinguishes it is that its demands are designed with members' health in mind, that members can decline without penalty, and that anyone in trouble can ask for help, or have help called for them, without hesitation. The rest of this book describes what that looks like in practice, beginning where every member's experience begins: the process of being chosen. Chapter 2: Recruitment, Intake, and the New-Member Months Almost every member's story in a fraternity or sorority begins with being evaluated. That is worth pausing on, because it shapes much of what follows. Before a student has any rights as a member, any friends in the chapter, or any sense of how things work, they spend days or weeks being assessed by people who hold the power to admit or refuse them. Then, if admitted, most spend another stretch of weeks or months as new members, in a position that is explicitly junior. The psychology of that period, the stress it creates, the patterns it sets, and the vulnerability it produces, explains a great deal about why wellness in Greek life is harder than it looks from the outside. How students come in The processes differ by council and by campus, but three broad patterns cover most students. In National Panhellenic Conference sororities on many campuses, recruitment is highly structured. Potential new members register in advance, often pay a fee, and move through a series of rounds over several days, visiting chapters and gradually narrowing their options while chapters narrow theirs. The process runs on mutual selection: at the end, a matching system pairs students' ranked preferences with chapters' ranked lists. Students are typically assigned a recruitment counselor, an upper-level sorority member who temporarily disaffiliates from her own chapter so she can guide potential new members impartially. On large campuses, primary recruitment can involve thousands of students, long days in formal clothes, and intense emotion, including for the members who spend a week or more before and during it rehearsing, decorating, and talking to hundreds of strangers. Interfraternity Council recruitment is usually less formal. Students attend events, meet members, and may receive bids (formal invitations to join) at any point over a recruitment period, and many chapters recruit continuously throughout the year. The absence of structure has advantages, but it also means less oversight, and events that serve as recruitment can blur into parties. National Pan-Hellenic Council organizations, and many culturally based fraternities and sororities, use a membership intake process instead of open recruitment. Interested students typically attend an informational meeting, submit an application with academic records and letters of recommendation, may be interviewed, and if selected complete a defined education program before initiation. Intake is often less visible and less frequent. Some chapters take a new line only once every year or two. Whatever the format, the experience shares a core feature: a student who wants something very much is being judged, often by people slightly older than themselves, according to criteria that are rarely fully explained. The stress of being chosen Recruitment stress is sometimes dismissed as trivial: it is only a few days, and there are other ways to find friends. But the research on social rejection suggests that it is not trivial at all. In a well-known 2003 study published in Science, Naomi Eisenberger, Matthew Lieberman, and Kipling Williams scanned participants' brains while they played a simple ball-tossing computer game in which other players, apparently, stopped throwing them the ball. Being excluded activated some of the same brain regions associated with the distress of physical pain. Later research has debated the details, but the core observation, that social exclusion hurts in a way that is more than metaphorical, has held up well. Recruitment concentrates that experience. A potential new member may be invited back to fewer chapters than she hoped, may be dropped by the chapter she most wanted, and may compare her results with friends' results in real time on social media. A student going through fraternity rush may attend events for a week and receive no bid while his roommate receives several. Students in intake processes may wait weeks to learn whether they were selected, often without explanation either way. Several features of modern recruitment intensify this stress. The first is visibility. What used to happen privately now often plays out publicly, with students posting outfits, bid-day videos, and reactions. The attention that sorority recruitment at some southern universities has received on social media in recent years has turned what was once a campus ritual into a national spectacle. For students who do not get the outcome they wanted, public visibility adds humiliation to disappointment. The second is timing. Recruitment often happens in the first weeks of a semester, sometimes before classes begin, when students have few other sources of social support on campus. A first-year student who is rejected in week two has not yet had time to build the friendships that would buffer the blow. The third is physical depletion. Formal recruitment can involve very long days, little food, standing for hours, and short nights. Both potential new members and active members working recruitment routinely report exhaustion. Sleep loss, as Chapter 5 describes, amplifies negative emotion and reduces the capacity to regulate it. A disappointment that would be manageable after a good night's sleep can feel devastating after four nights of five hours each. The stress of recruitment is not confined to those being evaluated. Active members working formal recruitment often spend the preceding week in intensive preparation, practicing conversations, songs, and presentations late into the night, and then spend recruitment itself on their feet for twelve hours or more a day, making hundreds of brief conversations sound warm and personal. They then sit through long selection sessions in which the chapter discusses and votes on potential members, sometimes past midnight. These sessions carry their own emotional weight: members may find themselves advocating for a friend's younger sister, disagreeing sharply with chapter sisters, or uncomfortable with the way some candidates are being discussed. Members who have experienced disordered eating, anxiety about appearance, or social anxiety sometimes find that recruitment, with its focus on presentation and first impressions, reactivates those struggles. Chapters that take wellness seriously build rest into the recruitment schedule, make food available and expected, set firm end times for selection sessions, and let members with health concerns take lighter roles without explanation. Intake processes create a different kind of strain. Because intake is less frequent and more selective, interested students may wait a long time for an opportunity and invest heavily in it. The process is often less transparent to outsiders, which can make it harder for students to judge what is legitimate. Some students report informal expectations before any official process begins, such as being seen at events, doing favors for members, or proving interest in ways that are not written down anywhere. National organizations in these councils explicitly prohibit such unofficial "pre-pledging," and a student who encounters it should understand that it is not part of the legitimate process, however common it may be locally. What helps when the answer is no There is no way to make rejection painless, but there are ways to make it less damaging. The most important is to understand what a recruitment outcome is and is not. It is the result of a brief, crowded process in which chapters make quick judgments based on limited information, partly shaped by factors that have nothing to do with the individual: chapter size targets, the number of legacies, a chapter's sense of its own "type," and sometimes luck. It is not a verdict on a person's worth, likability, or future. That is easy to say and hard to believe at 11 p.m. on the night results come out, which is why it helps to hear it before recruitment begins and to decide in advance how you will interpret a disappointing result. The second is to maintain other sources of belonging during recruitment. Students who treat recruitment as the only route to a social life have the most to lose. Keeping up with a club, a team, a job, a faith community, or friends from a residence hall means that a bad result is a setback rather than a catastrophe. The third is to talk to someone. Recruitment counselors exist in part for this reason, and campus counseling centers often see a rise in visits during and after recruitment. There is nothing weak about seeking help to process a painful experience. Parents can help most by listening rather than immediately fixing, and by resisting the temptation to treat the outcome as a family verdict. A parent who was a member of a particular organization can unintentionally add pressure by making clear how much they hoped their child would join it. Finally, students should know that many paths remain open. Many students who are not matched in formal recruitment find a chapter through continuous open bidding later in the year, join a different council's organization, or discover that their social life takes a different shape entirely. Some who were initially disappointed later say it was the best thing that could have happened. For active members, the lesson runs the other way. Chapters make choices that affect people's wellbeing, and they can make those choices with care. That means avoiding cruelty in how potential members are discussed, keeping conversations about potential members off social media, and remembering that the person being evaluated is a nervous eighteen-year-old in her third week of college, not a product. The new-member period and why it matters Once a student accepts a bid or is selected for intake, they enter the new-member period, sometimes still called pledging, though most national organizations have formally abandoned that term. This period typically involves education about the organization's history, values, and rituals; meetings; community service; academic expectations; and social events meant to integrate new members into the chapter. Many national organizations now set limits on its length and specify what it may include. It is also the period of greatest risk, for a simple structural reason. New members are not yet full members. They want very much to be initiated, and they know that others in the chapter will have a say in whether that happens. They are usually younger, newer to campus, and less sure of what is normal. They are, in the language that prevention researchers use, in a position of reduced power, and that asymmetry is precisely what hazing exploits. The national hazing research reviewed in Chapter 3 found that students frequently experienced hazing during this period and rarely identified it as such. Even where there is no hazing, the new-member period can be one of the most demanding stretches of a student's college career. Weekly new-member meetings, study hours, service requirements, chapter events, big-little activities, and informal expectations to "be around" can add up to many hours a week, layered on top of a first- or second-year academic load that the student is still learning to manage. Because new members are eager to show commitment, they rarely push back. Two other features of the new-member period deserve mention. The first is money. New-member fees, initiation fees, dues, required apparel, formal events, and gifts exchanged in big-little traditions can add up quickly, and students from families with fewer resources may feel unable to say that they cannot afford something. Many chapters and national organizations offer payment plans or scholarships, but students have to know to ask, and asking requires a willingness to disclose financial strain to people whose approval they want. Chapters can remove that barrier by publishing full costs in advance and making hardship arrangements confidential and routine. The second is the big-little relationship, in which each new member is paired with an older member who serves as mentor and friend. At its best, this is one of the most valuable features of chapter life: a built-in guide who remembers what it was like to be new and who can answer the questions a new member is embarrassed to ask. At its worst, it becomes a channel for pressure, with the older member passing along expectations that the chapter would never put in writing. A big who asks how classes are going, notices when the little seems tired or withdrawn, and says "you don't have to come tonight" is doing some of the most effective wellness work in the chapter. Table 1 sets out some of the signals that distinguish a healthy new-member program from one that warrants concern. None of the warning signs proves that something is wrong, but each is worth asking about. Table 1. Signals in the new-member period: healthy programs and warning signs. Area Healthy sign Warning sign Schedule Written calendar shared in advance, with end times Last-minute summons; events with no end time Sleep Nothing scheduled late on school nights Late-night or early-morning "mandatory" activities Secrecy Families and advisors can see what the program involves Told not to tell parents, advisors, or other members Status New members treated as members with less experience Separate rules, errands, or demeaning titles for new members Alcohol No alcohol connected to new-member activities Drinking expected at "bonding" events Leaving Clear that a new member may depart without penalty Implied threats, or guilt about "quitting" The first three rows matter especially because they are easy to check. A chapter that runs a healthy program has nothing to hide, and a written schedule with end times is a small but telling sign that someone has thought about members' lives outside the chapter. Secrecy directed at advisors or families is among the most reliable indicators that something is being done that would not survive scrutiny. The new-member period does more than admit people. It teaches them what the chapter expects, and those lessons outlast the period itself. A new member who learns that sleep is optional, that saying no is disloyal, and that problems stay inside the chapter will carry those lessons into active membership and, eventually, into leadership, where they will teach them to the next class. A new member who learns that the chapter plans ahead, respects academic priorities, and wants to know when people are struggling will carry those lessons forward instead. This makes the new-member educator, and the chapter officers who oversee that role, some of the most influential people in the chapter's health. They are not just delivering content. They are setting the norms that the next generation will assume are simply the way things are. For new members themselves, the practical advice is modest but important. Keep a written record of your weekly commitments and actual hours, which makes it easier to see when demands are becoming unreasonable. Protect the academic habits you had before you joined, especially regular study time and sleep. Stay in contact with friends outside the chapter. Learn the name of your campus fraternity and sorority life advisor and your chapter's alumni advisor, so you know whom to contact if something feels wrong. And remember that joining a chapter does not mean giving up the right to decide what you will and will not do. That right is the subject of Chapter 6, but it begins here, in the weeks when it is hardest to exercise. Many students never experience anything worse than a demanding schedule and a lot of new friends. But the new-member period is also where the most dangerous practice in Greek life has historically lived, and it is to that practice that the next chapter turns. Chapter 3: Hazing, Named Plainly On the night of February 2, 2017, Timothy Piazza, a nineteen-year-old sophomore at Penn State, accepted a bid from the Beta Theta Pi chapter. As part of a drinking ritual that members called "the gauntlet," he consumed at least eighteen drinks in about eighty-two minutes. He then fell headfirst down a flight of basement stairs. Over the following hours, as security cameras in the house recorded, he fell repeatedly while members tried to manage the situation themselves. No one called for help until the next morning, roughly twelve hours after the first fall. He died on February 4 of a fractured skull and a lacerated spleen. His father later said that if the members had called for help, the family would not be having the conversation they were having. Timothy Piazza's name is now attached to Pennsylvania's anti-hazing law, passed in 2018, and his parents, along with the families of other students who died in hazing incidents, were among the advocates whose work led Congress to pass the Stop Campus Hazing Act in December 2024. His death is also a case study in almost every theme of this book: an initiation built on alcohol, a group whose loyalty to itself outweighed its care for one person, and a delay in calling for help that turned a medical emergency into a death. Most hazing does not end in death. That is part of why it persists. This chapter describes what hazing is, how common it is, why intelligent people participate in it, what the law now requires, and what students can do when they see it. What counts as hazing, and what the law requires For years, one of the obstacles to preventing hazing was disagreement about what it was. State laws varied, campus policies varied, and students frequently described their own experiences in ways that excluded them from the category. The Stop Campus Hazing Act, signed into law on December 23, 2024, established the first federal definition for the purpose of campus reporting. Under that definition, hazing is any intentional, knowing, or reckless act committed by a person, alone or with others, against another person, regardless of that person's willingness to participate, that is done for the purpose of recruiting, joining, initiating, admitting, affiliating with, or maintaining membership in a student organization, and that causes or creates a risk, above the reasonable risk encountered in the course of participation in the institution or organization, of physical or psychological injury. The law lists examples, including whipping, beating, or striking; causing or requiring sleep deprivation, exposure to the elements, confinement, or extreme physical exertion; compelling someone to consume food, liquid, alcohol, drugs, or other substances; compelling sexual acts; activities that cause reasonable fear of bodily harm through threats; and activities that violate criminal law. Three features of this definition are worth highlighting. First, consent does not make it acceptable. The phrase "regardless of the willingness of such other person" addresses the most common defense of hazing, which is that the new members chose to take part. The law recognizes what research on group pressure has long shown: a person who wants badly to belong, surrounded by people who control whether they will be admitted, is not in a position to give meaningful consent. Second, psychological injury counts. Hazing is not only paddling and forced drinking. Humiliation, degradation, intimidation, and isolation can cause real harm, and the definition includes them. Third, sleep deprivation is named explicitly. This matters for the themes of this book. Keeping new members up all night, calling them out at 3 a.m., or requiring early-morning activities after late-night ones is not an eccentric tradition; it is one of the forms of hazing that federal law now specifically identifies. Researchers at StopHazing, the research and training organization founded by Elizabeth Allan, describe hazing as falling along a spectrum. At one end are intimidation behaviors that are often overlooked, such as deception, silence periods, and demeaning names. In the middle are harassment behaviors that cause emotional or physical discomfort, such as being yelled at, running errands for members, or wearing embarrassing clothing. At the far end are violent behaviors that can cause lasting injury or death, such as forced drinking, beating, and extreme deprivation. The spectrum is useful because it shows that the behaviors at the extreme end are rarely where a group starts. Groups escalate. A chapter that treats demeaning names and servitude as harmless fun has already accepted the premise, that new members may be treated as less than members, on which the more dangerous practices rest. Many real situations fall into gray areas, and it helps to work through a few. Suppose new members are required to attend a 6 a.m. workout three days a week while active members are not. The activity may seem harmless, even healthy, but it applies only to new members, is tied to their admission, and cuts into sleep; under the federal definition it risks becoming hazing, particularly if it follows late-night obligations. Suppose instead that the whole chapter, new and active members alike, signs up together for a charity 5K. That is a shared challenge with a clear purpose and no status distinction. Or consider a scavenger hunt. If it involves visiting campus landmarks and learning chapter history, it is an ordinary team activity. If it requires stealing items, performing embarrassing acts in public, or drinking at each stop, it is hazing. A few questions help sort such cases. Is this activity required only of new members, or would active members do it too? Would the chapter be comfortable if its advisor, national headquarters, or a new member's parents watched it happen? Does it involve alcohol, lost sleep, physical discomfort, secrecy, or humiliation? Would a new member who declined face consequences, formal or informal? Does it serve a purpose connected to the organization's stated values, or does it simply mark new members as lower in status? If the honest answer to any of these is troubling, the activity deserves to be changed. Beyond definitions, the legal landscape has shifted. For most of the history of anti-hazing efforts in the United States, the law was a patchwork of state statutes, most of them passed after a student died. Many states now treat hazing that causes serious injury or death as a felony. Pennsylvania's 2018 law, for example, created tiers of offenses and made hazing that results in bodily injury a felony. The Stop Campus Hazing Act adds a national layer, focused on transparency and prevention rather than criminal penalties. It amends the Clery Act, the federal law requiring colleges that participate in federal student aid programs to disclose crime statistics, which the act also renamed the Jeanne Clery Campus Safety Act. Its main requirements are as follows. Colleges must include statistics on hazing incidents reported to campus security authorities or local police in their annual security reports, with data collection beginning January 1, 2025, and the first annual security reports containing hazing statistics due by October 1, 2026. Colleges must have policies on hazing that describe how to report it, how reports are investigated, and what prevention programs are in place; these were due by June 23, 2025. Prevention programs must be research-informed and campus-wide, and must include primary prevention strategies. Most visibly for students and families, each college must publish a campus hazing transparency report on its website listing student organizations found responsible for hazing violations, with the organization's name, a description of the violation, and relevant dates. The first report was due by December 23, 2025, and the report must be updated at least twice a year. The transparency report is a significant change for prospective members and their families. For the first time, there is a nationally required public record of which organizations on a campus have been found responsible for hazing. It is worth reading before accepting a bid. What the research shows The most comprehensive national data on college hazing come from the study Allan and Mary Madden published in 2008 under the title Hazing in View: College Students at Risk. They surveyed 11,482 undergraduates at 53 colleges and universities and conducted more than 300 interviews with students and staff at 18 of those campuses. Their findings, some of which are summarized in Table 2, remain the most widely cited evidence on the subject. Table 2. Share of students in each group type who reported experiencing hazing behaviors. Group type Experienced hazing behaviors Note Varsity athletics 74% Highest of all groups studied Social fraternities and sororities 73% Drinking games reported by 47% Club sports 64% Often less supervised than varsity All students in clubs, teams, or organizations 55% Across all group types Source: Allan and Madden, Hazing in View (2008). Several other findings from the study matter as much as the prevalence figures. Nine out of ten students who had experienced hazing behaviors in college did not consider themselves to have been hazed. In 95 percent of the cases in which students did identify their experience as hazing, they did not report it to campus officials. In more than half of hazing incidents, a member of the group posted pictures on a public website. In a quarter of cases, alumni were present. A quarter of the time, a coach or advisor was aware. Nearly half of students had experienced hazing before college, in high school teams and groups. And students were more likely to describe positive outcomes of the experience, such as feeling more like part of the group, than negative ones. Taken together, these findings describe a practice that is widespread, frequently public, often known to adults, seldom reported, and usually not recognized by the people it happens to. That combination is what makes hazing so durable. It is not hidden so much as normalized. Later research by Allan, David Kerschner, and colleagues has explored the gap between what students privately believe and what they think their peers believe. Consistent with the research on misperceived norms described in Chapter 1, students often assume others are more accepting of hazing than they are. The researchers have argued that effective prevention must work at many levels at once, from individual knowledge and skills, to group norms, to campus policies and leadership. Their Hazing Prevention Framework, published in 2018, lays out the elements a campus needs: commitment from leadership, capacity to carry out prevention work, cultural competence, assessment, planning, evaluation, sustainability, and the implementation of promising strategies. Why people haze and why people accept it It is tempting to assume that hazing is done by cruel people to naive ones. The research suggests something more uncomfortable: hazing is usually done by ordinary students, many of whom were hazed themselves and some of whom disliked it at the time, to other ordinary students who accept it because they want what the group offers. Several mechanisms help explain this. The first is the psychology of effort. In a classic 1959 experiment, Elliot Aronson and Judson Mills found that people who went through a more severe initiation to join a discussion group later rated the group more favorably than those who went through a mild one. When people suffer for something, they tend to value it more, partly to justify the suffering to themselves. This helps explain why hazed members often defend the practice afterward and why they may later inflict it on others: to question it would be to question the value of what they endured. The second is the belief that hazing builds unity. Members often say that shared hardship bonds a new-member class together. There is something to the idea that shared challenges can build connection, but the evidence that hazing specifically produces cohesion is weak. Research by Aldo Cimino and others has suggested that hazing is often driven more by the status motives of existing members, their desire to establish dominance over newcomers and to ensure that those newcomers are committed, than by any demonstrated effect on group solidarity. Groups build strong bonds in many ways that involve no harm at all. The third is tradition and the cycle it creates. Members who were hazed often feel that the next class should not get off easier than they did. Stopping the practice can feel like a betrayal of what the older members went through. This "cycle of hazing" means that a chapter can continue a practice for decades after most members have privately stopped believing in it. The fourth is diffusion of responsibility. In a group, it is easy for each person to assume that someone else is in charge or that someone else will stop things if they go too far. The Penn State case illustrated this with terrible clarity. Many people were present over many hours. Some expressed concern. No one acted decisively until too late. For the person being hazed, the calculus is also understandable. They want to belong. They have usually already invested time, money, and social identity in the group. They see others enduring the same thing and assume it must be normal. They fear the social cost of leaving or objecting. And, crucially, they often do not have the word for what is happening to them. This is where the finding that nine in ten hazed students do not label their experience as hazing becomes so important. Naming it is the first step toward resisting it. What to do when you see it Knowing what hazing is does not make it easy to respond. A new member who is being hazed may fear losing membership. An active member who objects may fear being ostracized by friends. Chapter 7 addresses bystander intervention in detail, but a few principles belong here. If anyone is in physical danger, the only priority is safety. Call 911. Chapter 4 explains why the fear of getting the chapter in trouble should never delay that call, and how medical amnesty and Good Samaritan policies protect people who seek help. If the situation is not an emergency, there are several routes to report hazing. Campus fraternity and sorority life offices and dean of students offices handle reports, and most campuses now offer online reporting forms that can be submitted anonymously. National fraternity and sorority headquarters take reports directly, and many operate anonymous reporting lines; this is often faster than students expect. Chapter alumni advisors can be approached privately. The Stop Campus Hazing Act requires colleges to publish how reports can be made, so the information should be easy to find. A new member who wants to leave a chapter because of hazing can do so. Membership is voluntary, and departing is always an option, however strongly the group may suggest otherwise. Leaving can be painful, but it is not a failure; it is a judgment that the price was too high. For members who want to change their own chapter's practices, the most effective path is usually to find allies. Because private disapproval of hazing is often more widespread than it appears, a member who raises concerns with two or three trusted friends frequently discovers that they are not alone. A small group that proposes replacing a hazing tradition with a meaningful alternative, such as a challenging service project, a retreat with a real purpose, or a ritual that honors history without degrading anyone, is far more likely to succeed than a lone objector. National organizations and campus staff can often provide support, including training and facilitation, to chapters that want to change. The goal is not a chapter without challenge. Joining something meaningful can and should ask something of people. The goal is a chapter in which the challenge builds members up rather than breaks them down, and in which no one ever has to choose between belonging and safety. Nowhere is that choice more stark than in the moment the next chapter describes: a member in medical danger, and a room full of people deciding whether to call. Chapter 4: Alcohol, Emergencies, and the Call That Matters In most chapters, on most weekends, nothing terrible happens. People drink, some more than they should, and they wake up the next day tired, perhaps embarrassed, perhaps hungover, and otherwise fine. That ordinariness is part of the danger. Because most nights end safely, members come to believe they know how to handle a friend who has had too much: put them to bed, turn them on their side, check on them later. Most of the time, that works. Occasionally it does not, and the difference between those outcomes often comes down to a few minutes and a single decision. This chapter is not a lecture about abstinence. Many college students drink, including many fraternity and sorority members, and some do not, and both groups deserve accurate information. The aim is to describe the risks clearly, explain what alcohol poisoning looks like and what to do about it, and make the case that no chapter rule, no fear of consequences, and no loyalty to the group should ever delay a call for help. The scale of the problem According to the 2023 National Survey on Drug Use and Health, as reported by the National Institute on Alcohol Abuse and Alcoholism, 49.6 percent of full-time college students aged 18 to 25 drank alcohol in the past month, 29.3 percent engaged in binge drinking (defined as five or more drinks on one occasion for men, four or more for women), and 6.8 percent engaged in heavy alcohol use (binge drinking on five or more days in the past month). About 14 percent of full-time college students met the criteria for alcohol use disorder in the past year. The consequences are substantial. NIAAA estimates that 1,519 college students between 18 and 24 die each year from alcohol-related unintentional injuries, including motor vehicle crashes, and that 696,000 students in that age group are assaulted by another student who has been drinking. A majority of sexual assaults in college involve alcohol or other substances. About one in four college students report academic consequences from drinking, such as missing class or falling behind. Chapter 1 described the evidence that fraternity and sorority members, particularly those living in chapter houses, drink more heavily on average than their peers, and that the pattern can persist well beyond college. This is not true of every chapter or every member, and some chapters are entirely substance-free. But the average matters because it describes the environment in which many members make decisions. National organizations have responded with policy. In August 2018, members of the North American Interfraternity Conference voted to prohibit alcohol products above 15 percent alcohol by volume, which in practice means hard liquor, in any chapter facility or at any chapter event unless served by a licensed third-party vendor. The standard took effect for chapters in the United States on September 1, 2019. Many individual fraternities and sororities have gone further, with substance-free housing policies, restrictions on events with alcohol, and requirements for sober monitors. Policies alone do not change behavior, but they signal what the organization considers acceptable and give members who want a safer culture something to point to. How alcohol poisoning happens Understanding the mechanics of alcohol poisoning helps explain why the usual responses are dangerous. A standard drink in the United States contains about 14 grams of pure alcohol. That is roughly 12 ounces of regular beer at about 5 percent alcohol, 5 ounces of wine at about 12 percent, or 1.5 ounces of distilled spirits at about 40 percent. Mixed drinks, punches, and drinks poured at parties frequently contain far more than one standard drink, and people routinely underestimate how much they have consumed. The body can process only a limited amount of alcohol at a time; NIAAA notes that the liver can metabolize roughly one standard drink per hour for many people, and nothing speeds that up. Alcohol consumed quickly continues to be absorbed from the stomach and intestine into the bloodstream after drinking has stopped. This means that a person's blood alcohol concentration can keep rising for some time after their last drink, even while they are asleep. A person who "passed out" may not be sleeping it off; they may be getting worse. At high concentrations, alcohol suppresses the parts of the brain that control basic life-support functions, including breathing, heart rate, body temperature, and the gag reflex. A person can stop breathing, or choke on vomit because the gag reflex no longer works. Rapid drinking, drinking games, and drinking on an empty stomach make these outcomes more likely, which is why so many hazing deaths have involved large amounts of alcohol consumed quickly. Combining alcohol with other depressants, such as opioids, benzodiazepines, or sleep medications, is especially dangerous. Counterfeit pills containing fentanyl have made this risk more acute in recent years, and many campuses now encourage students and chapters to keep naloxone, the medication that reverses opioid overdose, on hand. Alcohol also affects memory and judgment in ways that bear directly on safety. At high blood alcohol levels, many people experience blackouts: periods for which the brain did not form memories, even though the person may have been walking, talking, and appearing to function. Someone in a blackout can seem more capable than they are, which is one reason friends misjudge danger. Blackouts also matter for sexual consent. A person who is incapacitated by alcohol cannot give consent, and a person who is intoxicated may be unable to recognize that another person is incapacitated. Chapters that host events with alcohol carry a particular responsibility here, because the settings they create, with crowded rooms, private upstairs spaces, and a host group that controls the drinks, are settings in which sexual assault is more likely to occur. Drinks left unattended can be tampered with, and students should feel free to pour their own drinks, keep them in hand, and leave with the people they arrived with. Table 3 lists the warning signs of alcohol overdose identified by NIAAA, alongside common responses that do not help. The most important instruction is the simplest: a person does not need to show all of these signs to be in danger. Table 3. Signs of alcohol overdose and responses that do not help. Warning sign What to do What does not work Confusion or stupor; cannot be woken Call 911 immediately Letting them "sleep it off" Vomiting while drowsy or unconscious Turn on side; stay with them Leaving them alone in a room Slow breathing (fewer than 8 per minute) Call 911; monitor breathing Waiting to see if it improves Irregular breathing (10+ seconds between breaths) Call 911; tell responders what was taken Cold showers Seizures Call 911; protect from injury Coffee or "walking it off" Clammy, pale, or bluish skin; low body temperature Call 911; keep warm Giving more food or drink to "absorb" it Source: National Institute on Alcohol Abuse and Alcoholism, "Understanding the Dangers of Alcohol Overdose." While waiting for help, stay with the person. If they are conscious and vomiting, keep them sitting up and leaning forward. If they are unconscious, turn them on their side so that vomit can drain rather than block the airway. Tell emergency responders what the person drank, how much if you know, and anything else they may have taken. Do not try to make them vomit or give them anything by mouth. Why people do not call, and how amnesty helps If the right response is so clear, why do people hesitate? Research at Cornell University in the early 2000s found a striking gap: 19 percent of students surveyed had considered calling for help for an intoxicated peer, but only 4 percent had actually done so. The reasons students gave included uncertainty about whether the situation was serious enough and fear of the consequences. Both reasons are understandable, and both are dangerous. Uncertainty is built into the situation. Friends are rarely trained to judge whether someone's breathing is slow enough to be a problem, and they are often intoxicated themselves. The only safe rule is to resolve uncertainty in favor of calling. An ambulance that turns out not to have been needed is a minor inconvenience; a delay that turns out to have mattered can be permanent. Fear of consequences is especially powerful in chapters. A member who calls for help at a chapter event may worry not only about getting themselves or their friend in trouble but about bringing sanctions on the whole organization: suspension, loss of housing, or the end of a chapter with decades of history. Members may feel enormous pressure, sometimes explicit, to handle things internally. The Penn State case is the most notorious example, but it is far from the only one. In 2004, Lynn Gordon "Gordie" Bailey Jr., an eighteen-year-old first-year student at the University of Colorado, died of alcohol poisoning after a fraternity event. He had been left to "sleep it off." His family later established the Gordie Center, now based at the University of Virginia, which works to prevent hazing and alcohol deaths and teaches students to recognize alcohol poisoning and act. Medical amnesty policies exist to remove the fear of consequences from the decision to call. Their logic is straightforward: if students hesitate to call for help because they fear punishment, then reducing the punishment for calling will increase the number of calls, and more calls will save lives. Cornell University implemented one of the first well-studied medical amnesty protocols in 2002. Under the policy, students who called for help for themselves or a friend in an alcohol emergency would not face formal judicial action for alcohol violations, though they would be expected to meet with health staff afterward. A 2006 evaluation by Deborah Lewis and Timothy Marchell, published in the International Journal of Drug Policy, found that calls for emergency help in alcohol-related situations increased after the policy was introduced, and that the share of students who received follow-up education after such incidents rose substantially, from 22 percent to 52 percent over two years. A 2018 study of a policy change at another university found that medical amnesty did not increase drinking or alcohol-related problems, answering the concern that such policies might encourage risky behavior. Medical amnesty now takes two forms. Campus medical amnesty policies protect students from institutional discipline for alcohol or drug violations when they seek help. State medical amnesty or Good Samaritan laws protect people from certain criminal charges, such as underage possession, when they call for help in an alcohol or drug emergency. According to the Gordie Center, as of 2022, 40 states and the District of Columbia had medical amnesty laws covering alcohol; many states also have Good Samaritan laws covering drug overdoses. There is no federal medical amnesty law. The details of these protections vary, and every member should look up their own campus policy and state law. Some important variations include whether the policy covers only the person who needed help or also the caller and others present; whether it extends to the chapter as an organization; whether it applies to drugs as well as alcohol; and whether it covers other violations, such as hazing or assault, that may have occurred. Many campus policies require the student who received help to complete an educational program or follow-up meeting. Some national fraternities and sororities have adopted their own policies stating that a chapter that calls for help will be treated more leniently than one that does not, and that a chapter that fails to call will face the most serious consequences. That is exactly the right set of incentives. Even where protections are limited or unclear, the answer is the same. Call. No disciplinary consequence is worse than a death, and chapters that have been sanctioned for an incident in which they sought help can recover. Chapters in which a member died because no one called often do not, and neither do the people who were in the room. Building a chapter that calls Individual knowledge is necessary but not sufficient. What makes calling routine is a chapter culture in which calling is expected and praised. Several practices help. Chapters can make "call first" an explicit, repeated standard, stated at the start of each semester and at every event where alcohol may be present, and reinforced by officers who make clear that members who call will be supported, not blamed. Chapters can designate sober monitors at events who have been trained to recognize the signs in Table 3 and who have the authority to call for help without seeking anyone's permission. They can put emergency numbers, the campus medical amnesty policy, and the local non-emergency and campus police numbers somewhere visible in the house. They can make water and food available at every event, avoid drinking games, and ensure that people who do not drink are fully included in social life, which also reduces pressure on those who are drinking less. And after an incident in which someone called for help, chapter leaders can thank the caller publicly, which sends a clearer message than any policy document. Consider how this plays out in a single night. It is 1 a.m. at a chapter party. A junior who has been serving as a sober monitor notices a first-year guest slumped on a couch in a back room. Her friends say she is fine, that she just had too many shots and needs to sleep. The monitor kneels, says the guest's name loudly, and gets only a mumble. Her breathing seems slow, though the monitor is not sure. Two older members wander in and say that if an ambulance comes to the house, the chapter will be on probation for the rest of the year. In that moment, everything depends on whether the monitor believes three things: that she does not need anyone's permission to call, that uncertainty is itself a reason to call, and that her chapter and her campus will stand behind her if she does. If the chapter has spent the semester saying "call first," thanked previous callers, and made sure every monitor knows the medical amnesty policy, she will call. If it has not, she may hesitate, and hesitation is the most dangerous thing in the room. Whatever happens afterward with the chapter's standing, a phone call at 1:04 a.m. is a far better outcome than a phone call at 9 the next morning. For individual members, the guidance is modest and practical. Know what a standard drink is and count them. Eat before and while drinking. Alternate alcoholic and non-alcoholic drinks. Decide in advance how much you intend to drink, and have a friend who will hold you to it. Never leave a drunk friend alone, and never assume that someone who is unconscious is simply asleep. And remember that choosing not to drink, for a night or for good, is a legitimate choice that a healthy chapter will respect. The next chapter turns to the resource that alcohol, late nights, and a crowded calendar all draw down at once: sleep. Chapter 5: Sleep and the Chapter Calendar Ask chapter members what they sacrifice to keep up with everything, and the answer is almost always the same. Not grades, at least not at first. Not friendships inside the chapter, because the chapter is where their friendships are. Not the job, because rent is due. What goes is sleep. It goes quietly, a half-hour here and an hour there, and because the loss is gradual, most people do not notice how much they have given up until they are running on five and a half hours a night and wondering why everything feels harder. Sleep is the most undervalued health resource on a college campus and, for fraternity and sorority members, often the most contested. It is contested not because anyone sets out to deprive members of rest, but because a chapter calendar is built by many hands, each adding something reasonable, and no one is responsible for adding up the total. This chapter makes the case that a chapter's calendar is a health document, whether anyone treats it as one or not, and describes what individuals and chapters can do to protect sleep. What sleep does and what happens without it In 2015 the American Academy of Sleep Medicine and the Sleep Research Society published a joint consensus statement, developed by a panel of experts after reviewing the scientific evidence, recommending that adults sleep seven or more hours per night on a regular basis to promote optimal health. The statement noted that sleeping more than nine hours a night may be appropriate for young adults, for people recovering from sleep debt, and for people with illnesses. Traditional-age college students fall squarely in the young-adult group, and many of them need more than seven hours to feel and function at their best. Most do not get it. In a 2014 review in the journal Nature and Science of Sleep, Shelley Hershner and Ronald Chervin of the University of Michigan reported that about 50 percent of college students experience daytime sleepiness and about 70 percent get insufficient sleep. They documented the consequences: lower grade point averages, greater risk of academic failure, compromised learning, impaired mood, and increased risk of motor vehicle crashes. The connection between sleep and mental health is especially important. Research presented at the 2019 annual meeting of the Associated Professional Sleep Societies, led by researchers at the University of Arizona and drawing on data from more than 110,000 students in the American College Health Association's National College Health Assessment, found that each additional night of insufficient sleep per week was associated with an average increase of more than 20 percent in the likelihood of experiencing mental health symptoms. The associations covered depressed mood, anxiety, hopelessness, anger, functional problems, and thoughts of self-harm and suicide. These are correlations, and poor mental health also disrupts sleep, so the relationship runs in both directions. But the broader experimental literature on sleep deprivation makes clear that insufficient sleep worsens emotional regulation directly. People who are short on sleep react more strongly to negative events and have a harder time calming down afterward. Sleep also matters for learning. During sleep, the brain consolidates memories formed during the day, transferring them into more durable storage. A student who studies until 3 a.m. and sleeps four hours before an exam has given their brain little opportunity to do that work. And sleep matters for safety. Drowsy driving impairs reaction time in ways comparable to alcohol, which is particularly relevant for students driving home from late chapter events, road trips to other campuses, or early-morning philanthropy shifts. Two features of young adult biology make the problem worse. First, the internal body clock tends to shift later during adolescence and early adulthood, so many college students naturally feel alert late at night and struggle to fall asleep early. Second, alcohol, often present on the same nights that run late, disrupts sleep. It may help people fall asleep faster, but it fragments sleep in the second half of the night and suppresses the rapid eye movement stage, so that a night of drinking often produces a night of poor-quality rest even when the hours look adequate. How the calendar eats the night Consider an illustrative week for a sorority member in her second year. Monday has a two-hour chapter meeting that starts at 8 p.m. and often runs until 10:30. Tuesday is a committee meeting and a study-hours requirement at the house. Wednesday is a sisterhood event. Thursday is the night most of the social life happens, and although it is not mandatory, her friends will all be there. Friday has a mixer with a fraternity. Saturday is a philanthropy event beginning at 8 a.m. Sunday is when she catches up on the week's coursework, and her big has asked her to brunch. Scattered through all of this are group chats that start buzzing after 10 p.m., when everyone is finally free, and continue until well past midnight. None of these commitments is unreasonable on its own. Each was scheduled by someone trying to do something good: to run the chapter, support academics, build friendships, raise money for a cause. But together they leave very few nights on which she can be in bed by midnight, and several on which getting seven hours before an early class is impossible. Many chapters also use points or attendance systems to encourage participation, in which members earn credit for attending events and face consequences, such as fines or restrictions on social privileges, if they fall short. These systems exist for understandable reasons. A chapter with low attendance cannot function, and officers who plan events want people to come. But points systems can quietly convert optional events into obligatory ones, and they tend to reward the members with the most free time, not necessarily the most committed ones. Members who work paid jobs, have demanding majors, care for family members, or manage health conditions are the ones most likely to be squeezed. Officers are especially vulnerable. Chapter presidents, recruitment chairs, and treasurers often describe their roles as consuming the equivalent of a part-time job, with meetings, emails, and crises arriving at any hour. They are also the people least likely to complain, because complaining feels like admitting they cannot handle the role they asked for. Table 4 sets out some common calendar practices, how they affect sleep, and alternatives that serve the same purpose with less cost. Table 4. Chapter calendar practices, their effect on sleep, and alternatives. Common practice Effect on sleep Alternative Weeknight meetings that start at 8 or 9 p.m. with no end time Pushes bedtime past midnight Earlier start; firm 90-minute limit; written agenda Early-morning events after late-night ones Cuts sleep from both ends At least ten hours between scheduled activities Group chat traffic late at night Delays sleep; wakes people Quiet hours for chapter channels; scheduled messages Points systems that reward sheer attendance Makes optional events feel mandatory Fewer, better events; flexible ways to meet expectations Heavy programming during exam periods Competes with study and sleep Protected exam weeks with no required events Officers on call at all hours Chronic sleep loss for leaders Shared duties; clear off-hours; a backup contact The alternatives are not radical. A chapter meeting that starts at 7 p.m. and ends at 8:30 accomplishes the same business as one that runs from 8:30 to 11. A group chat can have quiet hours. An exam week can be kept free of required events. What makes these changes hard is not their difficulty but the fact that no one is responsible for making them. The chapter calendar rarely has an owner who asks, "Taken together, what does this week cost our members?" Protecting your own sleep Individual members cannot redesign the chapter calendar alone, but they have more control than they often assume. The first step is to see the week clearly. A simple exercise helps: take a typical week and write down every commitment, including class, study, work, chapter obligations, and travel, alongside the time you actually went to sleep and woke up. Many students are surprised by what they find. The point is not to feel guilty but to have accurate information. It is much easier to decide what to change when you can see where the hours go. The second is to decide on a sleep floor, the minimum number of hours you will protect on most nights, and treat it as a commitment rather than a leftover. A student who decides that, five nights a week, she will be in bed by 12:30 a.m. with the phone on silent, has something concrete to protect when the invitations arrive. Chapter 6 describes how to decline gracefully, but the decision about what to protect comes first. The third is to keep a consistent wake time. Sleep researchers generally advise that waking at roughly the same time each day, including weekends, helps stabilize the body clock and makes it easier to fall asleep at night. Sleeping until noon on Saturday after a late Friday feels restorative but can make Sunday night's sleep harder and Monday morning worse. The fourth is to manage the phone. Notifications from active group chats are among the most common reasons students give for delayed or interrupted sleep. Muting chapter channels after a set hour, keeping the phone out of reach of the bed, and letting close friends know that you will reply in the morning are small changes with outsized effects. The fifth concerns caffeine and alcohol. Caffeine remains active in the body for many hours, so an afternoon energy drink can still be interfering with sleep at midnight. Mixing caffeine with alcohol is particularly risky because the stimulant can mask how intoxicated a person feels. And, as noted above, alcohol may knock you out but will not give you good sleep. Finally, if you live in a chapter house, the environment matters. Houses can be loud late at night, and sharing a room with someone on a different schedule is difficult. Earplugs, an eye mask, and an honest conversation with roommates about quiet hours are worth more than any sleep-tracking app. Houses can adopt quiet hours policies, especially during exam periods, and residents can ask house managers to enforce them. Return to the illustrative second-year member whose week opened this section, and consider what a realistic repair might look like. She cannot skip chapter meeting, and she does not want to. But she can ask the chapter president whether meetings could start at 7:30 rather than 8, and in the meantime she can go straight to bed afterward rather than joining the hour of conversation in the kitchen that usually follows. She can do her Tuesday study hours in the morning at the library, which the chapter's academic chair agrees counts just as well, freeing the evening. She can go to Wednesday's sisterhood event and leave when it officially ends. She can decide that Thursday is a night she will go out, and plan for it by scheduling nothing before 11 a.m. on Friday; or she can decide that this particular Thursday, with a problem set due Friday morning, she will stay in, and tell her friends she will see them at the mixer. She can go to the Saturday philanthropy event and decline the Friday mixer, or go to the mixer and leave by midnight. She can mute the chapter group chat at 11 p.m. and tell her big that she will answer in the morning. None of these choices requires her to love the chapter less or participate less in what matters to her. What they require is a clear view of the week, a decision about what she will protect, and the confidence to act on it. By the end of such a week, she might have gained six or seven hours of sleep without missing anything she truly cared about. That is roughly an extra night, recovered from the gaps between obligations. A word about naps, which many students use to compensate for short nights. A short nap of twenty to thirty minutes in the early afternoon can improve alertness without much effect on nighttime sleep. Long naps, or naps late in the day, can make it harder to fall asleep at night and start a cycle in which the student is awake at 2 a.m. and exhausted at 10 a.m. Naps are a patch, not a substitute for adequate nighttime sleep. If sleep problems persist despite these steps, including trouble falling or staying asleep most nights for several weeks, loud snoring or gasping, or excessive daytime sleepiness even after enough hours in bed, it is worth talking to campus health services. Insomnia is highly treatable, and the first-line treatment recommended by major medical organizations, cognitive behavioral therapy for insomnia, is available on many campuses. Making sleep a chapter value The changes that matter most happen at the chapter level, and they begin when someone decides to treat sleep as a legitimate concern rather than a personal failing. A chapter can review its calendar at the start of each term with sleep in mind, asking of each recurring event whether it needs to happen that often, that late, or at all. It can adopt a few standing rules: no required events after 10 p.m. on school nights, a firm end time for chapter meetings, a minimum gap between late-night and early-morning obligations, and quiet hours on chapter communication channels. It can make exam periods genuinely protected. It can distribute officer responsibilities more evenly so that no one person is on call all the time. And it can audit its points or attendance system, asking whether it is rewarding commitment or simply rewarding free time. The new-member period deserves particular attention. As Chapter 3 noted, the Stop Campus Hazing Act specifically lists sleep deprivation among the behaviors that can constitute hazing. A new-member program that routinely keeps new members up late or wakes them early is not just unkind; it may be unlawful under federal reporting rules and campus policy. A chapter that wants to demonstrate its commitment to new members' wellbeing can start with a simple promise: nothing scheduled for new members after 10 p.m. or before 8 a.m. Leaders set the tone here as elsewhere. A chapter president who says at the first meeting of the semester, "I go to bed by midnight on weeknights, and I don't answer chapter messages after 11," gives every member permission to do the same. A president who is visibly exhausted and answers messages at 3 a.m. teaches the opposite lesson, however often they tell members to take care of themselves. Protecting sleep is sometimes dismissed as soft, a lesser concern next to hazing and alcohol poisoning. But the three are connected. Sleep-deprived students are more emotionally volatile, more susceptible to peer pressure, worse at judging risk, and more likely to rely on alcohol and caffeine to get through the week. A well-rested chapter is a safer chapter. It is also, not incidentally, a chapter whose members have the energy to enjoy one another. That is what the calendar is supposed to be for. Chapter 6: Boundaries and the Art of Saying No Every chapter of this book so far has come back to a single capacity: the ability to decline. The new member who can say no to an activity that feels wrong, the guest who can say no to another round of shots, the member who can say no to a 10 p.m. event before an 8 a.m. exam, the officer who can say no to one more responsibility. In each case, the skill is simple to describe and difficult to practice, because the person saying no wants very much to stay in good standing with the people they are saying it to. This chapter is about that skill. It treats boundaries not as walls that keep people out but as the conditions under which a person can stay in a community for the long run without losing themselves. Members who cannot set boundaries tend to burn out, pull away abruptly, or quietly resent the chapter. Members who can set them tend to stay, and to stay well. What a boundary is A boundary is a decision about what you will and will not do, give, or accept. It is not a rule you impose on others; you cannot control what other people ask of you. It is a rule about your own response. "My chapter should not schedule meetings so late" is a request, and a reasonable one. "I leave chapter meetings at 10 on weeknights" is a boundary. Boundaries in chapter life tend to fall into a few categories. Time boundaries concern how many hours you give, when, and to what. Physical and substance boundaries concern alcohol, drugs, physical activity, and bodily safety. Financial boundaries concern what you spend on dues, events, clothes, trips, and gifts. Emotional boundaries concern how much of others' distress you take on and how much of your own you share. Digital boundaries concern when you are reachable and what you post or allow to be posted about you. And academic boundaries concern the study time you protect, whatever else is happening. The most important thing about boundaries is that they work best when decided in advance. In the moment, standing in a crowded room with friends urging you to stay, it is very hard to reason clearly about what you want. Social pressure, fatigue, alcohol, and the desire to be liked all push toward yes. A boundary decided on a calm Sunday afternoon, when you can think about your week and your priorities, is much easier to hold at midnight on Thursday. Research on goal pursuit supports this. The psychologist Peter Gollwitzer and his colleagues have studied what they call implementation intentions: specific if-then plans that link a situation to a response, such as "If someone offers me a drink after my second, then I'll ask for water." A 2006 meta-analysis by Gollwitzer and Paschal Sheeran, drawing together results from many studies, found that forming such plans had a meaningful positive effect on whether people actually achieved their goals. The mechanism is intuitive. When the situation arises, the response has already been chosen, so there is no need to deliberate under pressure. Why saying no feels so hard Most students overestimate the social cost of declining. Several lines of research help explain why. The first is what the psychologists Thomas Gilovich, Victoria Medvec, and Kenneth Savitsky called the spotlight effect. In a set of studies published in 2000, they found that people consistently overestimate how much others notice their appearance and behavior. A student who leaves a party early may imagine that everyone registers the departure and judges it. In practice, most people are absorbed in their own experience and barely notice. The second concerns the person making the request. Research by Vanessa Bohns and her colleagues has found that people who ask others for things tend to underestimate how hard it is for the other person to say no. In other words, the older member who casually asks a new member to drive her across town at midnight probably does not realize how much pressure the request carries. That is not an excuse for the request, but it does mean that a polite refusal is less likely to surprise or offend the asker than the refuser fears. The asker often never imagined that the request was difficult to decline. The third is the misperceived norms problem described in Chapter 1. Members often believe that their peers are more enthusiastic about late nights, heavy drinking, and constant availability than those peers actually are. The person who says no first frequently gives others permission to do the same. None of this means saying no carries no cost. Sometimes it does. A member who consistently declines social events may be seen as less engaged. A new member who objects to an activity may face real hostility. But the cost is usually smaller than feared, and it has to be weighed against the cost of saying yes: lost sleep, lower grades, compromised safety, and the slow erosion of a person's sense that their own judgment matters. How to say it Declining well is a skill, and like any skill it improves with practice. A few principles help. Keep it short. The instinct when saying no is to explain at length, in the hope that a good enough reason will make the refusal acceptable. But long explanations invite negotiation. "I can't tonight, I've got an exam tomorrow" is enough. So is "I'm heading home, see you Saturday." You do not owe anyone a detailed justification for protecting your sleep, health, or safety. Be warm and clear at once. Warmth and firmness are not opposites. "I love that you guys are going, and I'm going to sit this one out" communicates both affection and a decision. What undermines a boundary is vagueness: "I'll probably come by later" when you do not intend to, which leaves the door open for follow-up pressure. Offer an alternative when you mean it. "I can't make brunch, but can we get coffee Tuesday?" preserves the relationship without abandoning the boundary. Only offer it if you mean it, because an alternative you do not follow through on becomes its own source of stress. Use the language of habit rather than exception. "I don't drink on weeknights" is more stable than "I don't feel like drinking tonight," because it describes who you are rather than a passing mood, and people are less likely to argue with it. The same applies to "I'm in bed by midnight during the week," "I don't do anything before my 9 a.m. lab," and "I don't post photos of other people without asking." Repeat without escalating. If someone presses, the most effective response is often to repeat the same boundary calmly, perhaps with slightly different words, without adding new justifications or becoming defensive. "Honestly, I'm good. I'm heading out." Most people stop pressing after the second or third calm repetition. Some situations call for specific approaches. Declining alcohol at a social event is easier with a drink in hand, even a non-alcoholic one, because it removes the most common prompt ("Why aren't you drinking?"). A simple, habitual answer ("I'm good for tonight," "I'm driving," "I've got an early morning") is usually sufficient. A friend who knows your plan in advance can back you up. Declining a request from an older member, a big, or an officer is harder because of the difference in status. It helps to address the request, not the relationship: "I can't do that tonight, but I'd really like to help with the event next week." If an older member makes a request that seems inappropriate, such as running personal errands, performing tasks only new members are asked to do, or anything involving alcohol, secrecy, or humiliation, the new member has every right to decline, and the request is itself something a chapter officer or advisor should know about. Declining a leadership role is sometimes the healthiest decision a member can make. Chapters often pressure capable, reliable members to take on more and more, precisely because they are capable and reliable. A member who is already stretched can say, "I'm honored you asked, and I need to focus on my classes this semester. Can I help in a smaller way?" Chapters that respect such answers are more likely to have members willing to take on roles in future semesters. Declining an activity that may be hazing is the hardest case, and it is discussed further in Chapter 7. A new member can say, "I'm not comfortable with this, and I'm not going to do it," and then leave if necessary. Afterward, contacting a trusted older member, the chapter advisor, the campus fraternity and sorority life office, or the national organization is not disloyalty. It is exactly what those people are there for. Financial boundaries are among the least discussed and most stressful. Beyond dues, chapter life can involve a steady stream of smaller costs: themed outfits for events, formals and date parties, trips, big-little gifts, charity fundraisers where members are expected to contribute, and meals out with friends who have more money. Students from families with fewer resources often absorb these costs silently, working extra shifts or taking on credit card debt rather than admitting that they cannot keep up. A clear boundary, such as a monthly amount set aside for chapter-related spending beyond dues, is easier to hold if it is decided in advance and treated as fixed. Declining can be simple: "That's outside my budget this month, but I'll be at the next one." Chapters can help by keeping optional costs genuinely optional, providing affordable or free alternatives, and making it easy to raise financial hardship privately with the treasurer or the national organization. A member should never have to choose between chapter participation and rent. Digital boundaries concern both availability and visibility. On availability, the chapter group chat can create an expectation that members respond at any hour, and the pressure to keep up can be constant. Muting channels, setting notification schedules, and telling close friends when you will and will not reply are all legitimate. On visibility, members have a right to decide what images of them are posted and where. Photos taken at parties, especially of people who are intoxicated, can follow a person for years, and the hazing research described in Chapter 3 found that images from hazing incidents frequently end up online. "Please don't post that one" should be enough, and a chapter norm of asking before posting photos of others protects everyone. Some members have boundaries rooted in identity or health that others may not know about. A member in recovery from a substance use disorder, a member whose faith prohibits alcohol, a member managing an eating disorder, a diabetic member, or a member taking medication that interacts with alcohol all have reasons to decline that are nobody else's business. They should not have to explain, and a healthy chapter will not ask. Many campuses now operate collegiate recovery programs that offer community and support for students in recovery, and some students find that these programs complement chapter membership well. Chapters can make these members' lives easier simply by planning events where not drinking is unremarkable. Consider how these principles might come together across one ordinary weekend for an illustrative first-year fraternity member. On Friday afternoon he looks at his calendar and makes three decisions: he will go to the Friday party and leave by 1 a.m. with the friend he is walking home with; he will not drink more than three drinks; and he will be at Saturday's philanthropy car wash at 10 a.m. At the party, an older member hands him a fourth drink and he says, "I'm good, thanks, I'm on the car wash tomorrow," and takes a water instead. The older member shrugs and moves on, which is what usually happens. At 12:45 his friends want to go to another party. He says, "I'm heading back, have fun," and leaves. On Saturday, his big asks whether he can help move furniture into the house on Sunday morning. He has an essay due Monday, and he says, "Sunday morning's my writing block, but I can do Sunday at four." His big says fine. None of these exchanges took more than a few seconds, and none cost him anything with the people involved. What made them possible was that he had decided in advance what mattered to him that weekend. Emotional boundaries and supporting others One of the gifts of chapter life is that members look after one another. That can also become a burden. A member who is known as a good listener may find that friends bring every crisis to her, including serious ones involving depression, self-harm, eating disorders, or trauma, sometimes late at night and often in confidence. She may feel that she cannot step back without abandoning someone who needs her. Supporting friends is good. But no student is equipped to be another student's only source of help in a serious mental health crisis, and trying to fill that role can harm both people. The supporter can become exhausted, anxious, and depressed. The friend in crisis may not get the professional help they need, because they have someone to talk to and so never reach out further. A healthy emotional boundary in this situation does not mean withdrawing support. It means supporting the friend in getting additional help: "I'm really glad you told me, and I want to keep being here for you. I also think you deserve more support than I can give. Can we look at the counseling center together?" It means knowing that if a friend talks about wanting to die or has a plan to hurt themselves, the right response is to involve others immediately, including calling or texting 988, contacting campus counseling crisis lines, or calling 911 if the danger is immediate, even if the friend asked for secrecy. Keeping a friend alive matters more than keeping a promise. It also means recognizing when your own reserves are low and saying so. "I want to help, and I'm really wiped out tonight. Can we talk tomorrow? If things get worse before then, please call 988 or the counseling center's crisis line." Chapter 8 describes how chapters can structure mental health support so that it does not fall on a few informal caregivers. When the boundary is the chapter itself For some members, the question eventually becomes whether to stay in the chapter at all. This is a legitimate question, and it deserves to be asked without shame. People join organizations at eighteen or nineteen based on limited information, and they change. The chapter may change too. A member who finds that membership consistently costs more than it gives, in health, grades, money, or integrity, is entitled to reconsider. There are often options short of leaving entirely. Some organizations allow members to take a temporary leave, reduce their involvement during a difficult semester, or change membership status for reasons such as study abroad, financial hardship, or health. The details vary widely by organization, and members should ask their chapter officers, advisors, or national headquarters what is available. For others, leaving is the right choice. Members who resign should understand that their national organization's rules govern that process, including any financial obligations, and they can ask the campus fraternity and sorority life office for help navigating it. Leaving can be painful, especially when a member's closest friends remain in the chapter. But friendships that are real usually survive the change. A member who leaves a chapter because it was harming them has not failed at belonging. They have made a judgment about their own wellbeing, which is precisely the capacity this chapter has been about. For members who stay, the goal is a relationship with the chapter that is sustainable: one in which they give generously, receive support in return, and can decline when they need to without fearing that their place is at risk. That kind of membership does not happen by accident. It depends on individuals who know their limits and on chapters that honor them. It also depends on members being willing to act when someone else's safety is at stake, which is where the next chapter turns. Chapter 7: Stepping In When It Is Your Own Chapter Most bystander intervention training begins with strangers. A person is harassed on a train, a stranger collapses on the sidewalk, someone at a bar is being steered toward the door by a man she does not seem to know. The question is whether onlookers will act, and the research on that question is substantial and, on the whole, encouraging. Chapter life poses a harder version of the problem. The people whose behavior you might need to interrupt are not strangers. They are your friends, your big, the chapter president, the older members whose approval you want, and the alumni who will be at homecoming. The people who might need your help are also people you know. And the situations are rarely as clear as a collapse on the sidewalk. They are a drinking game that is getting out of hand, a new-member activity that seems a bit much, a comment about a woman at the party that is not quite a threat, a friend who has been saying worrying things in the group chat. Stepping in means risking relationships you care about, often in a room where everyone else seems to think things are fine. This chapter explains why people do and do not intervene, what makes intervention more likely, and how to do it in ways that are effective and, as far as possible, preserve relationships. Its central claim is that intervention inside a chapter is less about individual heroism than about preparation and permission: members who have practiced what they would say, in chapters that have explicitly decided that stepping in is what members do. Why bystanders hesitate The modern study of bystander behavior began with the psychologists Bibb Latané and John Darley in the late 1960s. In a series of experiments, they found that people were less likely to help, or slower to help, when other people were present. In one well-known study, participants filling out questionnaires in a room that began to fill with smoke were much slower to report it when they were sitting with others who did not react than when they were alone. Latané and Darley proposed that intervention requires a person to pass through a series of steps, and that the presence of others can derail any of them. First, the bystander must notice that something is happening. In a loud, crowded party, or when a person is focused on their own conversation, this is not guaranteed. Second, the bystander must interpret the situation as one that requires action. Here, other people's reactions matter enormously. If everyone else seems calm, a bystander may conclude that there is no problem, even if privately worried. Each person looks to the others for cues, and if everyone is doing the same, the group collectively concludes that nothing is wrong. This is the same mechanism of pluralistic ignorance described in Chapter 1. Third, the bystander must decide that it is their responsibility to act. In a group, responsibility is diffused: everyone assumes someone else, perhaps someone older, more senior, or closer to the person, will handle it. Fourth, the bystander must know how to help. A person who does not know what to say to a friend who is being pressured, or does not recognize the signs of alcohol poisoning, may freeze even if they want to act. Fifth, the bystander must actually act, which means overcoming the fear of embarrassment, of being wrong, of social consequences, or of physical danger. Every one of these steps is harder in a chapter setting than in a stranger setting. Noticing is harder because chapter events are often loud, crowded, and involve alcohol. Interpreting is harder because what looks alarming to an outsider may be framed as tradition or fun by people you trust. Taking responsibility is harder because there is almost always someone more senior present. Knowing how to help is harder because the usual advice, "tell someone in charge," does not work when the person in charge is part of the problem. And acting is harder because the social cost of being wrong, or even of being right, falls on relationships you will live with every day. It would be easy to conclude from this that bystanders rarely act. But more recent research offers a more hopeful picture. A 2020 study published in American Psychologist, led by Richard Philpot with colleagues including Mark Levine, analyzed real-life public conflicts captured by surveillance cameras in Lancaster in the United Kingdom, Amsterdam, and Cape Town. In nine out of ten of those conflicts, at least one bystander intervened, and the likelihood that someone would intervene increased as the number of bystanders grew. Earlier work by Levine and colleagues found that shared identity mattered too: in one study, soccer fans were more likely to help an injured stranger wearing their own team's shirt than one wearing a rival team's or a plain shirt. These findings suggest that the problem is not that people are unwilling to help, but that the conditions for helping have to be right. The second finding is especially relevant to chapter life. Shared identity increases helping. Fraternity and sorority members share an intense identity. The question is whether that identity has been defined to include looking out for one another in ways that sometimes mean confronting one another. The ways to step in Most bystander training programs used on college campuses teach a small set of intervention options, often summarized as the "Ds." The Green Dot program and others commonly teach three: direct, distract, and delegate. Some add delay (checking in afterward) and document (recording what happened, when it is safe and useful). The value of having several options is that no one has to choose between a dramatic confrontation and doing nothing. There is almost always something in between. Direct intervention means addressing the situation head-on. "Hey, he's done. No more drinks for him." "That's not okay, stop." "We're not doing this to the new members." Direct intervention is often the most effective when the bystander has status in the group and the situation is not physically dangerous to the intervener. It can also be the hardest, because it puts the bystander in open disagreement with others. Distraction means interrupting a situation without confronting it. A member who notices a friend being cornered by someone at a party can walk up and say, "There you are, I need you for a second," and take the friend away. A member who sees a drinking game escalating can announce that the pizza is here or put on music that changes the room's energy. Distraction works because it changes the dynamics without requiring anyone to admit that anything was wrong, which makes it especially useful when direct confrontation would be socially costly or unsafe. Delegation means getting someone else involved, usually someone with more authority or capacity. In a chapter, that might be a sober monitor, a chapter officer, a house director, the chapter advisor, campus police, or emergency services. Delegation is not a lesser form of intervention. In a medical emergency, calling 911 is the most important intervention there is. In a hazing situation, contacting an advisor or the national organization may be more effective than confronting the members directly. Delaying means acting after the fact: checking in with the person who was targeted, asking if they are okay, offering support, and helping them decide what to do next. It matters because not every situation can be interrupted in the moment, and because people who have been harmed often feel most alone afterward. Documenting means recording what happened, when doing so is safe, will not further harm the person targeted, and is done to support them rather than to shame them. A written note of dates, times, and what was said can later help a person who decides to report. The best choice depends on the situation, the bystander's relationship to the people involved, and safety. There is no single right answer, and the choice to delegate or distract rather than confront directly is not cowardice. It is often good judgment. Chapter situations and what stepping in looks like The general principles become more useful when applied to specific situations members are likely to face. When a member or guest is dangerously intoxicated, the relevant intervention is primarily medical, and Chapter 4 describes it in detail. The bystander's job is to recognize the signs, stay with the person, and call for help without seeking permission. If others in the room resist calling, the bystander can say, "I'm calling. If it turns out to be nothing, that's fine," and do so. Nothing about chapter reputation or policy justifies waiting. When a new-member activity appears to be crossing into hazing, the bystander's options depend on their position. An active member who sees something wrong can often intervene directly, especially if they recruit one or two others first: "Hey, let's wrap this up. This isn't what we're about." An active member who feels unable to intervene in the moment can delegate afterward by speaking with the chapter president, the new-member educator, or the chapter advisor, or by reporting to the campus or national organization. A new member who is being hazed is a bystander as well as a target, and can speak up for fellow new members, which is often easier than speaking up for oneself: "I don't think he's okay. He needs to stop." The most effective intervention against hazing often happens long before any activity takes place, in the meeting where the new-member program is planned. A member who says, at that meeting, "Why are we doing this? What's it for? Is there another way to get the same result?" can stop a practice before it starts. This kind of upstream intervention is less dramatic than stepping into a hazing event, but it is also less risky and often more successful, because it gives others the chance to agree without having to back down publicly. When a sexual assault may be about to happen, for instance when someone who is clearly intoxicated is being led away from a party, or when a member is pressuring a guest who seems uncomfortable, distraction and direct intervention are both useful. A bystander can approach the person being targeted and check in: "Hey, are you okay? Your friends are looking for you." They can get the person's friends involved. They can tell the other person directly that the target is too drunk to be making decisions. They can involve a sober monitor or chapter officer. And if the situation seems dangerous, they can call campus police. Chapters that host events have a particular obligation here, because the host group controls the space. When a member is struggling with their mental health, the intervention is different in kind. It usually means noticing changes, such as withdrawal, missed events, changes in mood, talk of hopelessness, or giving away belongings, and then having a private, caring conversation. "I've noticed you haven't been around much, and you seem really down. I care about you. How are you doing, really?" If the person indicates that they are thinking about suicide, the most important thing is to ask directly, stay with them, and connect them with help. Asking about suicide does not put the idea in someone's head; that concern is a common myth. Programs such as QPR (Question, Persuade, Refer) teach exactly this sequence and are offered on many campuses. The 988 Suicide and Crisis Lifeline, reached by calling or texting 988 in the United States, can help both the person in crisis and a friend who is trying to support them. If the danger is immediate, call 911. When a member makes a racist, sexist, homophobic, or otherwise demeaning comment, the stakes may seem lower, but the pattern of intervention is similar. A direct response can be brief: "Not cool, man." "We don't talk like that here." A distraction can change the subject. A delayed response can be a private conversation later, or checking in with anyone who was hurt by the comment. These moments matter for the chapter's broader culture, because they show members what is tolerated, and a chapter in which demeaning comments pass without challenge is usually one in which more serious harms can go unchallenged too. Making intervention a chapter norm Individual members can learn to intervene, but the most powerful changes happen when the chapter as a whole decides that stepping in is what members do. That decision has to be explicit, repeated, and backed by leaders. The first step is to name it. A chapter that says, at the start of each term and at every event, "In this chapter, if you see something wrong, you step in, and you'll have our full support when you do," changes the third step of Latané and Darley's model for every member. Responsibility is no longer diffused; it is assigned to everyone. The second step is to train. Many campuses offer bystander intervention workshops for student organizations, and many national fraternities and sororities require or provide them. Programs such as Step UP!, Green Dot, and others teach the steps described above and give participants practice. Practice matters. A member who has actually said, "Hey, he's done, no more for him," in a role-play is far more likely to say it at a real party than one who has only heard that it is a good idea. The third step is to prepare specific plans. Chapters can decide in advance who will serve as sober monitors at events and what authority they have, what the process is for calling for medical help, whom members should contact if they are worried about hazing, and how members can raise concerns about a brother or sister's mental health. Plans remove the need to improvise under pressure. The fourth step is to honor intervention after the fact. When a member steps in, calls for help, or raises a concern about a tradition, the chapter's response determines whether anyone will do it again. A chapter that thanks and protects the intervener sends a clear signal. A chapter that blames them for bringing trouble, even implicitly, ensures that the next person will stay silent. Chapters and individuals also need to take the intervener's own safety seriously. Stepping in should never mean putting oneself in physical danger. If a situation involves violence, weapons, or a group that is out of control, the right intervention is to get to safety and call for help. Members who report hazing or other misconduct sometimes fear retaliation from the people they reported. Most campus conduct codes explicitly prohibit retaliation against people who report in good faith, and federal law prohibits retaliation in matters covered by Title IX, such as sexual harassment and assault. A member who experiences retaliation, whether exclusion, threats, or harassment, should document it and tell the campus office that received the original report. Retaliation is itself a violation, and in many cases it is taken as seriously as the original conduct. It also helps to remember that intervention does not have to succeed perfectly to matter. A member who says "that's not cool" and is laughed at has still told everyone in the room that at least one person disagrees, and research on norms suggests that others who were privately uncomfortable will have noticed. The first objection is often the hardest. The second person to object usually finds it much easier, because the first has already broken the illusion that everyone agrees. Finally, chapters can harness the identity that makes intervention hard. The same loyalty that makes members reluctant to confront one another can be redirected: "We look out for each other. That's what brotherhood means. That's what sisterhood means." Framed this way, stepping in is not a betrayal of the chapter's values but the most direct expression of them. The next chapter describes how leaders can build that framing into everything the chapter does, starting with the way it handles the mental health of its members. Chapter 8: Leading a Chapter Toward Mental Health A chapter president has an unusual amount of influence over the wellbeing of other people. At twenty or twenty-one years old, often with little training, she presides over an organization of dozens or hundreds of members, many of whom live together, socialize together, and look to her for cues about what matters. She controls, directly or indirectly, the calendar, the agenda, the tone of meetings, the treatment of new members, and the chapter's response to crises. She will serve for a year, perhaps less, and then hand the whole thing to someone else. This chapter is written for people in that position and for those who advise them: chapter officers, wellness and risk-management chairs, new-member educators, alumni advisors, campus fraternity and sorority life staff, and the national organizations that support them. It argues that mental health can and should be ordinary chapter business, as routine as finances or recruitment, and it describes what that looks like in practice. Why leaders matter most Student mental health has become one of the central concerns of American higher education. The Healthy Minds Study, which surveys students across the country every year, has found encouraging trends recently. In its 2024–2025 report, based on more than 84,000 students at 135 institutions, 37 percent of students screened positive for moderate to severe depression, down from 44 percent in 2022; 32 percent screened positive for moderate to severe anxiety, down from 37 percent; and 11 percent reported suicidal ideation in the past year, down from 15 percent. About 37 percent of students had received therapy or counseling in the past year, and among students with symptoms of depression or anxiety, 60 percent had received some form of treatment. These numbers describe improvement, and they also describe a large population of students who are struggling at any given moment. In a chapter of one hundred members, the Healthy Minds figures suggest that dozens may be experiencing significant symptoms of depression or anxiety, and several may have had thoughts of suicide in the past year. They are in the chapter meeting. They are at the formal. They are in the group chat. Some of them are officers. Chapter 1 described the Jed Foundation's 2024 report on fraternities and mental health. Its findings are a useful guide for leaders because they point both to strengths and to gaps. Fraternity members, on average, reported lower rates of depression, anxiety, and suicidal ideation than non-members, which suggests that the belonging chapters provide is genuinely protective. But fraternity members were also no more likely to use therapy than non-members, despite greater awareness of campus services, and the report identified shame, secrecy, and norms that equate struggle with weakness as barriers to help-seeking. Sorority members were more likely than non-members to use therapy, a difference that suggests the barriers are cultural and changeable rather than inherent to chapter life. Leaders matter because they shape those norms more than anyone else. Members take their cues about what is acceptable from the people at the front of the room. A president who mentions in a chapter meeting that she sees a counselor, or a fraternity president who tells the new-member class that he went through a hard semester and got help, does more to reduce stigma than any poster in the house. Leaders also control the practical conditions described throughout this book, including the calendar, the new-member program, the risk-management procedures, and the response to crises. When they treat these as mental health decisions, the chapter's culture follows. What a mentally healthy chapter does The Jed Foundation report offers eight recommendations for fraternities, and they apply equally well to sororities and to culturally based organizations. They are to make mental health a priority and set up systems for assessment and tracking; to affirm and build on what is already working; to address clear challenges to mental health, especially substance misuse, hazing, and exploitative sexual norms; to reduce shame and secrecy around help-seeking; to enhance self-awareness, capacity for vulnerability, and opportunities for self-care; to conduct regular screenings to identify students at risk; to develop and follow crisis-management procedures; and to make it easy to access resources. Translated into chapter practice, several concrete steps follow. Define the wellness role carefully. Many chapters now have a wellness or mental health chair. This is a valuable position, but it can easily become an informal counselor role, with one student absorbing the crises of dozens of others. The role works best when it is defined as a connector and organizer rather than a caregiver. The wellness chair's job is to know the resources, bring in trainers and speakers, make sure the chapter's crisis procedures are current, advocate for sleep-protecting and stress-reducing changes to the calendar, and help members find professional help. It is not to be the person everyone calls at 2 a.m. The chair should have backup, including another officer and the chapter advisor, and should know that they can hand off any situation that is beyond their capacity. Train more than one person. Programs such as Mental Health First Aid and QPR (Question, Persuade, Refer) teach laypeople how to recognize signs that someone is struggling, how to start a conversation, and how to connect them with help. Many campus counseling centers offer these trainings for free to student organizations. A chapter in which a dozen members have completed such training is far more resilient than one that relies on a single wellness chair. Some national organizations require or subsidize this training for officers. Make access easy. Barriers to help are often mundane: not knowing where the counseling center is, not knowing how to make an appointment, not knowing whether it costs money, fearing that someone will see you walk in. A chapter can lower these barriers by putting the counseling center's phone number, crisis line, and hours in the chapter's shared documents and in the house, inviting a counselor to speak at a chapter meeting so that members meet a real person, organizing a group visit to the center, and normalizing talk about appointments. The simplest version is a single page, posted where every member will see it, listing the resources in Table 5. Table 5. Where chapter members can turn for help. Resource What it offers How to reach it 988 Suicide and Crisis Lifeline 24/7 crisis support by phone, text, or chat Call or text 988 (US) Crisis Text Line 24/7 text-based crisis support Text HOME to 741741 (US) Campus counseling center Counseling, crisis appointments, after-hours line Campus health or counseling website Fraternity and sorority life office Advising, hazing reports, chapter support Campus student affairs website National organization headquarters Health and safety staff, anonymous reporting Organization's website Emergency services Medical, safety, and overdose emergencies Call 911 Build a crisis protocol and practice it. Chapters should have a written procedure for the most serious situations: a medical emergency at an event, a member who expresses suicidal intent, a sexual assault report, a hazing allegation, and the death of a member. The procedure should specify who calls whom, which campus offices and advisors are notified, and how the chapter communicates with members. It should be reviewed with every new set of officers. The death of a member, whether by suicide, accident, or illness, is among the most difficult events a chapter can face, and campus counseling centers and national organizations can help chapters respond in ways that support grieving members and reduce the risk to others. Organizations such as the American Foundation for Suicide Prevention and the Jed Foundation have published guidance on responding after a suicide in a school or campus community. Check in regularly. Screening in the Jed Foundation's sense can be as simple as encouraging members to use campus or online self-assessment tools, and as structured as brief wellbeing check-ins built into big-little relationships or small-group "families" within the chapter. The goal is that no member's struggles go unnoticed for months. Protect academic life. Academic stress is among the most common triggers for mental health difficulties. Chapters that maintain study support, protect exam periods, and treat a member's academic difficulty as a problem to be solved together rather than a standards violation to be punished tend to see better outcomes on both fronts. Where chapters have minimum grade requirements, which many do, the response to a member who falls below them can be supportive before it is disciplinary. Changing a culture without breaking the chapter Many chapter leaders reading this will recognize the gap between the chapter described above and their own. The question is how to close it. Culture change is slow, and it faces particular obstacles in fraternity and sorority life: one-year officer terms, deep attachment to tradition, older members and alumni who remember things differently, and the ever-present fear that changing too much will make the chapter less attractive in recruitment. Several principles help. Start with the chapter's own values. Nearly every fraternity and sorority has a ritual, creed, or founding statement that speaks of care for members, honor, integrity, scholarship, and service. Change framed as a return to those values is far more persuasive than change framed as compliance with outside rules. "Our creed says we will care for each other. Is this how we care for each other?" is a question few members can easily dismiss. Find allies before you need them. Because private discomfort with harmful practices is usually more common than it appears, a leader who talks privately with several respected members before proposing a change often finds support that was invisible in chapter meetings. Change proposed by a group is harder to dismiss than change proposed by one person. Replace rather than just remove. Traditions persist because they meet real needs: marking transitions, building bonds, creating stories. A chapter that simply bans a tradition leaves a void that is often filled by an underground version. A chapter that replaces a hazing ritual with a meaningful alternative, such as a demanding service project, a retreat built around the chapter's history, or a mentoring program that pairs new members with alumni, meets the same needs without the harm. Work with alumni rather than around them. Alumni often have enormous influence, and some resist changes to practices they remember fondly. Many more are supportive when asked, particularly those who are now parents. Chapters can involve alumni advisors early, explain the reasons for changes, and invite alumni to take part in new traditions. The Stop Campus Hazing Act's transparency requirements, which make hazing violations part of the public record, have given many alumni a new reason to support prevention. Write it down. The single biggest threat to culture change in chapters is officer turnover. A president who transforms the chapter's approach to mental health may see the changes erode within two years if they live only in her leadership. Changes that are written into bylaws, officer handbooks, the new-member curriculum, event-planning procedures, and the chapter's annual calendar are much more likely to survive. So are changes that the new-member class experiences as normal from their first day, because they will teach them to the classes after them. Use outside help. Campus fraternity and sorority life offices can provide training, facilitation, and data. National organizations increasingly employ health and safety staff, provide online training, and operate anonymous reporting systems. Umbrella organizations, including the North American Interfraternity Conference, the National Panhellenic Conference, the National Pan-Hellenic Council, and councils for culturally based organizations, publish standards and resources. Independent organizations offer specialized support: the Jed Foundation on mental health, the Gordie Center on alcohol and hazing, StopHazing and the Hazing Prevention Network on hazing prevention, and many campus-based programs on bystander intervention. Under the Stop Campus Hazing Act, every college must now run research-informed, campus-wide hazing prevention programs, so chapters that want help with prevention should find campuses more ready to provide it than before. An illustrative example shows how these principles fit together. Imagine a fraternity chapter of about sixty members whose new-member period has long ended with a week of late nights, early wake-ups, and a final night of heavy drinking, which older members describe as the thing that "made us brothers." A newly elected president, who privately hated that week when he went through it, spends his first month talking one-on-one with a dozen respected members. He finds that most of them have mixed feelings, and several share his view but assumed they were alone. With three of them, he drafts a proposal: the final week will be replaced with a weekend retreat at a campsite, led by two alumni advisors, built around the chapter's founding story and ritual, with a demanding day of service at a local food bank and an evening in which each older member tells the new members, sincerely, what the chapter has meant to him. The proposal is introduced at a chapter meeting not as a ban but as a return to the chapter's creed. There is pushback, some of it heated, and a few alumni call the president to complain. But the proposal passes, the retreat happens, and the new members describe it afterward as the moment they felt most connected to the chapter. The president writes the retreat into the chapter's new-member manual and the officer handbook. Two years later, most members of the chapter have never experienced anything else, and the old week has become a story that older alumni tell. Nothing in that example is guaranteed. Some chapters resist change more fiercely, and some changes fail. But the pattern of private conversations, allies, a replacement rather than a ban, grounding in the chapter's own values, involvement of alumni, and written institutionalization is the pattern that prevention researchers and experienced campus staff describe again and again when change succeeds. The role of advisors, staff, and parents Students lead chapters, but they do not do it alone, and the adults around them have responsibilities that are easy to underestimate. Chapter advisors and alumni volunteers have continuity that students lack. They can carry lessons from one set of officers to the next, remind a new president of the chapter's crisis protocol, and notice when a practice that was stopped has quietly resumed. They are also, as the hazing research showed, sometimes present when harm occurs; an advisor who treats hazing or heavy drinking as harmless tradition gives it cover. Advisors who make clear that they expect members to call for help, protect sleep, and treat new members with respect are among the most powerful allies a reforming chapter can have. Campus fraternity and sorority life staff operate at the level of the whole community. The Hazing Prevention Framework developed by Allan and her colleagues describes what effective campus prevention requires, from sustained leadership commitment and adequate staffing to assessment, planning, and evaluation. Staff can use data from campus surveys to show chapters how their members' actual attitudes compare with perceived norms, which is one of the most effective tools for shifting behavior. They can also make sure that the medical amnesty policy is well known and consistently applied, because a policy that students doubt will not change what they do. Parents occupy a quieter but important position. They cannot and should not manage their student's chapter life, but they can ask good questions. How much time is the chapter taking? Are you sleeping? What does the new-member period involve? Do you know what to do if someone at a party needs help? Is there anything happening that you would not want me to know about? That last question, asked calmly and without an immediate threat of consequences, gives a student permission to talk. Parents can also model the attitude toward help-seeking that this book argues for: a student who knows that a parent will respond to "I'm struggling" with support rather than alarm or disappointment is much more likely to say it. None of this requires any single person to be heroic. It requires many people, students and adults, to make small decisions consistently in the same direction: a meeting that ends on time, a counselor invited to speak, a new-member program with nothing after 10 p.m., a sober monitor who knows she has the authority to call, a president who says out loud that she sees a therapist. Over a few years, those decisions add up to a different chapter. Conclusion Go back through the situations this book has described and a pattern appears. The potential new member deciding whether to ask a chapter how many hours its new-member program really takes. The new member standing at a 6 a.m. workout that only new members attend. The first-year handed a fourth drink. The sober monitor kneeling beside a guest who will not wake up, while two older members warn about probation. The sophomore muting the group chat at 11 p.m. The member telling a friend in crisis that she wants to help and that the friend deserves more help than she can give. The junior at the planning meeting asking, "What is this tradition actually for?" The president telling the chapter that he sees a therapist. Each of these is a moment in which someone either declines something or asks for something, and each carries a price. Sometimes the price is trivial: a shrug, a few seconds of awkwardness. Sometimes it is high: a friendship strained, a chapter sanctioned, a status lost. What the chapters of this book suggest, taken together, is that the size of that price is the single most revealing fact about a chapter's health. The cost of no Here, then, is a test that any member, officer, advisor, or parent can apply to any chapter: How much does it cost a member to say no? To say no to a drink. To say no to an event on a school night. To say no to a new-member activity that feels wrong. To say no to a leadership role in a hard semester. To say no to keeping a dangerous situation inside the chapter, which means calling 911. To say no to the idea that struggling is weakness, which means saying "I'm not okay." In a chapter where these refusals are cheap, where declining a drink draws no comment, where leaving early is unremarkable, where calling for help is praised, where officers talk openly about their own sleep and their own counseling, members are protected from most of the harms this book has described. Hazing cannot take hold where new members can decline without consequence and older members can object without being shunned. Alcohol emergencies end in phone calls rather than funerals where calling is expected. Sleep survives where the calendar is designed by people who assume members have lives. Mental health struggles are caught early where saying so carries no shame. In a chapter where these refusals are expensive, the opposite holds, and it holds no matter how many policies are on paper, how many trainings members have completed, or how sincerely the chapter's creed speaks of care. A new member who fears that declining will cost her the bid will endure things she should not. A member who fears that calling 911 will destroy the chapter will hesitate. A president who fears that admitting exhaustion will look like weakness will keep going until something breaks. This test is useful because it cuts through the argument about whether Greek life is good or bad. That argument has no general answer, as Chapter 1 showed, because the same qualities produce both belonging and harm. The cost of no is specific. It can be observed, asked about, and changed. It explains why two chapters of the same organization on neighboring campuses can be so different. And it points directly to what needs to change. Why a cheap no makes a stronger yes There is an objection that chapter members sometimes raise, and it deserves an answer. If saying no becomes too easy, won't commitment collapse? Won't members skip everything, drink with no one, and treat the chapter as a club they drop into when convenient? Isn't some cost to declining what makes membership mean something? The answer, drawn from everything in the preceding chapters, is that this gets the relationship backward. A yes that is extracted under pressure is not commitment. It is compliance, and compliance is brittle. Members who stay because leaving is too costly, who attend because missing is punished, who drink because refusing is mocked, are not bound to the chapter by loyalty. They are held by fear, and fear produces the resentment, burnout, secrecy, and sudden departures that chapters often puzzle over. A yes that is freely given is different. When a member who could easily decline chooses to show up at the 8 a.m. philanthropy event, it means something. When a new member who knows he could walk away chooses to stay, his commitment is real. When a chapter's traditions are ones that members would choose even if they could opt out, those traditions have earned their place. The research on hazing found that hazing does not reliably build the cohesion its defenders claim. The belonging that lasts is the kind people choose. This is also why the chapter's strengths, its loyalty, its identity, its traditions, are not the enemy of wellness. They are its best resource. Loyalty can mean "we don't let anyone leave" or "we always come for each other." Identity can mean "we're the hardest-partying house" or "we're the chapter that looks out for its people." Tradition can mean "we did it to them because it was done to us" or "we pass on what matters." The chapters that change are rarely the ones that abandon their identity. They are the ones that redefine it. What the law can do and what it cannot The Stop Campus Hazing Act marks a real shift. For the first time, colleges across the country must count hazing incidents, publish the names of organizations found responsible, and run research-informed prevention programs. The first annual security reports including hazing statistics arrive this fall. Families choosing a chapter can see a public record. Chapters now have one more reason, grounded in reputation, to take prevention seriously. But the law operates at the level of institutions and records, and the cost of no is set in rooms. No statute can decide whether the older member shrugs or sneers when a first-year turns down a drink. No transparency report can decide whether the president answers messages at 3 a.m. No policy can make a sober monitor believe that her chapter will stand behind her. Those things are decided by students, one moment at a time, and by the advisors, staff, and parents who shape what students believe is normal. That is why this book has spent so much of its length on ordinary weeks and small decisions. The dramatic cases, the deaths that give laws their names, are the visible end of a long chain. Their beginnings lie in things like a new-member schedule with no end times, a group chat that never goes quiet, a comment that no one challenged, a tradition that everyone privately doubted and no one questioned aloud. A chapter worth belonging to Return, finally, to the sophomore on the floor of her chapter house at 11:40 on a Tuesday night, with a problem set due in the morning and a big sister texting about movie night. What she needs is not a lecture on time management. She needs to believe that she can text back, "I'm going to bed, see you Thursday," and that her big will reply with a heart and nothing more. She needs a chapter meeting that ended at 9:30 instead of 10:30. She needs to know that if the flatness in the mornings continues, she can mention it to a friend in the chapter and be walked to the counseling center rather than told everyone feels that way. Every one of those things is within the power of the people around her. None of them requires the chapter to be less ambitious, less fun, or less close. They require only that the chapter decide, deliberately and repeatedly, that its members' ability to say no is something to protect rather than something to overcome. A chapter that makes that decision is not a weaker version of Greek life. It is the version that delivers on what fraternities and sororities have always promised: a group of people who will look after you, who expect the best of you, and who will still be there when you need them. That promise is worth keeping. Keeping it starts with making no an easy word to say. Notes Introduction 1. Elizabeth J. Allan and Mary Madden, Hazing in View: College Students at Risk. Initial Findings from the National Study of Student Hazing (2008). https://stophazing.org/research/national-hazing-study-hazing-in-view/ 1. Stop Campus Hazing Act, Public Law 118-173, signed December 23, 2024. Summary: Clery Center, "The Stop Campus Hazing Act: What You Need to Know." https://www.clerycenter.org/scha-what-you-need-to-know 2. 988 Suicide and Crisis Lifeline. https://988lifeline.org/ Chapter 1: What Belonging Gives and What It Can Cost 1. Roy F. Baumeister and Mark R. Leary, "The Need to Belong: Desire for Interpersonal Attachments as a Fundamental Human Motivation," Psychological Bulletin 117, no. 3 (1995): 497–529. 2. Healthy Minds Network, The Healthy Minds Study: 2024–2025 Data Report (2025); summary figures from University of Michigan School of Public Health, "Healthy Minds Study: College Student Depression, Anxiety Decline for Third Consecutive Year" (2025). https://sph.umich.edu/news/2025posts/college-student-mental-health-third-consecutive-year-improvement.html 3. Gallup, Fraternities and Sororities: Understanding Life Outcomes (2014); summary at https://news.gallup.com/opinion/gallup/173630/fraternity-sorority-membership-linked-higher-college-grads.aspx 4. The Jed Foundation, Fraternities and Mental Health: Supporting Emotional Well-Being (December 2024). https://jedfoundation.org/wp-content/uploads/2024/12/Fraternities-and-Mental-Health-ReportFinalDec-3-2024.pdf 5. Postsecondary Education Research Center, University of Tennessee, Knoxville, 2020 Mental Health Study (Foundation for Fraternal Excellence research grant report, 2021); summary at https://nicfraternity.org/fraternity-members-report-higher-levels-of-positive-mental-health-and-support/ 6. National Institute on Alcohol Abuse and Alcoholism, "College Drinking: Prevalence," citing the 2023 National Survey on Drug Use and Health. https://www.collegedrinkingprevention.gov/statistics/prevalence 7. Sean Esteban McCabe, Philip Veliz, and John E. Schulenberg, "How Collegiate Fraternity and Sorority Involvement Relates to Substance Use During Young Adulthood and Substance Use Disorders in Early Midlife: A National Longitudinal Study," Journal of Adolescent Health 62, no. 3 (2018): S35–S43. 8. Sean Esteban McCabe et al., "Selection and Socialization Effects of Fraternities and Sororities on US College Student Substance Use: A Multi-Cohort National Longitudinal Study," Addiction 100, no. 4 (2005): 512–524. 9. H. Wesley Perkins and Alan D. Berkowitz, "Perceiving the Community Norms of Alcohol Use Among Students: Some Research Implications for Campus Alcohol Education Programming," International Journal of the Addictions 21, nos. 9–10 (1986): 961–976. 10. Deborah A. Prentice and Dale T. Miller, "Pluralistic Ignorance and Alcohol Use on Campus: Some Consequences of Misperceiving the Social Norm," Journal of Personality and Social Psychology 64, no. 2 (1993): 243–256. Chapter 2: Recruitment, Intake, and the New-Member Months 1. Naomi I. Eisenberger, Matthew D. Lieberman, and Kipling D. Williams, "Does Rejection Hurt? An fMRI Study of Social Exclusion," Science 302, no. 5643 (2003): 290–292. 2. On the hazing findings referred to in this chapter, see note 1. Chapter 3: Hazing, Named Plainly 1. On the death of Timothy Piazza and Pennsylvania's 2018 anti-hazing law: "'Why Didn't You Call for Help?' Parents of Timothy Piazza, Penn State Community Grapple with Loss 5 Years Later," The Daily Collegian (2022). 2. Federal definition of hazing under the Stop Campus Hazing Act, as reproduced by the University of Florida, "Federal and State Definitions." https://stophazing.ufl.edu/what-is-hazing/federal-and-state-definitions/ ; and Kettering University, "Stop Campus Hazing Act." https://www.kettering.edu/stop-campus-hazing-act 3. Implementation dates: Clery Center (note 2); StopHazing, "Federal Anti-Hazing Law: Stop Campus Hazing Act." https://stophazing.org/policy/stop-campus-hazing-act/ 4. Allan and Madden, Hazing in View (note 1). Full report: https://stophazing.org/wp-content/uploads/2014/06/hazinginview_web1.pdf 5. Elizabeth J. Allan, Jessica M. Payne, and David Kerschner, "Transforming the Culture of Hazing: A Research-Based Hazing Prevention Framework," Journal of Student Affairs Research and Practice 55, no. 4 (2018): 412–425. 6. Elizabeth J. Allan, David Kerschner, and Jessica M. Payne, "College Student Hazing Experiences, Attitudes, and Perceptions: Implications for Prevention," Journal of Student Affairs Research and Practice 56, no. 1 (2019): 32–48. 7. Elliot Aronson and Judson Mills, "The Effect of Severity of Initiation on Liking for a Group," Journal of Abnormal and Social Psychology 59, no. 2 (1959): 177–181. 8. Aldo Cimino, "The Evolution of Hazing: Motivational Mechanisms and the Abuse of Newcomers," Journal of Cognition and Culture 11 (2011): 241–267. 9. StopHazing, "Hazing Prevention Framework." https://stophazing.org/resources/hazing-prevention-framework/ Chapter 4: Alcohol, Emergencies, and the Call That Matters 1. National Institute on Alcohol Abuse and Alcoholism, "College Drinking: Prevalence" (note 9) and "College Drinking: Consequences." https://www.collegedrinkingprevention.gov/statistics/consequences 2. North American Interfraternity Conference, "NIC Fraternities Ban Hard Alcohol in Decisive Action" (2018). https://nicfraternity.org/nic-fraternities-vote-to-ban-hard-alcohol/ 3. National Institute on Alcohol Abuse and Alcoholism, "Understanding the Dangers of Alcohol Overdose." https://www.niaaa.nih.gov/publications/brochures-and-fact-sheets/understanding-dangers-of-alcohol-overdose 4. The Gordie Center, University of Virginia, "Medical Amnesty," including the Cornell survey findings on calling for help, the number of states with medical amnesty laws as of 2022, and the 2018 evaluation of a medical amnesty policy change. https://gordie.studenthealth.virginia.edu/learn/medical-amnesty 5. Deborah K. Lewis and Timothy C. Marchell, "Safety First: A Medical Amnesty Approach to Alcohol Poisoning at a U.S. University," International Journal of Drug Policy 17, no. 4 (2006): 329–338. Chapter 5: Sleep and the Chapter Calendar 1. Nathaniel F. Watson et al., "Recommended Amount of Sleep for a Healthy Adult: A Joint Consensus Statement of the American Academy of Sleep Medicine and Sleep Research Society," Journal of Clinical Sleep Medicine 11, no. 6 (2015): 591–592. 2. Shelley D. Hershner and Ronald D. Chervin, "Causes and Consequences of Sleepiness Among College Students," Nature and Science of Sleep 6 (2014): 73–84. 3. American Academy of Sleep Medicine, "Insufficient Sleep Linked to Mental Health in College Students" (2019), reporting an abstract presented at SLEEP 2019 by Thea Ramsey, Michael Grandner, and colleagues. https://aasm.org/insufficient-sleep-college-student-athletes/ Chapter 6: Boundaries and the Art of Saying No 1. Peter M. Gollwitzer and Paschal Sheeran, "Implementation Intentions and Goal Achievement: A Meta-Analysis of Effects and Processes," Advances in Experimental Social Psychology 38 (2006): 69–119. 2. Thomas Gilovich, Victoria Husted Medvec, and Kenneth Savitsky, "The Spotlight Effect in Social Judgment: An Egocentric Bias in Estimates of the Salience of One's Own Actions and Appearance," Journal of Personality and Social Psychology 78, no. 2 (2000): 211–222. 3. Francis J. Flynn and Vanessa K. B. Lake (Bohns), "If You Need Help, Just Ask: Underestimating Compliance with Direct Requests for Help," Journal of Personality and Social Psychology 95, no. 1 (2008): 128–143; see also Vanessa K. Bohns, You Have More Influence Than You Think (W. W. Norton, 2021). Chapter 7: Stepping In When It Is Your Own Chapter 1. Bibb Latané and John M. Darley, "Group Inhibition of Bystander Intervention in Emergencies," Journal of Personality and Social Psychology 10, no. 3 (1968): 215–221; and The Unresponsive Bystander: Why Doesn't He Help? (Appleton-Century-Crofts, 1970). 2. Richard Philpot, Lasse Suonperä Liebst, Mark Levine, Wim Bernasco, and Marie Rosenkrantz Lindegaard, "Would I Be Helped? Cross-National CCTV Footage Shows That Intervention Is the Norm in Public Conflicts," American Psychologist 75, no. 1 (2020): 66–75. 3. Mark Levine, Amy Prosser, David Evans, and Stephen Reicher, "Identity and Emergency Intervention: How Social Group Membership and Inclusiveness of Group Boundaries Shape Helping Behavior," Personality and Social Psychology Bulletin 31, no. 4 (2005): 443–453. 4. Step UP! bystander intervention program. https://stepupprogram.org/ Chapter 8: Leading a Chapter Toward Mental Health 1. Healthy Minds Study 2024–2025 figures (note 5). 2. The Jed Foundation, Fraternities and Mental Health (note 7), for the findings on help-seeking and the eight recommendations. 3. Crisis Text Line. https://www.crisistextline.org/ 4. On campus prevention requirements under the Stop Campus Hazing Act, see notes 2 and 18; on the Hazing Prevention Framework, see notes 20 and 24. Conclusion 1. On the reporting timeline for hazing statistics in annual security reports, see note 2. Further Reading Elizabeth J. Allan and Mary Madden, Hazing in View: College Students at Risk (2008).** The foundational national study of college hazing, freely available from StopHazing. Short, readable, and essential for anyone who wants to understand how common hazing is and why it goes unrecognized. StopHazing (stophazing.org). The research and training organization founded by Elizabeth Allan. Its site includes the Hazing Prevention Framework, plain-language explainers on the Stop Campus Hazing Act, and resources for students, parents, and campus professionals. Hank Nuwer, Hazing: Destroying Young Lives (Indiana University Press, 2018).** An edited volume by the journalist who has documented hazing deaths for decades, bringing together researchers and practitioners on hazing in fraternities, sororities, athletics, the military, and beyond. Walter M. Kimbrough, Black Greek 101: The Culture, Customs, and Challenges of Black Fraternities and Sororities (Fairleigh Dickinson University Press, 2003).** A clear introduction to the history and culture of historically Black Greek-letter organizations, including an honest treatment of the move from pledging to membership intake and the persistence of underground hazing. The Jed Foundation, Fraternities and Mental Health: Supporting Emotional Well-Being (2024).** A research-based report with practical recommendations for chapters, national organizations, and campuses. Useful for any officer building a wellness program. The Gordie Center, University of Virginia (gordie.studenthealth.virginia.edu). Free materials on recognizing alcohol poisoning, medical amnesty laws by state, and hazing prevention, created in memory of Gordie Bailey. National Institute on Alcohol Abuse and Alcoholism, College Drinking Prevention (collegedrinkingprevention.gov). Reliable statistics on college drinking, guidance for parents, and CollegeAIM, a guide that rates campus alcohol interventions by evidence. Matthew Walker, Why We Sleep (Scribner, 2017).** A popular account of sleep science by a neuroscientist. Some of its claims have been criticized as overstated, so read it alongside more cautious sources, but it conveys vividly why sleep matters for learning and emotion. Vanessa K. Bohns, You Have More Influence Than You Think (W. W. Norton, 2021).** A social psychologist's accessible account of how people underestimate their influence on others and how hard it is for others to say no, with direct relevance to boundaries and peer pressure. 988 Suicide and Crisis Lifeline (988lifeline.org) and the American Foundation for Suicide Prevention (afsp.org). Crisis support available by call or text at 988 in the United States, and educational materials on recognizing warning signs and supporting someone at risk. Hashtags: #GreekLifeWellness #FraternityAndSororityLife #GreekLifeBalance #CollegeStudentWellness #StudentMentalHealth #CampusMentalHealth #SleepHealth #HealthySleepHabits #SleepDeprivation #TimeManagement #ChapterObligations #AcademicLifeBalance #StudentWellbeing #MentalHealthAwareness #CollegeStressManagement #BurnoutPrevention #HealthyBoundaries #PeerPressure #StudentSelfCare #FraternityWellness #SororityWellness #ChapterLeadership #CampusSafety #HazingPrevention #AlcoholSafety #BystanderIntervention #StudentBelonging #SupportiveCommunities #MentalHealthSupport #HealthyCampusCulture